ietf-mta-filters
[Top] [All Lists]

Re: more comments on draft-ietf-sieve-vacation-01

2005-04-08 08:14:40



3.  Vacation Action

        3.1  Days Parameter
        
           The ":days" argument is used to specify the period in which 
addresses
           are kept and are not responded to, and is always specified in days.
           The minimum value used for this parameter is normally 1.  Sites MAY
           define a different minimum value.

is 0 a valid minimum value?

0 would effectively disable duplicate response detection. Do we want to
allow implementations to do this? My feeling is no, but I'd like to hear
from others on this one.

           The optional ":handle" parameter can be used to tell the sieve

nitpick: Sieve

Fixed.

           single response.  (Which response is sent depends on the order in
           which the messages are processed.

nitpick: missing end parenthesis

Fixed.

           Note that one way to implement the necessary mechanism here is to
           store a hash of either the current handle and the recipient or, if 
no
           handle is provided, a hash of the generated message content and the
           recipient.

this text should be changed if the intent is to consider the constant
value of the reason argument rather than the result after expanding
variables.

Agreed. Changed.

        3.3  Subject and from parameters
        
           The ":subject" parameter specifies a subject line to attach to any
           vacation response that is generated.  UTF-8 characters can be used 
in
           the string argument; implementations MUST convert the string to
           [RFC2047] encoded words if non-ASCII characters are present.

how should :subject "=?UTF-8?Q?whatever?=" be handled?  I believe it
should encode the string since it looks like an encoded word.

There's no need to encode it; it's already encoded. It just needs to be passed
through like any other text. The most we need to do here is to point out that
users can specify encoded words in the subject argument. And frankly, I'd
rather not point that out.

in other
words, even arguments which are US-ASCII only may need encoding.

I sure don't see why unless you're transcoding, which is far beyond the scope
of this specification.

        4.2  Subject Parameter
        
           Users can specify the subject of the reply with the ":subject"
           parameter.  If the :subject parameter is not supplied, then the
           subject is generated as follows: The subject is set to the 
characters
           "Re: " followed by the original subject with all leading occurrence
           of the characters "Re: " stripped off.

see below.

           be generated, and References need not bne changed.

nitpick: "bne"

Fixed.

        5.  Relationship to Recommendations for Automatic Responses to
           Electronic Mail
        
           The vacation extension implements a "Personal Responder" in the
           terminology defined in [RFC3834].  Care has been taken in this
           specification to comply with the recommendations [RFC3834] makes in
           regards to how personal responders should behave.

RFC 3834 says:

           The Subject field SHOULD contain a brief indication that the 
message
           is an automatic response, followed by contents of the Subject field
           (or a portion thereof) from the subject message.  The prefix 
"Auto:"
           MAY be used as such an indication.  If used, this prefix SHOULD be
           followed by an ASCII SPACE character (0x20).

okay, MAY isn't as strong as a recommendation, but why not use "Auto:"
rather than "Re:"?  in any case, the stated algorithm in 4.2 does not
contain any indication of the message being an automatic response.

I have no problem with this. Changed. I also dropped the bit about
removing Re: since it no longer makes sense to do that.

        6.  Security Considerations
        
           It is critical that implementations correctly implement the
           limitations described above.  Replies MUST NOT be sent out in
           response to messages not sent directly to the user, and replies 
MUST
           NOT be sent out more often than the :days argument states.

since the spec allows the database to be reset whenever the script is
updated, I wonder if the second MUST should be changed into a SHOULD?

I'd rather qualify it with "unless the script changes".

                                Ned


<Prev in Thread] Current Thread [Next in Thread>