Re: [VCARDDAV] Publication requested, draft-ietf-vcarddav-kind-app-00

[Peter Saint-Andre <[e-mail]>]

Naturally, since I am the author of this document I shan't function as
the responsible AD. Pete Resnick has graciously agreed to serve in that
capacity for this I-D.

On 9/14/11 8:46 AM, Simon Perreault wrote:
> VCARDDAV requests publication of draft-ietf-vcarddav-kind-app-00.
> 
> PROTO writeup is below.
> 
> Thanks,
> Simon
> 
> ---
> 
>>   (1.a) Who is the Document Shepherd for this document?
> 
> Simon Perreault <[e-mail]>
> 
>>         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? 
> 
> Yes.
> 
>>   (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 has received significant reviews from the community.
> 
>>   (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.
> 
> No concerns.
> 
>>         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. 
> 
> None.
> 
>>   (1.e) How solid is the WG consensus behind this document?
> 
> Very solid.
> 
>>         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?   
> 
> The WG has a good understanding of, and agreement with, this 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 such threats or appeals.
> 
>>   (1.g) Has the Document Shepherd personally verified that the 
>>         document satisfies all ID nits? (See the Internet-Drafts Checklist 
>>         and http://tools.ietf.org/tools/idnits/).
> 
> Yes.
> 
>>         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? 
> 
> The document does not specify a MIB, media type, or URI, and thus
> does not need to meet those review criteria.
> 
>>   (1.h) Has the document split its references into normative and 
>>         informative?
> 
> Yes.
> 
>>         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]. 
> 
> All normative references are upward references. All references are to
> RFCs (including a reference to draft-ietf-vcarddav-vcardrev which has
> been published as RFC 6350).
> 
>>   (1.i) Has the Document Shepherd verified that the document IANA 
>>         consideration section exists and is consistent with the body 
>>         of the document?
> 
> Yes.
> 
>>         If the document specifies protocol 
>>         extensions, are reservations requested in appropriate IANA 
>>         registries?
> 
> Yes.
> 
>>         Are the IANA registries clearly identified?
> 
> Yes.
> 
>>         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 [RFC5226]. 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 document does not create a new IANA registry.
> 
>>   (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 contains no such formal language.
> 
>>   (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. 
> 
> This document defines a value of "application" for the vCard KIND property so
> that vCards can be used to represent software applications. An example use case
> is representing an XMPP server.
> 
>>      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?
> 
> The scope was significantly reduced from "thing" to "application". No problems
> reaching consensus.
> 
>>      Document Quality 
>>         Are there existing implementations of the protocol?
> 
> http://xmpp.org/extensions/xep-0292.html
> 
>>         Have a 
>>         significant number of vendors indicated their plan to 
>>         implement the specification?
> 
> XMPP implementations are expected 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?
> 
> They are listed in the acknowledgements section.
> 
>>         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? 
> 
> No such reviews were necessary.
>