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

[Barry Leiba <[e-mail]>]

> Section 2: a maximum of 2**31 seems a little excessive. 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).
>
> 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.

Including Ned's comments to this also, I've made the text this:

      The time value is specified in seconds, and MUST be greater than
or equal to
      0 and less than 2**31.  All valid values MUST be accepted
without error, but
      sites MAY define a minimum value to actually be used if a smaller value is
      specified, and/or a maximum value to be used if a larger value
is specified.
      If a site imposes a maximum value, that value MUST be at least
86400 (one day).

      If 0 is specified and used, it means that all auto-replies are
      sent, and no attempt is made to suppress consecutive replies.
      This changes the base vacation specification, which does not
allow ":days 0";
      the change is necessary to allow operation of an auto-responder
      (see <xref target='I-D.ietf-sieve-autoreply' />).

...and I've added an informative reference to sieve-autoreply.  Please comment.

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

Text is now this:

      Security considerations for the Sieve Vacation extension
      <xref target='RFC5230' /> apply equally here.  In addition,
      implementations SHOULD consider the number of auto-replies that
      might be generated by allowing small values of ":seconds" (including 0),
      and MAY impose additional limits on that number.
      See the Security Considerations section of RFC 3834 <xref
target='RFC3834' />
      for a fuller discussion.

...and I've added an informative reference to RFC 3834 (I had
previously thought that the reference to 5230 and *its* reference to
3834 sufficed).  Please comment.

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

Yeh, missed that on the previous round.

Barry