Re: more 3028bis comments

[Kjetil Torgrim Homme <[e-mail]>]

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.