[sieve] Status of draft-freed-sieve-notary

[Alexey Melnikov <[e-mail]>]

This document is past IESG review, but I am blocking approval of this 
document until the following SecDir issues (be Tero Kivinen) are resolved:

> Also in section 5, it should be made clear that the "bytime" can also
> be negative, if the bymode is "notify" and the message is already
> pasts is notification time.
>
> Section 5 also says that the "bytime" is "the initial integer part of
> the delive-by extension", but then comments that deliver-by by-time is
> decremented as message passes through the transport infrastructure.
> This does not make it clear whether the sieve filtering system should
> also decrement the number while message is waiting to be processed.
> I.e. if message was received earlier, but it took some time before the
> sieve email filter could be run on the message, should the "bytime" be
> the original time from the smtp MAIL FROM BY= part, or whether it is
> decremented.
> (This needs to be clarified for both "envelope-deliverby" and 
> "redirect-deliverby",

> because the answer is likely to be different for them.)
>
> Also the example in 5.1 is wrong, as it is only true if the sieve
> filter is run exactly when the deliver-by expired. It should compare
> whether the "bytime" is <= 0, not whether it is equal to 0 (note, that
> if the bymode is "return" then the "bytime" never should reach 0, as
> at that point mail is returned to the sender.
>
> In section 7 it should be made clear that ":bytime" parameter "<limit:
> number>" can be negative too, but it seems that RFC 5228 specifies
> that numbers can only be non-negative so I am not sure whether the
> usage is correct or not.

I am sure that Ned can do a better summary of his discussion with Tero, 
but he proposed several changes:

1). Restrict the bytime to be a non-negative value. I think this change 
needs WG consensus.

2) There was also a proposal to change relative times to absolute times. 
I personally like the idea, but I think this change would require WG 
consensus.

3) Another possible change related to this is to change the numeric 
parameters to be strings, so that they can be used with variables. For 
example, this would allow one to examine a deliverby value using 
envelope-deliverby extension and pass the value to redirect (using 
redirect-deliverby).