Re: [VCARDDAV] vcarddav-birth-death-extensions update

I for one am still quite ambivalent on the addition of birth/death location and date of death properties to vCard. 
I think the use cases presented so far all fall under a slightly broader set of genealogy related properties, and as such that may make more sense as a cluster of properties to make into an extension.

In addition some comparing and contrasting can be done with existing genealogy formats (e.g. GEDCOM. more here: http://microformats.org/wiki/genealogy-formats which of course tracks/references these extensions as well) to both inform the design (set/naming) of properties, with hopefully some degree of schematic interop with existing format(s). 

Regarding:
"why we'd want to add all sorts of
properties that seem to have little bearing on what people would put
into address books, and whether we might eventually start adding eye
colour, shoe size, and favourite movie."

Indeed.

Far more often than any of those properties, I have seen forms use (and seen utility for tracking)

t-shirt size

Often in conference forms and company address books so that someone getting a bunch of t-shirts can order sizes accordingly.

Does this mean I should write-up a 

draft-ietf-vcarddav-tshirt-extension-01

document for this group to review?

Thanks,

Tantek

-----Original Message-----
From: Barry Leiba <barryleiba@computer.org>
Sender: vcarddav-bounces@ietf.org
Date: Thu, 3 Nov 2011 21:09:17 
To: vCardDAV<vcarddav@ietf.org>
Subject: [VCARDDAV] vcarddav-birth-death-extensions update

The IESG has discussed draft-ietf-vcarddav-birth-death-extensions-01,
and had a number of comments on it, most of which amount to asking the
question of what vCards are for, why we'd want to add all sorts of
properties that seem to have little bearing on what people would put
into address books, and whether we might eventually start adding eye
colour, shoe size, and favourite movie.  And, yes, we eventually
might, so that needs to be said somewhere, perhaps in a revision of
RFC 6350.

But for now, there are a few main points that I want to take up before
we let birth-death-extensions get published.  To that end, I'm ready
to post an -02 version, which you can currently view here:
http://trac.tools.ietf.org/wg/vcarddav/trac/browser/draft-ietf-vcarddav-birth-death-extensions-02.txt

There are three things that this version changes:

1. It resolves Sean's DISCUSS point, by putting the normative language
in from the ABNF for DEATHDATE into the "Description" section of the
registration template.  I agree with him that this is a good idea.

2. It addresses a suggestion by Adrian to have a way of specifying
that the vCard's subject is known to be dead, without specifying the
date or place of death (perhaps because they are unknown).  See the
"description" field for DEATHDATE, and please comment on whether you
think that is suitable.  (Note that I am NOT addressing Adrian's
further comment about explicitly noting that the subject is NOT dead
(which starts to sound Monty-Python-esque), or that it is not known
whether or not the subject is dead.  I think we can easily
overcomplicate things beyond the point of usefulness, and there's not
been any stated demand for that.)

3. It addresses a comment by Dan that it might be useful to allow
specification of the place of birth or death by, say, city or country.
 I agree that this would be a good idea, and have proposed a mechanism
for that in the description fields of BIRTHPLACE and DEATHPLACE: if
the value is text AND the text value contains semicolons, it is to be
interpreted as a structured field as described for the ADR property.
I think this is a reasonable way to do this, but I think the WG needs
to be OK with this in order for us to go forward with it.  Please
review this and comment.

If we're all OK with these three changes, then Peter can go ahead with
approving the -02 version.

Barry
_______________________________________________
VCARDDAV mailing list
VCARDDAV@ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav