Re: [VCARDDAV] Questions about vCard 4.0 (draft rev-11)

Daisuke Miyakawa <d.miyakawa@gmail.com> Wed, 23 June 2010 08:32 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 63FE13A6A64 for <vcarddav@core3.amsl.com>; Wed, 23 Jun 2010 01:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.495
X-Spam-Level: *
X-Spam-Status: No, score=1.495 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 T+cRZHfdUr3x for <vcarddav@core3.amsl.com>; Wed, 23 Jun 2010 01:32:16 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 741F33A6A68 for <vcarddav@ietf.org>; Wed, 23 Jun 2010 01:32:11 -0700 (PDT)
Received: by bwz11 with SMTP id 11so1333448bwz.31 for <vcarddav@ietf.org>; Wed, 23 Jun 2010 01:32:15 -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=3BaELUZNPaSpuJHRxf7gmGyJlNpP1g88KW8BeQLCpFk=; b=JDbHlXY5Op5O1aUMMCb5un0CJVXh6Tp77hPDwI2kFUeeNLSXIvILo8HpOt2snU56S2 xrOdhNPB9irkDjxRzFIoTnt/JB3rVaak7wRoNob4WJUQBQ+Hqiq3mEg/MEmUZZUeT3/X /mC/RUyb2L9O74ZxLTB0fwQWaL6GJnzsIJhxw=
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=lNsgIJss5rppQvOJldqkQeQkIDrloo8VFs633v5ypklU1pF77wYm6ZD+oTe8H4WkCw ZE2pBt78lbxrD7y3b9HuDdt0LSTdq5ijUZhCLbWMYrMnUTxvA9NnYmkeTftYkvOx2Ljj hpp9HaE8+tBKu422lVLqYMASMlOYORJLYFe4Y=
MIME-Version: 1.0
Received: by 10.204.25.210 with SMTP id a18mr5201069bkc.175.1277281935301; Wed, 23 Jun 2010 01:32:15 -0700 (PDT)
Received: by 10.204.67.13 with HTTP; Wed, 23 Jun 2010 01:32:15 -0700 (PDT)
In-Reply-To: <AE51FE4DF2604D0A9D2697A8438376E2@Javier2>
References: <AANLkTiniY60njEGixPGeKvs_m1LE_uVrvtnDQuXrP7jV@mail.gmail.com> <4C20B501.6030802@viagenie.ca> <AANLkTikd9ni-iCI2tIaGi803AEDjtKXE9PEIsJsONdCO@mail.gmail.com> <AE51FE4DF2604D0A9D2697A8438376E2@Javier2>
Date: Wed, 23 Jun 2010 17:32:15 +0900
Message-ID: <AANLkTimXsHS_C7X_K6BBrsTPsvUa4nxBS0efNnyAET6n@mail.gmail.com>
From: Daisuke Miyakawa <d.miyakawa@gmail.com>
To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
Content-Type: multipart/alternative; boundary="00032555517a081db60489ae6049"
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] Questions about vCard 4.0 (draft 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: Wed, 23 Jun 2010 08:32:17 -0000

2010年6月23日16:43 Javier Godoy <rjgodoy@fich.unl.edu.ar>:

> Besides, how are non-Japanese strings sorted among Japanese ones?
>

My understanding is "not defined formally".

- What icu library does and what my phone is doing looks different toward
ascii handling (ascii < kana in icu while kana < ascii in my phone).
- China and Japan uses same unicode codepoints with different
pronounciation.
- The comparator (collator, in icu term) would become huge if we define one
unified sort order toward every characters.

I'd like to know some authorities' answer.

Does it help to interoperability if romanized SORT-STRINGs are provided
> along/instead kana? Is it redundant? Is it ambiguous?
> SORT-STRING;にほんのそしき
> SORT-STRING;nippon no soshiki


> Does it help to interoperability if romanized SORT-STRINGs are provided
along/instead kana?
Hmm, sorry I don't think so.

e.g.

- かんべ (Kambe)
- べっしょ (Bessyo)
- よこはま (Yokohama)

The list above should be sorted as かんべ, べっしょ, よこはま from the view of how they
are phonetically expressed, while the order would become べっしょ (Bessyo), かんべ
(Kambe), よこはま (Yokohama) in alphabets. I suppose there's no relevance. Also,
Hepburn system may not be understood by some Japanese.

My understanding is that software/devices supporting vCard 4.0 should be
able to handle UTF-8, thus (at least) Unicode, so they should be able to
handle languages they want to support, but no software/device can understand
and correctly sort ALL languages in Unicode.
I don't think we need to prepare for cases other than kana, as for Japanese.
I'm not sure about the other languages.

> Is it redundant?
>From the view of one Japanese engineer, it looks redundant.
It may help for English speakers, but it should be simply "Japanese
organization" (Each organization would have English name).

> Is it ambiguous?
If we mix two types of SORT-STRINGs, it would become ambiguous. If we have
consistency which should be prefered, it should become clear.

What would happen if some vCard authors use one approach and others use the
> other?
>

I'm not 100% sure, but Japanese vCard authors implicitly understand that
SORT-STRING is same as X-PHONETIC- something used in some softwares and
"SOUND;X-IRMC-N", which has been used in vCard 2.1 to expressing phonetic
names or "Yomigana" (読み仮名, よみがな).

Japanese are so accustomed to phonetic sort that I could not understand
first why vCard 4.0 chose the name "SORT-STRING" instead of "PHONETIC-NAME"
(then, I learnt other countries often have other way of sorting =)

I'd like to know the other people's opinion.

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