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

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Sep 2011 10:46:56 -0400

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

>         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.

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2011 09:49:57 -0600

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.