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

[Stephan Bosch <[e-mail]>]

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?

Regards,

Stephan.