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

Daisuke Miyakawa <d.miyakawa@gmail.com> Tue, 06 July 2010 05:41 UTC

Return-Path: <d.miyakawa@gmail.com>
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 0BFBA3A6A18 for <vcarddav@core3.amsl.com>; Mon, 5 Jul 2010 22:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.808
X-Spam-Level: *
X-Spam-Status: No, score=1.808 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753]
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 4GAscnJ-fF2r for <vcarddav@core3.amsl.com>; Mon, 5 Jul 2010 22:41:32 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 208193A6A15 for <vcarddav@ietf.org>; Mon, 5 Jul 2010 22:41:32 -0700 (PDT)
Received: by gyh3 with SMTP id 3so3099750gyh.31 for <vcarddav@ietf.org>; Mon, 05 Jul 2010 22:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mOdLBeTlwNsZbJjIV65QHEPfYWGEFs9hPhfsdEmA9ok=; b=LmGnAZcxS7PAYFg4FcnsYXgFQ/RnYWyKlb4vmAP+fh6JMi0jyJ8OdsrSZYBhRCY52W 4dl5yolZix8JIpY08smSXKmWchVhhXgRhFHCC9n+EMtouNRnPzgESm4Xlgx93r/AORl4 M/B6k7rPrp1x1vD8Y+/L/h4zmNvoTgQaE0ofc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Fm+P31dYdIS+jJ/Imlxd9N/n/VumWdARMzEJJt+qCmp8C1wzL8rZLzXsHXEsetIfWh AEReb5UCisbtyPZgvCGe01d9su3BQwbbt7Qjn594kfVY7YNtdCVQQIcyxZ+qczRhJL1d IPkkVhkJqj6vrpNF7iyayjt84Pn4yzru7rc4M=
MIME-Version: 1.0
Received: by 10.90.49.7 with SMTP id w7mr4200905agw.193.1278394889315; Mon, 05 Jul 2010 22:41:29 -0700 (PDT)
Received: by 10.90.56.11 with HTTP; Mon, 5 Jul 2010 22:41:29 -0700 (PDT)
In-Reply-To: <AANLkTin2KEkx8wphdHhdQj2H9sY0VjR85JTsRjc7rJWr@mail.gmail.com>
References: <AANLkTik6O1nZvjdDRn1bdGb20xKbWJApIsnwfTJ8BbRa@mail.gmail.com> <4C31CF6B.9050500@viagenie.ca> <AANLkTimt74eL5nCfDFK2QgHggyL9qONlqAUDOWKjan-l@mail.gmail.com> <4C31DA5F.6030906@viagenie.ca> <AANLkTin2KEkx8wphdHhdQj2H9sY0VjR85JTsRjc7rJWr@mail.gmail.com>
Date: Tue, 06 Jul 2010 14:41:29 +0900
Message-ID: <AANLkTinAXf4I7sJMAb-yVBac4-B4Mwmzq1uuvfTUySJI@mail.gmail.com>
From: Daisuke Miyakawa <d.miyakawa@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: multipart/alternative; boundary="00163630f00542a6b9048ab18160"
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 05:41:34 -0000

2010年7月6日13:53 Daisuke Miyakawa <d.miyakawa@gmail.com>:

>
>
> 2010年7月5日22:13 Simon Perreault <simon.perreault@viagenie.ca>:
>
> 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 "\:".
>

Ah, sorry. After looking at the section 2.4.2 in RFC 2426, COLON MUST be
escaped. My bad :(
Please ignore my saying around colon. But I am still interested in this
topic overall.


>
> 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 (宮川大輔)
> d.miyakawa@gmail.com
>



-- 
Daisuke Miyakawa (宮川大輔)
d.miyakawa@gmail.com