Re: [sieve] Working Group Last Call: draft-ietf-sieve-vacation-seconds-00

[[e-mail]]

> Hi,
> Some comments on draft-ietf-sieve-vacation-seconds-00:

> Section 2: a maximum of 2**31 seems a little excessive.

As a practical matter, people are likely to implement this stuff using time_t
values, and it's unlikely that all implementations will, if actually given a
value as large as 2**31, do the right thing. OTOH, the 2**31 isn't the largest
value an implementation has to accept - we have other means of limiting that -
it's the largest value that the protocol allows, so this really doesn't do any
harm AFAICT.

> Also, the base
> vacation spec does allow sites to override the maximum value (:days MUST be
> > 7, SHOULD be > 30). I think it makes sense to at least allow a similar
> maximum limit for :seconds. I would suggest MUST be >= 86,400 (1 day).

RFC 5228 says that implementations are able to impose reasonable
limits; a maximum on this would certainly qualify so we don't *have* to
have explicit text to authorize implementations to do this. OTOH, if 
we want to discourage implementations from setting a maximum that's too
low. So I think adding this is a good idea.

> Section 2: base vacation spec does not allow a minimum of zero. Why do we
> allow it here? If it is OK here, perhaps we should add some text calling
> this out as one key difference from the base vacation behavior.

I have to say I view this as a case of accepting operational reality. For
better or worse, people often use Sieve vacation to implement autoresponders
rather than out of office messages. When you do that it's unacceptable to 
suppress any replies on a temporal basis.

We had no choice but to eliminate the nonzero value limitation in our
implementation years ago. Do so has caused, AFAIK, no operational problems
at all.

That said, some text discussing this change would be a good idea.

> Section 4: Second sentence seems a little weak. It only says
> implementations "SHOULD consider the number of auto-replies ... generated".
> It does not state why that is important, or what might be done to alleviate
> any problem related to it. So I think we need some more text here.

Perhaps something like "MAY impose additional limits on the number of replies 
generated" would help.

> Section 5: Please change the contact email to <[e-mail]>.

				Ned