![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi, Alexey,Thanks for the quick response back... now I can remember what I said in the review ;-)
Spencer
Spencer Dawkins wrote: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.Hi Spencer, Thank you for your review.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.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.
I think all of my comments could be handled as RFC editor notes, if Lisa prefers that - I'm good either way.
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 youprovide a specific reference for the reader here?Reference to the Sieve document?
If that's where the security considerations for sieve scripts are located - that would be fine.
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: iana at iana.org 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).Ok.
Thanks again, and have a great week. Spencer
Contact address: The Sieve discussion list <ietf-mta-filters at imc.org> 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 <ietf-mta-filters at imc.org> 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 <ietf-mta-filters at imc.org>
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.