Re: [VCARDDAV] Questions about text handling in vCard 4.0 (rev 11)

[Daisuke Miyakawa <[e-mail]>]

Hi,

At first, thank you for your follow-ups!

2010/7/6 Cyrus Daboo <[e-mail]>

> Hi Simon,
>
>
> --On July 6, 2010 9:46:12 AM -0400 Simon Perreault <
> [e-mail]> wrote:
>
>     Can you please suggest text for what you have in mind? Probably a
>>>    sentence or two to be added at the end of 3.3...?
>>>
>>> Here's an arbitrary example.
>>>
>>
>> I meant text that we should add to the vCard 4 specification and that
>> would address your concern...
>>
>
> Actually I do not think we should add any text that legitimizes incorrect
> generation of vCard data. The "be liberal" is a statement for implementors
> to act on, not for specifications themselves to describe.
>
> Yes I too have seen broken escape sequences in vCard data and have adjusted
> our parser to be "liberal" and treat any backslash/character pair that is
> not explicitly defined in vCard as an "escape" for the character. i.e., just
> remove the backslash. That is an implementation decision and not something
> that should go in the spec.


We should decide on whether or not the latest spec allows obvious ambiguity
and allows each developer to lose the original meaning, which means (at
least for me) developing regression tests will become harder, because I
cannot determine which kind of result is expected even after carefully
seeing the specification.

When multiple applications received/sent contact list, the meaning would
become ambiguous. I think we should avoid this kind of undefinedness if we
are already aware of it, as my understanding is that specification is for
removing that kind of ambiguity as much as possible at establishing stage.

If we can accept it, I have no further objection.


>  The problem here is we cannot estimate potential Unicode which harm
>>> actual readability/edit-ability/xxx-ability caused by receiver/editor
>>> side's limitation. Even readability is part of my concern.
>>>
>>
>> What we're talking about here is how Unicode characters get encoded in
>> vCard. The current method is to encode them as-is. You are suggesting to
>> use \xNNNN, and your argument is readability. I think this argument is
>> weak because:
>>
>> - Unicode characters may actually be *more* readable than \xNNNN notation.
>> - Do we really care about readability of vCard data that is going to be
>> displayed exactly the same to the user regardless of the encoding?
>>
>
> I am with Simon on this. \xNNNN escaping is not needed.



>  Another example: a final fallback method users will use during reading
>>> and editing vCard would be just opening the file and editing it
>>> manually. Then how can they edit unknown characters like Chinese,
>>> Japanese, Korean, V...?
>>>
>>
>> I don't see a problem. What do you mean by "unknown"? I can just use vi
>> on any UTF-8 file and edit it without any difficulty. One can do the
>> same with Microsoft Word or any other editor that understands UTF-8 I
>> would assume.
>>
>
> +1
>
> --
> Cyrus Daboo
>
>


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