Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT)

[Ned Freed <[e-mail]>]

> >>> The suggested default seems really long, especially for the example use
> >>> case described in Section 1.

Am I missing something? The first example is a straightfoward one where
message-id duplicates are filed to a special "Trash/Duplicate" folder. In such
a case basically the longer the retention interval the better things work.
Given the way message-ids are typically generated by most clients it's not like
the longer interval increases the liklihood of a duplicate occurring.
 
If the longer retention period has a downside for the user I am not seeing it.

So whether or not a 7 day retention is problematic really depends on the server
environment. If you're running a server for relatively small number of users,
i.e.., a small to medium sized enterprises, schools, small to medium sized
ISPs, etc. given the high liklihood that not everyone will opt to use this, and
given the power and capabilities of modern server hardware, I seriously doubt
that a 7 day default will cause any problems. An single instance of memcached
can handle an awful lot of entries of this type.

Of course a large ISP/MSP with users numbering in the many millions is going to
face a very different set of tradeoffs. But I have a sneaking suspicion that in
the unfortunately unlikely event that such a concern would bother to offer this
capability, they are capable of picking appropriate defaults, which the
document certainly allows.

And more generaly, it's not the the necessary expertise to size database back
ends of various sorts is hard to come by.

> >>> On the other hand, it seems odd that the
> >>> user's choice would be overriden by the preset maximum.

I don't know if anyone else has pointed this out, but that's not quite how it
works. The user's choice is only overridden if it exceeds the maximum. And
reason for that is simple: All servers need to prevent users from creating
entries that last for absurdly long periods, and in cases where the number
of retained entries is a potential problem, to prevent users from overloading
the system.

> >>> This would make
> >>> more sense to me if the default expiration were shorter and the user
> >>> could override it with a longer :seconds argument if he wanted. What is
> >>> the rationale for doing it the opposite way?

Again, that's not how it works. There are two values involved: A default
and a maximum. The default is what's used when no value is specified, whereas
is, well, the maximum. And the draft 

I don't really think the text is unclear about the distinction between defaults
and maximums, but if it is then it definitely needs to be changed.

And FWIW, my implementation of this also implements a minimum that is silently
substituted if a user goes under the value. My rationale for having this is
so something sensible is done when users screw up and enter absurdly low
values, then complain when their problem isn't solved. But I don't think
this is sufficiently useful that it belongs in the standard.

> >> The default was chosen in Sieve mailing list discussions, but in essence
> >> it is pretty arbitrary. It is mainly based on the period in which a
> >> series of duplicate messages may arrive with a margin of a few more days.
> > I find it a bit surprising that receipt of a duplicate multiple days after
> > the first message is received is that commonplace on today’s Internet. Is
> > there any data around to back that up?

> Arnt mentioned one example. I am no expert on this; I couldn't tell you.
> If I remember correctly, Alexey Melnikov proposed the default of seven days.

It's fairly uncommon for there to be significant delays, but that is largely
irrelevant. The point it is does happen, and when it does and duplicates get
through, users who have done to the trouble of setting this up will see them
and complain. And since email is often seen as a cost, not a value-added
service, trading off a bit more hardware - even if it comes to that - for fewer
support calls is not a bad idea.

> The "vacation" extension specification [RFC5230] mentions retention
> periods with similar magnitude (for ":days" argument).

And for similar reasons: Getting multiple vacation replies is fairly
irritating.

> >> The rationale for a maximum is to prevent users from having the ability
> >> to create duplicate tracking list entries that linger indefinitely.
> > Well, “indefinitely” wouldn’t necessarily be possible, because if the user
> > specifies nothing then it’s the default, and otherwise he could be
> > required to specify _something_, correct?

> True, but that something could be e.g. 2**32, which is pretty close to
> indefinitely.

I confess I don't understand this at all.

> > But I can appreciate that you don’t want to impose a long, arbitrary
> > retention requirement. Is the idea that the maximum would be surfaced
> > to the user if he’s using some GUI  create a duplicate filter?

> My implementation can provide a warning when this situation occurs. In
> the case of a GUI this would be returned through ManageSieve with the
> WARNINGS response code; http://tools.ietf.org/html/rfc5804#section-1.3 .
> I am not sure whether other implementations would do this or whether
> GUIs actually show these warnings, but at least there is a specification
> of this facility.

That's not a bad idea, although I note that nothing says the maximum that's
in effect when the sieve is created is going to be the same as the one
in effect when the sieve is executed.

> I could add text that implementations SHOULD issue a warning when a
> maximum ":seconds" value is substituted over what the user specified.

I don't have a problem with that as long as it's specific to managesieve.
There's really no straightforward viable path for reporting warnings at sieve
execution time. (The closest thing we have to that would be the addition of a
header, but the odds of anyone seeing it are so low there's really no point.)
And I don't think this extension is the right place to get into the issue of
hawo to provide warnings from sieve at executiion 

OTOH, I think we may have crossed the line into overdesign here.

				Ned