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

[Simon Perreault <[e-mail]>]

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

> 2) VERSION
> 
>> 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.
> BEGIN:VCARD
> FN:Daisuke;Miyakawa
> AGENT:BEGIN:VCARD\nFN:Cool!\nEND:VCARD
> 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
revision.

> 3) SORT-STRING
> 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...

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org