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

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Jan 2011 10:17:16 -0500

Simon wrote...
> 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.)

OK, but since we started using registration templates, *every*
extension I've been involved with has put the completed registration
template in the IANA Considerations section.  So if that's not what we
want, yeah, we have to be very explicit, because what's there now is
quite confusing.

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

You don't say where that would go; I presume you mean to put that as a
new paragraph at the end of section 10.2.1.  Let me propose a slight
variation:
  ----------
IMPORTANT:
An RFC specifying new vCard elements MUST include the completed
registration templates, which MAY be expanded with additional
information. These completed templates will go in the body of
the document, and SHOULD NOT be included or repeated in the
IANA Considerations section.

The IANA Considerations section MUST contain tables [see the tables
in section 10.3, below] that show exactly the changes that IANA is
requested to make to the registries. The registry's reference column
MUST point to the section in the RFC containing to the completed the
registration template.
  ----------

Reviewing all this also shows me that the IANA Considerations section
in vcardrev is missing things that will help IANA understand this
clearly, so let me suggest some changes.  First, section 10.1 just
throws a registration at IANA and expects them to know where to put
it.  They probably will.  Still, let's make it easy on them:

  10.1. MIME Type Registration

     IANA is asked to register the following MIME Media Type
     [in http://www.iana.org/assignments/media-types/].

Second, section 10.2 is a long section that defines how to do things
in the future.  IANA will need to review that, but there's nothing
they have to do with it now.  It'll help them if we say so:

  10.2. Registering New vCard Elements

     This section defines the process for registering new or modified
     vCard elements (properties, parameters, value data types, and
     values) with IANA.  This section does not contain any immediate
     IANA actions.

Third, we're throwing four new registries at IANA and asking them to
name them.  I suggest we help them out here too:

  10.3. Initial vCard Elements Registries

     The IANA is requested to create and maintain the following
     registries for vCard elements, with pointers to appropriate
     reference documents. The registries will be grouped together
     under the heading "vCard Elements".

...
  10.3.1. vCard Properties Registry

     The following table is to be used to initialize the properties
     registry [in http://www.iana.org/assignments/vcard-properties/].

...
  10.3.2. vCard Parameters Registry

     The following table is to be used to initialize the parameters
     registry [in http://www.iana.org/assignments/vcard-parameters/].

...
  10.3.3. vCard Value Data Types Registry

     The following table is to be used to initialize the parameters
     registry [in http://www.iana.org/assignments/vcard-value-data-types/].

...
  10.3.4. vCard Values Registry

     Separate tables will be used for property and parameter values in
     the values registry
     [in http://www.iana.org/assignments/vcard-values/].
...
     The following table is to be used to initialize the property values
     table in the values registry.
...
     The following table is to be used to initialize the parameter values
     table in the values registry.

OK?

Barry

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Jan 2011 10:23:54 -0500

I mostly agree. Just one thing:

>      [in http://www.iana.org/assignments/vcard-values/].

I think it would be better to have a single "vcard" top-level registry
which would contain the registries above as sub-registries. So instead I
propose that we rename all of them to "sub-registries".

The resulting URLs would become e.g.
http://www.iana.org/assignments/vcard/vcard.xml#properties
http://www.iana.org/assignments/vcard/vcard.xml#parameters
http://www.iana.org/assignments/vcard/vcard.xml#value-data-types
http://www.iana.org/assignments/vcard/vcard.xml#values
But I'm not sure we should "hard-code" them into the RFC. Just naming
the top-level registry should be enough direction.

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 04 Jan 2011 10:35:37 -0500

Hi Simon,

> the top-level registry should be enough direction.

I am not sure a "top-level" registry is needed as IANA will implicitly 
group the registries as it did for iCalendar (e.g. 
<http://www.iana.org/assignments/icalendar/icalendar.xhtml#components> is 
defined but RFC 5545 made no mention of a "top-level" registry). I believe 
much of the current registry text is taken from 5545.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 04 Jan 2011 10:41:10 -0500

Hi Barry,

> want, yeah, we have to be very explicit, because what's there now is

FYI iCalendar does it the same way as vCard v4 and I have no problem with 
that (having worked on several iCalendar extensions that register multiple 
new items).

I am OK with your suggested changes, but IANA seemed to cope with the 
iCalendar registries just fine without similar text present.

The instruction about putting the template in the body and using tables in 
the IANA section of extension documents is worthwhile to include. For the 
most part when I do extensions I typically copy the behavior in the base 
spec - mostly because it is simple to grab the xml fragments from the base 
to include in the extension. Actually, what might be useful is to have a 
"template" xml2rfc xml file that provides an outline for an extension. That 
way all the key sections could be present with empty values and xml for the 
IANA templates and referencing tables could be in-place and easily filled 
out.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Jan 2011 10:41:49 -0500

On 2011-01-04 10:35, Cyrus Daboo wrote:
> <http://www.iana.org/assignments/icalendar/icalendar.xhtml#components>
> is defined but RFC 5545 made no mention of a "top-level" registry). I
> believe much of the current registry text is taken from 5545.

I'm just borrowing from IANA's internal vocabulary. The icalendar
registry is exactly what I would like to have for vcard.

In iCalendar's case, "icalendar" would be the registry's name. Each
table in http://www.iana.org/assignments/icalendar/icalendar.xhtml is
called a sub-registry.

Anyway, let's just not put the URLs in our RFC. We don't care about the
URLs. Let IANA do their job. (Although it would be nice to have a note
to the RFC editor to add the URL picked by IANA to the final RFC.)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Jan 2011 10:53:08 -0500

> table in http://www.iana.org/assignments/icalendar/icalendar.xhtml is

I'm super wrong. Please disregard that. We will not rename the
registries to sub-registries.

Simon

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Jan 2011 10:59:58 -0500

Simon says...
> propose that we rename all of them to "sub-registries".

That works, though I personally prefer separate registries that are
grouped together in the main list.  It's a question of whether you
want to have all the tables in the same "file", or separate files for
the separate tables.  My preference is the latter, but I don't really
care how we wind up doing it.

> to the RFC editor to add the URL picked by IANA to the final RFC.)

Actually, IANA are happy to have us specify that; if you have any
doubt, we can check with Michelle.  And RFC 5226 does suggest putting
them in.

Cyrus says...
> Actually, what might be useful is to have a

I like that idea!  The people who prefer nroff won't be thrilled, but hey....

Barry

---

From: Likepeng <[email-masked]>
Date: Thu, 06 Jan 2011 02:06:13 +0000

Hello all,

I posted -01 for the ID property extension draft.

Main changes in this version:
1. Put the "terminology" section as a subsection of "Introduction";
2. Follow the registration template for the property definitions (suggestion from Simon);
3. Simplified the IANA registration section to just a registration table (suggestion from Simon);
4. Change "DDAY" to "DEATHDAY", change "BIRTH" to "BIRTHPLACE", and changed "DEATH" to ""DEATHPLACE", to make it easier to understand from the property name. This also follows the recommendation from the wiki page mentioned by Simon:
http://microformats.org/wiki/vCard4

Comments and suggestions are welcome!

Thanks,
Kind Regards
Kepeng
---------------------------------------------------------------------------------------------------
From: [email-masked] 
To: [email-masked] 
Reply-to: [email-masked] 
Subject: I-D Action:draft-li-vcarddav-vcard-id-property-extensions-01.txt 
X-RSN: 1/0/935/34380/37747 
 
A New Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : vCard Format Extensions : date of death; places of birth and death 
Author(s) : K. Li, B. Leiba 
Filename : draft-li-vcarddav-vcard-id-property-extensions-01.txt 
Pages : 6 
Date : 2011-01-05 
 
This document defines an extension to the vCard data format for 
representing and exchanging information about the date of death, the 
place of birth, and the place of death of the object the vCard 
represents. 
 
Note 
 
Discussion and suggestions for improvement are requested, and should 
be sent to [email-masked]. 
 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-li-vcarddav-vcard-id-property-extensions-01.txt