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

Simon Perreault <> Tue, 22 June 2010 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3037F3A67AC for <>; Tue, 22 Jun 2010 06:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v+o9SfQRxWSe for <>; Tue, 22 Jun 2010 06:04:58 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by (Postfix) with ESMTP id 7F63B3A67CC for <>; Tue, 22 Jun 2010 06:04:58 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:c000:403a:8033:d402:ebf7]) by (Postfix) with ESMTPSA id A42A020DC3 for <>; Tue, 22 Jun 2010 09:05:05 -0400 (EDT)
Message-ID: <>
Date: Tue, 22 Jun 2010 09:05:05 -0400
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
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: Tue, 22 Jun 2010 13:05:00 -0000

On 2010-06-21 22:27, Daisuke Miyakawa wrote:
> (Please tell me when I'm saying something inappropriate in this ML. I'm
> new to the community)
> I'm a Japanese interested in vCard 4.0, and have 3 questions for
> implementing parser/composer.

Good! This is the right place to ask such questions.

> 1) case sensitiveness
>>   Property names and parameter names are case insensitive (e.g., the
>>   property name "fn" is the same as "FN" and "Fn").
> 1-a) Rationale
> I'd like to know why this draft changed the behavior around
> case-sensitiveness of property name.
> My understanding is that vCard 2.1 and 3.0 implicitly preferred upper
> cases (though there seems no mention).

See RFC 2425 section 5.8.2:

   Type names and parameter names are case insensitive (e.g., the type
   name "fn" is the same as "FN" and "Fn").

The preference is irrelevant. Your parser needs to be able to understand
both forms.

> When developing a vCard parser for some embedded devices, I found using
> case-sensitive comparison was a little costly.

You must have been playing with some REALLY REALLY SMALL embedded
devices! ;) I've never encountered or heard of a platform where
case-insensitive comparison would make any measurable difference.

> At least, I think it is worth mentioning that upper cases would be
> better, as a lot of old vCard files (both vCard 2.1 and vCard 3.0) seem
> to use that form.

I'm sorry, I think this would be wrong. The right thing to say would be
that parsers need to understand both upper and lower case, but this is
already part of the text.

> 1-b) How about BEGIN and END?
> There's no mention about how BEGIN/END should be emitted. Is it ok to
> use "begin:vcard"?

No. Unless specified otherwise, property values are case sensitive.
Therefore "begin:VCARD", "BEGIN:VCARD", and "Begin:VCARD" would be
valid, but "begin:vcard" would not. The ABNF in section 6.1.1 makes this

>> Special notes: The property MUST be present in the vCard object.
>>                The value MUST be "4.0" if the vCard corresponds to this
>>                specification.
> When parsing vCard files, I found it should be better to have "VERSION"
> line "just after" "BEGIN:VCARD" line, as parsers cannot know which
> version should be used.
> My understanding is vCard 2.1 even allows vCard without "VERSION:2.1"
> line. When parsing some complicated text with backslash and
> Quoted-Printable (only allowed in vCard 2.1),
> the parser cannot determine how a target property is treated (error or not).
> e.g.
> FN:Daisuke;Miyakawa
> VERSION:3.0  <-- The parser found that this vCard is NOT in vCard 4.0
> but in vCard 3.0, so AGENT is valid.
> END:VCARD  <-- The parser found there's no N, which is valid in vCard
> 4.0 but not in vCard 3.0
> (error?)
> I think it would be better to explicitly mention that "VERSION:4.0 MUST
> be just after BEGIN:VCARD line" for better comfortability of actual
> implementation.

I tend to agree. Unless people disagree, this will be part of the next

> Some Japanese people said that we sometimes use organization (ORG) for
> sorting, but we need some sort string for it.
> However, the current draft says "SORT-STRING" is just for FN or N, not
> for ORG.
> Is there any discussion about that kind of topic?

You just started the discussion! ;)

I think this is valid and important. However, I would really like to see
a real-life example to ensure we stay grounded. Could you please write
one? I suppose it will be hard to translate to English, but please try...

NAT64/DNS64 open-source -->
STUN/TURN server        -->
vCard 4.0               -->