Re: [sieve] review of draft-freed-sieve-notary-06

[[e-mail]]

> Section 4:

> >   orcpt -  Match the original recipient, or ORCPT, value in decoded
> >      form associated with the TO address used in the SMTP RCPT TO

> The term "in decoded form" is vague and can be interpreted different ways
> (for example, I might consider removal of the "rfc822;" prefix to be part
> of decoding :-).

> I suggest this say "with xtext encoding (RFC 3461 section 4) removed".

That doesn't really work as a replacement for "in decoded form", so I changed
the item to read:

Match the original recipient, or ORCPT, value associated with the TO address
used in the SMTP RCPT TO command that resulted in this message getting
delivered to this user, with xtext encoding removed. The syntax and semantics
of the ORCPT parameter are defined in Section 4.2 of [RFC 3461]. 

> Section 6:

> >   notify-value = DQUOTE notify-esmtp-value DQUOTE

> The "notify-esmtp-value" can be interpreted to allow comments, empty comma
> fields and folding whitespace.  You either have to outlaw that in prose or
> have a bit more detail.  I suggest:

>    notify-value = DQUOTE ("NEVER" / notify-esmtp-list) DQUOTE

>    notify-esmtp-list = notify-list-element *("," notify-list-element)

> >   The notify-esmtp-value production is defined in Section 4.1 of
>         ^^^^^^^^^^^^^^^^^^
>         notify-list-element

Changed.

> Author's Address:

> >   Sun Microsystems
>     Oracle

Changed ;-)

> Q: Is there a reason this didn't deal with FUTURERELEASE (4865) at the same
> time?

Because Sieve is defined as operating at or around the time of final delivery.
Future release information cannot be present at that point. Delivery-by, OTOH,
last right up to the final delivery point, same as notary.

				Ned