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.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve