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

Daisuke Miyakawa <> Tue, 06 July 2010 04:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9261F3A685F for <>; Mon, 5 Jul 2010 21:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.338
X-Spam-Level: *
X-Spam-Status: No, score=1.338 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vyynJHIJAwZZ for <>; Mon, 5 Jul 2010 21:53:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1E47C3A6862 for <>; Mon, 5 Jul 2010 21:53:43 -0700 (PDT)
Received: by gyh3 with SMTP id 3so3089523gyh.31 for <>; Mon, 05 Jul 2010 21:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sioldF3lS2VO+RHAGsigrxk/t7H/QzRUJI7pn/1yymk=; b=X1qY9C6ri9Kv0vkIw7TVju24Yeu31TNxUUwg11DTwN1/fAUklQOgjkN/ccmyLgOSik fZbFl2ewhfQwBuSpeSHXImPsmzBe7dKN/KSE7AoMs9plNPp4auiMVJJyvoezOANmVrqu 7IKaF+tpK9kYMS5Peu9A8ODaCpJwAC4f+Wh4E=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bcw/IIY3gRaT+rdFEO3IdJo8CWVePuYB1IUe01jbiUJqpa+L0RQAVz1Fq0x6FxjcMv 060ZmbNHKs5h7nZaTWDyaj8YDX20PPjLDeHRqu5sIOM2EQk6RVI4z+Det4UX+wsQ3rU3 crEyklzifJ3I9ZhwjIi6Qgc6Tg8cXiX0r3bMc=
MIME-Version: 1.0
Received: by with SMTP id w18mr3921098aga.146.1278392020038; Mon, 05 Jul 2010 21:53:40 -0700 (PDT)
Received: by with HTTP; Mon, 5 Jul 2010 21:53:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 06 Jul 2010 13:53:39 +0900
Message-ID: <>
From: Daisuke Miyakawa <>
To: Simon Perreault <>
Content-Type: multipart/alternative; boundary="0016361e87fc3d059a048ab0d671"
Subject: Re: [VCARDDAV] Questions about text handling in vCard 4.0 (rev 11)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jul 2010 04:53:44 -0000

2010年7月5日22:13 Simon Perreault <>:

> 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

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

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 -->
> STUN/TURN server        -->
> vCard 4.0               -->

Daisuke Miyakawa (宮川大輔)