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

draft-ietf-sieve-3028bis-09

2006-12-06 13:01:13

Hi,

I was going over 3028bis-09 last night for a reread, and had a few
observations.  I realize that it's way past last call on this, and also
that one can never completely win (since things can be found on any new
reading.)  Then again, there have been comments since the drop-dead date
(like the non-negative vs positive numbers thing), and then again again,
I have these notes and nowhere to put them (that's not a setup line).

Ignore at will..



2.4.2.2. Headers
 ...
   Similarly, synactically invalid header names cause the same result as

"synactically" should be "syntactically"



2.8.     Blocks

   Blocks are sets of commands enclosed within curly braces and supplied
   as the final argument to a command.  Such a command is a control
   structure: when executed it has control over the number of times the
   commands in the block are executed.  and how

".  and how" ?  (dangling words)


3.3.     Control Stop

   Usage:   stop

   The "stop" action ends all processing.  If no actions have been
   executed, then the keep action is taken.

While that's correct, it's not really inclusive enough.  I think the
point is that the implicit keep should still be taken if it is
outstanding-- NOT just subject to whether or not any actions have been
taken.   i.e., "If the implicit keep has not been cancelled, it is
taken."



4.2.     Action redirect

   Usage:   redirect <address: string>

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or existing
   headers, but it may add new headers.  The "redirect" modifies the
   envelope recipient.

a) 'The "redirect" action modifies' rather than 'The "redirect" modifies'.
(or remove the quotes, i.e. 'The redirect modifies'.)

b) I know what the writer meant, but I don't think it's clear.  The
action doesn't really modify the envelope recipient.  i.e., a subsequent
test of 'envelope "to"' should still show the original envelope
recipient.  The text says to me that it won't.  I think what's meant is
that a new message is created which has a new envelope recipient.



4.3.     Action keep

I wonder if this oughtn't say that it cancels the implicit keep.


5.1.     Test address
 ...
   Internet email addresses [IMAIL] have the somewhat awkward
   characteristic that the local-part to the left of the at-sign is
   considered case sensitive, and the domain-part to the right of the
   at-sign is case insensitive.  The "address" command does not deal
   with this itself, but provides the ADDRESS-PART argument for allowing
   users to deal with it.

I note that this has the same issue as with the mime type test: one
can't do a test of both parts of an address separately since one can't
guarantee that the parts came from the same address.  That is, there
really isn't anything here (without, say, variables) that allows users
to deal with it, except for the case where there is only one address.
I guess I would just put a period after "itself" and remove the rest of
the sentence.


5.4.     Test envelope

This section does not say that it requires "envelope" capability.  It is
implied in the example, but not stated.


9.      Extended Example

            # If message header does not contain my address,
            # it's from a list.

Comment doesn't match code.  Leftover from previous edit?
(has been mentioned before)

            # Move all other (non-company) mail to "personal"
            # mailbox.

ditto... 



10.     Security Considerations

   Implementations SHOULD take measures to prevent languages from
   looping.

I think it means "messages" not "languages"


Yours with apologies,
-mm-

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