(Unfortunately this draft has expired. Hopefully this can be corrected in a
timely fashion.)
I reviewed this document once in the past and most of the issues I had were
addressed at that time. The only ones I see that remain are:
(1) In section 3.5 it should be noted that in-reply-to need not be generated
if the original message doesn't have a message-id. A references field
should also be generated and set similarly.
(2) In section 3.6 Resent- field variants should be checked for addresses in
addition to the To:/Cc:/Bcc: fields.
(3) A new section needs to be added before section 3.6 that discusses how
to set the From: field in vacaation responses. I believe the correct
advice to give is that the field SHOULD be set to the address of the
sieve owner.
(4) A new section needs to be added before section 3.6 that discusses how to
set the To: field in vacation responses. It should say that the
To: field SHOULD be set to the address of the recipient of the
response.
(5) A new section needs to be added that says an Auto-submitted: field
with a value of "auto-replied" SHOULD be included in the message header
of any vacation reply that is sent.
(6) The sections describing the response message to send are mingled
with the sections describing the various vacation action parameters.
These really need to be teased out into a separate major section. The
major section should also say that the generated response must be
a valid email message with all of the required header fields present.
(7) This document needs to be reconciled with Keith Moore's draft on
auto-responders, draft-moore-auto-email-response-04.txt, which has been
through last call. I've thought about this a lot, and I think the right
way to do it is to simply add a section that discusses what sort of
auto-responder this is in Keith's terms. Something like this:
4. Relationship to "Recommendations for Automatic Responses to Electronic Mail"
The sieve vacation extension implements a "Personal Responder" in the
terminology defined in [AUTO]. Care has been taken in this specification
to comply with the recommendations [AUTO] makes in regards to how
personal responders should behave.
And of course a reference to [AUTO] needs to be added to the references
section:
[AUTO] Moore, K., "Recommendations for Automatic Responses to Electronic
Mail", Internet-Draft, draft-moore-auto-email-response-04.txt.
(8) The security consideration section is likely to be seen as inadequate
in its discussion of potential problems auto-responders can cause.
Fortunately there's a nice way to resolve this without adding a bunch
of text to the present document: Refer to Keith Moore's auto-responder
draft with a sentence like:
Security issues associated with mail auto-responders are fully discussed
in the security consideration section of [AUTO].
(9) An IANA considerations section needs to be added just after the security
considerations:
5 IANA Considerations
The following template specifies the IANA registration of the vacation Sieve
extension specified in this document:
To: iana(_at_)iana(_dot_)org
Subject: Registration of new Sieve extension
Capability name: vacation
Capability keyword: vacation
Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information:
Tim Showalter
Mirapoint, Inc.
909 Hermosa Court
Sunnyvale, CA 94085
E-Mail: tjs(_at_)mirapoint(_dot_)com
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
(10) The references section needs to be split into normative and informative
groups. I believe [MAILBOXNAMES] belongs in the informative section
while all the others, including [AUTO], belong in the normative
section.
(11) IPR boilerplate needs to be added just before the copyright:
Appendix B Intellectual Property Rights Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
That's it.
Ned