IANA Registration for vCard Enumservice
draft-ietf-enum-vcard-06

[Ballot comment]
Looks like -06 removed the problematic downref.  The description of the authentication mechanisms is fairly weak and could be made more useful, but it should be adequate for common use cases.

[Ballot comment]
I agree with Sam that the use of HTTP authentication to limit access to this data or
to manage the identities for the purposes of synthesis seems unlikley to scale for
public deployment.  In deployments where it might work, other forms of discovery
seem more likely.

[Ballot discuss]
I agree with Cullen's discuss, and I'll point to this text within the note:

"This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time."

I believe that this makes the normative reference a downref, even if it is the consensus of the community that this should be published.

I also note that some discussion of DNSSEC's interaction with this mechanism may be in order.
One of the motivated reasons for the creation of NSEC3 was to limit zone walking.  Given that this enumservice contains pointers to personally identifiable information, the policy limitations
on making this available may require considering NSEC3 if the zone will use DNSSEC.

[Ballot comment]
This is not a blocking discuss.  However I wonder how useful the http
authentication is going to be.  How likely is it that the person
retrieving an enum vcard is going to have a close enough relationship
with the person publishing the vcard that they share an authentication
infrastructure?  If so, is enum really a best fit for distributing the
data?

[Ballot discuss]
My understanding from W3C is that they were not endorsing and did not plan to standardize the RDF/XML formation of vcards. Do we really want to be pointing at this?

I can go either way but I do want to at least talk about this for a minute.

IANA Last call Comments:

Upon approval of this document, the IANA will add three
new enumservice registrations into the registry
located at:

http://www.iana.org/assignments/enum-services

Enumservice Name: "vCard"
Enumservice Type: "vcard"
Enumservice Subtype: N/A
URI Scheme: "http", "https"
Functional Specification:
This Enumservice indicates that the resource identified
is a plain vCard according to RFC 2426 which may be
accessed using HTTP/HTTPS.
Clients fetching the vCard from the resource indicated
should expect access to be restricted. Additionally, the
comprehension of the data provided may vary depending
on the client's identity.
Security Considerations: See Section 6 of [Insert
reference to approved document].
Intended Usage: COMMON
Authors: Alexander Mayrhofer

Enumservice Name: "vCard"
Enumservice Type: "vcard"
Enumservice Subtype: "rdf"
URI Scheme: "http", "https"
Functional Specification:
This Enumservice indicates that the resource identified
is a RDF-formatted vCard according to section 3 - 5 of
W3C vcard-rdf which may be accessed using HTTP/HTTPS.
Clients fetching the vCard from the resource indicated
should expect access to be restricted. Additionally, the
comprehension of the data provided may vary depending on
the client's identity.
Security Considerations: See Section 6 of [Insert
reference to approved document].
Intended Usage: COMMON
Authors: Alexander Mayrhofer

Enumservice Name: "vCard"
Enumservice Type: "vcard"
Enumservice Subtype: "xml"
URI Scheme: "http", "https"
Functional Specification:
This Enumservice indicates that the resource identified
is a XML-formatted vCard according to section 6 of W3C
vcard-rdf which may be accessed using HTTP/HTTPS.
Clients fetching the vCard from the resource indicated
should expect access to be restricted. Additionally, the
comprehension of the data provided may vary depending on
the client's identity.
Security Considerations: See Section 6 of [Insert
reference to approved document].
Intended Usage: COMMON
Authors: Alexander Mayrhofer

The IANA understands that these three actions are the only
IANA Actions required upon approval of the document.

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes.

2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

The document was presented twice at IETF meetings to the ENUM WG,
and was also reviewed by non-WG members - those reviews
were helpful especially in extending the text about PII data in
the security considerations section.


3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No. Enumservice Registration documents are a routine matter.


4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

No.

5) 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?

The majority of the active WG members appreciated the document,
extensive feedback was provided during the first presentation of
the document, which was incorporated into the subsequent versions.

Additionally, the author gathered a lot of feedback from private
discussions with both WG and non-WG members.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

8) Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(Note: the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

references are properly split, there are no normative references to
internet drafts.

9) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:

- Technical Summary
- Working Group Summary
- Protocol Quality

Please provide such a writeup. (We will hopefully use it as is, but
may make some changes.) For recent examples, have a look at the
"protocol action" announcements for approved documents.

Technical summary:
------------------

The document proposes an Enumservice to refer from an E.164 number
to URIs addressing "vCards" (electronic business cards). The document
considers 3 different formats for those vCards, and uses http/https URIs
to access those cards.

Working Group Summary:
---------------------

Generally, this document is part of a series of straightforward
Enumservice registrations which are handled by the ENUM WG
according to the registration process in RFC 3761.

The document was on the schedule of two ENUM WG sessions, and has generally
enjoyed the appreciation of the group. Most concerns were related to the
potential issues of publishing PII data - subsequent revisions of the
document addressed those concerns.

Protocol Quality
----------------

Working group members have indicated that this is an interesting
Enumservice which could be used in a lot of environments, from
company directories to some kind of "next generation yellow pages"
service. An experimental implementation based on the Asterisk soft-PBX
is currently under development by the author.

Working group members have also indicated that they are investigating
use of this protocol for private inter-carrier directory services.


Note:

- When doing the technical summary, one would expect that the
relevant information is in the abstract and/or introduction of
the document. It turns out that the step of producing the writeup
sometimes points out deficiencies in the introduction/abstract
that are also worthy of rectifying.

- For the Working Group Summary, was there anything in WG process
that is worth noting? (E.g., controversy about particular points,
decisions where concensus was particularly rough, etc.)

- For the protocol quality, useful information could include:

- is the protocol already being implemented?

No..

- have a significant number of vendors indicated they plan to
implement the spec?

Unknown.

- are there any reviewers (during the end stages) that merit
explicit mention as having done a thorough review that resulted
in important changes or a conclusion that the document was fine
(except for maybe some nits?)

None that the chairs are aware of.