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

Simon Perreault <simon.perreault@viagenie.ca> Wed, 14 September 2011 14:44 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4801C21F8CDD; Wed, 14 Sep 2011 07:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level:
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaqFJCTGrKEt; Wed, 14 Sep 2011 07:44:50 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB221F8CEE; Wed, 14 Sep 2011 07:44:50 -0700 (PDT)
Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C546521F72; Wed, 14 Sep 2011 10:46:57 -0400 (EDT)
Message-ID: <4E70BE60.5010509@viagenie.ca>
Date: Wed, 14 Sep 2011 10:46:56 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qualcomm.com>, iesg-secretary@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: vcarddav@ietf.org
Subject: [VCARDDAV] Publication requested, draft-ietf-vcarddav-kind-app-00
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 14:44:55 -0000

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 <simon.perreault@viagenie.ca>

>         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