Subject: [VCARDDAV] Three extension drafts to consider

From: Barry Leiba <[email-masked]>
Date: Fri, 25 Feb 2011 18:11:36 -0500

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Feb 2011 08:45:50 -0500

> a common property needed by different specs.  Any ideas?

Can't you have one refer normatively to the other with text such as:
"The XYZZY property, as defined in [blah], MUST be supported."
?

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: Likepeng <[email-masked]>
Date: Tue, 01 Mar 2011 01:38:14 +0000

Good suggestion!

Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Simon Perreault
发送时间: 2011年2月28日 21:46
收件人: [email-masked]
主题: Re: [VCARDDAV] Three extension drafts to consider

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
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav