Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>
Cc: Randall Gellens <[email-masked]>, Cyrus Daboo <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 23 May 2007 13:37:47 +0100
List-Id: <ietf-imapext.imc.org>

Randall Gellens wrote:**

>>     This command sets the specified list of entries by adding or
>>     replacing the specified attributes with the values provided, on the
>>     specified existing mailboxes.
>
This sentence should have "or on the server (if the mailbox parameter is 
the empty string)" at the end.

>>   Clients can use NIL for values of
>>     attributes it wants to remove from entries.  The server MAY return a
>>     METADATA response containing the updated annotation data.
>>
>>  In this case, the server may return a METADATA response that doesn't
>>  contain the updated annotation data or a LIST response that does,
>>  correct?
>
You are right. The METADATA response is returned if per-server 
annotation is changed, the LIST response is returned if per-mailbox 
annotation is changes.

Hmm, the METADATA response is not unsolicited, so it can contain the 
update value.

So I think the last quoted sentence should be replaced with something 
like the following:

    If the client modified a server annotation then the server MAY 
return a METADATA response containing the updated annotation data (see 
section 4.5.1).
    If the client modified a mailbox annotation then the server MAY 
return an extended LIST response containing the METADATA item with the 
updated annotation data (see section 4.3).

But the more I think about the more I get convinced that the MAYs should 
be changed to SHOULD NOTs.
/*
*/

Date: Wed, 23 May 2007 12:22:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Dan Karp <[email-masked]>, Cyrus Daboo <[email-masked]>, Enhancements  to Internet email to support diverse service enivronments  <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Sender: [email-masked]

Hi Randy,

Randall Gellens wrote:

> I hope this isn't too late to be useful.
>
> At 9:31 PM -0700 4/2/07, Dan Karp wrote:
>
>>     A user can only set and retrieve private or shared annotations on a
>>     mailbox which exists and is returned to them via a LIST or LSUB
>>     command, irrespective of whether they have read or write access to
>>     the actual message content of the mailbox.  If the client 
>> attempts to
>>     set or retrieve annotations on other mailboxes, the server MUST
>>     respond with a NO response.
>>
>>  I can understand the logic behind requiring LIST/LSUB access for 
>> reading
>>  public mailbox annotations and for setting private annotations.  But
>>  that seems to be a very low bar for setting public mailbox annotations.
>>  Adding a new ACL permission for setting annotations would make this
>>  extension more complex and would also introduce a dependency on the ACL
>>  extension, but perhaps requiring [READ-WRITE] access to the mailbox
>>  might be reasonable?
>
> Seems reasonable.  It's interesting that any user can set a shared 
> server annotation.

I was also advocating a new ACL right, but Cyrus didn't think it was needed.

> Note that, separate from Dan's comments, the description of the 
> SETMETADATA command should explicitly mention that an empty string is 
> used to set server annotations, and should include some examples of 
> doing so.
>
> Perhaps servers should be permitted to reject an attempt to set shared 
> server annotations if, based on internal configuration (that is, not 
> standardized) the user isn't allowed to do so?  That would allow 
> servers to, for example, have some users that can set any shared 
> server annotations, others that can set none, and some that can set some.

Well yes, but implementations can already do that no matter what the 
spec says.

> I think trying to standardize this would require ACL extensions and 
> introduce an ACL dependency, which we don't want to do.  This could 
> always be done in the future, based on operational experience.

 [...]

>>     Each annotation is an entry that has a hierarchical name, with each
>>     component of the name separated by a slash ("/").  An entry name 
>> MUST
>>     NOT contain two consecutive "/" characters and MUST NOT end with a
>>     "/" character.
>>
>>     Each entry is made up of a set of attributes.  Each attribute has a
>>     hierarchical name, with each component of the name separated by a
>>     period (".").  An attribute name MUST NOT contain two consecutive 
>> "."
>>     characters and MUST NOT end with a "." character.
>>
>>  My last comment is personal preference: I fear that this may be a 
>> bit of
>>  overkill for folder annotation.  I understand the need for this type of
>>  flexible syntax for ACAP's purposes, but the use cases for IMAP appear
>>  significantly more limited in scope.  In accordance with the KISS
>>  philosophy, is there any chance I might be able to convince everyone to
>>  consider shedding a layer of hierarchy here?
>
> I think we need the entry hierarchy.  It might be possible to 
> eliminate the attribute hierarchy.  Didn't we end up doing something 
> like that for ANNOTATE?

Attribute hierarchy only has two levels, e.g. "value" . "shared". I 
think this is a non issue.

Date: Wed, 16 May 2007 15:44:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Can we last call I18N? (Was: Can we please close this WG)
Cc: Alexey Melnikov <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Pete Resnick writes:
> On 5/11/07 at 9:30 PM +0100, Alexey Melnikov wrote:
>
>> So can we please do some work and get the IMAP I18N document finished?
>
> Indeed. Arnt, are you ready for a writeup?

I think not. Alexey reviewed again after a long pause, and he found 
enough buried treasure that I will want WGLC after the next revision 
(on Tuesday, I think). Then we'll see whether I'm ready for a writeup.

Arnt

Date: Wed, 16 May 2007 13:41:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Can we last call I18N? (Was: Can we please close this WG)
Sender: [email-masked]

Pete Resnick wrote:

> On 5/11/07 at 9:30 PM +0100, Alexey Melnikov wrote:
>
>> So can we please do some work and get the IMAP I18N document finished?
>
> Indeed. Arnt, are you ready for a writeup?

IMHO, Arnt needs to address several ABNF errors that I've reported 
first. After that the document is in a reasonable shape for WGLC.

I can forward my comments to the mailing list, if people prefer.

Date: Tue, 15 May 2007 13:59:09 -0700
To: Dan Karp <[email-masked]>, Eric Burger <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Cc: Enhancements to Internet email to support diverse service enivronments	<[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I hope this isn't too late to be useful.

At 9:31 PM -0700 4/2/07, Dan Karp wrote:

>     A user can only set and retrieve private or shared annotations on a
>     mailbox which exists and is returned to them via a LIST or LSUB
>     command, irrespective of whether they have read or write access to
>     the actual message content of the mailbox.  If the client attempts to
>     set or retrieve annotations on other mailboxes, the server MUST
>     respond with a NO response.
>
>  I can understand the logic behind requiring LIST/LSUB access for reading
>  public mailbox annotations and for setting private annotations.  But
>  that seems to be a very low bar for setting public mailbox annotations.
>  Adding a new ACL permission for setting annotations would make this
>  extension more complex and would also introduce a dependency on the ACL
>  extension, but perhaps requiring [READ-WRITE] access to the mailbox
>  might be reasonable?

Seems reasonable.  It's interesting that any user can set a shared 
server annotation.

Note that, separate from Dan's comments, the description of the 
SETMETADATA command should explicitly mention that an empty string is 
used to set server annotations, and should include some examples of 
doing so.

Perhaps servers should be permitted to reject an attempt to set 
shared server annotations if, based on internal configuration (that 
is, not standardized) the user isn't allowed to do so?  That would 
allow servers to, for example, have some users that can set any 
shared server annotations, others that can set none, and some that 
can set some.  I think trying to standardize this would require ACL 
extensions and introduce an ACL dependency, which we don't want to 
do.  This could always be done in the future, based on operational 
experience.

>     This command sets the specified list of entries by adding or
>     replacing the specified attributes with the values provided, on the
>     specified existing mailboxes.  Clients can use NIL for values of
>     attributes it wants to remove from entries.  The server MAY return a
>     METADATA response containing the updated annotation data.
>
>  In this case, the server may return a METADATA response that doesn't
>  contain the updated annotation data or a LIST response that does,
>  correct?

The server might return a METADATA response containing incorrect data?

>     This extension adds the GETMETADATA command.  This allows clients to
>     retrieve server annotations.  Mailbox annotations are retrieved via
>     the extended LIST command described in the next section.
>
>     This extension adds the SETMETADATA command.  This allows clients to
>     set annotations.
>
>  It's a little incongruous that GETMETADATA is used only to retrieve
>  server annotations, but SETMETADATA can be used to set both server and
>  mailbox annotations.  I understand that the mailbox-level function of
>  GETMETADATA has been passed to the LIST-EXTENDED feature, but generally
>  it's clearer when a GETFOO and SETFOO pair cover the same target space.

I agree, this is odd.

>     /sort
>        Defines the default sort criteria [I-D.ietf-imapext-sort] to use
>        when first displaying the mailbox contents to the user, or NIL if
>        sorting is not required.  Note that the presence of this attribute
>        does not imply that the server supports the IMAP SORT
>        [I-D.ietf-imapext-sort] extension - servers can choose to support
>        or not support SORT independently of this extension.  In the
>        absence of the SORT extension, clients can choose to interpret
>        this entry as suggesting a client-side sort ordering of the
>        corresponding mailbox.
>
>     /thread
>        Defines the default thread criteria [I-D.ietf-imapext-sort] to use
>        when first displaying the mailbox contents to the user, or NIL if
>        threading is not required.  If both sort and thread are not NIL,
>        then threading should take precedence over sorting.  Note that the
>        presence of this attribute does not imply that the server supports
>        the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can
>        choose to support or not support THREAD independently of this
>        extension.  In the absence of the THREAD extension, clients can
>        choose to interpret this entry as a client-side thread ordering of
>        the corresponding mailbox.
>
>  These registered annotations are odd ducks.  They seem most appropriate
>  as private annotations on a mailbox, but in practice they may be
>  confusing to the end user because sorting and threading preferences are
>  often client-specific, not user-specific.
>
>  For instance, a user may prefer to read their mail nonthreaded on the
>  desktop, but on a mobile device they may want to make use of the reduced
>  visual footprint of a threaded display.  Likewise, more likely than not
>  a user won't expect their sort preferences to automatically be
>  transferred between their devices and clients.

One thought would be to keep the current "/sort" and "/thread" 
entries, but specify that "/sort/client/<client-token>" and 
"/thread/client/<client-token>" may exist and if so apply to specific 
clients.  If the server supports threading and sorting and knows the 
<client-token> for the session (using some 
to-be-specified-in-the-future mechanism) it uses the client-specific 
entry, otherwise it uses the default entry.  This assumes that a 
level in the hierarchy can have attributes and child levels.  If the 
server doesn't support threading or sorting, the client can always 
use a vendor-specific entry.

>     Each annotation is an entry that has a hierarchical name, with each
>     component of the name separated by a slash ("/").  An entry name MUST
>     NOT contain two consecutive "/" characters and MUST NOT end with a
>     "/" character.
>
>     Each entry is made up of a set of attributes.  Each attribute has a
>     hierarchical name, with each component of the name separated by a
>     period (".").  An attribute name MUST NOT contain two consecutive "."
>     characters and MUST NOT end with a "." character.
>
>  My last comment is personal preference: I fear that this may be a bit of
>  overkill for folder annotation.  I understand the need for this type of
>  flexible syntax for ACAP's purposes, but the use cases for IMAP appear
>  significantly more limited in scope.  In accordance with the KISS
>  philosophy, is there any chance I might be able to convince everyone to
>  consider shedding a layer of hierarchy here?

I think we need the entry hierarchy.  It might be possible to 
eliminate the attribute hierarchy.  Didn't we end up doing something 
like that for ANNOTATE?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I personally think we developed language because of our
deep need to complain.                    --Lily Tomlin

Date: Tue, 15 May 2007 15:13:08 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Can we last call I18N? (Was: Can we please close this WG)
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 5/11/07 at 9:30 PM +0100, Alexey Melnikov wrote:

>So can we please do some work and get the IMAP I18N document finished?

Indeed. Arnt, are you ready for a writeup?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>
Subject: Document Action: 'IMAP ANNOTATE Extension' to  Experimental RFC 
Date: Mon, 14 May 2007 17:35:03 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'IMAP ANNOTATE Extension '
   <draft-ietf-imapext-annotate-16.txt> as an Experimental RFC

This document is the product of the Internet Message Access Protocol 
Extension Working Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-16.txt

Technical Summary
 
   The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

Working Group Summary
 
   The IMAPEXT WG did a lot of good and careful work on this document. 
Very responsibly, the WG considered at the end whether this was actually
going to be implemented.  Although several client developers indicated a
strong need for annotation functionality, few server developers were
willing to commit to implementation (and deployment might be even worse).
Thus, the WG reluctantly concluded to publish this as Experimental, hoping
that some implementation experience will lead to a better understanding of
what it takes to convince server implementors to do this functionality,
along with what it takes to implement it robustly and in a decently
performant fashion.
 
Protocol Quality
 
   The IMAPEXT WG did as much work for this document as would be expected
for a Proposed Standard, including Last Calls and several individual
reviews.

   Lisa Dusseault reviewed this document for the IESG.

Note to RFC Editor

   Please add the following paragraph to the abstract.

   NEW: 
   "Note that this document was the product of a WG which had good
consensus on how to approach the problem.  Nevertheless, the WG felt it
did not have enough information on implementation and deployment hurdles
to meet all the requirements of a Proposed Standard.  The IETF solicits
implementations and implementation reports in order to make further
progress."

   Please add the following sub-section to section 7.

NEW: 7.4  Capability registration

   This document registers "ANNOTATE-EXPERIMENT-1" as an IMAPEXT
capability in http://www.iana.org/assignments/imap4-capabilities.

Date: Fri, 11 May 2007 21:30:22 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Can we please close this WG
Sender: [email-masked]

I am sure I saw on ADs slides in Prague:

WG that will close before Chicago:

IMAPEXT.

I find it very demotivating being so close to this honorable goal and 
yet so far away. What is left? 1.5 drafts: 1 is IMAP I18N, 0.5 is SORT 
(0.5, because it might need a minor change to address an IESG DISCUSS).
So can we please do some work and get the IMAP I18N document finished?

Thanks,
Alexey

Subject: Message ORGanization list formed
Date: Tue, 01 May 2007 17:08:24 +0100
From: Dave Cridland <[email-masked]>
To: Enhancements to Internet email to support diverse service enivronments <[email-masked]>, <[email-masked]>
Sender: [email-masked]

For those who are interested, a mailing list called [email-masked] has 
been formed to discuss the general issues surrounding message 
organization and search.

The intent is to examine what existing clients are actually doing, 
and see what servers might do to support this functionality such that 
it can be done efficiently (possibly including over limited 
bandwidth).

If it seems to be heading in a fruitful direction with a reasonable 
amount of support, I'll see what I can do about getting a BOF 
together with a much more concrete charter proposal.

To subscribe, it's the usual [email-masked] thing.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 23 May 2007 13:37:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>
CC: Randall Gellens <[email-masked]>, Cyrus Daboo <[email-masked]>, Enhancements  to Internet email to support diverse service enivronments  <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Sender: [email-masked]

Randall Gellens wrote:**

>>     This command sets the specified list of entries by adding or
>>     replacing the specified attributes with the values provided, on the
>>     specified existing mailboxes.
>
This sentence should have "or on the server (if the mailbox parameter is 
the empty string)" at the end.

>>   Clients can use NIL for values of
>>     attributes it wants to remove from entries.  The server MAY return a
>>     METADATA response containing the updated annotation data.
>>
>>  In this case, the server may return a METADATA response that doesn't
>>  contain the updated annotation data or a LIST response that does,
>>  correct?
>
You are right. The METADATA response is returned if per-server 
annotation is changed, the LIST response is returned if per-mailbox 
annotation is changes.

Hmm, the METADATA response is not unsolicited, so it can contain the 
update value.

So I think the last quoted sentence should be replaced with something 
like the following:

    If the client modified a server annotation then the server MAY 
return a METADATA response containing the updated annotation data (see 
section 4.5.1).
    If the client modified a mailbox annotation then the server MAY 
return an extended LIST response containing the METADATA item with the 
updated annotation data (see section 4.3).

But the more I think about the more I get convinced that the MAYs should 
be changed to SHOULD NOTs.
/*
*/

Date: Wed, 23 May 2007 12:22:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Dan Karp <[email-masked]>, Cyrus Daboo <[email-masked]>, Enhancements  to Internet email to support diverse service enivronments  <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Sender: [email-masked]

Hi Randy,

Randall Gellens wrote:

> I hope this isn't too late to be useful.
>
> At 9:31 PM -0700 4/2/07, Dan Karp wrote:
>
>>     A user can only set and retrieve private or shared annotations on a
>>     mailbox which exists and is returned to them via a LIST or LSUB
>>     command, irrespective of whether they have read or write access to
>>     the actual message content of the mailbox.  If the client 
>> attempts to
>>     set or retrieve annotations on other mailboxes, the server MUST
>>     respond with a NO response.
>>
>>  I can understand the logic behind requiring LIST/LSUB access for 
>> reading
>>  public mailbox annotations and for setting private annotations.  But
>>  that seems to be a very low bar for setting public mailbox annotations.
>>  Adding a new ACL permission for setting annotations would make this
>>  extension more complex and would also introduce a dependency on the ACL
>>  extension, but perhaps requiring [READ-WRITE] access to the mailbox
>>  might be reasonable?
>
> Seems reasonable.  It's interesting that any user can set a shared 
> server annotation.

I was also advocating a new ACL right, but Cyrus didn't think it was needed.

> Note that, separate from Dan's comments, the description of the 
> SETMETADATA command should explicitly mention that an empty string is 
> used to set server annotations, and should include some examples of 
> doing so.
>
> Perhaps servers should be permitted to reject an attempt to set shared 
> server annotations if, based on internal configuration (that is, not 
> standardized) the user isn't allowed to do so?  That would allow 
> servers to, for example, have some users that can set any shared 
> server annotations, others that can set none, and some that can set some.

Well yes, but implementations can already do that no matter what the 
spec says.

> I think trying to standardize this would require ACL extensions and 
> introduce an ACL dependency, which we don't want to do.  This could 
> always be done in the future, based on operational experience.

 [...]

>>     Each annotation is an entry that has a hierarchical name, with each
>>     component of the name separated by a slash ("/").  An entry name 
>> MUST
>>     NOT contain two consecutive "/" characters and MUST NOT end with a
>>     "/" character.
>>
>>     Each entry is made up of a set of attributes.  Each attribute has a
>>     hierarchical name, with each component of the name separated by a
>>     period (".").  An attribute name MUST NOT contain two consecutive 
>> "."
>>     characters and MUST NOT end with a "." character.
>>
>>  My last comment is personal preference: I fear that this may be a 
>> bit of
>>  overkill for folder annotation.  I understand the need for this type of
>>  flexible syntax for ACAP's purposes, but the use cases for IMAP appear
>>  significantly more limited in scope.  In accordance with the KISS
>>  philosophy, is there any chance I might be able to convince everyone to
>>  consider shedding a layer of hierarchy here?
>
> I think we need the entry hierarchy.  It might be possible to 
> eliminate the attribute hierarchy.  Didn't we end up doing something 
> like that for ANNOTATE?

Attribute hierarchy only has two levels, e.g. "value" . "shared". I 
think this is a non issue.

Date: Wed, 16 May 2007 15:44:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Can we last call I18N? (Was: Can we please close this WG)
Cc: Alexey Melnikov <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Pete Resnick writes:
> On 5/11/07 at 9:30 PM +0100, Alexey Melnikov wrote:
>
>> So can we please do some work and get the IMAP I18N document finished?
>
> Indeed. Arnt, are you ready for a writeup?

I think not. Alexey reviewed again after a long pause, and he found 
enough buried treasure that I will want WGLC after the next revision 
(on Tuesday, I think). Then we'll see whether I'm ready for a writeup.

Arnt

Date: Wed, 16 May 2007 13:41:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Can we last call I18N? (Was: Can we please close this WG)
Sender: [email-masked]

Pete Resnick wrote:

> On 5/11/07 at 9:30 PM +0100, Alexey Melnikov wrote:
>
>> So can we please do some work and get the IMAP I18N document finished?
>
> Indeed. Arnt, are you ready for a writeup?

IMHO, Arnt needs to address several ABNF errors that I've reported 
first. After that the document is in a reasonable shape for WGLC.

I can forward my comments to the mailing list, if people prefer.

Date: Tue, 15 May 2007 13:59:09 -0700
To: Dan Karp <[email-masked]>, Eric Burger <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Cc: Enhancements to Internet email to support diverse service enivronments	<[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I hope this isn't too late to be useful.

At 9:31 PM -0700 4/2/07, Dan Karp wrote:

>     A user can only set and retrieve private or shared annotations on a
>     mailbox which exists and is returned to them via a LIST or LSUB
>     command, irrespective of whether they have read or write access to
>     the actual message content of the mailbox.  If the client attempts to
>     set or retrieve annotations on other mailboxes, the server MUST
>     respond with a NO response.
>
>  I can understand the logic behind requiring LIST/LSUB access for reading
>  public mailbox annotations and for setting private annotations.  But
>  that seems to be a very low bar for setting public mailbox annotations.
>  Adding a new ACL permission for setting annotations would make this
>  extension more complex and would also introduce a dependency on the ACL
>  extension, but perhaps requiring [READ-WRITE] access to the mailbox
>  might be reasonable?

Seems reasonable.  It's interesting that any user can set a shared 
server annotation.

Note that, separate from Dan's comments, the description of the 
SETMETADATA command should explicitly mention that an empty string is 
used to set server annotations, and should include some examples of 
doing so.

Perhaps servers should be permitted to reject an attempt to set 
shared server annotations if, based on internal configuration (that 
is, not standardized) the user isn't allowed to do so?  That would 
allow servers to, for example, have some users that can set any 
shared server annotations, others that can set none, and some that 
can set some.  I think trying to standardize this would require ACL 
extensions and introduce an ACL dependency, which we don't want to 
do.  This could always be done in the future, based on operational 
experience.

>     This command sets the specified list of entries by adding or
>     replacing the specified attributes with the values provided, on the
>     specified existing mailboxes.  Clients can use NIL for values of
>     attributes it wants to remove from entries.  The server MAY return a
>     METADATA response containing the updated annotation data.
>
>  In this case, the server may return a METADATA response that doesn't
>  contain the updated annotation data or a LIST response that does,
>  correct?

The server might return a METADATA response containing incorrect data?

>     This extension adds the GETMETADATA command.  This allows clients to
>     retrieve server annotations.  Mailbox annotations are retrieved via
>     the extended LIST command described in the next section.
>
>     This extension adds the SETMETADATA command.  This allows clients to
>     set annotations.
>
>  It's a little incongruous that GETMETADATA is used only to retrieve
>  server annotations, but SETMETADATA can be used to set both server and
>  mailbox annotations.  I understand that the mailbox-level function of
>  GETMETADATA has been passed to the LIST-EXTENDED feature, but generally
>  it's clearer when a GETFOO and SETFOO pair cover the same target space.

I agree, this is odd.

>     /sort
>        Defines the default sort criteria [I-D.ietf-imapext-sort] to use
>        when first displaying the mailbox contents to the user, or NIL if
>        sorting is not required.  Note that the presence of this attribute
>        does not imply that the server supports the IMAP SORT
>        [I-D.ietf-imapext-sort] extension - servers can choose to support
>        or not support SORT independently of this extension.  In the
>        absence of the SORT extension, clients can choose to interpret
>        this entry as suggesting a client-side sort ordering of the
>        corresponding mailbox.
>
>     /thread
>        Defines the default thread criteria [I-D.ietf-imapext-sort] to use
>        when first displaying the mailbox contents to the user, or NIL if
>        threading is not required.  If both sort and thread are not NIL,
>        then threading should take precedence over sorting.  Note that the
>        presence of this attribute does not imply that the server supports
>        the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can
>        choose to support or not support THREAD independently of this
>        extension.  In the absence of the THREAD extension, clients can
>        choose to interpret this entry as a client-side thread ordering of
>        the corresponding mailbox.
>
>  These registered annotations are odd ducks.  They seem most appropriate
>  as private annotations on a mailbox, but in practice they may be
>  confusing to the end user because sorting and threading preferences are
>  often client-specific, not user-specific.
>
>  For instance, a user may prefer to read their mail nonthreaded on the
>  desktop, but on a mobile device they may want to make use of the reduced
>  visual footprint of a threaded display.  Likewise, more likely than not
>  a user won't expect their sort preferences to automatically be
>  transferred between their devices and clients.

One thought would be to keep the current "/sort" and "/thread" 
entries, but specify that "/sort/client/<client-token>" and 
"/thread/client/<client-token>" may exist and if so apply to specific 
clients.  If the server supports threading and sorting and knows the 
<client-token> for the session (using some 
to-be-specified-in-the-future mechanism) it uses the client-specific 
entry, otherwise it uses the default entry.  This assumes that a 
level in the hierarchy can have attributes and child levels.  If the 
server doesn't support threading or sorting, the client can always 
use a vendor-specific entry.

>     Each annotation is an entry that has a hierarchical name, with each
>     component of the name separated by a slash ("/").  An entry name MUST
>     NOT contain two consecutive "/" characters and MUST NOT end with a
>     "/" character.
>
>     Each entry is made up of a set of attributes.  Each attribute has a
>     hierarchical name, with each component of the name separated by a
>     period (".").  An attribute name MUST NOT contain two consecutive "."
>     characters and MUST NOT end with a "." character.
>
>  My last comment is personal preference: I fear that this may be a bit of
>  overkill for folder annotation.  I understand the need for this type of
>  flexible syntax for ACAP's purposes, but the use cases for IMAP appear
>  significantly more limited in scope.  In accordance with the KISS
>  philosophy, is there any chance I might be able to convince everyone to
>  consider shedding a layer of hierarchy here?

I think we need the entry hierarchy.  It might be possible to 
eliminate the attribute hierarchy.  Didn't we end up doing something 
like that for ANNOTATE?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I personally think we developed language because of our
deep need to complain.                    --Lily Tomlin

Date: Tue, 15 May 2007 15:13:08 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Can we last call I18N? (Was: Can we please close this WG)
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 5/11/07 at 9:30 PM +0100, Alexey Melnikov wrote:

>So can we please do some work and get the IMAP I18N document finished?

Indeed. Arnt, are you ready for a writeup?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>
Subject: Document Action: 'IMAP ANNOTATE Extension' to  Experimental RFC 
Date: Mon, 14 May 2007 17:35:03 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'IMAP ANNOTATE Extension '
   <draft-ietf-imapext-annotate-16.txt> as an Experimental RFC

This document is the product of the Internet Message Access Protocol 
Extension Working Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-16.txt

Technical Summary
 
   The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

Working Group Summary
 
   The IMAPEXT WG did a lot of good and careful work on this document. 
Very responsibly, the WG considered at the end whether this was actually
going to be implemented.  Although several client developers indicated a
strong need for annotation functionality, few server developers were
willing to commit to implementation (and deployment might be even worse).
Thus, the WG reluctantly concluded to publish this as Experimental, hoping
that some implementation experience will lead to a better understanding of
what it takes to convince server implementors to do this functionality,
along with what it takes to implement it robustly and in a decently
performant fashion.
 
Protocol Quality
 
   The IMAPEXT WG did as much work for this document as would be expected
for a Proposed Standard, including Last Calls and several individual
reviews.

   Lisa Dusseault reviewed this document for the IESG.

Note to RFC Editor

   Please add the following paragraph to the abstract.

   NEW: 
   "Note that this document was the product of a WG which had good
consensus on how to approach the problem.  Nevertheless, the WG felt it
did not have enough information on implementation and deployment hurdles
to meet all the requirements of a Proposed Standard.  The IETF solicits
implementations and implementation reports in order to make further
progress."

   Please add the following sub-section to section 7.

NEW: 7.4  Capability registration

   This document registers "ANNOTATE-EXPERIMENT-1" as an IMAPEXT
capability in http://www.iana.org/assignments/imap4-capabilities.

Date: Fri, 11 May 2007 21:30:22 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Can we please close this WG
Sender: [email-masked]

I am sure I saw on ADs slides in Prague:

WG that will close before Chicago:

IMAPEXT.

I find it very demotivating being so close to this honorable goal and 
yet so far away. What is left? 1.5 drafts: 1 is IMAP I18N, 0.5 is SORT 
(0.5, because it might need a minor change to address an IESG DISCUSS).
So can we please do some work and get the IMAP I18N document finished?

Thanks,
Alexey

Subject: Message ORGanization list formed
Date: Tue, 01 May 2007 17:08:24 +0100
From: Dave Cridland <[email-masked]>
To: Enhancements to Internet email to support diverse service enivronments <[email-masked]>, <[email-masked]>
Sender: [email-masked]

For those who are interested, a mailing list called [email-masked] has 
been formed to discuss the general issues surrounding message 
organization and search.

The intent is to examine what existing clients are actually doing, 
and see what servers might do to support this functionality such that 
it can be done efficiently (possibly including over limited 
bandwidth).

If it seems to be heading in a fruitful direction with a reasonable 
amount of support, I'll see what I can do about getting a BOF 
together with a much more concrete charter proposal.

To subscribe, it's the usual [email-masked] thing.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade