Subject: Re: Some ANNOTATE comments and questions
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: Sun, 27 Jan 2002 14:01:11 -0700
List-Id: <ietf-imapext.imc.org>

Arnt Gulbrandsen wrote:

> Alexey Melnikov <[email-masked]>
> > 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.
__________________________________________

Date: Sun, 27 Jan 2002 14:26:09 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Alexey Melnikov <[email-masked]>
> 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

Date: Sun, 27 Jan 2002 01:42:16 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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.
__________________________________________

Date: Wed, 23 Jan 2002 23:22:07 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> >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 [email-masked]" 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,
    [email-masked], [email-masked], [email-masked], [email-masked]

> 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

Date: Wed, 23 Jan 2002 10:29:56 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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 [email-masked]" 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/<recipient>/dsn-received/ or
/message/dsn-received/<recipient> -- 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/<status> with each value being a
list of recipients for which the status is true?  Or maybe it's
/message/dns-received/<index> where the name of the recipient is
encoded in the stored data, and the <index> 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

Date: Wed, 23 Jan 2002 12:03:34 -0500
To: Cyrus Daboo <[email-masked]>, [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: ANNOTATE question
Sender: [email-masked]

>>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

Date: Wed, 23 Jan 2002 11:57:36 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Maclean <[email-masked]>, [email-masked]
Subject: Re: ANNOTATE question
Sender: [email-masked]

--On Wednesday, January 23, 2002 11:26 AM -0500 Pete Maclean 
<[email-masked]> 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

Date: Wed, 23 Jan 2002 11:51:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

--On Wednesday, January 23, 2002 5:14 PM +0100 Arnt Gulbrandsen 
<[email-masked]> 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

Date: Wed, 23 Jan 2002 11:26:42 -0500
To: [email-masked]
From: Pete Maclean <[email-masked]>
Subject: ANNOTATE question
Sender: [email-masked]

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

Date: Wed, 23 Jan 2002 17:14:35 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> 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

Date: Wed, 23 Jan 2002 11:05:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

--On Wednesday, January 23, 2002 4:48 PM +0100 Arnt Gulbrandsen 
<[email-masked]> 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

Date: Wed, 23 Jan 2002 11:02:41 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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 
<[email-masked]> 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 [email-masked]" 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

Date: Wed, 23 Jan 2002 16:48:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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

Date: Wed, 23 Jan 2002 16:20:39 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Some ANNOTATE comments and questions
Sender: [email-masked]

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 [email-masked]" 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-03.txt
Date: Wed, 23 Jan 2002 09:24:50 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-06.txt
Date: Mon, 21 Jan 2002 07:43:16 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imap-multiappend-05.txt
Date: Fri, 11 Jan 2002 08:55:28 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-08.txt
Date: Fri, 11 Jan 2002 08:56:43 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-08.txt
Date: Fri, 11 Jan 2002 08:56:35 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 27 Jan 2002 14:01:11 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov <[email-masked]>
> > 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.
__________________________________________

Date: Sun, 27 Jan 2002 14:26:09 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Alexey Melnikov <[email-masked]>
> 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

Date: Sun, 27 Jan 2002 01:42:16 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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.
__________________________________________

Date: Wed, 23 Jan 2002 23:22:07 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> >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 [email-masked]" 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,
    [email-masked], [email-masked], [email-masked], [email-masked]

> 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

Date: Wed, 23 Jan 2002 10:29:56 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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 [email-masked]" 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/<recipient>/dsn-received/ or
/message/dsn-received/<recipient> -- 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/<status> with each value being a
list of recipients for which the status is true?  Or maybe it's
/message/dns-received/<index> where the name of the recipient is
encoded in the stored data, and the <index> 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

Date: Wed, 23 Jan 2002 12:03:34 -0500
To: Cyrus Daboo <[email-masked]>, [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: ANNOTATE question
Sender: [email-masked]

>>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

Date: Wed, 23 Jan 2002 11:57:36 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Maclean <[email-masked]>, [email-masked]
Subject: Re: ANNOTATE question
Sender: [email-masked]

--On Wednesday, January 23, 2002 11:26 AM -0500 Pete Maclean 
<[email-masked]> 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

Date: Wed, 23 Jan 2002 11:51:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

--On Wednesday, January 23, 2002 5:14 PM +0100 Arnt Gulbrandsen 
<[email-masked]> 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

Date: Wed, 23 Jan 2002 11:26:42 -0500
To: [email-masked]
From: Pete Maclean <[email-masked]>
Subject: ANNOTATE question
Sender: [email-masked]

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

Date: Wed, 23 Jan 2002 17:14:35 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> 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

Date: Wed, 23 Jan 2002 11:05:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

--On Wednesday, January 23, 2002 4:48 PM +0100 Arnt Gulbrandsen 
<[email-masked]> 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

Date: Wed, 23 Jan 2002 11:02:41 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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 
<[email-masked]> 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 [email-masked]" 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

Date: Wed, 23 Jan 2002 16:48:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Some ANNOTATE comments and questions
Sender: [email-masked]

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

Date: Wed, 23 Jan 2002 16:20:39 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Some ANNOTATE comments and questions
Sender: [email-masked]

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 [email-masked]" 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-03.txt
Date: Wed, 23 Jan 2002 09:24:50 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-06.txt
Date: Mon, 21 Jan 2002 07:43:16 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-crispin-imap-multiappend-05.txt
Date: Fri, 11 Jan 2002 08:55:28 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-08.txt
Date: Fri, 11 Jan 2002 08:56:43 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-08.txt
Date: Fri, 11 Jan 2002 08:56:35 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--