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

Daisuke Miyakawa <> Tue, 06 July 2010 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 624743A67C2 for <>; Tue, 6 Jul 2010 07:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.295
X-Spam-Level: **
X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[AWL=1.281, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wqHvSYHM9+Mw for <>; Tue, 6 Jul 2010 07:42:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C0B2D3A67BD for <>; Tue, 6 Jul 2010 07:42:47 -0700 (PDT)
Received: by gwb10 with SMTP id 10so3367446gwb.31 for <>; Tue, 06 Jul 2010 07:42:45 -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=BNswrFoX+ztDigt1FYmLoICZEsM44szN2Qk7S/WBhLc=; b=FKFY/y3PpxFbqmMzE0Xjml/dEDSlhJkCDyHS3VMhsA2vD5bCKOVbtiIHtLWEITHSlo p84N0FWjkgVIER2U8TZPFzo62+e9tZd59bA8U3OKbNHMC9XbaW5fD01Fn9Kcz/qp3YRu 2a/+RJCBLQASu0RLTKw7OLRufwvx7eITo0DAU=
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=UTDWsSVczo3RdGSNSTi6I5PVxfKgCUlAoIjstUcI0JU++zrPpvO0MUnkGSlw16/NCC VJWqRX8q71wgoMf3673H9z98OIuyGaGkTYqWPtUy6neCbKNjg6ckCUaijf2JUKJp3YI5 NO6fEkKSQTIaVC1HQnsc953cm8IgOgC6dUYI4=
MIME-Version: 1.0
Received: by with SMTP id g20mr4696365agb.90.1278427365612; Tue, 06 Jul 2010 07:42:45 -0700 (PDT)
Received: by with HTTP; Tue, 6 Jul 2010 07:42:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 06 Jul 2010 23:42:45 +0900
Message-ID: <>
From: Daisuke Miyakawa <>
To: Cyrus Daboo <>
Content-Type: multipart/alternative; boundary="0016361e8238ffa162048ab91098"
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 14:42:50 -0000


At first, thank you for your follow-ups!

2010/7/6 Cyrus Daboo <>

> Hi Simon,
> --On July 6, 2010 9:46:12 AM -0400 Simon Perreault <
>> 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 (宮川大輔)