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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve