"Mark E. Mallett" <mem(_at_)mv(_dot_)mv(_dot_)com> writes:
...
2.4.2.4. MIME Parts
> In a few places, [MIME] body parts are represented as strings. These
> parts include MIME headers and the body. This provides a way of
> embedding typed data within a Sieve script so that, among other
> things, character sets other than UTF-8 can be used for output
> messages.
This still confuses me. Where is it referenced?
I don't think it is. Indeed, it don't think it was in RFC 3028 either.
The 'vacation' extension uses something like this with its ':mime'
keyword, but it has enough of a definition there that I don't think the
text in 3028bis is needed. Everyone say "bye" to section 2.4.2.4...
2.8. Blocks
> A control structure is a command that happens to take a test and a
> block as one of its arguments; depending on the result of the test
> supplied as another argument, it runs the code in the block some
> number of times.
This is inconsistent since "require" and "stop" are defined to be
control structures, and neither of them take a block as an argument.
Either reword the above, or change 3.2 and 3.3 so that they don't
use the word "structure" (with perhaps an intro in '3' defining
the use of "control structure" vs just "control").
Yeah, calling just the subset of control commands that have a block
argument "control structures" seems the way to go. I'll make the
wording tweaks.
...
3.1. Control Structure If
Shouldn't this be "else <block3: block> ?
...
5.1. Test address
recommend adding the closing "}" here
...
5.8. Test not
Shouldn't this be something like "not <test1: test>" ?
I agree. Done.
Other random comments:
The spec provides no way to access the "From_" line (which is the
"From<sp>" line with no colon that is added by some mail software.
While it's not part of RFC2822, and admittedly a minor concern at
best, that 'header' is often there, but inaccessible. I have no
solution, other than perhaps making "From_" a special header name.
See my other reply for why I disagree with this.
There was some discussion about adding character escapes (\u etc);
this probably falls under the "substantive changes or additions"
prohibition, but maybe not.
Right. The discussion on the list following the Minneapolis meeting
concluded that such a change should be left an extension, if anyone
wants to define one, and that the base spec should simply recommend that
scripts avoid superfluous backslashes.
The 'variables' extension has to specify greedy/non-greedy ":matches" ;
this really ought to be in 3028 so that extensions can consistently
follow whatever rule there is; although, again, it might fail the
"non-substantive" test.
I agree with Kjetil and Ned: this is only observable in the presence of
such extensions, so it should be left to them. Indeed, two extensions
could define the opposite semantics if they had separate means of
observing the results and while it would be a pain to implement, it
wouldn't be impossible.
(I somehow doubt the latter such extension would pass its last-call if
it didn't have a superb justification for the different choice. The
base-spec doesn't have to ban annoying extensions to keep them from
happening; alternatively, given the efficacy of the previous ban on
side-effects-in-tests, we should be disinclined from going that path
again. A ban is neither necessary, nor sufficient.)
Philip Guenther