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

[Cyrus Daboo <[e-mail]>]

Hi Barry,

--On November 4, 2011 4:12:08 PM +0000 Barry Leiba 
<[e-mail]> wrote:

>> 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.
>
> Updated; same URL:
> http://trac.tools.ietf.org/wg/vcarddav/trac/browser/draft-ietf-vcarddav-b
> irth-death-extensions-02.txt
>
> Please check to make sure I got it right, including the ABNF and the
> examples.

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