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

[Daisuke Miyakawa <[e-mail]>]

Hi,

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

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).
When developing a vCard parser for some embedded devices, I found using
case-sensitive comparison was a little costly.
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.

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"?

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.

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?

Thanks,

-- 
Daisuke Miyakawa (宮川大輔)
[e-mail]