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

[Daisuke Miyakawa <[e-mail]>]

2010/7/6 Simon Perreault <[e-mail]>

> On 2010-07-06 10:25, Daisuke Miyakawa wrote:
> > One proposal I can do is that composer side are allowed (but not
> > recommended) to use the format only when they cannot emit the word (like
> > when users want to edit foreign friends name without an appropriate IME)
> > but know codepoint for that characters.
> > Receiver side MUST be able to decode \xNNNN to appropriate Unicode form.
> > This is a kind of dirty compromise but there's no technical difficulty
> > nor theoretically insufficiency. I suppose I can implement
> > sender/receiver easily.
>
> I think you are confusing encoding with how a particular implementation
> renders the text.



> It is perfectly fine for an implementation to render text as \xNNNN when
> e.g. a font is unavailable.
>
> It is also perfectly fine for an implementation to take \xNNNN as input.
>
> But what goes on the wire is pure UTF-8. How it gets rendered or how it
> is input by a user is completely irrelevant for the vCard data format.


Well, I think we should also take care of actual use cases vCard is treated
by users, not only from the view of purity of UTF-8. I know \xNNNN makes the
text dirtier.

This is my understanding: If we have contact application with 100%
capability, we don't need to take care of \xNNNN topic at all. But my
(short) experience tells me that, really often, I had to look at bare data
with emacs, vi, or notepad.
At that stage, adding \xNNNNNNNN is really practically useful fallback for
reading/editing the data.

Feel free to correct me. I know my saying is really biased toward "how it
can be implemented and be used",
not "how it should be written as a specification".

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]