[Top] [All Lists]

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

2013-03-15 13:24:17
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.

   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.

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

(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.

(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.

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.

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

(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.

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

sieve mailing list