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. In fact since the default
should be "relative to first" we can simply reuse the existing :last parameter
in use elsewhere.
Thoughts?
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve