Subject: [VCARDDAV] draft-li-vcarddav-vcard-id-property-extensions, and extension specs in general

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Dec 2010 08:45:44 -0500

Kepeng says...
> FYI that I uploaded a new I-D draft for vCard extensions.
> Welcome comments and suggestions.
...
>        Title           : vCard Format Extensions : DDAY, BIRTH, and DEATH
>        Author(s)       : K. Li, B. Leiba
>        Filename        : draft-li-vcarddav-vcard-id-property-extensions-00.txt
...
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-li-vcarddav-vcard-id-property-extensions-00.txt

This draft simply reinstates the DDAY, BIRTH, and DEATH properties
that were removed from the base vcardrev document in the -15 version.

As Kepeng and I wrote this, and I worked on the IANA Considerations
section, it became very clear that with the registration procedure
that's documented in vcardrev section 10.2, along with the normal way
of writing extension specifications, we end up putting the same
information twice, in two different sections of the document.  That's
bad.

We should take a moment to talk about how we really want to see
extensions written.  As it is, if I put the details only in the IANA
Considerations, the document winds up saying nothing after RFC
publication, and all the information is in the registry.  But
according to vcardrev, the registry has to contain exactly the
information that would normally be in the detailed specification.

Most registries just have basic information, and point to the document
that defines the item for the details.

Again... what is it that we really want, here?

Barry

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Dec 2010 12:00:17 -0500

> Again... what is it that we really want, here?

vcardrev doesn't say that the IANA Considerations section must contain
the registration template.

The registration template is for the expert reviewer. That's it. IANA
doesn't care about it. (vcardrev says that the template must be sent to
[email-masked], but that's only so that IANA may forward it to the
designated expert.)

We could be more explicit in vcardrev. A proposal:

"An RFC specifying new vCard elements MUST include the completed
registration templates, which MAY be expanded with additional
information. The IANA Considerations section should be short and to the
point. It should only list the changes that IANA is requested to make to
the registries. The registry's reference column should point to the
section in the RFC containing to the completed the registration template."

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