Re: [sieve] New Version Notification for draft-george-sieve-vacation-time-00

[Aaron Stone <[e-mail]>]

On Thu, Feb 4, 2010 at 3:44 PM, Derek Diget
<[e-mail]> wrote:
>
> On Feb 4, 2010 at 14:01 -0500, Barry Leiba wrote:
> =>
> =>> Thought experiment: what if :time referred to a time of day? All
> =>> vacation notices would be batched and sent at that time of day. What
> =>> might be a use case for this?
> =>
> =>Mm.  ":time 00:00:00" to send the (de-duped) batch at midnight.  I
> =>can't really see the need for that.  For the most part, you'd want the
> =>first notice ASAP, and just have duplicates suppressed after that,
> =>until the interval expires.
> =>
> =>The only reason I could see for delaying even the first notice until a
> =>designated time would be if you wanted to be able to cancel them if
> =>something has changed.  Like, maybe, "Don't tell people I'm gone
> =>unless I'm not back by 3:00."  Even with that, what happens when you
> =>get back at 3:01?  No, that just seems like a solution no one's asked
> =>for nor needs.
>
> De-lurking...I am not the experts you all are.

Welcome!

> Should there be something said on how implementations handle deltas to the
> :time (or :seconds) window with respect to the previous response history
> database?  Does a change to the sieve remove/wipe the previous response
> tracking history?  I don't see any mention of that in RFC 5230.  For
> example...
>
> Fred has a vacation rule with responses set for every 10800 seconds (he
> is in a morning meeting).  Wilma sends a message to Fred at 10:30 and
> receives a vacation response since it is the first message she has sent
> to Fred that day.  Fred gets out of his meeting and modifies his
> vacation sieve at 11:50 as he heads out to lunch with a :time now set to
> 5400.  (He might or might not change the reason string.)  Wilma sends
> another message to Fred at 12:00 that would "match" her first message
> and not have caused a response under the original rule.  Does Fred's
> modification of the filter cause the sieve system to remove/wipe/clean
> its response tracking history and thus cause a new response to Wilma's
> 12:00 message?
>
> The reason I ask is that I see with user's being able to set vacation
> replies using seconds they might connect their
> Twitter/MySpace/Facebook/etc account status with vacation rules.  They
> update their ${SOCIALSITE} status and it updates their vacation sieve
> rule with their new status message. :) or :( depending our the side of
> fence you stand.  And I could see same thing in the IM/presence world,
> too.
>
>
> If this is addressed somewhere sorry for wasting your time.

The question of when to respond is addressed, but your question is
entirely valid. In short, no, the response tracker should be separate
from the script.

>From RFC 5230, Section 4.2, "Previous Response Tracking":
   ...
   Tracking is not just per address, but must also take the vacation
   response itself into account.  A script writer might, for example,
   have a vacation action that will send a general notice only once in
   any two-week period.  However, even if a sender has received this
   general notice, it may be important to send a specific notice when a
   message about something timely or something specific has been
   detected.

   A particular vacation response can be identified in one of two ways.
   The first way is via an explicit :handle argument, which attaches a
   name to the response.  All vacation statements that use the same
   handle will be considered the same response for tracking purposes.

   The second way is via a synthesis of the :subject, :from, :mime, and
   reason vacation command arguments.  All vacation actions that do not
   contain an explicit handle and that use an identical combination of
   these arguments are considered the same for tracking purposes.
   ...

In the "second way" paragraph, the parameters :subject, :from, :mime,
and the reason are specified as the ones to use in constructing a
tracking handle. Omitted from the list is :days, probably for exactly
the reason you're asking about. I think what most implementations will
do is (implementers please correct me!):

  Receive message
  Run the sieve on the message
     Vacation action:
        Calculate the handle for the action
        Look up the handle - recipient pair last response time
        Is the current time - last response > :days?
            Yes: send a vacation response
            No: take no action


Later in Section 4.2:
   ...
   Implementations are free to limit the number of remembered responses;
   however, the limit MUST NOT be less than 1000.  When limiting the
   number of tracked responses, implementations SHOULD discard the
   oldest ones first.

No mention is made of keeping or wiping the response tracking log when
the sieve is updated, but it reads like we're just assuming that you
wouldn't do that :)

Cheers,
Aaron