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

Cyrus Daboo <cyrus@daboo.name> Tue, 06 July 2010 14:10 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DAA3A6915 for <vcarddav@core3.amsl.com>; Tue, 6 Jul 2010 07:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KmGEXYTTdC2 for <vcarddav@core3.amsl.com>; Tue, 6 Jul 2010 07:10:46 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 5976A3A6842 for <vcarddav@ietf.org>; Tue, 6 Jul 2010 07:10:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 390B7185B0BC2; Tue, 6 Jul 2010 10:10:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE6Aewqvl7Zy; Tue, 6 Jul 2010 10:10:45 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 94647185B0BB7; Tue, 6 Jul 2010 10:10:44 -0400 (EDT)
Date: Tue, 06 Jul 2010 10:10:42 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Simon Perreault <simon.perreault@viagenie.ca>, Daisuke Miyakawa <d.miyakawa@gmail.com>
Message-ID: <4C71F2C3664B9634B6E019EC@caldav.corp.apple.com>
In-Reply-To: <4C3333A4.4000307@viagenie.ca>
References: <AANLkTik6O1nZvjdDRn1bdGb20xKbWJApIsnwfTJ8BbRa@mail.gmail.com> <4C31CF6B.9050500@viagenie.ca> <AANLkTimt74eL5nCfDFK2QgHggyL9qONlqAUDOWKjan-l@mail.gmail.com> <4C31DA5F.6030906@viagenie.ca> <AANLkTin2KEkx8wphdHhdQj2H9sY0VjR85JTsRjc7rJWr@mail.gmail.com> <4C3333A4.4000307@viagenie.ca>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2136"
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] Questions about text handling in vCard 4.0 (rev 11)
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 14:10:47 -0000

Hi Simon,

--On July 6, 2010 9:46:12 AM -0400 Simon Perreault 
<simon.perreault@viagenie.ca> 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.

>> 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