vCard Format Extensions: Place of Birth, Place and Date of Death
draft-ietf-vcarddav-birth-death-extensions-02

[Ballot discuss]
1) Does the template allow "description" to be empty?  Sometimes folks really don't like normative language in the ABNF - maybe in the description is where you could duplicate the normative requirements from the ABNF.

2) cleared

[Ballot comment]
1. As other ADs have noticed place and date of death do not seem to fit comfortably within the scope of the typical information carried by vcards. It would be useful to add some text about applicability, maybe examples.

2. One of the more current information included in biographies when talking about the pace of birth is the country of birth. Did the authors and WG discuss including this information, maybe the ISO 3166 country codes? This question  also applies for the place of death

[Ballot comment]
1. As other ADs have noticed place and date of death do not seem to fit comfortably within the scope of the typical information carried by vcards. It would be useful to add some text about applicability, maybe examples.

2. One of the more current information included in biographies when talking about the pace of birth is the country of birth. Did the authors and WG discuss including this information, maybe the ISO 3166 country codes? This could be true also for the place of death

[Ballot comment]
Well, ain't it weird? RFC 6350 describes the purpose of vCard as...

  allows the capture and exchange of
  information normally stored within an address book or directory
  application.

IMHO, the death place and death date are not pertinent for such
applications. So, probably, people use vCard for more widespread
information storage. That may be OK, but I guess someone should say
so, somewhere.

This seems to follow up the comments from a number of other ADs
and I also wonder about inside-leg-measurement.

---

Suppose I know someone is dead, but don't know where or when. How do I
represent that in your new properties?

Including a place of death without a date of death, would clearly show
the person is dead. Similarly including a date of death without a place
would let me know. but obviously if both fields are absent it says
nothing one way or the other.

Maybe you could give as one of the examples...

      DEATHDATE;VALUE=text:unknown

...and that states that the person is actually dead,

But what about if you actually do not know whether the person is dead,
and you want to convey this?

And what do I now assume about a vCard that does not include the death
properties? Is that person alive?

---

Section 3 says:

  This presents no security considerations beyond those in section 9 of
  the base vcard specification [RFC6350].

But surely you have opened up the Internet to attacks from Zombies and
Vampires?

[Ballot comment]
Looking at the other comments, I do wonder whether we need a lighter weight registration scheme for these vcard attributes.

Wouldn't expert review be adequate?

[Ballot discuss]
1) Does the template allow "description" to be empty?  Sometimes folks really don't like normative language in the ABNF - maybe in the description is where you could duplicate the normative requirements from the ABNF.

2) Are there any privacy considerations for birthplace?

[Ballot comment]
The Gen-ART Review by Martin Thomson on 16-Sep-2011 raised a few
  questions.  Please consider them.

  Did anyone consider that a RESTINGPLACE tag might be added?  It seems
  like in some instances it could be more useful than DEATHPLACE.  That
  might be more relevant for certain "objects".  At risk of sounding
  macabre, for some "objects" this might need to allow multiple values.

  I note that there seems to be some contention about the precise
  coordinates to use in identifying the wreck, though it appears that
  Wikipedia (41?43'55"N, 49?56'45"W) was used as a source in this
  instance.

[Ballot discuss]
The Gen-ART Review by Martin Thomson on 16-Sep-2011 caught an error:

  The example DEATHPLACE seems to identify the location of the wreck of
  the titanic.  The example omits the 'geo:' URI prefix.

[Ballot comment]
Is this really needed? There's no real justification
and why wouldn't I follow this up with an equivalent
for height, shoe size, trouser size, favourite-drink,
scratches-nose-occasionally or whatever? Do we
really want an RFC for each and every such
thing/attribute?

[Ballot comment]
The Gen-ART Review by Martin Thomson on 16-Sep-2011 raised a few
  questions.  Please consider them.

  Did anyone consider that a RESTINGPLACE tag might be added?  It seems
  like in some instances it could be more useful than DEATHPLACE.  That
  might be more relevant for certain "objects".  At risk of sounding
  macabre, for some "objects" this might need to allow multiple values.

  I note that there seems to be some contention about the precise
  coordinates to use in identifying the wreck, though it appears that
  Wikipedia (41?43'55"N, 49?56'45"W) was used as a source in this
  instance.

[Ballot discuss]
The Gen-ART Review by Martin Thomson on 16-Sep-2011 caught an error:

  The example DEATHPLACE seems to identify the location of the wreck of
  the titanic.  The example omits the 'geo:' URI prefix.

[Ballot comment]
It would be interesting to know why date and place of death are considered useful information in a vcard, since that goes beyond most people's use of an address book or contact list.

IANA understands that, upon approval of this document, there is a single IANA Action which needs to be completed.

In the vCard Properties registry in the vCard Elements registry located at:

http://www.iana.org/assignments/vcard-elements/vcard-elements.xml

three new elements will be registered as follows:

+-----------+--------------+------------------------+
| Namespace | Property    | Reference              |
+-----------+--------------+------------------------+
|          | BIRTHPLACE  | RFC-to-be, section 2.1 |
|          | DEATHPLACE  | RFC-to-be, section 2.2 |
|          | DEATHDATE    | RFC-to-be, section 2.3 |
+-----------+--------------+------------------------+

IANA understands that this is the only IANA Action required upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (vCard Format Extensions : place of birth, place and date of death) to Proposed Standard


The IESG has received a request from the vCard and CardDAV WG (vcarddav)
to consider the following document:
- 'vCard Format Extensions : place of birth, place and date of death'
  as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The base vCard 4.0 specification defines a large number of
  properties, including date of birth.  This specification adds three
  new properties to vCard 4.0, for place of birth, place of death, and
  date of death.

Note

  Discussion and suggestions for improvement are requested, and should
  be sent to vcarddav@ietf.org.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-vcarddav-birth-death-extensions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-vcarddav-birth-death-extensions/


No IPR declarations have been submitted directly on this I-D.