Annotate

Some comments:

    Clients MUST NOT use annotations in lieu of equivalent IMAP base
    specification facilities.  For example, use of a "seen" flag in the
    vendor namespace together with ".PEEK" in fetches.  Such behaviour
    would significantly reduce IMAP interoperability.

I don't understand the example. What does .PEEK fetches have to do with 
\Seen flag, except without it the \Seen flag might change?

    If a server supports annotations, then it MUST store all annotation
    data permanently, i.e.  there is no concept of 'session only'
    annotations that would correspond to the behaviour of 'session' flags
    as defined in the IMAP base specification.  The exception to this is
    IMAP flags (which are accessible directly through annotations) which
    may be 'session only' as determined by the FLAGS and PERMANENTFLAGS
    responses to a SELECT or EXAMINE command.

Since IMAP flags can no longer be modified with ANNOTATE, the exception 
should probably be removed.

    The 'm' right controls both read and write access to .priv annotation
    values.  When it is on, access to .priv annotations is allowed, when
    it is off, access to .priv annotations is disallowed.

Is this really needed? I think private annotations should work the same 
way as private flags. You can always read them, and you can write them 
if it's possible to permanently save flags.

    /flags

Re: Annotate

Hi Timo,

--On Monday, November 1, 2004 7:27:45 PM EST +0200 Timo Sirainen 
<tss <at> iki.fi> wrote:

> Some comments:
>
>     Clients MUST NOT use annotations in lieu of equivalent IMAP base
>     specification facilities.  For example, use of a "seen" flag in the
>     vendor namespace together with ".PEEK" in fetches.  Such behaviour
>     would significantly reduce IMAP interoperability.
>
> I don't understand the example. What does .PEEK fetches have to do with
> \Seen flag, except without it the \Seen flag might change?

In this example we are saying that a 'rogue' client might choose to bypass 
the standard IMAP seen behavior by using .PEEK fetches (that do not change 
the IMAP \Seen flag) and instead use their own private seen annotation that 
is used to indicate seen state in that client. That hurts interop because a 
message that appears seen in one client, does not appear seen in another.

What I think will be best is to remove the text you quoted, and instead 
insert a comment in the flags section (actually this will appear in the new 
text I propose below in response to your last point).

>     If a server supports annotations, then it MUST store all annotation
>     data permanently, i.e.  there is no concept of 'session only'
>     annotations that would correspond to the behaviour of 'session' flags
>     as defined in the IMAP base specification.  The exception to this is

Re: Annotate

On 1.11.2004, at 20:09, Cyrus Daboo wrote:

>>     The 'm' right controls both read and write access to .priv 
>> annotation
>>     values.  When it is on, access to .priv annotations is allowed, 
>> when
>>     it is off, access to .priv annotations is disallowed.
>>
>> Is this really needed? I think private annotations should work the 
>> same
>> way as private flags. You can always read them, and you can write 
>> them if
>> it's possible to permanently save flags.
>
> In an ACL-aware server there are different ways to control the flag 
> state 's' and 'w' bits. As a result I think there should also be a way 
> to enable/disable private annotations independently - hence the 'm' 
> bit. I know Alexey had some concerns with 'm' too so this is still an 
> open issue.

Well, perhaps it would be useful to have "m" for writing because of 
that, but I think "r" would be more logical for reading private 
annotations.

>> I thought clients weren't allowed to make up their own annotation 
>> entry
>> names? Or what does this mean?
>
> If a client wants to create a 'boolean' (on/off) type property 
> associated with a message it has two options: use an IMAP keyword 

Not being able to attend IMAPEXT/Lemonade

Due to little trick that UK Home Office has played on me, I am still not 
in possession of my passport. My flight is tomorrow at noon. So I will 
most likely miss the IMAPEXT and Lemonade meetings. I will try to 
participate in jabber.

Alexey

Proposed agenda for IMAPEXT

I'm sorry this is so late, but here it is anyway.  Suggestions welcome.  
  Note the new ACL draft link which hasn't been commented on here on the  
list -- if you get a chance to read that draft by Monday that would be  
super.

Agenda for IMAPEXT meeting at 61st IETF
Monday, Nov 8,  1530-1730

0.  Agenda bashing, find note taker and jabber scribe:
(10 minutes)

1. Sorting, threading, and viewing (to be dealt with by one or more
   mechanisms)
  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.txt>
     status: still blocked on comparator (as is i18n draft)
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
extensions-10.txt>
     Barry Leiba will discuss
     Still issues on  /Placeholder from last meeting, which Alexey and  
Cyrus were tasked with resolving
(40 minutes)

2. Access Control Lists
  - <http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-10.txt>
     Not updated since last meeting -- probably still blocked on LISTEXT.
  -  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-00.txt>
     READ THIS if you're coming to the meeting!  Or even if you're not.  

Question about the SORT and THREAD extensions

Hello,

Can [could] the SORT and THREAD extensions handle messages like this 
http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html 
?

--

-- 
kael

http://del.icio.us/ubi.quito.us

Updated draft-ietf-imapext-2086upd (ACL)

I forgot to submit it. I think I've addressed all but one issue raised 
by Philip. I will send a separate message on this.
Apart from the issue, I think the document is ready for Last Call.

Alexey

IMAPEXT Working Group                                        A. Melnikov
Internet Draft                                                    Editor
Document: draft-ietf-imapext-2086upd-01.txt                November 2004
Updates: 2086, <<3501?>>
Expires: May 2005

                          IMAP4 ACL extension -
                        updated list of rights

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed, or
   will be disclosed, and any of which I become aware will be disclosed,
   in accordance with RFC 3668.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts. Internet Drafts are draft documents valid for a maximum of
   six months.  Internet Drafts may be updated, replaced, or obsoleted
   by other documents at any time.  It is not appropriate to use

Re: Annotate

Timo Sirainen wrote:

> On 1.11.2004, at 20:09, Cyrus Daboo wrote:
>
>>>     The 'm' right controls both read and write access to .priv 
>>> annotation
>>>     values.  When it is on, access to .priv annotations is allowed, 
>>> when
>>>     it is off, access to .priv annotations is disallowed.
>>>
>>> Is this really needed? I think private annotations should work the same
>>> way as private flags. You can always read them, and you can write 
>>> them if
>>> it's possible to permanently save flags.
>>
>> In an ACL-aware server there are different ways to control the flag 
>> state 's' and 'w' bits. As a result I think there should also be a 
>> way to enable/disable private annotations independently - hence the 
>> 'm' bit. I know Alexey had some concerns with 'm' too so this is 
>> still an open issue.
>
> Well, perhaps it would be useful to have "m" for writing because of 
> that, but I think "r" would be more logical for reading private 
> annotations.

I agree (a separate message on this is coming).

>>> I thought clients weren't allowed to make up their own annotation entry
>>> names? Or what does this mean?

Re: Moving the ANNOTATE document forward

Alexey Melnikov wrote:

> >   The 'm' right controls both read and write access to .priv annotation
> >   values.  When it is on, access to .priv annotations is allowed, when
> >   it is off, access to .priv annotations is disallowed.
>
> I still don't like using the "m" right for reading private 
> annotations, but we can discuss this during face to face meeting.

Ok, let me try to describe my concern.
 From the table in the ANNOTATE document:

   +===============+===============+===================================+
   |               |               |                                   |
   | No ACL        | read .priv    | Any mailbox that can be SELECTED  |
   |               | values        | or EXAMINED.                      |
   |               |               |                                   |
   +---------------+---------------+-----------------------------------+
   |               |               |                                   |
   | With ACL      | read .priv    | Any mailbox with the 'm'          |
   |               | values        | ACL right.                        |
   |               |               |                                   |
   +---------------+---------------+-----------------------------------+

Which means that a well behaving ANNOTATE&ACL-aware client needs to know 
whether the server supports ACL or not. Why? Because when the client 
opens a mailbox, it can't assume that private annotations are readable, 
because for the ACL-aware server the "m" right doesn't control if the 
mailbox can be SELECT/EXAMINEd or not.

Re: Listext

Timo Sirainen wrote:

> > 3.1. General principles for returning LIST responses
>
> Are these a MUST? Especially the "don't return mailbox more than once" 
> rule?

I would like to make the one you've mentioned a MUST. However it is not
going to be practical. I think they all SHOULDs.

However, if a single LIST command returns more than one extended LIST
response for a mailbox, we need to state some safe assumptions for
clients, e.g. the client can use mailbox flags from the latest LIST
response (and ignore all previous). I don't think many existing client
will be able to cope with multiple LIST responses for the same mailbox.

Alexey