[Top] [All Lists]

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

2010-09-29 01:08:55
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 <sieve(_at_)ietf(_dot_)org>.

Yeh, missed that on the previous round.

sieve mailing list