Re: [VCARDDAV] Proposal around escape character handling (2nd round)

[Daisuke Miyakawa <[e-mail]>]

As for the proposal 2, 3, 4, I'll refrain my opinion right now: there's no
strong opposition toward what you guys suggest =)

I'd like to focus on proposal 1: escaping semicolon, a field delimeter
2010/7/13 Cyrus Daboo <[e-mail]>
>
> Hi Daisuke,
>
> --On July 13, 2010 10:35:32 PM +0900 Daisuke Miyakawa <
[e-mail]> wrote:
>
>> ****** Proposal 1 (new):
>> The one-to-one rules above MUST be applied to "all" the properties, even
>> including X- properties, for uniformity between properties.
>> In other words, semicolons MUST be escaped even when the property does
>> not allow multiple values (like (0, 1)).
>>
>>
>> In this proposal, how readers must/should act when ';' is given without
>> escape in those properties is undefined. I don't think "undefined" is a
>> good idea,
>> but I cannot think up better idea for mentioning it as a formal
>> specification.
>
> ; is used as a separator for "compound" values not multiple values (i.e.
the "cardinality" (0, 1) has no bearing on that). In compound values it is
vitally important to know where the field delimiters are (';') vs normal
text occurrences of the field delimiter ('\;').
>
> So there is a real problem here. For example, if in the future I define a
new property FOO that uses a ;-delimited compound value, then I want to be
sure that clients not aware of this property will properly "round-trip" it.
So if I send such a client this:
>
> FOO:delimited;text\;string
>
> I want to be sure that when it parses and re-generates the vcard, the
exact same value (octet-by-octet) comes back. In that case the client must
not unescape - if it did then it would generate:
>
> FOO:delimited;text;string
>
> alternatively, if the client left the \; as-is and then re-generated it
could end up with:
>
> FOO:delimited;text\\;string
>
> and that would be wrong! Now a smart client might spot the use of \; in
the original value and somehow "mark" that as being compound and then apply
compound text generation rules when re-generating (in which case it would
hopefully generate the correct result). However, I am not sure we can rely
on that - if we want to then we need text clearly explaining what has to
happen. Failing that, there is no way to define a new property that uses a
compound TEXT value and ensure that it is backwards compatible (without
resorting to using something other than ; and , as delimiters).

That makes sense.

I think adding a rule migt be helpful:
- vCard readers MUST handle "\;" as a character ';' even when its property
name is unknown.
  That is, FOO, X-EXTRA-PROPERTY, or any other property names MUST NOT
affect how property values be treated.

>From the view of backward compatibility (2.1, 3.0), however, I agree that
this is not sufficient.
I guess a lot of vCard libraries would re-use implementations for vCard 3.0,
which does not have strict rule around the delimiter (;).
If they just use them, what you mention above would happen
(“delimited;text\;string” -> "delimited;text;string" OR
"delimited;text\\;string")


> Given all of that, I think we need text stating that new properties
(registered, X-, vendor etc) MUST NOT use COMMA or SEMI-COLON text
delimiting as existing clients may not roundtrip them. If a "structured"
value is required, then a different delimiter has to be used. We may want to
pick a specific character for that for IANA registered properties if we
care.

Feasible enough. If we do so, it would be better to clearly define what
"new" properties are.

We have several properties.

name = "SOURCE" / "NAME" / "KIND" / "FN" / "N" / "NICKNAME"

/ "PHOTO" / "BDAY" / "DDAY" / "BIRTH" / "DEATH"

/ "ANNIVERSARY" / "SEX" / "ADR" / "LABEL" / "TEL" / "EMAIL"

/ "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" / "LOGO"

/ "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" / "NOTE"

/ "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" / "URL"

/ "VERSION" / "CLASS" / "KEY" / "FBURL" / "CALADRURI"

/ "CALURI" / "XML" / iana-token / x-name

I think N, ORG, and ADR must be considered as "old" registered properties,
which are able to use the delimiter.
Then, does it make sense for us to prohibit the use of the delimiter in the
other properties including iana-token and x-name?

Also, we will need to take care of SORT-AS parameter too.

Now we don't have SORT-STRING as a property name, but rev12 has SORT-AS,
which utilized the delimiter (semicolon).
I think we also need to define its behavior

N;SORT-AS="Koura;Osamu":Koura;Osamu;;


Thanks,

-- 
Daisuke Miyakawa (宮川大輔)
[e-mail]