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

[Alexey Melnikov <[e-mail]>]

Hi Ned,
[All my comments are with AD hat off, unless otherwise specified]

Ned Freed wrote:

> I just posted a revised version of this draft. There are three very 
> important
> changes I've made in response to various last call comments that the 
> WG needs
> to be aware of:
>
> (1) The draft used to be silent on what happens to the envelope from 
> address.
>    An issue was raised as to the potential to generate backscatter; I 
> believe
>    this issue to be specious but it brought up another, more reasonable
>    qeustion: What does it mean to specify the generation of DSNs when the
>    destination of those DSNs is implementation dependent? The only 
> sensible
>    answer I could come up with was to add text saying that when either
>    the redirect-dsn or redirect-deliverby extensions are used, any
>    non-empty envelope from MUST be replaced by the address of the 
> sieve owner.

Agreed.

Looking at the newly added section 7.1:

7.1.  MAIL FROM address selection

   RFC 5228 does not require any particular envelope sender address be
   associated with redirected messages.  However, the redirect-deliverby
   extension, like the redirect-dsn extension, isn't terribly useful if
   the place where any delivery status notifications are sent isn't
   known.  Accordingly, when :bymode is specified and the envelope

I think you should be using :bytimerelative or :bytimeabsolute here, as :bymode is optional.

   sender address isn't empty, implementations MUST set the envelope
   sender address to the address of the sieve owner.

> (2) The envelope-deliverby extension only provided by-time information in
>    relative form. Given the lack of arithemtic operations in Sieve, this
>    form isn't terribly useful and there are cases where an absolute time
>    string would be better. I have changed the draft to have both a
>    bytimerelative and bytimeabsolute envelope-part and an optional :zone
>    arugment. The absolute time is returned in restricted ISO 8601 format.

This looks sensible.

Two side notes:
a). Maybe we should add some basic arithmetics to Sieve. But this 
document is not the right place for that.
b). Do we really need both relative and absolute options? (I don't have 
a good answer.)

> (3) The redirect-deliverby extension only allowed a relative by-time 
> as well.
>    This supports the obvious use-case of "deliver the message in this 
> amount
>    of time", but it fails to allow for "deliver before this time" usages.
>    So I've changed this to have both :bytimeabsolute and :bytimerelative.
>
> A number of clarifications to the text have also been made; these are 
> noted
> in the revision history.
>
> Please review these changes; if the consensus is this goes to far I 
> can always
> back them out.
>
> There's also the question of whether or not this warrants a new last call.

(AD hat on) I am afraid it does. The changes are just to drastic to 
approve as is.

Some additional comments on the latest version:

1) The following extensions should be listed as Informative references:

  "date", "variables"

2) In Section 5.1:

   require ["envelope", "envelope-deliverby", "relational", "date"

Missing comma after "date".

            "variables"];


3) An example using :zone in envelope test would be useful as well.


> I'll leave that decision to those above my pay grade ;-)

I will share my bonus with you once I get it ;-).