Subject: [Gen-art] Re: Gen-art review of draft-ietf-sieve-3028bis-09.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Feb 2007 14:23:03 +0000

Sharon Chisholm 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-ietf-sieve-3028bis-09.txt
>
>Summary: This draft is basically ready for publication, but has nits
>that should be fixed before publication. 
>
Hi Sharon,
Thanks again for your comments, I think they improved readability of the 
document!

Philip just published draft-ietf-sieve-3028bis-10.txt, which I believe 
addressed all important comments.
This is just to followup on your message in case Philip didn't do that 
already.

>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.
>
I believe that issues 1-9 are fixed.

>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.
>  
>
This change was not done.
As the base Sieve language doesn't support looping for more than 1 time, 
I don't think this change is needed.

>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. 
>  
>
I believe issues 11-16 are fixed.

>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.
>  
>
Philip didn't do that. If you still want this change to be done, you 
need to suggest some specific changes.

>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"?
>
I believe this is fixed.

>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.
>
The terms are now defined in section 2.9 instead.

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