Sieve: Vacation Extension
draft-showalter-sieve-vacation-06

Have pinged author for a requested update several times.  Most recent reply (2004-06-15): "I have not done it yet.  Let me see if I can get some time tonight or tomorrow."  Follow-up note sent six days later has received no reply at all.  This last follow-up noted that the document would be dropped if the author won't update the document.

Version 05 was restored upon Scott's request.
Sub State was automatically changed to AD Followup and Michael changed the sub state back to Revised ID Needed

AD review comments posted:

Further AD review comments 25-Jan-2004:

(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@iana.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@mirapoint.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.

Sieve meeting 20-Mar-2003:

  Draft long expired, needs to be revived. Remove use of
  bcc for OK to send notice, add use of resent- for OKs,
  send reply from first address in addresses list if
  legit, last call new draft once out.