[apps-discuss] Working Group Last Call draft-ietf-appsawg-sieve-duplicate

[t.petch <[e-mail]>]

This I-D seems to need more thought.

s.1 "For example, if a member of the list decides to
   reply to both the user and the mailing list itself, the user will
   one copy of the message directly and another through the mailing
   list.

Well, they MAY, but they don't on a good list system, such as the one in
use here.

"Also, if someone cross-posts over several mailing lists to
   which the user is subscribed, the user will receive a copy from each
   of those lists."

Ditto, not here.

"   Duplicate messages are normally detected using the Message-ID header
   field, which is required to be unique for each message.  "

REQUIRED maybe, but I seem to recall the malformed-mail I-D raising the
possibility that it was not.  In which case, ...?

s.3
"an earlier Sieve execution."
reading on it is apparent that this is any number of executions limited
by the size of the FIFO cache and the maximum lifetime of entries in the
cache.

"   Usage:  [":header" <header-name: string> /
                          ":uniqueid" <value: string>]

Why have two way of doing the same thing?  As I read it, this test is on
a header field, so why not have just ":header" with a default of message
I-D?

And what happens if I use header field X in one execution and then
header field Y in another? I presume separate caches for X and Y, in
which case, duplicates may not be detected.  The use of multiple fields
opens up all sorts of complications that need more explanation depending
on the concept of the scope of the operation, which I do not see clearly
explained.

"The user can explicitly control the
   length of this expiration time by means of the ":seconds" argument,
   which is always specified in seconds.  "

seconds seems short to me.  On the IETF lists, I typically see a gap of
several hours between a message on one list and a message on another
list, with four hours being the norm.  I would regard 5 minutes as the
minimum and 36 hours, or perhaps less, as the maximum.

"By adding the ":header" argument with a message header
   field name, the content of the specified header field can be used as
"

Does this apply to all headers? I assume it does, since if message I-D
is not used, then it would be an X- proprietary one that would seem to
me to be the next best thing.


"   If the tracked unique ID value is extracted directly from a message
   header field, i.e., when the ":uniqueid" argument is not used,"

you are saying that when uniqueid is not used, then a unique ID is used.
I think that this will cause confusion here and elsewhere - you need
another term than 'unique ID' as the collective noun for the identifying
string you are using in the equality comparison.

"leading and trailing whitespace MUST first be trimmed from the value"

This is a can of worms.  Normalisation often appears on these lists
without, usually, a satisfactory answer, let alone the issues of i18n.
More needs to be considered here.

So, nice idea, but more thought needed.

Tom Petch

----- Original Message -----
From: "Murray S. Kucherawy" <[e-mail]>
To: "IETF Apps Discuss" <[e-mail]>
Sent: Wednesday, January 01, 2014 3:05 PM
Subject: [apps-discuss] REMINDER: Working Group Last Calls still open


> Colleagues,
>
> I know many of us are busy or away possibly until next week.  This is
just
> a reminder that there are three documents in Working Group Last Call
state,
> extended for the holidays.  After two and a half weeks, there has been
a
> lot of commentary on one of them, a small amount on a second, and none
on
> the third.  Please remember to schedule some time to provide reviews
and
> commentary on all of them early in the new year so they can be
advanced to
> make room for new work.
>
> The documents are:
>
> draft-ietf-appsawg-sieve-duplicate
> draft-ietf-appsawg-rrvs-header-field
> draft-ietf-appsawg-xml-mediatypes
>
> Happy 2014 to everyone!
>
> -MSK, APPSAWG co-chair
>


------------------------------------------------------------------------
--------


> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>