Re: Three new drafts and a question

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

[Jutta Degener]:
>
>   I sent out three new sieve drafts last week that may be of interest:
>   
>    <http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
>     	
>   	fileinto :copy, redirect :copy -- keyword parameter that
>   	prevents cancelling the implicit "keep".

great idea!  a small typo, quotes are missing around ":copy" in

   Syntax:
        "fileinto" [:copy] <folder: string>
        "redirect" [:copy] <folder: string>

>    <http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>
>     	Deleting, adding, and changing message header fields.


| 5. Action replaceheader
|    [...]
|    The field-name is mandatory and always matched as a
|    case-insensitive us-ascii string.

I take it you mean an exact match (:is) ?  the following shouldn't
work:

   replaceheader "Original-*" :newname "${1}"

but it would be interesting, eh?  actually, :matches could be the
mandatory match type for the field-name, I don't think it influences
the rest.  if you do

   replaceheader "Original-*" :newname "${1}" :matches "*foo" :newvalue "${1}"

this will _not_ work, since the value match will run after the field
name match, and thus destroy the contents of the back references.

btw, it is interesting that this extension requires variable
references in strings to be resolved inside the action itself.  it
makes me wonder if I should add a "Note to implementers" in the
variables draft about this.

| 7. Security Considerations
|    [...]
|    A sieve filter that removes headers may unwisely destroy
|    evidence about the path a header has taken.

perhaps tampering with "Received" should be explicitly forbidden.
(even with that restriction, the above warning must be kept.)

>    <http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
>     	
>   	Sequential execution of (unrelated) sieve scripts by the
>   	environment.  A meta-feature -- it doesn't define new sieve
>   	language elements -- that's interesting in particular in
>   	contrast to Cyrus's "include" draft.

yes, I think they both are useful.  this is for site configuration,
"include" is for user convenience.

| 4. Locality of script actions
|    [...]
|    For sieve engines that implement the "variables" extension,
|    variable state is not carried over between scripts.

I think this is the right choice, since a set of scripts using
"include" should be considered _one_ script and variable state thus
carry over in that single script.  this also fits in with:

|    The "stop;" command ends the execution of its single
|    containing script, not of scripts in general.

so the "return" in Cyrus's draft is still useful.

I agree that a capability string is unnecessary.

>   There may or may not be another one for fileinto in the wings.
>   It's about Kjetil's open issue 0.3 b):
>   
>   Some implementations of "fileinto" create IMAP folders on the
>   fly if they don't exist; others don't.  (They redirect to
>   the inbox instead.)  Sieve doesn't proscribe either way.
>   
>   My own implementation used to only reuse existing folders; but now
>   that we're thinking about creating them on demand in conjunction
>   with the "variables" extension, I'm getting requests for a way for
>   a user to express their intention; something like
>   
>   	fileinto :create 	"If it doesn't exist, create it"
>   or
>   	fileinto :exists	"If it doesn't exist, redirect to INBOX."
>   
>   or something in that area.

it is unfortunate that behaviour is undefined.  both behaviours are
useful, so I think both should be in the draft.  well, the draft could
instead mandate fileinto to file into INBOX if the folder doesn't
exist and ":create" isn't specified.  this can also serve as a hint to
new implementers of Sieve.

-- 
Kjetil T.