Subject: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Dec 2013 19:41:14 -0800

Can we get some reviewers for this draft, please?

-MSK

On Mon, Nov 4, 2013 at 9:10 AM, Stephan Bosch <[email-masked]> wrote:

> On 11/4/2013 4:12 PM, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the Applications Area Working Group
> Working Group of the IETF.
> >
> >       Title           : Sieve Email Filtering: Detecting Duplicate
> Deliveries
> >       Author(s)       : Stephan Bosch
> >       Filename        : draft-ietf-appsawg-sieve-duplicate-01.txt
> >       Pages           : 11
> >       Date            : 2013-11-04
> >
> > Abstract:
> >    This document defines a new test command "duplicate" for the "Sieve"
> >    email filtering language.  This test adds the ability to detect
> >    duplicate message deliveries.  The main application for this new test
> >    is handling duplicate deliveries commonly caused by mailing list
> >    subscriptions or redirected mail addresses.  The detection is
> >    normally performed by matching the message ID to an internal list of
> >    message IDs from previously delivered messages.  For more complex
> >    applications, the "duplicate" test can also use the content of a
> >    specific header or other parts of the message.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-01
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-01
>
> The following changes were made in the draft:
>
> - Documented that the expiry time of entries in the duplicate tracking
> list is measured relative to the initial message.  When needed, this can
> also be performed relative to the last received duplicate by specifying
> the new `:last' argument.
> - Mentioned interaction with "imapsieve" extension and marked providing
> the "duplicate" test in the context of "imapsieve" as NOT RECOMMENDED.
> I've made a separate section for interaction with other Sieve extensions
> in the process.
> - The draft now explicitly states that the message ID value is tracked
> independent from its source, meaning that it doesn't matter whether it
> is the value of the Message-ID header, the value of some other arbitrary
> header specified using `:header', or a explicit string value provided
> using the `:uniqueid' argument.
> - Addressed a few editorial comments by Ned Freed.
>
> Any comments are welcome!
>
> Regards,
>
> Stephan.
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 03 Dec 2013 07:12:01 -0800 (PST)

> Can we get some reviewers for this draft, please?

I meant to follow up on this; sorry. Anyway, Stephan and I have been
working on this offline and I've reviewed it pretty carefully. I'm happy
with the current version.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 04 Dec 2013 10:59:26 -0500

Hi Murray,
Please note discussion of this draft started on the SIEVE mailing list 
(mailto:[email-masked]>). I have posted a message there asking for reviews 
to be posted to apps-discuss.

> Can we get some reviewers for this draft, please?

My review:

I only minor/editorial issues. This is a potentially useful extension and 
should be standardized.

Minor issues:

- §3 talks about how :header field values are normalized (leading/trailing 
spaces removed). I don’t see any text about how Message-ID ought to be 
normalized - is that needed?
- §3: talks about using SIEVE-MIME to extract message body text, but what 
about the SIEVE body extension (RFC 5173)?
- §5.3: some of the examples have “if” statements that erroneously end 
with a “)”
- §5.3: I would like to see an example of the use of :handle as I am not 
entirely sure when that would be applicable
Editorial:

- Abstract - no need to quote Sieve
- §1 ¶2: change "through mailing list” to "through the mailing list”
- §3 ¶6: change "If that limit is exceeded,” to "If that limit is 
exceeded by the “:seconds” argument,”
- §5.2 ¶2: change "script above the” to "script above, the”
- §6 ¶1: change "Implementations therefore SHOULD implement limits” to 
"Implementations SHOULD apply limits"

-- 
Cyrus Daboo

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 05 Dec 2013 09:39:50 +0100

Hi,

On 12/4/2013 4:59 PM, Cyrus Daboo wrote:
> I only minor/editorial issues. This is a potentially useful extension
> and should be standardized.
>
> Minor issues:
>
> - §3 talks about how :header field values are normalized
> (leading/trailing spaces removed). I don’t see any text about how
> Message-ID ought to be normalized - is that needed?

Yes that is need. It is mentioned, albeit indirect: "If the tracked
unique ID value is extracted directly from a message header field, i.e.,
when the ":uniqueid" argument is not used, leading and trailing
whitespace (see Section 2.2 of RFC 5228 [SIEVE]) MUST first be trimmed
from the value before performing the actual duplicate verification.".
This statement is perhaps a bit too indirect, so I'll make it more explicit.

> - §3: talks about using SIEVE-MIME to extract message body text, but
> what about the SIEVE body extension (RFC 5173)?

As stated in RFC5173, Section 6
(http://tools.ietf.org/html/rfc5173#section-6) the body test is exempt
from setting match variables in combination with the variables extension
and therefore it cannot be used to extract text from the message body
for use with the "duplicate" test.

> - §5.3: some of the examples have “if” statements that erroneously end

Right. I should feed these to my compiler. I will fix these.

> - §5.3: I would like to see an example of the use of :handle as I am
> not entirely sure when that would be applicable

So, just to be clear: do you want an example of why :handle is useful,
or do you want an example of how :handle works?

> "Implementations SHOULD apply limits"

Thanks for the review!

I'll make a new version within a week.

Regards,

Stephan.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 05 Dec 2013 09:53:42 -0500

Hi Stephan,

> or do you want an example of how :handle works?

I guess I am more interested in why it is useful (and thus whether it is 
needed at all). Based on that, it may or may not be worthwhile to include 
an example.

-- 
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Mon, 09 Dec 2013 22:41:49 -0800 (PST)

> needed at all). Based on that, it may or may not be worthwhile to include

As the draft states, :handle is so a single user can have multiple independent
tests of the same string value (Message-id: or whatever) and they won't
interfere with each other. An obvious use-case would be a script that
has been built up from multiple sources.

:handle isn't essential; you can do the same thing with variables, set, and
:uniqueid. But it's a hassle, and the one of the really nice things about this
extension is it presents itself in such a simple way.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 11 Dec 2013 23:49:47 +0100

Hi,

>> and should be standardized.

Most of your comments were processed in the -02 I just uploaded.

Ned answered your question about the :handle argument. Is that answer
satisfactory? Do you think that topic requires more clarification in the
document?

Regards,

Stephan.