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

From: Barry Leiba <[email-masked]>
Date: Thu, 3 Nov 2011 21:09:17 +0000

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

---

From: "Tantek Çelik" <[email-masked]>
Date: Fri, 4 Nov 2011 05:12:51 +0000

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 <[email-masked]>
Sender: [email-masked]
Date: Thu, 3 Nov 2011 21:09:17 
To: vCardDAV<[email-masked]>
Subject: [VCARDDAV] vcarddav-birth-death-extensions update

Barry
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Nov 2011 08:49:22 -0400

Hi Barry,

I'm OK with points 1 and 2. For point #3, see below.

> to be OK with this in order for us to go forward with it.  Please

I've been thinking about this and I have a suggestion: why not make 
BIRTHPLACE and DEATHPLACE *exactly* like ADR? This would include:
- the same components separated by semicolons
- the LABEL parameter for free-form description (you might want to 
expand the semantics to more than just "delivery address label")
- the GEO and TZ parameters

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: Cyrus Daboo <[email-masked]>
Date: Fri, 04 Nov 2011 09:37:12 -0400

Hi Simon,

--On November 4, 2011 8:49:22 AM -0400 Simon Perreault 
<[email-masked]> wrote:

> - the LABEL parameter for free-form description (you might want to expand
> the semantics to more than just "delivery address label")

I was thinking exactly the same, so +1.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Nov 2011 09:54:26 -0400

Simon and Cyrus say...
> I was thinking exactly the same, so +1.

Happy to do that, if no one objects.  I'll go ahead and make the
change, and put the version into SVN for now.  I'll just do it by
reference, saying that the description of ADR describes this as well.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Nov 2011 16:12:08 +0000

> reference, saying that the description of ADR describes this as well.

Updated; same URL:

Please check to make sure I got it right, including the ABNF and the examples.

Barry

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Nov 2011 12:44:24 -0400

> Please check to make sure I got it right, including the ABNF and the examples.

I reviewd the changes and have a few comments. First, the simple syntax 
errors.

Commas in double-quoted parameter strings don't need to be escaped. 
Also, there are 7 components so 6 semicolons are needed.

OLD:
	DEATHPLACE;LABEL="Aboard the Titanic\, near Newfoundland";	
	 GEO="geo:41.731944,-49.945833":;;;;;
NEW:
	DEATHPLACE;LABEL="Aboard the Titanic, near Newfoundland";	
	 GEO="geo:41.731944,-49.945833":;;;;;;

OLD:
	BIRTHPLACE;GEO="geo:46.769307,-71.283079":;;;;;Canada
NEW:
	BIRTHPLACE;GEO="geo:46.769307,-71.283079":;;;;;;Canada

==============

More importantly, what is the difference between this

	DEATHPLACE;LABEL="Aboard the Titanic\, near Newfoundland";	
	 GEO="geo:41.731944,-49.945833":;;;;;

and this?

	DEATHPLACE;LABEL="Aboard the Titanic\, near Newfoundland";	
	 VALUE=uri:geo:41.731944\,-49.945833

(ADR didn't allow URI values so it didn't have the same possible 
ambiguity...)

==============

Reserving the English string "unknown" seems awkward to me. How is the 
LANGUAGE parameter supposed to handle this?

Is this supposed to be interpreted as "unknown"?

	DEATHDATE;VALUE=text;LANGUAGE=en:unknown

How about this one?

	DEATHDATE;VALUE=text;LANGUAGE=en-US:unknown

How about this one?

	DEATHDATE;VALUE=text;LANGUAGE=fr:inconnue

How about this?

	DEATHDATE;VALUE=text;LANGUAGE=en:unknown
	DEATHDATE;VALUE=text;LANGUAGE=fr:inconnue

An idea, which I'm not sure is a good one, could be to reserve the empty 
string instead.

	DEATHDATE;VALUE=text:

With or without a LANGUAGE parameter, it would always be the same.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 04 Nov 2011 13:34:04 -0400

Hi Barry,

> Please check to make sure I got it right, including the ABNF and the

1) So in the formal syntax for each property you list altid-param, but in 
the template "Property Parameters", ALTID is not listed.

That said, I am wondering why "Property Parameters" appears to be missing 
from all the properties in RFC6350. The template says that parameters MUST 
be listed (actually it says "Any of the valid property parameters for the 
property MUST be specified." but that really ought to be "All of the 
valid..."). It seems a little odd for 6350 to not follow its own rules...

2) The formal syntax for DEATHDATE splits out the sets of parameters valid 
for each value type. Shouldn't that also be done for BIRTHPLACE and 
DEATHPLACE?

3) I am a little concerned about introducing new "compound" properties 
(having previously said +1 to that). The problem is how will existing vCard 
parsers handle those? The key issue being \ encoding of ;. Specifically 
6350 says:

   Some properties (e.g., N and ADR) comprise multiple fields delimited
   by a SEMICOLON character (U+003B).  Therefore, a SEMICOLON in a field
   of such a "compound" property MUST be escaped with a BACKSLASH
   character.  SEMICOLON characters in non-compound properties MAY be
   escaped.  On input, an escaped SEMICOLON character is never a field
   separator.  An unescaped SEMICOLON character may be a field
   separator, depending on the property in which it appears.

Now, a parser that does not know BIRTHPLACE is compound, could read it in 
as "plain" text, and re-generate it using \; in place of ; (because it says 
"SEMICOLON characters in non-compound properties MAY be escaped."). That is 
going to be problematic. In fact this is a subset of a bigger problem with 
extensibility that also crops up in iCalendar - namely how do existing 
parsers cope with new properties whose default value type is not TEXT? 
e.g., URIs can contain comma characters, so a parser not aware of the fact 
that a new property's default is URI could reject the vcard because of an 
unescaped comma, or could "tolerate" it but then re-generate the value with 
a \, - which would make it an invalid URI.

Now, one solution to the later problem is to always require a VALUE= 
parameter on new properties even when the actual value type is the default 
(except perhaps if the default is TEXT). That should "force" existing 
parsers to properly parse the value and properly regenerate it.

As to the first problem with compound value types, I am not sure what the 
answer is other than to not allow those in extensions (which would kind of 
break this extension). It probably would have been better to have a 
"TEXT-LIST" value type to indicate a compound value...

NB One way around both problems would be for parsers to treat any 
unrecognized property's value as "raw text". i.e. store and re-generate 
as-is without applying any kind of encoding/decoding.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Nov 2011 13:38:04 -0500

Simon says...
> LANGUAGE parameter supposed to handle this?

Cyrus says...
> parsers handle those? The key issue being \ encoding of ;.
...
> Now, a parser that does not know BIRTHPLACE is compound, could read it in as
> "plain" text, and re-generate it using \; in place of ; (because it says
> parsers cope with new properties whose default value type is not TEXT? e.g.,
> URIs can contain comma characters, so a parser not aware of the fact that a
> new property's default is URI could reject the vcard because of an unescaped
> comma, or could "tolerate" it but then re-generate the value with a \, -
> which would make it an invalid URI.

Oy.

OK, given Simon's and Cyrus's comments, it seems that both of these
changes are too much to deal with post-IESG-approval.  I think the
best thing to do is pull the changes back out, and leave the approved
version.

It's too bad that we didn't leave things open for broader use of the
"ADR" property style.  Maybe we should have created a value type of
"address", defined as the semicolon-delimited string that's in ADR.
Then we could have applied it in ADR, and wherever else it might later
make sense.  Alas, we don't have that, so we're stuck.

Let's keep that in mind for future extensions and other changes: don't
put special-case parsing into value=text; instead, create value types
for the structured data.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 23 Nov 2011 14:36:14 -0500

Hi Barry,

> put special-case parsing into value=text; instead, create value types

Another option: how about instead of BIRTHPLACE as a property, we could use 
ADR with a TYPE=birthplace? I suspect that may be too radical in that 
existing clients will present it as a "valid" mailing address that could 
get confused with others. But it seems reasonable to me that any property 
that needs to look like an "ADR" value out to simply be ADR with a specific 
type...

A question: is there really no URI scheme for a mailing address? Should 
there be one?

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Nov 2011 14:44:47 -0500

> existing clients will present it as a "valid" mailing address that could get
> confused with others. But it seems reasonable to me that any property that
> needs to look like an "ADR" value out to simply be ADR with a specific
> type...

Yes, that sounds sensible, as well.  But again, too late for this.

> A question: is there really no URI scheme for a mailing address? Should

Hm.
I think there isn't.  Why not ask the "why not?" question over on uri-review ?

b

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Nov 2011 14:03:07 -0700

> Yes, that sounds sensible, as well.  But again, too late for this.

Agreed.

Barry, do you think we are done with this I-D? I see that Sean Turner
has cleared his DISCUSS, and the various IESG comments appear to be
related to vCard more broadly, so I think this I-D is ready for AD
approval. But I might be missing something. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 29 Nov 2011 16:14:08 -0500

> approval. But I might be missing something. :)

Yes, we're ready.  Since this has been approved by the IESG, this is
set to go into "Approved, announcement to be sent."

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Nov 2011 14:27:08 -0700

> set to go into "Approved, announcement to be sent."

Yepper. I'll email the IESG Secretary about that now...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/