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

From: Dan Karp <[email-masked]>
Date: Sun, 17 Feb 2008 18:22:56 -0800 (PST)

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.

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?  Moreover, since the number of
mailboxes returned by a LIST-EXTENDED request is fairly small, 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.

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.

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.

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.

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?  If
so, this is a sizable requirement on servers and it should be made
explicit in the draft.

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].  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?  Is there a way that these could be set maliciously?
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.  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?  I can't think of one, certainly
not a common enough one that would warrant adding more complexity to the
draft.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade