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

"Javier Godoy" <> Wed, 23 June 2010 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14E0C3A683F for <>; Wed, 23 Jun 2010 12:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O2eZyPwyga4C for <>; Wed, 23 Jun 2010 12:03:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 52B7A3A6885 for <>; Wed, 23 Jun 2010 12:03:39 -0700 (PDT)
Received: from Javier2 ([]) (authenticated user by (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits)); Wed, 23 Jun 2010 16:03:51 -0300
Message-ID: <5B4FBB6514E844ED85BB57E5F030E33D@Javier2>
From: Javier Godoy <>
To: Simon Perreault <>
References: <><> <> <AE51FE4DF2604D0A9D2697A8438376E2@Javier2> <>
Date: Wed, 23 Jun 2010 14:52:50 -0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-2022-JP"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
Subject: Re: [VCARDDAV] Questions about vCard 4.0 (draft 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: Wed, 23 Jun 2010 19:03:42 -0000

On 2010-06-23 9:32 AM, Simon Perreault wrote:

> On 2010-06-23 03:43, Javier Godoy wrote:
>> Since ORG is (0,n) now it makes sense to define SORT-STRING as (0,n),
> I disagree. FN is (1,n). We're still in the same situation.

I though that FN was (1,n) because the name of the same person may be written 
in different languages (or scripts), and not because one person could have 
different names in the same language. On the other side, ORG is (0,n) not only 
because the name of the same organization may be given in different languages, 
but also because the same individual may be related to several organizations.

> Suppose you have multiple FN properties. Which one are you going to use
> for sorting? The first one? It wouldn't make sense to pick e.g. the
> second one because there's nothing guaranteeing that all second FN
> properties in all vCards have anything in common. Also, the order of
> properties can be changed by any intermediate system since order doesn't
> matter.

I would use the preferred one, if the PREF parameter is provided. In case of 
tie, or if no SORT-STRING is provided,  would choose any of them (i.e. 
But, why did we allow FN to be (0,n)?

> Since we're in the same situation with ORG, I don't see why we wouldn't
> solve it exactly in the same way with a separate property, e.g.

If one wouldn't need to store the kana for every ORG, that would be fine. As 
explained below, a conservative guess would be that it might not be the case.

org1.ORG;LANGUAGE=ja;PREF=80:日本の組織  # "Japanese organization"
org1.ORG;LANGUAGE=en;PREF=80:Japanese organization
org2.ORG;LANGUAGE=ja;PREF=90: もう一つの日本の組織
org2.ORG;LANGUAGE=en;PREF=90:Another Japanese organization
org2.SORT-STRING:もう ひとつ の にっぽん の そしき

Would collate by にほんのそしき (Kana for "Japanese organization"). If it is 
changed to:

org2.ORG;LANGUAGE=ja;PREF=70: もう一つの日本の組織
org2.ORG;LANGUAGE=en;PREF=70:Another Japanese organization

It would collate by もう ひとつ の にっぽん  の そしき (kana for "Another 
Japanese organization")

> Now, one thing that I like about your example is the use of the LANGUAGE
> tag. We need to at least add an example where the LANGUAGE tag is also
> applied to the SORT-STRING property.

LANGUAGE is not a parameter for SORT-STRING. Adding a LANGUAGE would allow 
different SORT-STRINGs for different languages while preserving (0,1) 

> Example:
> ORG;LANGUAGE=ja:日本の組織  # "Japanese organization"
> ORG;LANGUAGE=en:Japanese organization
> (I'll figure out an equivalent example in French since we can't have
> Japanese characters in RFCs...)

I don't think there is an equivalent example in US-ASCII.

As I understand this issue, ORG and FN use unsortable ideograms (kanji), while 
SORT-STRING uses a syllabic script (kana) which is appropriate for collation. 
Personal names are represented in kanji in normal, everyday writing, while 
their collation sequence in a directory (or a catalog) follows kana 
representations [1], and both are required when you fill a form (though some 
algorithms exist, maybe converting properly from kanji to kana is not a 
straighforward task, I don't know)

I think we should provide a layman's description of kanji/kana, so that we can 
render the example as:

ORG;LANGUAGE=ja:<kanji for Japanese organization>
ORG;LANGUAGE=en:Japanese organization
ORG-SORT-STRING;LANGUAGE=ja:<kana for Japanese organization>


Best Regards