[VCARDDAV] Three extension drafts to consider

[Barry Leiba <[e-mail]>]

I have recently updated two drafts and submitted a first version of another:

http://tools.ietf.org/html/draft-george-vcarddav-vcard-extension
draft-george-vcarddav-vcard-extension is about social-networking
properties.  We've gotten almost no discussion about these, and, while
we've seen some interest from a couple of groups that work on
social-networking information, no one has agreed to work on the
document with us.  We'd very much like to move this forward -- there's
clearly a lot of interest in *having* social networking stuff in vCard
-- and we need some input.

http://tools.ietf.org/html/draft-li-vcarddav-vcard-id-property-extensions
draft-li-vcarddav-vcard-id-property-extensions returns a few
properties -- place of birth, date and place of death -- that were
removed in the -15 version of the vCard 4 spec.  I think this is solid
(it just puts the items back, and they were removed simply because
they didn't seem to be necessary in the base spec, and could be saved
for an extension), so I'm not as worried about comments.  We'd like a
review, and then we'll use it as a first test for how ready we are for
extensions once the v4 spec is done.

http://tools.ietf.org/html/draft-cauchie-vcarddav-oma-cab-extensions
draft-cauchie-vcarddav-oma-cab-extensions defines some items that
parallel work in the OMA CAB spec.  Comments and review on this are
welcome.  I think we'll see similar proposals, over time, of
information from other places that people want to include in vCard.

There's also one thing in particular that the first and third specs
bring out, in doing extensions.  Both have a property called
"interests".  Of course, the registry is there to make sure that there
aren't collisions, and that once someone grabs "xyzzy", the next guy
can't have that and might have to settle for "plugh".  But this is
different: first, the two specs are coming in at the same time, and
second, the two properties really are defining the same thing, and are
not in conflict.  The question is how to handle the case when there's
a common property needed by different specs.  Any ideas?

We clearly need to put priority on progress of vcardrev, but I hope we
can have some discussion of these three proposals without interfering
with that.  We've asked for a short time on the Prague agenda for
them.

Barry