libvc 003 released with vCard 2.1 compatibility and question for the public

Announcement:

Hello,

Libvc has just been released with the ability to parse vCard 2.1
files.  The previous release had choked on vCard 2.1 parameters.
This new fix means that libvc can read in Microsoft vCard files.

The details about obtaining the new release can be found on the web
site:

http://rolo.sf.net/

                             ~~~

Question for the public:

The problem that was preventing libvc from reading in vCard 2.1
files before was the parameter parsing.

  TEL;PREF:+64-9-111-2222

would produce an error because libvc was expecting vCard 3.0 format:

  TEL;TYPE=PREF:+64-9-111-2222

in libvc 003, it will parse the vCard 2.1 format and turn it into
the vCard 3.0 format on output.

This leads to the side-effect of parsing multiple vCard 2.1 parameters
as separate name-value pairs.  For example, if libvc 003 comes
across:

  TEL;PREF;HOME:+64-9-111-2222

It will turn it into:

  TEL;TYPE=PREF;TYPE=HOME:+64-9-111-2222

instead of smushing all the parameter values with the same parameter
name like:

  TEL;TYPE=PREF,HOME:+64-9-111-2222

However, the next iteration of libvc can be made to smush parameters
with the same name into one parameter name with a parameter list,
but this would need some extra smarts coded into the library.

And this ultimately leads to my question for the public:  Is vCard
intended to be "human friendly for reading and writing cards" or
is it intended to be just "human readable".  For if it was intended
to be "human readable", then the specification would benefit from
the strict definition of how to list the parameter values of the
same parameter name: either in list format or in separate name-value
pairs (i.e. either like TYPE=PREF,HOME or like TYPE=PREF;TYPE=HOME).
A strict definition would make writing a parser much easier.  However,
if vCard was intended to be "human friendly for reading and writing",
perhaps the flexibility allows a human to choose the format that
is "easier to type" or "easier for the user to conceptualize".  What
are people's thoughts on the matter?

Cheers,
Andrew

-- 
 .
 .  Andrew Hsu
 .  email: [email protected]
 .  email: [email protected]
 .