Re: [VCARDDAV] wg concensus to publish? YES

[Filip Navara <[e-mail]>]

We have an implementation of the current vCard 4 draft in our
client-side application [1].

In fact, we use our own contact store that was designed based on vCard
3 and ACAP properties. Currently we allow import of vCard 3 with
several non-standard properties (as generated by Apple Address Book,
Microsoft Outlook and Windows Contacts) and vCard 4 (as defined by the
current draft). We can also generate vCard 3 (in several flavors that
represent the additional information as X- properties) and vCard 4
from the same contact store and in fact we use that for our CardDAV
implementation, where the appropriate version is determined by
querying the server and then used for upload.

There are several properties that we don't fully implement and several
features of vCard 4 that cause problems for us (multiple versions of
the same property in different languages), but overall I believe the
draft is an improvement over vCard 3 and should become a RFC as it is.
The features that cause problems for us are not unsolvable given the
structure of the contact store and the structure of the format itself.
For example we can still support only one language for displaying and
editing properties, but keep the others consistent as long as user
doesn't edit the property directly.

I have looked at PoCo and I believe that there exists direct PoCo ->
vCard 4 mapping for most properties and that the rest could easily be
specified in an additional RFC. Reverse mapping is also possible even
though it may not be lossless (for extendedAddress, pobox,
multi-language properties and possibly others).

I, personally, also wrote a vCard parsing library with support for
vCardXML mapping and I find the mapping to be good for machine
parsing. It may not be ideal for humans writing the XML, but is that
the point? I see it more as a way leverage existing libraries to parse
the vCard data than as a mapping that is trying to replace hCard (or
any other similar format for that matter).

Best regards,
Filip Navara

[1] www.emclient.com

On Tue, Sep 28, 2010 at 8:03 PM, Marc Blanchet
<[e-mail]> wrote:
> Hello,
>  I would like to get a wg concensus feel on this.
>
> Question: do you think draft-ietf-vcarddav-vcardrev and
> draft-ietf-vcarddav-vcardxml should be sent to IETF last call?
>
> Please reply to the mailing list by adding a simple YES or NO at the end of
> the subject line of this message.
>
> If there is no clear concensus, then I'm thinking of proposing a webex
> teleconf before Beijing to discuss and try to get concensus.
>
> Marc, co-chair.
>
> Le 10-09-27 09:53, Cyrus Daboo a écrit :
>>
>> Hi folks,
>> At this time my feeling is that we should go ahead with publication of
>> vcard 4.0 (and the XML spec) as-is. These documents have been in
>> development and review for several years now and everyone has had a
>> chance to comment (of course IETF last call is still to be done so an
>> opportunity to comment further naturally exists).
>>
>> vCard 4 is based on the well-founded technology of earlier vCard
>> specifications. It represents a comprehensive solution to contact
>> information, and not just personal contacts (e.g., see the recent draft
>> on calendar resource information that adds vCard properties specific to
>> the calendaring process). It now has easy extensibility built-in, via
>> IANA registrations, so new properties, for e.g., social networking, are
>> easy to define and add by consensus.
>>
>> I do believe that we should help other groups define simple mappings
>> between their formats and vCard. At this point I do not believe that is
>> a major effort - certainly not one that should hold up vCard 4 at this
>> time.
>>
>> So I would urge the chairs and ADs to move our working group documents
>> along the standards process at this time. We can continue to work with
>> OMA and W3C through liaisons and their participation in this open IETF
>> working group.
>>
>
>
> --
> =========
> IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
> Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
> DTN news service: http://reeves.viagenie.ca
> NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
>
> _______________________________________________
> VCARDDAV mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vcarddav
>