Document: draft-ietf-sieve-3028bis-09.txt Reviewer: Sharon Chisholm Review Date: Tuesday 11/21/2006 3:05 PM CST IETF LC Date: 11/01/2006 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments -------- Note that since this was a bis, I mostly avoided comments that would have led to massive rewrites of existing text. 1. In section 1, third paragraph, replace "MTA" with Mail Transfer Agent (MTA)". In general, I think it would be good to define each acronym once in the document. 2. In section 1.1, last paragraph, first sentence, replace "The formal grammar for these commands in section 10 " with "The formal grammar for these commands is defined in section 10 ". 3. In section 2.4, there is some general confusion as a reader between the date types defined in this document and their normal use in technical discussions. The most amusing is in section 2.4.1 where it says "those numbers that have a tendency to be fairly large". I realize this is a bis, but the document would be clearer if a distinction was made between the number type and the string type and just numbers and strings. Section 2.5.1 uses the term 'syntax element', which might be generally useful. 4. In section 2.4.2.1, first paragraph it says "Implementations are encouraged to use short-circuit evaluation in these cases." This seems an arbitrary and somewhat obvious bit of implementation advice. 5. In section 2.4.2.2, third paragraph, replace "synactically" with "syntactically" twice. 6. In section 2.4.2.2, third paragraph, this is very oddly worded (and new to this revision). It seems a round about way of saying that invalid header names are ignored. 7. In section 2.4.2.3, it says "addresses must be compliant with [IMAIL], but are further constrained.", but it doesn't say where. Should that read "addresses must be compliant with [IMAIL], but are further constrained within this document." 8. Section 2.5.1 gives an example but no syntax. Is it a common separated list inside round brackets? 9. In section 2.8. first paragraph, last sentence is "and how", which seems to be an editorial error. 10. In section 2.8, second paragraph is says "commands supplied in this memo, there are no loops.", but in the first paragraph is says "Such a command is a control structure: when executed it has control over the number of times the commands in the block are executed." which sounds like a loop. 11. In section 2.10.2, fourth paragraph, it says 'None of the actions specified in this document meet that criteria, but extension actions will', but I expect that should be 'None of the actions specified in this document meet that criteria, but extension actions may', unless we are setting a requirement that all extensions MUST meet this criteria. 12. In section 2.10.3, it says that "Implementations SHOULD NOT deliver a message to the same mailbox more than once", but it doesn't indicate under which circumstances it would be OK to do this. 13. In section 2.10.5, third paragraph, it says "If a script does not understand an extension declared with require, the script must not be used at all.", which seems to be confusing the thing reading the script and the script itself. 14. In section 2.10.5, the "Note" tries to justify why you have require statements when they don't really provide any useful information like location of library or include file. This seems to be missing the only reason that makes sense to me. Either you don't have an explicit require and all extensions supported on the system apply to the script in question, perhaps resulting in some unanticipated behaviour if these extensions modify behaviour in a way not anticipated or you make the script indicate explicitly which extensions it wants to apply to itself. The latter is potentially more annoying but more predictable. A note should be added to explain this justification for forcing the require. 15. In section 2.10.6, the new text added in this release is an improvement. Is it possible to delete the old text? It is very loose and does not sounds like a standards document. 16. In section 3.1, the paragraph that starts with "When the interpreter", should the last "runs the else case." be "runs the else block"? 17. Section 4 defines terms that have been used for 20 pages. It would be good to define keep, fileinto, redirect, and discard briefly in a terminology section at the beginning of the document.