I have reviewed draft-ietf-sieve-3028bis-12.txt and that draft has sufficient
quality that I will vote "yes" for it to become proposed standard.
However, I have found enough issues during review that the improvement in a
draft 13 based on the non-controversial comments I've made would be worth the
delay, IMHO.
One particular issue, marked with "***" below is a cross-WG compatibility issue
-- the sort of issue it is my job as area director to catch.
As AD I do not wish to impose engineering decisions on WGs except in egregious
cases, so I do not require the WG to fix any of the issues listed below. The
WG is free to say "-12" is good enough. In that case consider these comments
fodder for 3028ter.
- Chris Newman
Applications Co-Area Director
-----
Section 1, 4th paragraph
the Mail Transfer Agent (MTA) does final delivery, such as
traditional Unix mail, it is reasonable to sort when the MTA deposits
mail into the user's mailbox. ^^^^
Q: Should that be "filter"?
Implementations MUST support integer values in the inclusive range
zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.
Q: Is there a Sieve capability to indicate support for larger numbers?
section 2.4.2.1. String Lists
Conversely, in any case where a list of strings is appropriate, a
Awkward wording.
Q: Perhaps this text should mention empty lists are forbidden to align with the
ABNF?
Section 2.5
actions. In this document, tests are given to if/elsif/else to
Q: Are tests "given" to else?
Section 2.6.2
To simplify this specification, tagged arguments SHOULD NOT take
tagged arguments as arguments.
Q: How does what future standards choose to do with tagged arguments make this
specification simpler? Perhaps just remove "To simplify this specification, "?
Section 2.6.3
different orderings on UTF-8 [UTF-8] characters.
The ordering and equality rules of a comparator apply to strings, not
characters. So this could be made more precise.
There are three match types describing the matching used in this
specification: ":is", ":contains", and ":matches". Match type
arguments are supplied to those commands which allow them to specify
what kind of match is to be performed.
Awkward wording.
Section 2.7.1
in use. In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
defines a character to be any UTF-8 octet sequence encoding one
Perhaps just say "a Unicode-based comparator would define ..." since the basic
comparator got split out of the base spec and could change dramatically.
Section 2.10.4
Site policy MAY limit numbers of actions taken and MAY impose
numbers -> the number
Section 2.10.5
Implementations MUST NOT execute at all any script which requires an
Perhaps drop the "at all"
Experience with PostScript suggests that mechanisms that allow
a script to work around missing extensions are not used in
practice.
This statement would argue that the proposed "ihave" action needs to go
experimental until utility is demonstrated at which point this text would be
misleading.
Extensions which define actions MUST state how they interact with
actions discussed in the base specification.
Q: Isn't this redundant with the last paragraph of section 2.10.1?
2.10.7. Limits on Execution
Q: There is no mention of limits on script size, string size, or list size.
Should there be?
Section 4.2
The message is send back out with the address from the redirect
send->sent
Section 5.1 ***
There's some tricky interaction with IDN and EAI here. It could be clarified
with text like: A Sieve implementation for use with Internet email MUST support
the use of IDN-encoded domain names [IDN] in the key-list. A Sieve
implementation MAY support use of UTF-8 for domain names in the key-list (a
subsequent Sieve extension could add a capability name to require that
behavior).
Section 5.4
command. The null reverse-path is matched against as the empty
string, regardless of the ADDRESS-PART argument specified.
Awkward wording.
Personally, I would have preferred unknown envelope parts were ignored. In the
case of EAI, I'd include "alt-address" in most tests but wouldn't care if the
implementation supports it. I could always add a require "alt-address" to the
script if I really needed it to work. With the "unknown envelope parse SHOULD
result in an error", one has to use the ihave extension to support the "don't
care if it works" case.
Section 5.9
Note that for a message that is exactly 4,000 octets, the message is
neither ":over" 4000 octets or ":under" 4000 octets.
^^
nor
As the range of mail systems that this document is intended to apply
to is quite varied, a method of advertising which capabilities an
implementation supports is difficult due to the wide range of
possible implementations.
I suggest removing all text up to and including the "," to simplify this
sentence.
Section 8.1
multiline-dotstuff = "." 1*octet-not-crlf CRLF
This name is misleading because it covers all lines starting with a dot,
whether or not they are dot-stuffed. Perhaps it should be "multiline-dotstart".
Section 10
Implementations SHOULD take measures to prevent scripts from looping.
Q: Isn't this trivially true because Sieve scripts have no loop command?
Perhaps you meant to say "creating mail loops" instead of "looping".
Section 13
[COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet
Application Protocol Collation Registry" draft-
newman-i18n-comparator-07.txt (work in progress),
March 2006.
Now RFC 4790...Thanks Arnt!
Section 15
This is missing some important changes.
10. Added encoded-character capability and deprecated (but did not remove)
use of arbitrary binary in Sieve scripts.
11. Updated IANA registration template, and permit capability prefix
registrations. Prefix registrations outside "vnd." require IESG approval.
12. Added .sieve as a valid extension for sieve scripts.
- Chris