[apps-discuss] Benoit Claise's No Objection on draft-ietf-appsawg-sieve-duplicate-09: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-appsawg-sieve-duplicate-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Background info:
While doing a PC migration, along with an email migration, I found myself
in the situation where
- I had some duplicate emails in thunderbird
- Some of my emails were already manually classified into folders. So it
was hard to discover those without redoing the manual classification.

This thunderbird add-on , http://removedupes.mozdev.org/, was very
helpful to me.

Discussing with Stephan Bosch, I understand that Thunderbird add-on is
used to remove duplicates from the user's mailbox, after delivery, while
this Sieve extension is used to detect duplicates while they are being
delivered. This is performed using a persistent duplicate tracking list
with unique ID values (typically the Message-ID) of previous deliveries
and not by searching the destination folder(s) for messages with a
matching ID.

The issue with the SIEVE extension is that you have to enable this
functionality in advance ... when you know that you're going to do
something dangerous. Maybe that works ... but that reminds me of
access-list management: "No, I will not do anything stupid! ... oops, I
can't access my device any longer!". Or maybe you probably expect this
SIEVE extension to be always on? I don't think it's mentioned.

Along the same line (and with my use case in mind):

  Implementations SHOULD let entries in the tracking list expire after
   a short period of time. 

I was thinking: "short" = seconds, or minute. So not applicable to my
email/PC migration use case.
I saw later:

   A default expiration time of around 7 days is usually
   appropriate. 

Good.

I like your 4 examples, but the one I was more interested into was: can
we send the duplicates into the same folder.
That would allow me to troubleshoot the root cause being the duplicates
(subscribed to 2 mailing lists, synch issue, redirection, etc.)

Bottom line: this draft could be improved by discussing the use cases you
have in mind. Certainly not a blocking factor though