Oren’s Weblog

Cyrus is running through related standards.

Liberty Alliance has an ID_SIS Contact Book Service. Uses XML abstraction of vCard and XPATH-based queries. Web services infrastructure used for the service itself. Liberty also has a people profile.

OASIS: CIQ (Customer Information Quality) Defines XML based formats for names, addresses, and relationships. Doesn’t have any direct correspondence with vCard. Has a much richer format for mailing address information and relationships between different contacts.

LDAP – well established directory service application protocol. Used for much more than just contact information. Uses a “tree” model for relationships/boundaries. White Pages schema used for representing contacts. RFC2798 is a common one. Compared CardDAV to LDAP at the BOF in Chicago. COnclusion was that mapping vCard into LDAP is hard and you can’t get a good mapping – so it’s worthwhile to have a vCard-serving service.

hCard – 1-to01 mapping between vCard and semantic XHTML. Suitable for embedding in XHTML, Atom, RSS, and XML. One of several microformats.

CardDAV – WebDAV-based address book access protocol. Uses vCard as the data exchange format. Similar to CalDAV. Uses proven web technology to provide a low barrier to entry.

Jon Miner notes in the back channel that there’s a RDF vcard format at:
http://www.w3.org/TR/vcard-rdf

Technorati Tags: calconnect, vcard

Mark Paterson from Oracle is talking about the relationship between OMA DS (the standard formerly known as SyncML) and vCard. We asked the OMA Data Sync group about what the issues are with vCard in that world.

it’s a method for synchronizing contact and calendar information between a handheld device and a computer. You can use it for syncing any data.

OMA doesn’t want to be in the business of defining information payloads – wants to use existing information. For instance, supports vCal and iCal. Supports vCard 2.1 or 3.0. So any problem in vCard affects synchronization.

There are too many Type combination possibilities in vCard. Would be nice if there were a more stringent definition of order of types and possible combinations.

There’s no good way of knowing what a device can store or provide.

There’s no support for enumerating contact methods.

Phone number formats aren’t probably defined, nor are addresses.

Formats for numbers, addresses, date/time stamps aren’t specified enough.

Obsolete methods of communication are supported while new methods are not.

OMA DS would like a Vcard standard that solved these issues (like calsify for vCard) and test suites that help with conformance and interoperability. So if CalConnect could sponsor some vCard exchange events that would probably help.

Despite its problems, vCard has been successful and is supported in lots of places.

Chris is talking about the vCard BOF at the recent IETF. To have a successful working group in the IETF there needs to be one or two chairs. Allowed up to two BOFs to form work. There was quite a bit of interest, but a little short of people with the energy to keep the work happening. He’s looking for the second co-chair. Then charter can be completed and a working group can be formed pretty quickly. Next IETF is first week of December in Vancouver.

Nice to see Google Presentations join the Google Docs family! It doesn’t have all the bells and whistles that Powerpoint does – bug or feature?

Dave Thewlis, in his intro to the day, notes that vCard is one of those things that everyone complains about, but nobody has stepped up to try to fix. The goal of the day is to try to understand what the problems are and what some likely approaches might be to solve them.

Cyrus is giving the Overview of where we are today with vCard.

vCard history – was developed by Versit Consortium in 1995, based on X.500, brought into text format as IETF standard.

Transferred rights to Internet Mail Consortium in 1996. Vcard 2.1.

Later IETF standardized vCard 3.0 in 1998. A few IETF extensions have been done since then to add specific fields like Jabber ID etc. But hasn’t been any formal enhancement work since then.

vCard is in heave use today as a contact interchange formate – most desktop email programs support it, mobile devices, etc. There are spinoffs like hCard microformat standards, Jabber XML variant. The hCard people did a detailed analysis of the vCard format and what the problems are with it.

Issues – Interoperability – we need all apps and devices to exchange data without loss or corruption in either direction. That’s where users experience problems.

We’re seeing new technologies that need to use contact info in new ways – like social networking. We need extensibility in the format that allows adding new parameters while maintaining interoperability. Lack of formal extensibility (e.g. a registry for new properties) has led to loss of intereop.

Why are we here? Various groups interested in improving the state of vCard interoperability. The IETF are also assessing interest. Goal is to determine what the interest is and what steps we should take to move the work forward.

Experiment – let’s all exchange vCards right now…. We ought to be able to easily do this. Instead we all still have paper business cards – our goal should be to put the business card scanner people out of business.

Questionnaire comments – about 20 received.

Multiple vCards in one file is not always supported

Better UTF-8 support. Relates to internationalization issues.

Easier way to drag and drop vCards between apps

Incompatible TEL attributes on mobiles. Or work, home, preferred, etc. Attributes don’t make sense together.

What extensions are supported? distinguished name. lists of x- properties, many IM related. Do we want to go out and survey what x- properties are out there and figure out which should be standardized?

What are the alternative contact formats? XML formats with SDKs. CSV variants (Outlook, Tbird, et al), LDIF, Updateable vCard (goes back to an address book service – keeping vcards up to date over time), LDAP schema, RDF/XML.

Things to consider: Consider issues arising from use of hCard microformat; Sync IOP issues caused by current limitations; Lack of groups; Linking vCard info to other directories and repositories; get vCard IM and Calendar extensions deployed.

Other issues: Get everybody on same version (mobile systems still tend to use vCard 2.1); Use for things other than people (organizations, venues, etc).

Technorati Tags: calconect-fall-2007, vcard

Dave Thewlis, in his intro to the day, notes that vCard is one of those things that everyone complains about, but nobody has stepped up to try to fix. The goal of the day is to try to understand what the problems are and what some likely approaches might be to solve them.

Cyrus is giving the Overview of where we are today with vCard.

vCard history – was developed by Versit Consortium in 1995, based on X.500, brought into text format as IETF standard.

Transferred rights to Internet Mail Consortium in 1996. Vcard 2.1.

Later IETF standardized vCard 3.0 in 1998. A few IETF extensions have been done since then to add specific fields like Jabber ID etc. But hasn’t been any formal enhancement work since then.

vCard is in heave use today as a contact interchange formate – most desktop email programs support it, mobile devices, etc. There are spinoffs like hCard microformat standards, Jabber XML variant. The hCard people did a detailed analysis of the vCard format and what the problems are with it.

Issues – Interoperability – we need all apps and devices to exchange data without loss or corruption in either direction. That’s where users experience problems.

We’re seeing new technologies that need to use contact info in new ways – like social networking. We need extensibility in the format that allows adding new parameters while maintaining interoperability. Lack of formal extensibility (e.g. a registry for new properties) has led to loss of intereop.

Why are we here? Various groups interested in improving the state of vCard interoperability. The IETF are also assessing interest. Goal is to determine what the interest is and what steps we should take to move the work forward.

Experiment – let’s all exchange vCards right now…. We ought to be able to easily do this. Instead we all still have paper business cards – our goal should be to put the business card scanner people out of business.

Questionnaire comments – about 20 received.

Multiple vCards in one file is not always supported

Better UTF-8 support. Relates to internationalization issues.

Easier way to drag and drop vCards between apps

Incompatible TEL attributes on mobiles. Or work, home, preferred, etc. Attributes don’t make sense together.

What extensions are supported? distinguished name. lists of x- properties, many IM related. Do we want to go out and survey what x- properties are out there and figure out which should be standardized?

What are the alternative contact formats? XML formats with SDKs. CSV variants (Outlook, Tbird, et al), LDIF, Updateable vCard (goes back to an address book service – keeping vcards up to date over time), LDAP schema, RDF/XML.

Things to consider: Consider issues arising from use of hCard microformat; Sync IOP issues caused by current limitations; Lack of groups; Linking vCard info to other directories and repositories; get vCard IM and Calendar extensions deployed.

Other issues: Get everybody on same version (mobile systems still tend to use vCard 2.1); Use for things other than people (organizations, venues, etc).

Technorati Tags: calconect-fall-2007, vcard