Received: by above.proper.com (8.11.6/8.11.3) id g0RL1KD06048 for ietf-imapext-bks; Sun, 27 Jan 2002 13:01:20 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0RL1J306044 for ; Sun, 27 Jan 2002 13:01:19 -0800 (PST) Received: from messagingdirect.com (188.207-34-100-0.interbaun.com [207.34.100.188]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g0RL1Dj04143; Sun, 27 Jan 2002 14:01:13 -0700 Message-ID: <3C546A97.3000B7BF@messagingdirect.com> Date: Sun, 27 Jan 2002 14:01:11 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> <3C53BD68.D61D7D24@messagingdirect.com> <20020127142609.G6102@melkebalanse.gulbrandsen.priv.no> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov > > I am not sure how you can define sort extension without referring to a > > capability. > > In the usual way: by referring to the extensions's draft/rfc :) > > > One can mention both SORT and future SORT2? > > The SORT draft I see in my mirror says: > > A server which supports this extension indicates this with a > capability name of "SORT". Client implementations SHOULD accept any > capability name which begins with "SORT" as indicating support for > the extension described in this document. This provides for future > upwards-compatible extensions. > > I think referring to the SORT extension (and listing > draft-ietf-imapext-sort-xx in the Refences section) is better than > referring to either "the capability SORT" or "any capability whose name > starts with SORT". I think if you want to use "a sort extension in a sense defined in draft-ietf-imapext-sort-xx" that is fine with me. > > I think the default behavior should be to send FLAG updates for all flags that can be mapped to > > annotations and send annotations for the rest (e.g. if the server implements \Draft as a shared > > flag, than a change to > > /message/flags/flagged value.shared is reported as FETCH FLAGS, but a change to > > /message/flags/flagged value.priv is returned as annotation). > > Makes sense to me, but then, why provide these flags as annotations? During last IETF meeting people in the meeting room agreed to map IMAP flags to annotations. There are several reasons: 1). Annotations are more flexible, because if a server supports both a shared and a private version of a flag, it can expose only one of the two through IMAP flags and both through ANNOTATE extension. 2). This works nicely with CONDSTORE extension, because the same syntax can be used to reference both annotations and flags. Alexey Melnikov __________________________________________ R & D, ACI Worldwide (formerly MessagingDirect Ltd.) phone 780.424.4922 x357 I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g0RDOm522730 for ietf-imapext-bks; Sun, 27 Jan 2002 05:24:48 -0800 (PST) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0RDOl322726 for ; Sun, 27 Jan 2002 05:24:47 -0800 (PST) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g0RDQAj07399; Sun, 27 Jan 2002 14:26:10 +0100 Date: Sun, 27 Jan 2002 14:26:09 +0100 From: Arnt Gulbrandsen To: Alexey Melnikov Cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020127142609.G6102@melkebalanse.gulbrandsen.priv.no> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> <3C53BD68.D61D7D24@messagingdirect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C53BD68.D61D7D24@messagingdirect.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov > I am not sure how you can define sort extension without referring to a > capability. In the usual way: by referring to the extensions's draft/rfc :) > One can mention both SORT and future SORT2? The SORT draft I see in my mirror says: A server which supports this extension indicates this with a capability name of "SORT". Client implementations SHOULD accept any capability name which begins with "SORT" as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. I think referring to the SORT extension (and listing draft-ietf-imapext-sort-xx in the Refences section) is better than referring to either "the capability SORT" or "any capability whose name starts with SORT". > I think the default behavior should be to send FLAG updates for all flags that can be mapped to > annotations and send annotations for the rest (e.g. if the server implements \Draft as a shared > flag, than a change to > /message/flags/flagged value.shared is reported as FETCH FLAGS, but a change to > /message/flags/flagged value.priv is returned as annotation). Makes sense to me, but then, why provide these flags as annotations? --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0R8gaA25539 for ietf-imapext-bks; Sun, 27 Jan 2002 00:42:36 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0R8gY325531 for ; Sun, 27 Jan 2002 00:42:34 -0800 (PST) Received: from messagingdirect.com (073.207-34-100-0.interbaun.com [207.34.100.73]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g0R8gEj01917; Sun, 27 Jan 2002 01:42:15 -0700 Message-ID: <3C53BD68.D61D7D24@messagingdirect.com> Date: Sun, 27 Jan 2002 01:42:16 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > > >5. In 8.6, there's a reference to "SORT". I think it would be better > > > to rewrite that to take account of SORT2 etc. > > > > > > The ANNOTATION criterion is available if the server supports both > > > the ANNOTATE and SORT extensions. > > > > I think the current SORT will remain as is but we will add generalise i18n > > stuff to it. This is still an open question. > > I'm afraid I expressed myself badly. The issue isn't with SORT, it's with > the wording - I think you should refer to presence of the sort extension > rather than to the string "SORT" in the CAPABILITY list. I am not sure how you can define sort extension without referring to a capability. One can mention both SORT and future SORT2? > > >6. Message responsibility in shared mailboxes has to be a fairly > > > common use for this, or am I wrong? The draft does not specify any > > > annotation for it. > > > > Should we add: > > > > /message/owner > > > > as annotation? If so what should the value be - a user id or a name or an > > arbitraty string? > > For a shared mailbox, there is a set of users that can be responsible for > answering mail in that mailbox. That set presumably corresponds to a set > of user ids, which in turn is a subset of the set of users. > > Which leads to the following alternatives: > > - Arbitrary string. Low cost to the draft, high cost to the user agents, > who'll have to make an enum out of that. > - User ID. High cost to the draft and servers, since there'll be a > fundamentally new datatype. Leaves open quesions about the subset of > users that are valid for any particular mailbox. > - Enum. High cost to the draft and servers, lowish cost to supporting > user agents. > > The first can be added at any time. Currently there is no IMAP extensions that allows to list user IDs. > > >11. One last pedantic excursion: If someone else changes a flag and > > > I've fetched some annotations, I suppose I'm going to receive an > > > unsolicited FETCH response with both FLAGS and ANNOTATION versions > > > of the same information. Is that intentional? > > > > Yes. This is still an issue with -03, though we do give clients the choice > > of turning on or off the unsolicted ANNOTATATION responses. Given that, > > should we add some more select parameters to control this? We could have: > > > > NOFLAGSRESPONSES - turns off unsolicted FLAGS responses > > NOANNOTATEFLAGSRESPONSES - turns off unsolicted ANNOATATION responses > > for standard IMAP flags > > > > This would allow clients to fine tune the response behaviour based on > > whether they want to primarily uses FLAGS or ANNOTATIONs for dealing with > > IMAP flags. Any comments on this? > > I shudder :) Just mandating one behaviour or the other seems so much > simpler. I think the default behavior should be to send FLAG updates for all flags that can be mapped to annotations and send annotations for the rest (e.g. if the server implements \Draft as a shared flag, than a change to /message/flags/flagged value.shared is reported as FETCH FLAGS, but a change to /message/flags/flagged value.priv is returned as annotation). IMHO, having a parameter to SELECT/EXAMINE to control the behavior seems like a good idea. Also I think that the description of generic SELECT/EXAMINE extensibility should be moved to a separate document. === Other comments: > /message/flags/answered > /message/flags/flagged > /message/flags/deleted > /message/flags/seen > /message/flags/draft > /message/flags/recent > These correspond to the standard IMAP flags. I think you should add a phrase saying that these annotations map one-to-one to IMAP flags, otherwise it is not clear what "correspond" means. Also recent must be read-only. Or was the omission of being read-only intentional? Alexey Melnikov __________________________________________ R & D, ACI Worldwide (formerly MessagingDirect Ltd.) phone 780.424.4922 x357 I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMJwH12942 for ietf-imapext-bks; Wed, 23 Jan 2002 14:19:58 -0800 (PST) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NMJr312929 for ; Wed, 23 Jan 2002 14:19:53 -0800 (PST) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g0NMM8Q05285; Wed, 23 Jan 2002 23:22:08 +0100 Date: Wed, 23 Jan 2002 23:22:07 +0100 From: Arnt Gulbrandsen To: Cyrus Daboo Cc: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1011783761@socrates.cyrusoft.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo > >2. /message/smtp-envelope seems to work only for mail to me. What > > about mail that I send? When I get a delivery notification, > > wouldn't I want to parse it, find the corresponding message and > > write "delivery succeeded/failed for a@b.com" annotations? > > Good point. Should we add: > > /message/dsn-received > /message/mdn-received > > standard annotations? If so what should their value be? We could define > values based on the standard dsn/mdn response codes, or allow the value to > be the message/rfc822 of the actual response message. The names are more puzzling to me. Assume that all the addresses in this header field are successfully delivered, how could the annotations end up looking in? To: "G=Stakkars/S=Tulling;OU=blah/O=blah/PRMD=tiresome/ADMD=bothersome"@gateway.telenor.no, a@example.org, b@example.org, c@example.org, d@example.org > Some clients may choose to keep an offline cache of annotations, as they d > now for other message data. In such cases they will likely not re-fetch > annotations they already have cached, but will need to be notified of > changes. Yes... however, I can imagine that there will be both - clients that are meant for LAN usage, and use a big /vendor/blah/ tree - clients that are meant for wireless usage, and want to use as little bandwidth as possible There is a conflict there. > >5. In 8.6, there's a reference to "SORT". I think it would be better > > to rewrite that to take account of SORT2 etc. > > > > The ANNOTATION criterion is available if the server supports both > > the ANNOTATE and SORT extensions. > > I think the current SORT will remain as is but we will add generalise i18n > stuff to it. This is still an open question. I'm afraid I expressed myself badly. The issue isn't with SORT, it's with the wording - I think you should refer to presence of the sort extension rather than to the string "SORT" in the CAPABILITY list. > >6. Message responsibility in shared mailboxes has to be a fairly > > common use for this, or am I wrong? The draft does not specify any > > annotation for it. > > Should we add: > > /message/owner > > as annotation? If so what should the value be - a user id or a name or an > arbitraty string? For a shared mailbox, there is a set of users that can be responsible for answering mail in that mailbox. That set presumably corresponds to a set of user ids, which in turn is a subset of the set of users. Which leads to the following alternatives: - Arbitrary string. Low cost to the draft, high cost to the user agents, who'll have to make an enum out of that. - User ID. High cost to the draft and servers, since there'll be a fundamentally new datatype. Leaves open quesions about the subset of users that are valid for any particular mailbox. - Enum. High cost to the draft and servers, lowish cost to supporting user agents. The first can be added at any time. > >7. What happens to annotations if a message is copied to a different > > mailbox? All copied, I suppose, even .shared notifications when a > > message is copied to a private folder? > > Good point. There is no mention of the interaction of ANNOTATE and COPY. I > will add some text about this. It seems to me that shared annotations will > allways be copied, however only private annotations for those users that > have access to the destination mailbox should be copied. Yes. > >8. Is a client permitted to write to e.g /message/smtp-envelope/from ? > > The draft currently allows modifications of these entries but states a > client SHOULD NOT modify them unless the message is marked as a Draft. I > think this is reasonable. Yes. > >10. Or how about a syntactically valid but meaningless one, such as > > /body/2/comment for a single-part message? I'm being overly > > pedantic now, I guess. I'll stop here and brew some tea instead :) > > I will add some text for this specific point to say that servers MUST > return a BAD response for an illegal part-specifier. I've also just noticed > that the base spec allows an empty part-specifier to refer to the whole > message - we need to disallow that in annotate as we already have the > /message entries for that - I will add text for that too. Or, possibly, sanction the empty part-specified and wipe out /message? I've no arguments either way. > >11. One last pedantic excursion: If someone else changes a flag and > > I've fetched some annotations, I suppose I'm going to receive an > > unsolicited FETCH response with both FLAGS and ANNOTATION versions > > of the same information. Is that intentional? > > Yes. This is still an issue with -03, though we do give clients the choice > of turning on or off the unsolicted ANNOTATATION responses. Given that, > should we add some more select parameters to control this? We could have: > > NOFLAGSRESPONSES - turns off unsolicted FLAGS responses > NOANNOTATEFLAGSRESPONSES - turns off unsolicted ANNOATATION responses > for stanard IMAP flags > > This would allow clients to fine tune the response behaviour based on > whether they want to primarily uses FLAGS or ANNOTATIONs for dealing with > IMAP flags. Any comments on this? I shudder :) Just mandating one behaviour or the other seems so much simpler. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NIUSi07988 for ietf-imapext-bks; Wed, 23 Jan 2002 10:30:28 -0800 (PST) Received: from localhost.sendmail.com (natted.Sendmail.COM [63.211.143.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NIUR307983 for ; Wed, 23 Jan 2002 10:30:27 -0800 (PST) Received: (from jutta@localhost) by localhost.sendmail.com (8.11.6/8.11.6) id g0NITvF01679; Wed, 23 Jan 2002 10:29:57 -0800 Date: Wed, 23 Jan 2002 10:29:56 -0800 From: Jutta Degener To: ietf-imapext@imc.org Cc: Arnt Gulbrandsen Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123182956.GA1437@jutta.sendmail.com> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1011783761@socrates.cyrusoft.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 23, 2002 at 11:02:41AM -0500, Cyrus Daboo wrote: > >2. /message/smtp-envelope seems to work only for mail to me. What > > about mail that I send? When I get a delivery notification, > > wouldn't I want to parse it, find the corresponding message and > > write "delivery succeeded/failed for a@b.com" annotations? > > Good point. Should we add: > > /message/dsn-received > /message/mdn-received > > standard annotations? These would have to be per recipient(s), right? So, either /message//dsn-received/ or /message/dsn-received/ -- except that we can't do that because mailbox names are case-sensitive and names of annotations aren't. So maybe it'll be /message/dns-received/ with each value being a list of recipients for which the status is true? Or maybe it's /message/dns-received/ where the name of the recipient is encoded in the stored data, and the indexes ... no, wait, we don't store that. If you want to store sent mail information, how about starting with who it was sent to? (Of course, this creates new security issues, because now you're creating another record of whom you Bcc'ed something to.) Doing all this sounds like a good idea in general, but maybe it's worth waiting for some more client implementations before standardizing on something. I don't see mail clients present DNSes and MDNs much in terms of attributes of their sent messages; that makes it hard to guess what information they tend to need. > >6. Message responsibility in shared mailboxes has to be a fairly > > common use for this, or am I wrong? The draft does not specify any > > annotation for it. > > Should we add: > > /message/owner > > as annotation? If so what should the value be - a user id or a name or an > arbitrary string? Hm. I would wait with this one, too; I don't quite know what it means. "Responsibility" is too application-specific to be of cross-application usefulness, and if a single application wants to talk about the "owner" of its messages, it can use the vendor namespace to do it. --Jutta Received: by above.proper.com (8.11.6/8.11.3) id g0NH2qB05676 for ietf-imapext-bks; Wed, 23 Jan 2002 09:02:52 -0800 (PST) Received: from hera.webcom.com (hera.webcom.com [209.1.28.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NH2p305671 for ; Wed, 23 Jan 2002 09:02:51 -0800 (PST) Received: from eresh (eresh.webcom.com [209.1.28.49]) by hera.webcom.com (8.9.1/8.9.1) with SMTP id JAA12983; Wed, 23 Jan 2002 09:02:53 -0800 Received: from [216.207.178.10] by banana (WebCom SMTP 2.0) with SMTP id 140649387; Wed Jan 23 09:04 PST 2002 Message-Id: <4.3.2.7.2.20020123120224.03a06ed0@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 12:03:34 -0500 To: Cyrus Daboo , ietf-imapext@imc.org From: Pete Maclean Subject: Re: ANNOTATE question In-Reply-To: <2147483647.1011787056@socrates.cyrusoft.com> References: <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <4.3.2.7.2.20020123112607.03a67158@pop.webcom.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: >>I am curious about one thing in ANNOTATE. Since I am reading the draft >>for the first time, it may be that this issue has already been discussed >>and, if so, I apologize. As I understand the extension, there is no way >>to remove an annotation entry. What is the rationale for this? > >The value is defined as an nstring, so storing NIL into all values >(value.shared and value.priv for each users) effectively deletes that >entry. At the top of Section 8.4 it does state that clients can do that, >but I will also add additional text to the description of the value >attribute that says the same. Great! That makes perfect sense...although, even after re-reading 8.4, it does not seem at all clear. Pete Received: by above.proper.com (8.11.6/8.11.3) id g0NGvgW05487 for ietf-imapext-bks; Wed, 23 Jan 2002 08:57:42 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGve305483 for ; Wed, 23 Jan 2002 08:57:41 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA28217; Wed, 23 Jan 2002 11:55:14 -0500 (EST) Date: Wed, 23 Jan 2002 11:57:36 -0500 From: Cyrus Daboo To: Pete Maclean , ietf-imapext@imc.org Subject: Re: ANNOTATE question Message-ID: <2147483647.1011787056@socrates.cyrusoft.com> In-Reply-To: <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, January 23, 2002 11:26 AM -0500 Pete Maclean wrote: > I am curious about one thing in ANNOTATE. Since I am reading the draft > for the first time, it may be that this issue has already been discussed > and, if so, I apologize. As I understand the extension, there is no way > to remove an annotation entry. What is the rationale for this? The value is defined as an nstring, so storing NIL into all values (value.shared and value.priv for each users) effectively deletes that entry. At the top of Section 8.4 it does state that clients can do that, but I will also add additional text to the description of the value attribute that says the same. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g0NGpRi05338 for ietf-imapext-bks; Wed, 23 Jan 2002 08:51:27 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGpP305334 for ; Wed, 23 Jan 2002 08:51:25 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA28178; Wed, 23 Jan 2002 11:48:58 -0500 (EST) Date: Wed, 23 Jan 2002 11:51:20 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen cc: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <2147483647.1011786680@socrates.cyrusoft.com> In-Reply-To: <20020123171435.E19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123164818.C19874@witt-witt.caldera.de> <2147483647.1011783921@socrates.cyrusoft.com> <20020123171435.E19874@witt-witt.caldera.de> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, January 23, 2002 5:14 PM +0100 Arnt Gulbrandsen wrote: > Btw, > shouldn't the new argument to SELECT/EXAMINE be moved to > draft-crispin-imapv? When I was writing the select parameter stuff I did have the feeling that it ought to go in its own document - particularly if more extensions than ANNOTATED and conditional store would likely use it. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g0NGQ2q04732 for ietf-imapext-bks; Wed, 23 Jan 2002 08:26:02 -0800 (PST) Received: from hecate.webcom.com (hecate.webcom.com [209.1.28.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGQ2304728 for ; Wed, 23 Jan 2002 08:26:02 -0800 (PST) Received: from kigal (kigal.webcom.com [209.1.28.57]) by hecate.webcom.com (8.9.1/8.9.1) with SMTP id IAA10119 for ; Wed, 23 Jan 2002 08:25:59 -0800 Received: from [216.207.178.10] by inanna.webcom.com (WebCom SMTP 2.0) with SMTP id 100233327; Wed Jan 23 08:25 PST 2002 Message-Id: <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 11:26:42 -0500 To: ietf-imapext@imc.org From: Pete Maclean Subject: ANNOTATE question In-Reply-To: <2147483647.1011783761@socrates.cyrusoft.com> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> 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: I am curious about one thing in ANNOTATE. Since I am reading the draft for the first time, it may be that this issue has already been discussed and, if so, I apologize. As I understand the extension, there is no way to remove an annotation entry. What is the rationale for this? Thanks, Pete Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NGFEv04405 for ietf-imapext-bks; Wed, 23 Jan 2002 08:15:14 -0800 (PST) Received: from witt-witt.caldera.de (witt-witt.caldera.de [195.143.241.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGFC304400 for ; Wed, 23 Jan 2002 08:15:13 -0800 (PST) Received: (from arnt@localhost) by witt-witt.caldera.de (8.11.6/8.11.6) id g0NGEao30034; Wed, 23 Jan 2002 17:14:36 +0100 Date: Wed, 23 Jan 2002 17:14:35 +0100 From: Arnt Gulbrandsen To: Cyrus Daboo Cc: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123171435.E19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123164818.C19874@witt-witt.caldera.de> <2147483647.1011783921@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1011783921@socrates.cyrusoft.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo > After an EXAMINE the current mailbox IS the EXAMINE mailbox - you can only > have one mailboxes SELECT'ed or EXAMINE'd at a time - so I don't see the > issue here. Sorry, I was confusing EXAMINE with something else. STATUS I think. Btw, shouldn't the new argument to SELECT/EXAMINE be moved to draft-crispin-imapv? I'll reply to the other message later today; need to make some stuff build before I go home and it's late already. --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g0NG5Tu04009 for ietf-imapext-bks; Wed, 23 Jan 2002 08:05:29 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NG5S304003 for ; Wed, 23 Jan 2002 08:05:28 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA27874; Wed, 23 Jan 2002 11:03:00 -0500 (EST) Date: Wed, 23 Jan 2002 11:05:21 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <2147483647.1011783921@socrates.cyrusoft.com> In-Reply-To: <20020123164818.C19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123164818.C19874@witt-witt.caldera.de> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, January 23, 2002 4:48 PM +0100 Arnt Gulbrandsen wrote: > Simultaneously, a -03 was published. So I cast a glance at it. Ah - OK. I just sent my reply to your early message suggestion you checked to see whether you had -02 or -03! I guess we hit a race-condition here! > I wrote: >> 3. The Open Issue in 8.2 can be relaxed slightly: > > I see it was changed differently in -03. Suppose that I say SELECT INBOX > (ANNOTATE), and then EXAMINE a different mailbox without saying ANNOTATE. > In that case, -03 then says that the EXAMINE turns off unsolicited > annotation responses; isn't that a bit weird? Examining a different > mailbox should not have effect on the current mailbox. After an EXAMINE the current mailbox IS the EXAMINE mailbox - you can only have one mailboxes SELECT'ed or EXAMINE'd at a time - so I don't see the issue here. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NG2mk03908 for ietf-imapext-bks; Wed, 23 Jan 2002 08:02:48 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NG2l303903 for ; Wed, 23 Jan 2002 08:02:47 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA27828; Wed, 23 Jan 2002 11:00:19 -0500 (EST) Date: Wed, 23 Jan 2002 11:02:41 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <2147483647.1011783761@socrates.cyrusoft.com> In-Reply-To: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, I think your comments below refer to the -02 draft rather than the new -03 draft. Can you double-check what version you have. --On Wednesday, January 23, 2002 4:20 PM +0100 Arnt Gulbrandsen wrote: > > Here are, simply, my notes as I read through the draft somewhat thoroughly > last night. > > 1. typo: ".pric" in -02, fixed in -03 > 2. /message/smtp-envelope seems to work only for mail to me. What > about mail that I send? When I get a delivery notification, > wouldn't I want to parse it, find the corresponding message and > write "delivery succeeded/failed for a@b.com" annotations? Good point. Should we add: /message/dsn-received /message/mdn-received standard annotations? If so what should their value be? We could define values based on the standard dsn/mdn response codes, or allow the value to be the message/rfc822 of the actual response message. > 3. The Open Issue in 8.2 can be relaxed slightly: > > Servers MUST NOT include ANNOTATION data in responses until the > client has used the ANNOTATE extension in some way. > > I don't think it matters whether I have used FETCH or just SEARCH > for annotations; after that, the server should know that I > understand the extension. Changed in -03 with introduction of select parameter. > 4. The requirement to send unsolicited FETCH ANNOTATION responses > when third parties modify an annotation could usefully be watered > down a bit. IMHO, the server should be required to send me > updates to annotations I have fetched, and be allowed to send me > others. > > That way, a client that only accesses /message/comment doesn't > have to be burdened with a large /vendor tree used by another > client. Some clients may choose to keep an offline cache of annotations, as they d now for other message data. In such cases they will likely not re-fetch annotations they already have cached, but will need to be notified of changes. > 5. In 8.6, there's a reference to "SORT". I think it would be better > to rewrite that to take account of SORT2 etc. > > The ANNOTATION criterion is available if the server supports both > the ANNOTATE and SORT extensions. I think the current SORT will remain as is but we will add generalise i18n stuff to it. This is still an open question. > 6. Message responsibility in shared mailboxes has to be a fairly > common use for this, or am I wrong? The draft does not specify any > annotation for it. Should we add: /message/owner as annotation? If so what should the value be - a user id or a name or an arbitraty string? > 7. What happens to annotations if a message is copied to a different > mailbox? All copied, I suppose, even .shared notifications when a > message is copied to a private folder? Good point. There is no mention of the interaction of ANNOTATE and COPY. I will add some text about this. It seems to me that shared annotations will allways be copied, however only private annotations for those users that have access to the destination mailbox should be copied. > 8. Is a client permitted to write to e.g /message/smtp-envelope/from ? The draft currently allows modifications of these entries but states a client SHOULD NOT modify them unless the message is marked as a Draft. I think this is reasonable. > 9. What should the server do if a client attempts to write to an > annotation unknown to the server? One that may not be > IANA-registered, or that may be newer than the server? A server should accept any annotation, whether its registered or not. No one is ging to build the IANA registry into their server and there is no way you could stay current wrt vendor annotations. > 10. Or how about a syntactically valid but meaningless one, such as > /body/2/comment for a single-part message? I'm being overly > pedantic now, I guess. I'll stop here and brew some tea instead :) I will add some text for this specific point to say that servers MUST return a BAD response for an illegal part-specifier. I've also just noticed that the base spec allows an empty part-specifier to refer to the whole message - we need to disallow that in annotate as we already have the /message entries for that - I will add text for that too. > 11. One last pedantic excursion: If someone else changes a flag and > I've fetched some annotations, I suppose I'm going to receive an > unsolicited FETCH response with both FLAGS and ANNOTATION versions > of the same information. Is that intentional? Yes. This is still an issue with -03, though we do give clients the choice of turning on or off the unsolicted ANNOTATATION responses. Given that, should we add some more select parameters to control this? We could have: NOFLAGSRESPONSES - turns off unsolicted FLAGS responses NOANNOTATEFLAGSRESPONSES - turns off unsolicted ANNOATATION responses for stanard IMAP flags This would allow clients to fine tune the response behaviour based on whether they want to primarily uses FLAGS or ANNOTATIONs for dealing with IMAP flags. Any comments on this? -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g0NFmQM03443 for ietf-imapext-bks; Wed, 23 Jan 2002 07:48:26 -0800 (PST) Received: from witt-witt.caldera.de (witt-witt.caldera.de [195.143.241.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NFmP303439 for ; Wed, 23 Jan 2002 07:48:25 -0800 (PST) Received: (from arnt@localhost) by witt-witt.caldera.de (8.11.6/8.11.6) id g0NFmIS29976; Wed, 23 Jan 2002 16:48:18 +0100 Date: Wed, 23 Jan 2002 16:48:18 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123164818.C19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simultaneously, a -03 was published. So I cast a glance at it. I wrote: > 3. The Open Issue in 8.2 can be relaxed slightly: I see it was changed differently in -03. Suppose that I say SELECT INBOX (ANNOTATE), and then EXAMINE a different mailbox without saying ANNOTATE. In that case, -03 then says that the EXAMINE turns off unsolicited annotation responses; isn't that a bit weird? Examining a different mailbox should not have effect on the current mailbox. > 5. In 8.6, ... That's 8.7 in -03. --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g0NFIR402496 for ietf-imapext-bks; Wed, 23 Jan 2002 07:18:27 -0800 (PST) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NFIQ302492 for ; Wed, 23 Jan 2002 07:18:26 -0800 (PST) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g0NFKdj05085; Wed, 23 Jan 2002 16:20:39 +0100 Date: Wed, 23 Jan 2002 16:20:39 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Some ANNOTATE comments and questions Message-ID: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are, simply, my notes as I read through the draft somewhat thoroughly last night. 1. typo: ".pric" 2. /message/smtp-envelope seems to work only for mail to me. What about mail that I send? When I get a delivery notification, wouldn't I want to parse it, find the corresponding message and write "delivery succeeded/failed for a@b.com" annotations? 3. The Open Issue in 8.2 can be relaxed slightly: Servers MUST NOT include ANNOTATION data in responses until the client has used the ANNOTATE extension in some way. I don't think it matters whether I have used FETCH or just SEARCH for annotations; after that, the server should know that I understand the extension. 4. The requirement to send unsolicited FETCH ANNOTATION responses when third parties modify an annotation could usefully be watered down a bit. IMHO, the server should be required to send me updates to annotations I have fetched, and be allowed to send me others. That way, a client that only accesses /message/comment doesn't have to be burdened with a large /vendor tree used by another client. 5. In 8.6, there's a reference to "SORT". I think it would be better to rewrite that to take account of SORT2 etc. The ANNOTATION criterion is available if the server supports both the ANNOTATE and SORT extensions. 6. Message responsibility in shared mailboxes has to be a fairly common use for this, or am I wrong? The draft does not specify any annotation for it. 7. What happens to annotations if a message is copied to a different mailbox? All copied, I suppose, even .shared notifications when a message is copied to a private folder? 8. Is a client permitted to write to e.g /message/smtp-envelope/from ? 9. What should the server do if a client attempts to write to an annotation unknown to the server? One that may not be IANA-registered, or that may be newer than the server? 10. Or how about a syntactically valid but meaningless one, such as /body/2/comment for a single-part message? I'm being overly pedantic now, I guess. I'll stop here and brew some tea instead :) 11. One last pedantic excursion: If someone else changes a flag and I've fetched some annotations, I suppose I'm going to receive an unsolicited FETCH response with both FLAGS and ANNOTATION versions of the same information. Is that intentional? --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NEOrO29409 for ietf-imapext-bks; Wed, 23 Jan 2002 06:24:53 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NEOq329401 for ; Wed, 23 Jan 2002 06:24:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09796; Wed, 23 Jan 2002 09:24:51 -0500 (EST) Message-Id: <200201231424.JAA09796@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-annotate-03.txt Date: Wed, 23 Jan 2002 09:24:50 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-03.txt Pages : 19 Date : 22-Jan-02 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-annotate-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-annotate-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: <20020122153444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153444.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g0LChKr27618 for ietf-imapext-bks; Mon, 21 Jan 2002 04:43:20 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LChI327614 for ; Mon, 21 Jan 2002 04:43:19 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07397; Mon, 21 Jan 2002 07:43:16 -0500 (EST) Message-Id: <200201211243.HAA07397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nerenberg-imap-binary-06.txt Date: Mon, 21 Jan 2002 07:43:16 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 Binary Content Extension Author(s) : L. Nerenberg Filename : draft-nerenberg-imap-binary-06.txt Pages : 6 Date : 18-Jan-02 This memo defines the BINARY extension to the Internet Message Access Protocol [IMAP4rev1]. It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer-encoding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nerenberg-imap-binary-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nerenberg-imap-binary-06.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-nerenberg-imap-binary-06.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: <20020118144742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nerenberg-imap-binary-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-nerenberg-imap-binary-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020118144742.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJm6F05838 for ietf-imapext-bks; Fri, 11 Jan 2002 11:48:06 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (noodle@tomobiki-cho.cac.washington.edu [128.95.135.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BJm5305834 for ; Fri, 11 Jan 2002 11:48:05 -0800 (PST) Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Fri, 11 Jan 2002 07:28:17 -0800 (PST) Received: from mailscan3.cac.washington.edu (mailscan3.cac.washington.edu [140.142.32.15]) by hefty.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW01.12) with SMTP id g0BFSHDL025612 for ; Fri, 11 Jan 2002 07:28:17 -0800 Received: FROM mx1.cac.washington.edu BY mailscan3.cac.washington.edu ; Fri Jan 11 07:28:15 2002 -0800 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW01.12) with ESMTP id g0BFSDpr030257; Fri, 11 Jan 2002 07:28:13 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA06756 for ietf-123-outbound.07@ietf.org; Fri, 11 Jan 2002 10:15:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA06001 for ; Fri, 11 Jan 2002 08:55:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14597 for ; Fri, 11 Jan 2002 08:55:28 -0500 (EST) Message-Id: <200201111355.IAA14597@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crispin-imap-multiappend-05.txt Date: Fri, 11 Jan 2002 08:55:28 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imap-multiappend-05.txt Pages : 6 Date : 10-Jan-02 This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-multiappend-05.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-multiappend-05.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: <20020110150415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imap-multiappend-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imap-multiappend-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150415.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g0BDukJ24093 for ietf-imapext-bks; Fri, 11 Jan 2002 05:56:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BDuj324089 for ; Fri, 11 Jan 2002 05:56:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14824; Fri, 11 Jan 2002 08:56:43 -0500 (EST) Message-Id: <200201111356.IAA14824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-08.txt Date: Fri, 11 Jan 2002 08:56:43 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-08.txt Pages : 13 Date : 10-Jan-02 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-thread-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-thread-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020110150637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150637.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BDudc24086 for ietf-imapext-bks; Fri, 11 Jan 2002 05:56:39 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BDuc324082 for ; Fri, 11 Jan 2002 05:56:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14808; Fri, 11 Jan 2002 08:56:36 -0500 (EST) Message-Id: <200201111356.IAA14808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-08.txt Date: Fri, 11 Jan 2002 08:56:35 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-08.txt Pages : 10 Date : 10-Jan-02 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sort-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-sort-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020110150627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150627.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g0RL1KD06048 for ietf-imapext-bks; Sun, 27 Jan 2002 13:01:20 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0RL1J306044 for ; Sun, 27 Jan 2002 13:01:19 -0800 (PST) Received: from messagingdirect.com (188.207-34-100-0.interbaun.com [207.34.100.188]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g0RL1Dj04143; Sun, 27 Jan 2002 14:01:13 -0700 Message-ID: <3C546A97.3000B7BF@messagingdirect.com> Date: Sun, 27 Jan 2002 14:01:11 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> <3C53BD68.D61D7D24@messagingdirect.com> <20020127142609.G6102@melkebalanse.gulbrandsen.priv.no> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov > > I am not sure how you can define sort extension without referring to a > > capability. > > In the usual way: by referring to the extensions's draft/rfc :) > > > One can mention both SORT and future SORT2? > > The SORT draft I see in my mirror says: > > A server which supports this extension indicates this with a > capability name of "SORT". Client implementations SHOULD accept any > capability name which begins with "SORT" as indicating support for > the extension described in this document. This provides for future > upwards-compatible extensions. > > I think referring to the SORT extension (and listing > draft-ietf-imapext-sort-xx in the Refences section) is better than > referring to either "the capability SORT" or "any capability whose name > starts with SORT". I think if you want to use "a sort extension in a sense defined in draft-ietf-imapext-sort-xx" that is fine with me. > > I think the default behavior should be to send FLAG updates for all flags that can be mapped to > > annotations and send annotations for the rest (e.g. if the server implements \Draft as a shared > > flag, than a change to > > /message/flags/flagged value.shared is reported as FETCH FLAGS, but a change to > > /message/flags/flagged value.priv is returned as annotation). > > Makes sense to me, but then, why provide these flags as annotations? During last IETF meeting people in the meeting room agreed to map IMAP flags to annotations. There are several reasons: 1). Annotations are more flexible, because if a server supports both a shared and a private version of a flag, it can expose only one of the two through IMAP flags and both through ANNOTATE extension. 2). This works nicely with CONDSTORE extension, because the same syntax can be used to reference both annotations and flags. Alexey Melnikov __________________________________________ R & D, ACI Worldwide (formerly MessagingDirect Ltd.) phone 780.424.4922 x357 I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g0RDOm522730 for ietf-imapext-bks; Sun, 27 Jan 2002 05:24:48 -0800 (PST) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0RDOl322726 for ; Sun, 27 Jan 2002 05:24:47 -0800 (PST) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g0RDQAj07399; Sun, 27 Jan 2002 14:26:10 +0100 Date: Sun, 27 Jan 2002 14:26:09 +0100 From: Arnt Gulbrandsen To: Alexey Melnikov Cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020127142609.G6102@melkebalanse.gulbrandsen.priv.no> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> <3C53BD68.D61D7D24@messagingdirect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C53BD68.D61D7D24@messagingdirect.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov > I am not sure how you can define sort extension without referring to a > capability. In the usual way: by referring to the extensions's draft/rfc :) > One can mention both SORT and future SORT2? The SORT draft I see in my mirror says: A server which supports this extension indicates this with a capability name of "SORT". Client implementations SHOULD accept any capability name which begins with "SORT" as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. I think referring to the SORT extension (and listing draft-ietf-imapext-sort-xx in the Refences section) is better than referring to either "the capability SORT" or "any capability whose name starts with SORT". > I think the default behavior should be to send FLAG updates for all flags that can be mapped to > annotations and send annotations for the rest (e.g. if the server implements \Draft as a shared > flag, than a change to > /message/flags/flagged value.shared is reported as FETCH FLAGS, but a change to > /message/flags/flagged value.priv is returned as annotation). Makes sense to me, but then, why provide these flags as annotations? --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0R8gaA25539 for ietf-imapext-bks; Sun, 27 Jan 2002 00:42:36 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0R8gY325531 for ; Sun, 27 Jan 2002 00:42:34 -0800 (PST) Received: from messagingdirect.com (073.207-34-100-0.interbaun.com [207.34.100.73]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g0R8gEj01917; Sun, 27 Jan 2002 01:42:15 -0700 Message-ID: <3C53BD68.D61D7D24@messagingdirect.com> Date: Sun, 27 Jan 2002 01:42:16 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > > >5. In 8.6, there's a reference to "SORT". I think it would be better > > > to rewrite that to take account of SORT2 etc. > > > > > > The ANNOTATION criterion is available if the server supports both > > > the ANNOTATE and SORT extensions. > > > > I think the current SORT will remain as is but we will add generalise i18n > > stuff to it. This is still an open question. > > I'm afraid I expressed myself badly. The issue isn't with SORT, it's with > the wording - I think you should refer to presence of the sort extension > rather than to the string "SORT" in the CAPABILITY list. I am not sure how you can define sort extension without referring to a capability. One can mention both SORT and future SORT2? > > >6. Message responsibility in shared mailboxes has to be a fairly > > > common use for this, or am I wrong? The draft does not specify any > > > annotation for it. > > > > Should we add: > > > > /message/owner > > > > as annotation? If so what should the value be - a user id or a name or an > > arbitraty string? > > For a shared mailbox, there is a set of users that can be responsible for > answering mail in that mailbox. That set presumably corresponds to a set > of user ids, which in turn is a subset of the set of users. > > Which leads to the following alternatives: > > - Arbitrary string. Low cost to the draft, high cost to the user agents, > who'll have to make an enum out of that. > - User ID. High cost to the draft and servers, since there'll be a > fundamentally new datatype. Leaves open quesions about the subset of > users that are valid for any particular mailbox. > - Enum. High cost to the draft and servers, lowish cost to supporting > user agents. > > The first can be added at any time. Currently there is no IMAP extensions that allows to list user IDs. > > >11. One last pedantic excursion: If someone else changes a flag and > > > I've fetched some annotations, I suppose I'm going to receive an > > > unsolicited FETCH response with both FLAGS and ANNOTATION versions > > > of the same information. Is that intentional? > > > > Yes. This is still an issue with -03, though we do give clients the choice > > of turning on or off the unsolicted ANNOTATATION responses. Given that, > > should we add some more select parameters to control this? We could have: > > > > NOFLAGSRESPONSES - turns off unsolicted FLAGS responses > > NOANNOTATEFLAGSRESPONSES - turns off unsolicted ANNOATATION responses > > for standard IMAP flags > > > > This would allow clients to fine tune the response behaviour based on > > whether they want to primarily uses FLAGS or ANNOTATIONs for dealing with > > IMAP flags. Any comments on this? > > I shudder :) Just mandating one behaviour or the other seems so much > simpler. I think the default behavior should be to send FLAG updates for all flags that can be mapped to annotations and send annotations for the rest (e.g. if the server implements \Draft as a shared flag, than a change to /message/flags/flagged value.shared is reported as FETCH FLAGS, but a change to /message/flags/flagged value.priv is returned as annotation). IMHO, having a parameter to SELECT/EXAMINE to control the behavior seems like a good idea. Also I think that the description of generic SELECT/EXAMINE extensibility should be moved to a separate document. === Other comments: > /message/flags/answered > /message/flags/flagged > /message/flags/deleted > /message/flags/seen > /message/flags/draft > /message/flags/recent > These correspond to the standard IMAP flags. I think you should add a phrase saying that these annotations map one-to-one to IMAP flags, otherwise it is not clear what "correspond" means. Also recent must be read-only. Or was the omission of being read-only intentional? Alexey Melnikov __________________________________________ R & D, ACI Worldwide (formerly MessagingDirect Ltd.) phone 780.424.4922 x357 I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMJwH12942 for ietf-imapext-bks; Wed, 23 Jan 2002 14:19:58 -0800 (PST) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NMJr312929 for ; Wed, 23 Jan 2002 14:19:53 -0800 (PST) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g0NMM8Q05285; Wed, 23 Jan 2002 23:22:08 +0100 Date: Wed, 23 Jan 2002 23:22:07 +0100 From: Arnt Gulbrandsen To: Cyrus Daboo Cc: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123232207.A4936@melkebalanse.gulbrandsen.priv.no> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1011783761@socrates.cyrusoft.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo > >2. /message/smtp-envelope seems to work only for mail to me. What > > about mail that I send? When I get a delivery notification, > > wouldn't I want to parse it, find the corresponding message and > > write "delivery succeeded/failed for a@b.com" annotations? > > Good point. Should we add: > > /message/dsn-received > /message/mdn-received > > standard annotations? If so what should their value be? We could define > values based on the standard dsn/mdn response codes, or allow the value to > be the message/rfc822 of the actual response message. The names are more puzzling to me. Assume that all the addresses in this header field are successfully delivered, how could the annotations end up looking in? To: "G=Stakkars/S=Tulling;OU=blah/O=blah/PRMD=tiresome/ADMD=bothersome"@gateway.telenor.no, a@example.org, b@example.org, c@example.org, d@example.org > Some clients may choose to keep an offline cache of annotations, as they d > now for other message data. In such cases they will likely not re-fetch > annotations they already have cached, but will need to be notified of > changes. Yes... however, I can imagine that there will be both - clients that are meant for LAN usage, and use a big /vendor/blah/ tree - clients that are meant for wireless usage, and want to use as little bandwidth as possible There is a conflict there. > >5. In 8.6, there's a reference to "SORT". I think it would be better > > to rewrite that to take account of SORT2 etc. > > > > The ANNOTATION criterion is available if the server supports both > > the ANNOTATE and SORT extensions. > > I think the current SORT will remain as is but we will add generalise i18n > stuff to it. This is still an open question. I'm afraid I expressed myself badly. The issue isn't with SORT, it's with the wording - I think you should refer to presence of the sort extension rather than to the string "SORT" in the CAPABILITY list. > >6. Message responsibility in shared mailboxes has to be a fairly > > common use for this, or am I wrong? The draft does not specify any > > annotation for it. > > Should we add: > > /message/owner > > as annotation? If so what should the value be - a user id or a name or an > arbitraty string? For a shared mailbox, there is a set of users that can be responsible for answering mail in that mailbox. That set presumably corresponds to a set of user ids, which in turn is a subset of the set of users. Which leads to the following alternatives: - Arbitrary string. Low cost to the draft, high cost to the user agents, who'll have to make an enum out of that. - User ID. High cost to the draft and servers, since there'll be a fundamentally new datatype. Leaves open quesions about the subset of users that are valid for any particular mailbox. - Enum. High cost to the draft and servers, lowish cost to supporting user agents. The first can be added at any time. > >7. What happens to annotations if a message is copied to a different > > mailbox? All copied, I suppose, even .shared notifications when a > > message is copied to a private folder? > > Good point. There is no mention of the interaction of ANNOTATE and COPY. I > will add some text about this. It seems to me that shared annotations will > allways be copied, however only private annotations for those users that > have access to the destination mailbox should be copied. Yes. > >8. Is a client permitted to write to e.g /message/smtp-envelope/from ? > > The draft currently allows modifications of these entries but states a > client SHOULD NOT modify them unless the message is marked as a Draft. I > think this is reasonable. Yes. > >10. Or how about a syntactically valid but meaningless one, such as > > /body/2/comment for a single-part message? I'm being overly > > pedantic now, I guess. I'll stop here and brew some tea instead :) > > I will add some text for this specific point to say that servers MUST > return a BAD response for an illegal part-specifier. I've also just noticed > that the base spec allows an empty part-specifier to refer to the whole > message - we need to disallow that in annotate as we already have the > /message entries for that - I will add text for that too. Or, possibly, sanction the empty part-specified and wipe out /message? I've no arguments either way. > >11. One last pedantic excursion: If someone else changes a flag and > > I've fetched some annotations, I suppose I'm going to receive an > > unsolicited FETCH response with both FLAGS and ANNOTATION versions > > of the same information. Is that intentional? > > Yes. This is still an issue with -03, though we do give clients the choice > of turning on or off the unsolicted ANNOTATATION responses. Given that, > should we add some more select parameters to control this? We could have: > > NOFLAGSRESPONSES - turns off unsolicted FLAGS responses > NOANNOTATEFLAGSRESPONSES - turns off unsolicted ANNOATATION responses > for stanard IMAP flags > > This would allow clients to fine tune the response behaviour based on > whether they want to primarily uses FLAGS or ANNOTATIONs for dealing with > IMAP flags. Any comments on this? I shudder :) Just mandating one behaviour or the other seems so much simpler. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NIUSi07988 for ietf-imapext-bks; Wed, 23 Jan 2002 10:30:28 -0800 (PST) Received: from localhost.sendmail.com (natted.Sendmail.COM [63.211.143.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NIUR307983 for ; Wed, 23 Jan 2002 10:30:27 -0800 (PST) Received: (from jutta@localhost) by localhost.sendmail.com (8.11.6/8.11.6) id g0NITvF01679; Wed, 23 Jan 2002 10:29:57 -0800 Date: Wed, 23 Jan 2002 10:29:56 -0800 From: Jutta Degener To: ietf-imapext@imc.org Cc: Arnt Gulbrandsen Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123182956.GA1437@jutta.sendmail.com> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <2147483647.1011783761@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1011783761@socrates.cyrusoft.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 23, 2002 at 11:02:41AM -0500, Cyrus Daboo wrote: > >2. /message/smtp-envelope seems to work only for mail to me. What > > about mail that I send? When I get a delivery notification, > > wouldn't I want to parse it, find the corresponding message and > > write "delivery succeeded/failed for a@b.com" annotations? > > Good point. Should we add: > > /message/dsn-received > /message/mdn-received > > standard annotations? These would have to be per recipient(s), right? So, either /message//dsn-received/ or /message/dsn-received/ -- except that we can't do that because mailbox names are case-sensitive and names of annotations aren't. So maybe it'll be /message/dns-received/ with each value being a list of recipients for which the status is true? Or maybe it's /message/dns-received/ where the name of the recipient is encoded in the stored data, and the indexes ... no, wait, we don't store that. If you want to store sent mail information, how about starting with who it was sent to? (Of course, this creates new security issues, because now you're creating another record of whom you Bcc'ed something to.) Doing all this sounds like a good idea in general, but maybe it's worth waiting for some more client implementations before standardizing on something. I don't see mail clients present DNSes and MDNs much in terms of attributes of their sent messages; that makes it hard to guess what information they tend to need. > >6. Message responsibility in shared mailboxes has to be a fairly > > common use for this, or am I wrong? The draft does not specify any > > annotation for it. > > Should we add: > > /message/owner > > as annotation? If so what should the value be - a user id or a name or an > arbitrary string? Hm. I would wait with this one, too; I don't quite know what it means. "Responsibility" is too application-specific to be of cross-application usefulness, and if a single application wants to talk about the "owner" of its messages, it can use the vendor namespace to do it. --Jutta Received: by above.proper.com (8.11.6/8.11.3) id g0NH2qB05676 for ietf-imapext-bks; Wed, 23 Jan 2002 09:02:52 -0800 (PST) Received: from hera.webcom.com (hera.webcom.com [209.1.28.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NH2p305671 for ; Wed, 23 Jan 2002 09:02:51 -0800 (PST) Received: from eresh (eresh.webcom.com [209.1.28.49]) by hera.webcom.com (8.9.1/8.9.1) with SMTP id JAA12983; Wed, 23 Jan 2002 09:02:53 -0800 Received: from [216.207.178.10] by banana (WebCom SMTP 2.0) with SMTP id 140649387; Wed Jan 23 09:04 PST 2002 Message-Id: <4.3.2.7.2.20020123120224.03a06ed0@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 12:03:34 -0500 To: Cyrus Daboo , ietf-imapext@imc.org From: Pete Maclean Subject: Re: ANNOTATE question In-Reply-To: <2147483647.1011787056@socrates.cyrusoft.com> References: <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <4.3.2.7.2.20020123112607.03a67158@pop.webcom.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: >>I am curious about one thing in ANNOTATE. Since I am reading the draft >>for the first time, it may be that this issue has already been discussed >>and, if so, I apologize. As I understand the extension, there is no way >>to remove an annotation entry. What is the rationale for this? > >The value is defined as an nstring, so storing NIL into all values >(value.shared and value.priv for each users) effectively deletes that >entry. At the top of Section 8.4 it does state that clients can do that, >but I will also add additional text to the description of the value >attribute that says the same. Great! That makes perfect sense...although, even after re-reading 8.4, it does not seem at all clear. Pete Received: by above.proper.com (8.11.6/8.11.3) id g0NGvgW05487 for ietf-imapext-bks; Wed, 23 Jan 2002 08:57:42 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGve305483 for ; Wed, 23 Jan 2002 08:57:41 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA28217; Wed, 23 Jan 2002 11:55:14 -0500 (EST) Date: Wed, 23 Jan 2002 11:57:36 -0500 From: Cyrus Daboo To: Pete Maclean , ietf-imapext@imc.org Subject: Re: ANNOTATE question Message-ID: <2147483647.1011787056@socrates.cyrusoft.com> In-Reply-To: <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, January 23, 2002 11:26 AM -0500 Pete Maclean wrote: > I am curious about one thing in ANNOTATE. Since I am reading the draft > for the first time, it may be that this issue has already been discussed > and, if so, I apologize. As I understand the extension, there is no way > to remove an annotation entry. What is the rationale for this? The value is defined as an nstring, so storing NIL into all values (value.shared and value.priv for each users) effectively deletes that entry. At the top of Section 8.4 it does state that clients can do that, but I will also add additional text to the description of the value attribute that says the same. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g0NGpRi05338 for ietf-imapext-bks; Wed, 23 Jan 2002 08:51:27 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGpP305334 for ; Wed, 23 Jan 2002 08:51:25 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA28178; Wed, 23 Jan 2002 11:48:58 -0500 (EST) Date: Wed, 23 Jan 2002 11:51:20 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen cc: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <2147483647.1011786680@socrates.cyrusoft.com> In-Reply-To: <20020123171435.E19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123164818.C19874@witt-witt.caldera.de> <2147483647.1011783921@socrates.cyrusoft.com> <20020123171435.E19874@witt-witt.caldera.de> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, January 23, 2002 5:14 PM +0100 Arnt Gulbrandsen wrote: > Btw, > shouldn't the new argument to SELECT/EXAMINE be moved to > draft-crispin-imapv? When I was writing the select parameter stuff I did have the feeling that it ought to go in its own document - particularly if more extensions than ANNOTATED and conditional store would likely use it. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g0NGQ2q04732 for ietf-imapext-bks; Wed, 23 Jan 2002 08:26:02 -0800 (PST) Received: from hecate.webcom.com (hecate.webcom.com [209.1.28.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGQ2304728 for ; Wed, 23 Jan 2002 08:26:02 -0800 (PST) Received: from kigal (kigal.webcom.com [209.1.28.57]) by hecate.webcom.com (8.9.1/8.9.1) with SMTP id IAA10119 for ; Wed, 23 Jan 2002 08:25:59 -0800 Received: from [216.207.178.10] by inanna.webcom.com (WebCom SMTP 2.0) with SMTP id 100233327; Wed Jan 23 08:25 PST 2002 Message-Id: <4.3.2.7.2.20020123112607.03a67158@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 11:26:42 -0500 To: ietf-imapext@imc.org From: Pete Maclean Subject: ANNOTATE question In-Reply-To: <2147483647.1011783761@socrates.cyrusoft.com> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> 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: I am curious about one thing in ANNOTATE. Since I am reading the draft for the first time, it may be that this issue has already been discussed and, if so, I apologize. As I understand the extension, there is no way to remove an annotation entry. What is the rationale for this? Thanks, Pete Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NGFEv04405 for ietf-imapext-bks; Wed, 23 Jan 2002 08:15:14 -0800 (PST) Received: from witt-witt.caldera.de (witt-witt.caldera.de [195.143.241.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NGFC304400 for ; Wed, 23 Jan 2002 08:15:13 -0800 (PST) Received: (from arnt@localhost) by witt-witt.caldera.de (8.11.6/8.11.6) id g0NGEao30034; Wed, 23 Jan 2002 17:14:36 +0100 Date: Wed, 23 Jan 2002 17:14:35 +0100 From: Arnt Gulbrandsen To: Cyrus Daboo Cc: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123171435.E19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123164818.C19874@witt-witt.caldera.de> <2147483647.1011783921@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1011783921@socrates.cyrusoft.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo > After an EXAMINE the current mailbox IS the EXAMINE mailbox - you can only > have one mailboxes SELECT'ed or EXAMINE'd at a time - so I don't see the > issue here. Sorry, I was confusing EXAMINE with something else. STATUS I think. Btw, shouldn't the new argument to SELECT/EXAMINE be moved to draft-crispin-imapv? I'll reply to the other message later today; need to make some stuff build before I go home and it's late already. --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g0NG5Tu04009 for ietf-imapext-bks; Wed, 23 Jan 2002 08:05:29 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NG5S304003 for ; Wed, 23 Jan 2002 08:05:28 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA27874; Wed, 23 Jan 2002 11:03:00 -0500 (EST) Date: Wed, 23 Jan 2002 11:05:21 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <2147483647.1011783921@socrates.cyrusoft.com> In-Reply-To: <20020123164818.C19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> <20020123164818.C19874@witt-witt.caldera.de> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, January 23, 2002 4:48 PM +0100 Arnt Gulbrandsen wrote: > Simultaneously, a -03 was published. So I cast a glance at it. Ah - OK. I just sent my reply to your early message suggestion you checked to see whether you had -02 or -03! I guess we hit a race-condition here! > I wrote: >> 3. The Open Issue in 8.2 can be relaxed slightly: > > I see it was changed differently in -03. Suppose that I say SELECT INBOX > (ANNOTATE), and then EXAMINE a different mailbox without saying ANNOTATE. > In that case, -03 then says that the EXAMINE turns off unsolicited > annotation responses; isn't that a bit weird? Examining a different > mailbox should not have effect on the current mailbox. After an EXAMINE the current mailbox IS the EXAMINE mailbox - you can only have one mailboxes SELECT'ed or EXAMINE'd at a time - so I don't see the issue here. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NG2mk03908 for ietf-imapext-bks; Wed, 23 Jan 2002 08:02:48 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NG2l303903 for ; Wed, 23 Jan 2002 08:02:47 -0800 (PST) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA27828; Wed, 23 Jan 2002 11:00:19 -0500 (EST) Date: Wed, 23 Jan 2002 11:02:41 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <2147483647.1011783761@socrates.cyrusoft.com> In-Reply-To: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> X-Mailer: Mulberry/3.0.0d2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, I think your comments below refer to the -02 draft rather than the new -03 draft. Can you double-check what version you have. --On Wednesday, January 23, 2002 4:20 PM +0100 Arnt Gulbrandsen wrote: > > Here are, simply, my notes as I read through the draft somewhat thoroughly > last night. > > 1. typo: ".pric" in -02, fixed in -03 > 2. /message/smtp-envelope seems to work only for mail to me. What > about mail that I send? When I get a delivery notification, > wouldn't I want to parse it, find the corresponding message and > write "delivery succeeded/failed for a@b.com" annotations? Good point. Should we add: /message/dsn-received /message/mdn-received standard annotations? If so what should their value be? We could define values based on the standard dsn/mdn response codes, or allow the value to be the message/rfc822 of the actual response message. > 3. The Open Issue in 8.2 can be relaxed slightly: > > Servers MUST NOT include ANNOTATION data in responses until the > client has used the ANNOTATE extension in some way. > > I don't think it matters whether I have used FETCH or just SEARCH > for annotations; after that, the server should know that I > understand the extension. Changed in -03 with introduction of select parameter. > 4. The requirement to send unsolicited FETCH ANNOTATION responses > when third parties modify an annotation could usefully be watered > down a bit. IMHO, the server should be required to send me > updates to annotations I have fetched, and be allowed to send me > others. > > That way, a client that only accesses /message/comment doesn't > have to be burdened with a large /vendor tree used by another > client. Some clients may choose to keep an offline cache of annotations, as they d now for other message data. In such cases they will likely not re-fetch annotations they already have cached, but will need to be notified of changes. > 5. In 8.6, there's a reference to "SORT". I think it would be better > to rewrite that to take account of SORT2 etc. > > The ANNOTATION criterion is available if the server supports both > the ANNOTATE and SORT extensions. I think the current SORT will remain as is but we will add generalise i18n stuff to it. This is still an open question. > 6. Message responsibility in shared mailboxes has to be a fairly > common use for this, or am I wrong? The draft does not specify any > annotation for it. Should we add: /message/owner as annotation? If so what should the value be - a user id or a name or an arbitraty string? > 7. What happens to annotations if a message is copied to a different > mailbox? All copied, I suppose, even .shared notifications when a > message is copied to a private folder? Good point. There is no mention of the interaction of ANNOTATE and COPY. I will add some text about this. It seems to me that shared annotations will allways be copied, however only private annotations for those users that have access to the destination mailbox should be copied. > 8. Is a client permitted to write to e.g /message/smtp-envelope/from ? The draft currently allows modifications of these entries but states a client SHOULD NOT modify them unless the message is marked as a Draft. I think this is reasonable. > 9. What should the server do if a client attempts to write to an > annotation unknown to the server? One that may not be > IANA-registered, or that may be newer than the server? A server should accept any annotation, whether its registered or not. No one is ging to build the IANA registry into their server and there is no way you could stay current wrt vendor annotations. > 10. Or how about a syntactically valid but meaningless one, such as > /body/2/comment for a single-part message? I'm being overly > pedantic now, I guess. I'll stop here and brew some tea instead :) I will add some text for this specific point to say that servers MUST return a BAD response for an illegal part-specifier. I've also just noticed that the base spec allows an empty part-specifier to refer to the whole message - we need to disallow that in annotate as we already have the /message entries for that - I will add text for that too. > 11. One last pedantic excursion: If someone else changes a flag and > I've fetched some annotations, I suppose I'm going to receive an > unsolicited FETCH response with both FLAGS and ANNOTATION versions > of the same information. Is that intentional? Yes. This is still an issue with -03, though we do give clients the choice of turning on or off the unsolicted ANNOTATATION responses. Given that, should we add some more select parameters to control this? We could have: NOFLAGSRESPONSES - turns off unsolicted FLAGS responses NOANNOTATEFLAGSRESPONSES - turns off unsolicted ANNOATATION responses for stanard IMAP flags This would allow clients to fine tune the response behaviour based on whether they want to primarily uses FLAGS or ANNOTATIONs for dealing with IMAP flags. Any comments on this? -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g0NFmQM03443 for ietf-imapext-bks; Wed, 23 Jan 2002 07:48:26 -0800 (PST) Received: from witt-witt.caldera.de (witt-witt.caldera.de [195.143.241.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NFmP303439 for ; Wed, 23 Jan 2002 07:48:25 -0800 (PST) Received: (from arnt@localhost) by witt-witt.caldera.de (8.11.6/8.11.6) id g0NFmIS29976; Wed, 23 Jan 2002 16:48:18 +0100 Date: Wed, 23 Jan 2002 16:48:18 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: Some ANNOTATE comments and questions Message-ID: <20020123164818.C19874@witt-witt.caldera.de> References: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simultaneously, a -03 was published. So I cast a glance at it. I wrote: > 3. The Open Issue in 8.2 can be relaxed slightly: I see it was changed differently in -03. Suppose that I say SELECT INBOX (ANNOTATE), and then EXAMINE a different mailbox without saying ANNOTATE. In that case, -03 then says that the EXAMINE turns off unsolicited annotation responses; isn't that a bit weird? Examining a different mailbox should not have effect on the current mailbox. > 5. In 8.6, ... That's 8.7 in -03. --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g0NFIR402496 for ietf-imapext-bks; Wed, 23 Jan 2002 07:18:27 -0800 (PST) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NFIQ302492 for ; Wed, 23 Jan 2002 07:18:26 -0800 (PST) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g0NFKdj05085; Wed, 23 Jan 2002 16:20:39 +0100 Date: Wed, 23 Jan 2002 16:20:39 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Some ANNOTATE comments and questions Message-ID: <20020123162039.A5081@melkebalanse.gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are, simply, my notes as I read through the draft somewhat thoroughly last night. 1. typo: ".pric" 2. /message/smtp-envelope seems to work only for mail to me. What about mail that I send? When I get a delivery notification, wouldn't I want to parse it, find the corresponding message and write "delivery succeeded/failed for a@b.com" annotations? 3. The Open Issue in 8.2 can be relaxed slightly: Servers MUST NOT include ANNOTATION data in responses until the client has used the ANNOTATE extension in some way. I don't think it matters whether I have used FETCH or just SEARCH for annotations; after that, the server should know that I understand the extension. 4. The requirement to send unsolicited FETCH ANNOTATION responses when third parties modify an annotation could usefully be watered down a bit. IMHO, the server should be required to send me updates to annotations I have fetched, and be allowed to send me others. That way, a client that only accesses /message/comment doesn't have to be burdened with a large /vendor tree used by another client. 5. In 8.6, there's a reference to "SORT". I think it would be better to rewrite that to take account of SORT2 etc. The ANNOTATION criterion is available if the server supports both the ANNOTATE and SORT extensions. 6. Message responsibility in shared mailboxes has to be a fairly common use for this, or am I wrong? The draft does not specify any annotation for it. 7. What happens to annotations if a message is copied to a different mailbox? All copied, I suppose, even .shared notifications when a message is copied to a private folder? 8. Is a client permitted to write to e.g /message/smtp-envelope/from ? 9. What should the server do if a client attempts to write to an annotation unknown to the server? One that may not be IANA-registered, or that may be newer than the server? 10. Or how about a syntactically valid but meaningless one, such as /body/2/comment for a single-part message? I'm being overly pedantic now, I guess. I'll stop here and brew some tea instead :) 11. One last pedantic excursion: If someone else changes a flag and I've fetched some annotations, I suppose I'm going to receive an unsolicited FETCH response with both FLAGS and ANNOTATION versions of the same information. Is that intentional? --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NEOrO29409 for ietf-imapext-bks; Wed, 23 Jan 2002 06:24:53 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NEOq329401 for ; Wed, 23 Jan 2002 06:24:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09796; Wed, 23 Jan 2002 09:24:51 -0500 (EST) Message-Id: <200201231424.JAA09796@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-annotate-03.txt Date: Wed, 23 Jan 2002 09:24:50 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-03.txt Pages : 19 Date : 22-Jan-02 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-annotate-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-annotate-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: <20020122153444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153444.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g0LChKr27618 for ietf-imapext-bks; Mon, 21 Jan 2002 04:43:20 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LChI327614 for ; Mon, 21 Jan 2002 04:43:19 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07397; Mon, 21 Jan 2002 07:43:16 -0500 (EST) Message-Id: <200201211243.HAA07397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nerenberg-imap-binary-06.txt Date: Mon, 21 Jan 2002 07:43:16 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 Binary Content Extension Author(s) : L. Nerenberg Filename : draft-nerenberg-imap-binary-06.txt Pages : 6 Date : 18-Jan-02 This memo defines the BINARY extension to the Internet Message Access Protocol [IMAP4rev1]. It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer-encoding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nerenberg-imap-binary-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nerenberg-imap-binary-06.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-nerenberg-imap-binary-06.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: <20020118144742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nerenberg-imap-binary-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-nerenberg-imap-binary-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020118144742.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJm6F05838 for ietf-imapext-bks; Fri, 11 Jan 2002 11:48:06 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (noodle@tomobiki-cho.cac.washington.edu [128.95.135.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BJm5305834 for ; Fri, 11 Jan 2002 11:48:05 -0800 (PST) Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Fri, 11 Jan 2002 07:28:17 -0800 (PST) Received: from mailscan3.cac.washington.edu (mailscan3.cac.washington.edu [140.142.32.15]) by hefty.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW01.12) with SMTP id g0BFSHDL025612 for ; Fri, 11 Jan 2002 07:28:17 -0800 Received: FROM mx1.cac.washington.edu BY mailscan3.cac.washington.edu ; Fri Jan 11 07:28:15 2002 -0800 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW01.12) with ESMTP id g0BFSDpr030257; Fri, 11 Jan 2002 07:28:13 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA06756 for ietf-123-outbound.07@ietf.org; Fri, 11 Jan 2002 10:15:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA06001 for ; Fri, 11 Jan 2002 08:55:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14597 for ; Fri, 11 Jan 2002 08:55:28 -0500 (EST) Message-Id: <200201111355.IAA14597@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crispin-imap-multiappend-05.txt Date: Fri, 11 Jan 2002 08:55:28 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imap-multiappend-05.txt Pages : 6 Date : 10-Jan-02 This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-multiappend-05.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-multiappend-05.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: <20020110150415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imap-multiappend-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imap-multiappend-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150415.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g0BDukJ24093 for ietf-imapext-bks; Fri, 11 Jan 2002 05:56:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BDuj324089 for ; Fri, 11 Jan 2002 05:56:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14824; Fri, 11 Jan 2002 08:56:43 -0500 (EST) Message-Id: <200201111356.IAA14824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-08.txt Date: Fri, 11 Jan 2002 08:56:43 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-08.txt Pages : 13 Date : 10-Jan-02 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-thread-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-thread-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020110150637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150637.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BDudc24086 for ietf-imapext-bks; Fri, 11 Jan 2002 05:56:39 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BDuc324082 for ; Fri, 11 Jan 2002 05:56:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14808; Fri, 11 Jan 2002 08:56:36 -0500 (EST) Message-Id: <200201111356.IAA14808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-08.txt Date: Fri, 11 Jan 2002 08:56:35 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-08.txt Pages : 10 Date : 10-Jan-02 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sort-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-sort-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020110150627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150627.I-D@ietf.org> --OtherAccess-- --NextPart--