Subject: Gen-ART review of draft-melnikov-sieve-imapext-metadata-08

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 23 Dec 2008 12:05:06 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-melnikov-sieve-imapext-metadata-08
Reviewer: Spencer Dawkins
Review Date: 2008-12-23
IETF LC End Date: 2009-01-14
IESG Telechat date: (not known)

Summary: Almost ready for publication as a Proposed Standard. Please see
notes below.

Comments:

3.  mailbox and mboxmetadata extensions

3.1.  Test mailboxexists

   Note that a successful "mailboxexists" test for a mailbox doesn't
   necessarily mean that a "fileinto" action on this mailbox would
   succeed.  For example the "fileinto" action might put user over
   quota.  The "mailboxexists" only verifies existence of the mailbox
   and whether the user in whose context the Sieve script runs has
   permissions to execute fileinto on it.

Spencer (nit): you've been putting "fileinto" in quotes, up to this point -
suggest that this be consistent.

   The capability string for use with the require command is "mailbox".

   Example: The following example assumes that the Sieve engine also
   supports "reject" [REJECT] and "fileinto" [SIEVE].  However these
   extensions are not required in order to implement the "mailbox"
   extension.

        require ["fileinto", "reject", "mailbox"];
        if mailboxexists "Partners" {
           fileinto "Partners";
        } else {
           reject "This message was not accepted by the Mailstore";
        }

5.  Security Considerations

   Extensions defined in this document deliberately don't provide a way
   to modify annotations.

Spencer: The next two paragraphs punt to "same as sieve script" - could you
provide a specific reference for the reader here? Just the reference would
be fine, nothing else needed.

   A failure to retrieve data due to the server storing the annotations
   being down or otherwise inaccessible may alter the result of Sieve
   processing.  So implementations SHOULD treat a temporary failure to
   retrieve annotations in the same manner as a temporary failure to
   retrieve a Sieve script.

   Protocols/APIs used to retrieve annotations MUST provide the same
   level of confidentiality as protocols/APIs used to retrieve Sieve
   scripts.

6.  IANA Considerations

   IANA is requested to add the following registrations to the list of
   Sieve extensions:

   To: [email-masked]
   Subject: Registration of new Sieve extension
   Capability name: mailbox
   Description: adds test for checking for mailbox existence and a new
   optional argument to fileinto for creating a mailbox before
   attempting mail delivery.
   RFC number: this RFC

Spencer: you probably want to add notes to IANA and the RFC Editor to
replace "this RFC" with the RFC number when it is assigned (just make it
easier for them).

   Contact address:
       The Sieve discussion list <[email-masked]>

   Capability name: mboxmetadata
   Description: adds tests for checking for mailbox metadata item
   existence and for retrieving of a mailbox metadata value.
   RFC number: this RFC
   Contact address:
       The Sieve discussion list <[email-masked]>

   Capability name: servermetadata
   Description: adds tests for checking for server metadata item
   existence and for retrieving of a server metadata value.
   RFC number: this RFC
   Contact address:
       The Sieve discussion list <[email-masked]>

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Dec 2008 21:11:09 +0300

> Summary: Almost ready for publication as a Proposed Standard. Please see
Hi Spencer,
Thank you for your review.
> suggest that this be consistent.
Ok.
In my experience RFC editors are quite good in catching this type of 
thing. But I will fix that if I need to publish another revision before 
publication.
> provide a specific reference for the reader here?
Reference to the Sieve document?
> Just the reference would
Ok.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 23 Dec 2008 12:41:24 -0600

Hi, Alexey,

Thanks for the quick response back... now I can remember what I said in the 
review ;-)

Spencer

> thing. But I will fix that if I need to publish another revision before 

I think all of my comments could be handled as RFC editor notes, if Lisa 
prefers that - I'm good either way.

> Reference to the Sieve document?

If that's where the security considerations for sieve scripts are located - 
that would be fine.

>> replace "this RFC" with the RFC number when it is assigned (just make it

Thanks again, and have a great week.

Spencer