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

[Barry Leiba <[e-mail]>]

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

Cyrus says...
> 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 ;.
...
> 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.

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