Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-01.txt

[Stephan Bosch <[e-mail]>]

Hi Ned,

Op 3/15/2013 6:39 PM, Ned Freed wrote:
>> Any thoughts about this?
>
> Sorry to take so long to respond; I finally managed to complete my
> implementation yesterday.
>
> In implementing this, I saw nothing about the semantics of the test I 
> would
> like to see changed. I really like the clever way the single word 
> "duplicate"
> ends up doing the right thing in most cases.
>
> The draft also seems pretty complete, although a couple of clarifications
> are needed:
>
> (0) A clear execution model is really important here. In particular, 
> the way
>    this has to be implemented is that during sieve execution queries
>    whatever back end database you're using but does *not* update it.
>    Only after the sieve has been evalauted without error and the actions
>    it specified have been perform should the database be updated.

Ok, I'll improve that a bit.

>    I note that the same applies in environments that support multiple 
> sieves -
>    you evaluate them all, apply the results, and for the subset of sieves
>    that evaluated without error, perform the updates. I'll also note 
>    that how duplicate tests in multiple scripts interact is tricky. I
>    eventually decided to qualify duplicate with the sieve "owner", which
>    then acts like another handle.
>
>    I don't see any reason to get into the multiple scripts bit in the 
> draft;
>    I'm just noting it in case someone is interested.

Agreed. Perhaps when someone finishes the multiscript draft at some 
point, it could be mentioned there.

> (1) The draft says nothing about what happens when the specified header
>    field does not exist. The test should fail unconditionally in this 
> case.

Agreed.

> (2) The draft says nothing about what happens when there are more than 
> one
>    of the specified fields present. It should say that the first one
>    that is found is used.

Yes, good catch. This is what my current implementation does too.

> (3) The draft probably should say that duplicate does not support 
> either the
>    index or mime extensions directly (:index, :mime:, and :anychild), and
>    that if you want to perform such checks you can do them with variables
>    and :value.

Yes, always good to give hints in the right direction.

> And finally, a few nits:
>
> (1) The "MUST throw a compile time error if both :header and :value are
>    specified" is a bit strong. For one thing, such a check is 
> inappropriate
>    if ihave is in effect. And for another, while I was able to implement
>    it, it may not be convenient for all implementations to perform this
>    check at compile time.

I'm not sure what you mean here. Do you want me to make the kind of 
error more open, e.g. by adopting the wording used for the :zone and 
:originalzone arguments for the date extension?

`It is an error to specify both :zone and :originalzone.'

Which basically leaves the kind of error up to the implementer. I have no problem with that.

> (2) I'm wondering if it wouldn't be best to suggest a default timeout.
>    12 hours? A day?

It can be useful. Anyone else got suggestions or comments about this?

> (3) A MUST be case-sensitive is probably a good idea, perhaps with a note
>    as to how you can use the set action to muck around with case.

Yes, otherwise users could get surprised at some point.

> That's it! Thanks for producing such a good draft!

Thanks. I'll make a new version some time next week.

Regards,

Stephan.