[VCARDDAV] vcarddav-birth-death-extensions update

[Barry Leiba <[e-mail]>]

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