ietf-mta-filters
[Top] [All Lists]

more 3028bis comments

2005-07-05 13:52:04


Here's a few more comments about 3028bis (3028bis-02 specifically,
which is the latest one that I have seen).  Sorry if any of this
has already been addressed.

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 ?


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?


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").



2.9.     Commands

   ...

   > A control command is similar, but it takes a test as an argument, and
   > ends with a block instead of a semicolon.

same sort of thing as previous comment.  Maybe more like:

   A control command is a command that affects the flow of execution of
   the Sieve script in some way.  One form of a control command is a
   "control structure" which ends with a block instead of a semicolon.


   > A test command is used as part of a control command.  It is used to
   > specify whether or not the block of code given to the control command
   > is executed.

similarly, maybe say "control structure command"


2.10.5.  Extensions and Optional Features

   > Because of the differing capabilities of many mail systems, several
   > features of this specification are optional.  Before any of these
   > extensions can be executed, they must be declared with the "require"
   > action.

"require" is defined to be a control.  So... '"require" control' rather
than '"require" action'.



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.



3.      Control Commands
3.2.     Control Structure Require
3.3.     Control Structure Stop

The whole "structure" thing mentioned above.


3.1.     Control Structure If

   > Syntax:   if <test1: test> <block1: block>
   >
   > Syntax:   elsif <test2: test> <block2: block>
   >
   > Syntax:   else <block>

Shouldn't this be "else <block3: block> ?


5.1.     Test address

   > Example:  if address :is :all "from" "tim(_at_)example(_dot_)com" {
   >              discard;

recommend adding the  closing "}" here 



5.8.     Test not

   > Syntax:   not <test>

Shouldn't this be something like  "not <test1: test>"  ?




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.

There was some discussion about adding character escapes (\u etc);
this probably falls under the "substantive changes or additions"
prohibition, but maybe not.

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.

Yours,
-mm-


<Prev in Thread] Current Thread [Next in Thread>