[lemonade] Document Shepherd Write-up: Lemonade IMAP NOTIFY

[Eric Burger <[e-mail]>]

DOCUMENT:

The IMAP NOTIFY Extension

draft-ietf-lemonade-imap-notify-06.txt

(Standards Track)


(1.a)  Who is the Document Shepherd for this document?  Has the

         Document Shepherd personally reviewed this version of the

         document and, in particular, does he or she believe this

         version is ready for forwarding to the IESG for publication?



Eric Burger is the document shepherd for this document.

The document is ready for publication.



  (1.b)  Has the document had adequate review both from key WG members

         and from key non-WG members?  Does the Document Shepherd have

         any concerns about the depth or breadth of the reviews that

         have been performed?



This document was extensively reviewed by the Lemonade WG. Issues  
raised were addressed in the latest draft. There are no concerns about  
the depth of the reviews.



  (1.c)  Does the Document Shepherd have concerns that the document

         needs more review from a particular or broader perspective,

         e.g., security, operational complexity, someone familiar with

         AAA, internationalization or XML?



No concerns.



  (1.d)  Does the Document Shepherd have any specific concerns or

         issues with this document that the Responsible Area Director

         and/or the IESG should be aware of?  For example, perhaps he

         or she is uncomfortable with certain parts of the  document, or

         has concerns whether there really is a need for it.  In any

         event, if the WG has discussed those issues and has indicated

         that it still wishes to advance the document, detail those

         concerns here.  Has an IPR disclosure related to this  document

         been filed?  If so, please include a reference to the

         disclosure and summarize the WG discussion and conclusion on

         this issue.



No specific concerns. No IPR disclosure was filed for this document.



  (1.e)  How solid is the WG consensus behind this document?  Does it

         represent the strong concurrence of a few individuals, with

         others being silent, or does the WG as a whole understand and

         agree with it?



There is a solid WG consensus behind the document.



  (1.f)  Has anyone threatened an appeal or otherwise indicated  extreme

         discontent?  If so, please summarise the areas of conflict in

         separate email messages to the Responsible Area Director.   (It

         should be in a separate email because this questionnaire is

         entered into the ID Tracker.)

No.



  (1.g)  Has the Document Shepherd personally verified that the

         document satisfies all ID nits?  (See

         http://www.ietf.org/ID-Checklist.html and

         http://tools.ietf.org/tools/idnits/).  Boilerplate checks are

         not enough; this check needs to be thorough.  Has the  document

         met all formal review criteria it needs to, such as the MIB

         Doctor, media type and URI type reviews?



IDnits 2.08.10 was used to verify the document. It reported missing  
Table of Content <<will fix before IETF LC>>, 2 outdated references  
(which can be fixed by the RFC editor. BTW, the references *were*  
correct when the draft was posted) and 1 missing reference, which is  
not a reference (it is an IMAP response code).



  (1.h)  Has the document split its references into normative and

         informative?  Are there normative references to documents  that

         are not ready for advancement or are otherwise in an unclear

         state?  If such normative references exist, what is the

         strategy for their completion?  Are there normative  references

         that are downward references, as described in [RFC3967]?  If

         so, list these downward references to support the Area

         Director in the Last Call procedure for them [RFC3967].



Yes, references are properly split. There are no downward normative  
references.

There are 3 normative references to drafts. One of them (draft- 
cridland-imap-context-05.txt) is in AUTH48, the other one (draft-ietf- 
lemonade-msgevent-05.txt) is in IESG review. And the last one is past  
IETF LC and should be finished shortly after Dublin (draft-daboo-imap- 
annotatemore-13.txt).



  (1.i)  Has the Document Shepherd verified that the document IANA

         consideration section exists and is consistent with the body

         of the document?  If the document specifies protocol

         extensions, are reservations requested in appropriate IANA

         registries?  Are the IANA registries clearly identified?  If

         the document creates a new registry, does it define the

         proposed initial contents of the registry and an allocation

         procedure for future registrations?  Does it suggest a

         reasonable name for the new registry?  See [RFC2434].  If the

         document describes an Expert Review process has Shepherd

         conferred with the Responsible Area Director so that the IESG

         can appoint the needed Expert during the IESG Evaluation?



The IANA considerations section exists and is clearly defined. It  
contains registration of a new IMAP extension and registration of a  
new LIST-EXTENDED extended data item. It doesn't create new IANA  
registries.



  (1.j)  Has the Document Shepherd verified that sections of the

         document that are written in a formal language, such as XML

         code, BNF rules, MIB definitions, etc., validate correctly in

         an automated checker?



The document passes Bill Fenner's ABNF Parser.



  (1.k)  The IESG approval announcement includes a Document

         Announcement Write-Up.  Please provide such a Document

         Announcement Write-Up?  Recent examples can be found in the

         "Action" announcements for approved documents.  The approval

         announcement contains the following sections:



         Technical Summary

            Relevant content can frequently be found in the abstract

            and/or introduction of the document.  If not, this may be

            an indication that there are deficiencies in the abstract

            or introduction.



The IDLE command (defined in [RFC2177]) provides a way for the client  
to go into a mode where the IMAP server pushes notifications about  
IMAP mailstore events for the selected mailbox.  However, the IDLE  
extension doesn't restrict or control which server events can be sent,  
or what information the server sends in response to each event.  Also,  
IDLE only applies to the selected mailbox, thus requiring an  
additional TCP connection per mailbox.



This document defines an IMAP extension that allows clients to express  
their preferences about unsolicited events generated by the server.   
The extension allows clients to only receive events they are  
interested in, while servers know that they don't need to go into  
effort of generating certain types of untagged responses.





         Working Group Summary

            Was there anything in WG process that is worth noting?   For

            example, was there controversy about particular points or

            were there decisions where the consensus was particularly

            rough?



There was an early discussion about document allowing mailbox matching  
criteria that were too expensive to implement in servers.  The current  
draft represents consensus among active WG members.  There was a  
discussion about not having any events tied together. However some  
implementers expressed concerns about difficulty of implementing  
certain event combinations untied. The current text is a compromise  
and represents consensus among active WG members.



         Document Quality

            Are there existing implementations of the protocol?   Have a

            significant number of vendors indicated their plan to

            implement the specification?  Are there any reviewers that

            merit special mention as having done a thorough review,

            e.g., one that resulted in important changes or a

            conclusion that the document had no substantive  issues?  If

            there was a MIB Doctor, Media Type or other expert review,

            what was its course (briefly)?  In the case of a Media  Type

            review, on what date was the request posted?



Multiple client developers (at least 4) expressed the desire to have  
this feature. Multiple server developers committed to implement the  
extension (at least 3) and a couple of developers already have  
prototype implementations.



         Personnel

            Who is the Document Shepherd for this document?  Who is  the

            Responsible Area Director?



Eric Burger is the document shepherd for this document.

  
_______________________________________________
lemonade mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade