Skip to main content

Shepherd writeup
draft-ietf-extra-sieve-special-use

Document Shepherd Write-Up for draft-ietf-extra-sieve-special-use-04

1. This document is being requested as a Proposed Standard because it
adds new capabilities to existing Standards Track document(RFC 5228).
The request type is indicated in the title page header.

2.

Technical Summary

  The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows
   clients to identify special-use mailboxes; e.g., where draft or sent
   messages should be put.  This simplifies client configuration.  In
   contrast, the Sieve mail filtering language (RFC 5228) currently has
   no such capability.  This memo defines a Sieve extension that fills
   this gap: it adds a test for checking whether a special-use attribute
   is assigned for a particular mailbox or any mailbox, and it adds the
   ability to file messages into an anonymous mailbox that has a
   particular special-use attribute assigned.

Working Group Summary

  The EXTRA WG meeting in IETF 102 had detailed discussion about this draft.
  The authors had updated it accordingly. Alexey reviewed the draft in detail
  and gave some significant comments. All identified issues were reflected in
  the new version of the draft. The WG has looked throught this document in
  detail. It passed WGLC. The EXTRA WG meeting in IETF 103 thought that it is
  ready to move forward.

Document Quality

  The document is in good shape and is ready to be published.
  Alexey Melnikov has indicated that he has implemented it.
  He gave some comments and suggestions based on implementation experiences.
  After WG's discussion, some comments and suggestions have been updated into
  the new version of this document.

Personnel

  Document Shepherd - Jiankang Yao (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov

3. The Document Shepherd has read the document through in detail and
think that it is ready to go.

4. There has no concerns.

5. There is no review required for the document by other areas, it's
very self-contained.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is very solid, while not everybody spoke, it was
clear that the entire group understood and agreed with the idea and
the method chosen.

10. There has been no discontent.

11. The ID nits tool shows the following:

"
if you have code  sections in the document, please surround them with '<CODE
BEGINS>'  and  '<CODE ENDS>' lines. "

     Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. The publication of this document does not change the status of any
existing RFCs.

17. The IANA considerations ask for the following item to be added to the
registry:

   IANA is requested to add the new entry spcified in section 8 to the "Sieve
   Extensions".

18. None of the IANA registries mentioned require Expert Review.

19. Have checked the formal language. According to the ID nits suggestion, the
authors may consider to surround the Pseudocode in section 6 with '<CODE
BEGINS>'  and  '<CODE ENDS>' lines.
Back