Re: Some ANNOTATE comments and questions

Alexey Melnikov <mel@messagingdirect.com> Sun, 27 January 2002 21:01 UTC

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 <ietf-imapext@imc.org>; 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 <mel@messagingdirect.com>
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 <arnt@gulbrandsen.priv.no>
CC: Cyrus Daboo <daboo@cyrusoft.com>, 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Alexey Melnikov <mel@messagingdirect.com>
> > 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.
__________________________________________