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

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 21 Nov 2006 16:04:59 -0500

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. 

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.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Nov 2006 15:19:53 +0000

>have led to massive rewrites of existing text.
Hi Sharon,
Thanks for the comments. I've quickly scanned through them (and I think 
they are mostly correct) and will only comment on two of them. Philip 
should comment on the rest.

>an arbitrary and somewhat obvious bit of implementation advice.
This text is trying to say that implementations may (even MAY) use 
short-circuit evaluation.
I agree that this section might not be the obvious place for this kind 
of advice, but I think it is Ok.
Unless you want to have a separate section stating implementation 
considerations?

>under which circumstances it would be OK to do this.
This sentence is trying to say that implementations SHOULD support 
duplicate elimination when a message is delivered to the same mailbox, e.g.

fileinto "ABC";
fileinto "ABC";

should just behave as:

fileinto "ABC";

I can't think of any other case when duplicate elimination would be Ok.

Regards,
Alexey

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Nov 2006 12:14:21 -0500

Hi

> This text is trying to say that implementations may (even 
> MAY) use short-circuit evaluation.
> I agree that this section might not be the obvious place for 
> this kind of advice, but I think it is Ok.
> Unless you want to have a separate section stating 
> implementation considerations?

I don't think we need an implementation section. The text just struck me
as an odd thing to include.

> This sentence is trying to say that implementations SHOULD 
> support duplicate elimination when a message is delivered to 
> the same mailbox, e.g.
> 
> fileinto "ABC";
> fileinto "ABC";
> 
> should just behave as:
> 
> fileinto "ABC";
> 

Sorry, what are the cases when duplicate elimination shouldn't be done?
Or are you agreeing there aren't any and perhaps we should change this
to a MUST?

Sharon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Nov 2006 22:56:51 +0000

Hi Sharon,

>as an odd thing to include.
So basically you are not objecting to the text?

>Sorry, what are the cases when duplicate elimination shouldn't be done?
I don't think there are any, but the WG didn't want to mandate any 
duplicate elimination.

>Or are you agreeing there aren't any and perhaps we should change this
**