[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