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

[Daisuke Miyakawa <[e-mail]>]

2010年7月6日13:53 Daisuke Miyakawa <[e-mail]>:

>
>
> 2010年7月5日22:13 Simon Perreault <[e-mail]>:
>
> On 2010-07-05 09:00, Daisuke Miyakawa wrote:
>> > I think "undefined" does not help actual receivers. They will have to
>> > cope with real senders which often have some bugs. Almost all of the
>> > bugs are unexpected, but some can be, like this time. At least, we are
>> > able to reduce the possibility of ambiguity now.
>> >
>> > When my developing a receiver for vCard 3.0, I found some really
>> > well-known sender  (please let me make the application's name secret..)
>> > encoded texts wrongly using '\', and I had to decide on how to handle
>> > it, as receiver's behavior was "undefined" while actually it is easily
>> > detected.
>> >
>> > I don't think just one tiny mistake in sender side should make receivers
>> > confused.
>>
>> 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.
>
> NOTE:Some sender do like this\: yes, a colon is escaped.\N
>  \tIn this line, a tab is wrongly escaped.\n;This semicolon is not escaped,
> then Parsers would confuse;
>  what this semicolon actually means in sender side apart from
> specification\; the sender wanted to split
>  this note into two while vCard 4.0 does not allow\, or just it is an
> exception?
>
> What I actually saw and got confused in vCard 3.0 was "\:".
>

Ah, sorry. After looking at the section 2.4.2 in RFC 2426, COLON MUST be
escaped. My bad :(
Please ignore my saying around colon. But I am still interested in this
topic overall.


>
> What I may possibly encounter in the vCard 4.0 will be the combination
> of "\;" and ";" in one sentence, while of course it is wrong in our
> specification.
>
> According to "Postel's Law", we should "be liberal in what you accept, and
> conservative in what you send." This time, however, "how to be liberal in
> what we accept" is not defined in the current draft,
> while I agree "how to be conservative in what we send" is defined well.
>
> > This time, on the other hand, we cannot see the value without encoding
>> > (" \x3000 " is much easier to read than "  "). Making the ambiguity
>> > around spaces and control characters visible is feasible enough, I
>> suppose.
>>
>> I disagree again. If you are using a given character in a sentence,
>> whether it is visible or not, it is because you intend the recipient to
>> read it. Otherwise, the character would not be useful and would not be
>> present. For example, in this paragraph I used many spaces which are
>> invisible and I don't think we would gain anything by replacing them
>> with \x20 in a vCard. We are encoding user-readable text in vCard, not
>> random bits.
>>
>
> Well, sorry for confusing you.
> The space is just an example, and I also don't think it is a good idea to
> let senders to use \x method toward every characters including Ascii.
>
> 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.
>
> 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...?
>
>
>
>> Thanks,
>> Simon
>> --
>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
>> STUN/TURN server        --> http://numb.viagenie.ca
>> vCard 4.0               --> http://www.vcarddav.org
>>
>
>
>
> --
> Daisuke Miyakawa (宮川大輔)
> [e-mail]
>



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