Attached is my review of the specified document, submitted as part of the Gen-ART process. For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Document: http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-04.txt Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: 1. In section 2, it says "Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 1.1.", but it isn't clear which notations one would expect to find there. 2028bis describes itself as "a language for filtering email messages at time of final delivery". Could we instead then say "This document uses the language for filtering emails at the time of final delivery defined in [I-D.ietf-sieve-3028bis]. It therefore uses the grammar and conventions defined within that specification.". Note that section 1.1 is not self contained so pointing only to that section doesn't seem sufficient. Also, the reference in its current form under-sells the fact that a reasonable understanding of the language defined in 3028bis is required for this document to make any sense. 2. There appears to be something magical about being able to split the local address into its two pieces - user and detail. The document does already have a number of disclaimer around this, but it doesn't quite seem sufficient. 2.1 Perhaps if the document contained some elements of procedure that went something like - Perform implementation/mail-system specific method of parsing out user and detail from local address - Use these two values to evaluate the statements defined in the sieve language, including this subaddressing extension 2.2 Can we get more prescriptive as to what the encoding would be for specific mail systems? 3. For the security considerations section, are there not any new ways to badly format an email address as a result of this extension that could cause damage to either the mail server or the user? 4. The use of double quotes in this document is quite confusing. Some instances are to indicate values of fields or of keywords in the sieve language. Others appear to be random words in sentences. I realize this is not a change from the previous version of the RFC, but it does make the document awkward. The editor should determine what double quotes are being used for in the document, ensure this both adds clarity and makes grammatical sense and then delete all other occurrences. 5. The section "Meta-information on this document" provides some information that presumably the RFC editor is to remove. The section is not very specific on exactly what information needs to get removed and by whom. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
