vCard Format Extensions: Place of Birth, Place and Date of Death
RFC 6474

Note: This ballot was opened for revision 02 and is now closed.

(Peter Saint-Andre) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-11-01 for -)
No email
send info
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?

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

Comment (2011-10-26 for -)
No email
send info
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. 

(Adrian Farrel) No Objection

Comment (2011-11-01 for -)
No email
send info
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?

(Stephen Farrell) No Objection

Comment (2011-10-30 for -)
No email
send info
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?


(David Harrington) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2011-10-30)
No email
send info
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.

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

Comment (2011-11-03 for -)
No email
send info
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

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection