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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Jan 2008 19:38:24 +0000

The IESG wrote:

>The IESG has received a request from an individual submitter to consider 
>the following document:
>
>- 'IMAP METADATA Extension '
>   <draft-daboo-imap-annotatemore-12.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2008-01-30. Exceptionally, 
>comments may be sent to [email-masked] instead. In either case, please 
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-12.txt
>  
>
Hi Cyrus,
As discussed earlier, below is the list of issues raised by various 
people you've asked to reraise during IETF LC:

1). What IMAP rights are required to set public and private annotations 
on the server?

No rights are required, but I think this should be stated explicitly.

2).

>>>   ...  If the collation identifier is
>>>   specified, then that collation MUST be used to do the comparison of
>>>   the annotation entry values being tested.
>>
>> What if the collation is unknown to the server?  Does it fail with an
>> error? What error?
>
> Explicitly stated that a BAD be returned.

For consistency with draft-ietf-imapext-i18n-14.txt (which is a 
normative dependency for draft-daboo-imap-annotatemore), I suggest 
changing this to tagged NO response and adding a requirement to return 
BADCOMPARATOR response code defined in draft-ietf-imapext-i18n.

3).

>>           C: a SETMETADATA INBOX.% /comment
>
> Is it really necessary to allow arbitrary wildcards for SETMETADATA?
> It's a lot of complexity and I'm not sure it's useful.

  [...]

> It also seems excessively complex to support both "%" and "*" at
> arbitrary points in the match.  Wouldn't it be simpler and sufficient to
> just support "*" at the end?

In response to this: while I agree that support for "%" and "*" in 
arbitrary matches is not that useful, this is consistent with IMAP LIST 
command and the same pattern matching code can be used for both.

4). The latest version defines 2 IMAP extensions: METADATA-SERVER and 
METADATA (the latter being a superset of the former).
For ease of coding clients I suggest that any server advertising the 
latter MUST also advertise the former.

Regards,
Alexey

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf