Subject: Re: [lemonade] [Fwd: Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to Proposed Standard]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Mar 2008 20:07:57 +0000

Hi Dan,
Sorry for the slow respons to your comments.

Dan Karp wrote:

>Comments on the latest METADATA draft:
>
>
>METADATA requires both ENABLE and LIST-EXTENDED.  LIST-EXTENDED is a
>significant, non-trivial extension and should not be listed as a
>prerequisite unless absolutely necessary.  

You have a point.

>Extending LIST-EXTENDED to support comparison tests and collations adds
>a significant amount of complexity to the server.  Realistically, when
>would a client make use of this feature?

When a client want to find some date using language specific or task
specific (e.g. searching for a value representing a number) collation.

>  Moreover, since the number of
>mailboxes returned by a LIST-EXTENDED request is fairly small,

This assumption is wrong and similar statements in the past ("who would
have a mailbox with 30,000 messages") lead to all sorts of problems.

> it would be much simpler for the client to retrieve the annotations and do any
>sorting (or, far less likely, comparisons) locally.
>
>The draft states that "Text comparisons may be done as part of the
>GETMETADATA or LIST-EXTENDED commands."  However, the draft ABNF
>includes no mechanism to do comparisons via GETMETADATA.

Good point.

>The IMAP protocol is entirely case-insensitive, even down to message
>header names and user-defined keywords.  METADATA entry and attribute
>names are case-sensitive.  They should not be.

Hmm, I can go with that, as this will suite the backend protocol I will
use to store this ;-).
Of course entry names are in UTF-8, so matching should be done using
i;unicode-casemap.

>SETMETADATA is used to set all annotations.  GETMETADATA is used to
>fetch some of them; LIST-EXTENDED is used to fetch the others.  Server-
>level metadata is set using "SETMETADATA NIL /comment", but retrieved
>using "GETMETADATA /comment" (without the NIL).  In general, SET and GET
>commands should be complementary; anything set with SET should be
>retrievable via GET, and the command syntax should be identical.  The
>defined set of METADATA-related commands is awkward.
>
>The access control model requires only LIST access on a mailbox to set
>shared annotations on it.  While this might be acceptable for a server
>in a business, the bar is placed far too low for a real-world ISP or EDU
>install.  There is almost a 100% likelihood that someone will
>immediately set all shared metadata on all "public folders" to values
>that are, shall we say, "not useful".  Administrator access on a folder
>seems a more realistic requirement.

Agreed. Either an 'a' right or a separate right would work for me.

>The draft does not specify the permissions required to set shared
>server-level metadata.  According to mail from the draft's authors,
>*any* user can set any writable server annotation.  If that's the case,
>there's no point in having writable ".shared" server-level metadata at
>all.  The access control model for server-level metadata needs to be
>made explicit and it needs to be more reasonable than a free-for-all.

Right.

>Most IMAP servers internally (and invisibly) redirect requests between
>hosts to satisfy SELECTs on mailboxes homed on servers other than the
>one the user logged in to.  Some place the mail data on a separate tier
>and allow full access to any mailbox from any IMAP server.  Very few if
>any use MAILBOX-REFERRALS to explicitly redirect clients to other hosts.
>Given that, what does server-level ".priv" metadata mean?  Are servers
>required to present the same set of ".priv" server annotations
>regardless of which actual host is servicing a user's connection?

Yes.

>If so, this is a sizable requirement on servers and it should be made
>explicit in the draft.

Sure.

>METADATA carries over the "value" and "size" attribute names from ACAP.
>But there is no use case given for the "size" attribute for annotations,
>and none is obvious.  A client will fetch a piece of metadata that it
>needs regardless of size -- very similar to how there is no need for
>BODY.SIZE[HEADER.FIELDS (...)] or BODY.SIZE[1].

I don't think this is a good example. Clients need to know body part
sizes, but they are available in bodystructure, if I remember correctly.

While I don't expect annotations to be big, I think it would be a
disservice to clients if there would be no way to filter our annotations
by size.
For example if an annotation should contain a 4Kb picture, but instead
it contains 200Kb, then the client might decide that it is probably has
wrong dimensions and shouldn't be downloaded at all. (Hmm, CONVERT for
annotations :-)).

>METADATA would lose no
>power and become a fair amount simpler by getting rid of attributes.
>
>There is no explanation on how the various ".shared" mailbox metadata
>values should be used by clients.  Is a client expected by default to
>use the ".shared" /sort, /thread, and /check values and display the
>shared /comment?

I would expect the client to not specify any suffix and thus request
both by default. Maybe this should require more discussion in the draft.

>Is there a way that these could be set maliciously?

This is a valid security consideration and should be discussed in the
document.

But I think this is largely related to you comment about access control
above.

>If these ".shared" values are not used by default, what is the
>real-world use for ".shared" mailbox annotations?
>
>Almost all of the predefined mailbox-level annotations (including /sort,
>/thread, /check, and /checkperiod) reference settings that have
>heretofore generally been viewed as per-client.  It may be unexpected --
>and possibly undesirable -- for these settings to be set as ".priv"
>mailbox annotations and thus shared between a user's clients.

I think clients should pick items that they considered shareable.

However I would like to suggest that the list of predefined annotations
should be shorten and the rest be moved to a separate document.

>What's appropriate for a desktop client can be counterproductive on a mobile
>device.
>
>The use of wildcards in SETMETADATA is unnecessary.  Can you think of a
>realistic use case where a client would need to set the same piece of
>metadata on multiple mailboxes at once?

/sort?

>I can't think of one, certainly
>not a common enough one that would warrant adding more complexity to the
>draft.

I am starting to think that we should either restrict allowable mailbox
patterns, or replace patterns with mailbox depth specifier (i.e. all
direct children, all subordinate mailboxes, etc.)

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