Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)

From: Randall Gellens <[email-masked]>
Date: Tue, 15 May 2007 13:59:09 -0700

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

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 May 2007 13:37:47 +0100

Randall Gellens wrote:**

>>     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
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 serverge: en-us, en
To: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Cc: Cyrus Daboo <[email-masked]>,
	to Internet email to support diverse service enivronments
	<[email-masked]>, IMAP Extensions WG <[email-masked]>,
	Enhancements

Hi Randy,

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

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

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

 [...]

>>  significantly more limited in scope.  In acge: en-us, en
To: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC)
Cc: Cyrus Daboo <[email-masked]>,
	to Internet email to support diverse service enivronments
	<[email-masked]>, IMAP Extensions WG <[email-masked]>,
	Enhancements

Hi Randy,

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

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

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

 [...]

>>  significantly more limited in scope.  In ac 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.
/*
*/

cordance with the KISS
> eliminate the attribute hierarchy.  Didn't we end up doing something 

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 May 2007 13:37:47 +0100

Randall Gellens wrote:**

    If the client modified a server annotation then the servercordance with the KISS

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 May 2007 13:37:47 +0100

Randall Gellens wrote:**

    If the client modified a server annotation then the server MAY 

 MAY