[Top] [All Lists]

Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt

2013-04-10 06:58:11
Op 4/8/2013 12:23 AM, Ned Freed schreef:
There is one thing I  thought of and haven't addressed so far. My
>> current implementation makes a new entry in the duplicate tracking
>> list irrespective of whether one exists already, overwriting the
>> old one and thereby resetting the expiry time to whatever is
>> configured using ":seconds". This will make example 3 in the draft
>> yield unexpected results; if duplicates arrive within the expiry
>> time, the total expiry time is in effect extended. The semantic
>> difference here is that the expiry time is either measured relative
>> to the initial message or relative to the last duplicate. This
>> means that the 30 minutes in the example can stretch indefinitely
>> if duplicates keep arriving before the expiry deadline. So, for the
>> scenario of example 3, such behavior is quite obviously wrong.
>> However, would there be an application for having the expiry time
>> be relative to the last message received with the specified ID
>> rather than the initial one? How would we accommodate for that?
> I should have given this more consideration.
> The difference between timeouts "relative to first" and "relatve to
> last" seems significant enough to me to provide a means to control
> it. It's certainly easy enough for me to accomodate in my
> implementation.

I agree.

In fact since the default  should be "relative to first" we can simply
> reuse the existing :last parameter in use elsewhere.

Would we make allowing the presence of :last dependent on :seconds (much like :index) ?

Alternatives I can think of:

:refresh, :update, :renew - with the semantic interpretation that the entry in the tracking list is being updated/refreshed/renewed.

Anyone else suggestions?


sieve mailing list