[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-freed-sieve-notary-03.txt
> Hi Ned, a really brief review below...
Thanks for taking the time to do it.
> On Thu, Jan 15, 2009, Internet-Drafts@xxxxxxxx said:
> >
> > Title : Sieve Email Filtering: Delivery Status Notifications Extension
> > Author(s) : N. Freed
> > Filename : draft-freed-sieve-notary-03.txt
> > Pages : 8
> > Date : 2009-01-15
> >
> > This document describes the "envelope-dsn" and "redirect-dsn"
> > extensions to the Sieve email filtering language. The "envelope-dsn"
> > extension provides access to additional envelope information provided
> > by the delivery status notification extension to SMTP defined in RFC
> > 3461. The "redirect-dsn" extension extends Sieve's redirect action
> > to provide control over delivery status notification parameters.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-03.txt
> >
> In Section 4.0:
> The "relational" extension [RFC5231] adds a match type called
> ":count". The count of an envelope test of with an envelope-part of
> ^^^^
> Leftover word "of".
Fixed.
> In Section 4.1 I do not understand the examples :-(
Not sure what to say to that ... I tried some wordsmithing in hopes of making
things clearer, but really, I don't think these are all that complex or obscure
as long as you understand the DSN extension, which seems like a prerequisite
here.
> In Section 5.0:
> Usage: redirect [NOTIFY] [RET] <address: string>
> It seems awkward to me to mix the formal EBNF with the more casual usage
> description. This would be better IMHO:
> Usage: redirect [:notify "value"] [:ret "FULL"|"HDRS"]
> <address: string>
> (Unless other extensions are already doing inline EBNF, in which case
> consistency says keep it that way, but I personally don't prefer it.)
I'm not sure what the state of play is but this has already confused at least
one reader I know of. So I'm going to try it your way.
> Also Section 5.0:
> These parameters are only available when the delivery status
> notification (DSN) ESMTP extension is available; they are simply
> ignored and MUST NOT cause an error if the DSN extension is
> unavailable.
> Easier to understand like this:
> These parameters are only available when the delivery status
> notification (DSN) ESMTP extension is available. When the DSN
> extension is not available, the parameters MUST be ignored and
> MUST NOT cause an error.
Changed.
> Section 5.1:
> One possible use of :notify on redirect is to ccmbine the copy
> ^^^
> Misspell of "combine".
Fixed.
Ned