On Tue, 2005-07-05 at 16:52 -0400, Mark E. Mallett wrote:
2.2. Whitespace
> Whitespace is used to separate tokens. Whitespace is made up of
> tabs, newlines (CRLF, never just CR or LF), and the space character.
> The amount of whitespace used is not significant.
This is specifically about whitespace in the Sieve language. So... how
many implementations violate this? i.e., does everyone generate an
error if a script's whitespace contains a naked CR or LF ?
does it matter? this text is unchanged from RFC 3028, so it will not
affect conformance.
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 think it's only "reject" in the original spec. I agree the text is
confusingly placed even in RFC 3028, and now that reject has been moved
to a separate document, the above text should follow along.
2.10.6. Errors
> When an error happens, implementations MUST notify the user that an
> error occurred, which actions (if any) were taken, and do an implicit
> keep.
Probably extremely nit-picky, but I've always wondered when I read
this "what user, and how do we notify them?" Some users have no
access to anything other than their mailboxes. I suspect that many
implementations will do some system-wide logging, which notifies the
admin, but not the user.
good question. delivering an error report to INBOX in addition to the
message is one way of solving this, but does anyone do this?
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.
we have envelope "from" for the e-mail address. we don't have anything
for the delivery date, but I suspect Ned is considering that for his
"date" extension.
There was some discussion about adding character escapes (\u etc);
this probably falls under the "substantive changes or additions"
prohibition, but maybe not.
Philip has tried to pave the way for it:
A quoted string starts and ends with a single double quote (the <">
character, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted
string is followed by either another backslash or a double quote.
This two-character sequence represents a single backslash or double-
quote within the string, respectively.
Scripts SHOULD NOT escape other characters with a backslash.
An undefined escape sequence (such as "\a" in a context where "a" has
no special meaning) is interpreted as if there were no backslash (in
this case, "\a" is just "a").
this allows future extensions to define a special meaning for "\a".
(you can find the discussion on this around 2005-03-08)
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 don't think this behaviour description is relevant for the main spec.
it can not be observed without the variables extension.
--
Kjetil T.