Subject: AD review comments on draft-degener-sieve-copy-01.txt

From: [email-masked]
Date: Sun, 25 Jan 2004 07:47:32 -0800 (PST)

I just reviewed this specification and I think it is quite close to being ready
for last call. My only comments are:

(1) An example showing the use of  the extentsion is needed. In particular,
    I've found that it really helps to have something that shows people what
    needs to be in the "reauire" clause.

(2) There needs to be an IANA considerations section telling IANA what
    to do. Something like this should appear as a section after the security
    considerations:

5 IANA Considerations
    
    The following template specifies the IANA registration of the copy Sieve
    extension specified in this document:
    
    To: [email-masked]
    Subject: Registration of new Sieve extension

    Capability name: copy
    Capability keyword: copy
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number: this RFC
    Person and email address to contact for further information:

      Jutta Degener
      Sendmail, Inc.
      6425 Christie Ave, 4th Floor
      Emeryville, CA 94608

      Email: [email-masked]

    This information should be added to the list of sieve extensions
    given on http://www.iana.org/assignments/sieve-extensions.
    
(3) IPR boilerplate is missing and needs to be added as a separate section
    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. Jutta, if you can make these changes quickly that would be great, if
not I'll probably go ahead and get the last call started anyway and the update
can happen during the last call.

				Ned

---

From: [email-masked]
Date: Sun, 25 Jan 2004 08:12:10 -0800 (PST)

> for last call. My only comments are:

Oops, missed one. The title of Appendix A needs to be changed to
"Appendix A. Normative references". Sorry about that.

				Ned

---

From: [email-masked]
Date: Sun, 25 Jan 2004 08:17:22 -0800 (PST)

(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: [email-masked]

    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: [email-masked]

(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:

That's it.

				Ned