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

[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 "\:".

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]