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

[[e-mail]]

> >> OK, I'll buy that.  Good.  So for the next version:
> >>
> >> 1. I will change ":time" to ":seconds".
> >
> > Personal comments:
> >
> > Since Ned has :hours, and here we're talking about :seconds, why not
> > also add :minutes?

> I'm happy to add :minutes and :hours to the draft if we think there's
> value, but it seems to add unnecessary stuff.  :seconds can cover all
> the minutes and hours we'd need.  At some level, ":hours 4" looks
> nicer than ":seconds 14400", but they really are the same thing.  And
> something like ":hours 1 :minutes 30" seems to work out better as
> simply ":seconds 5400".

> Ned?

I agree. Seconds is sufficient; I don't see any need to formally define
:hours (it's only used internally by our product anyhow).

> > 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.

I have to agree, although I note that we could, if we wanted to, define
this in terms of the FUTURERELEASE extension.

But perhaps a better place for that would be with notify mailto;, not vacation.

> 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.

There's also the issue that cancellations of this sort may be very difficult
to implement. I would certainly want it to be a separate extension in any case.

> > I'm in general favor of making it a WG document, but I'd like to think
> > out if there are more changes to vacation that anybody has in mind.
> > Should we open an "evacation" can of worms? (Probably not.) Should we
> > consider that a couple of vacation extensions might come together and
> > should be profiled as "vacation2" or something like that?

> I'd be amenable to expanding the scope of this, but that would be at
> the expense of delays caused by other stuff that might b harder.  This
> is a simple change, and is needed (as Ned points out) if we want to
> make more general auto-replies work through "vacation".  I'd rather
> have this on its own, and then have "vacation2", if it happens,
> incorporate this as a feature.

Agreed as well.

> (P.S.  Please review notify-presence, as well, with the same thoughts
> in mind (I'm about to post an update to that one.)

I was planning to do that. Unfortunately this whole SUNW->ORCL injection thing
has me a tad preoccupied :-)

				Ned