vcard-implementations

2006-12-30T07:19:40Z

JakeHo:

<h1> vCard implementations </h1>

In the development of [[hcard|hCard]] and proxies like X2V, we have discovered various behaviors and quirks of vCard implementations. See also the [[vcard-errata]].

__TOC__

== Contributors==
* Tantek Çelik
* Brian Suda
* Steve Robillard

== Microsoft Outlook ==

version? platform?

=== single import ===
Outlook (either 2003 or 2007 beta version) appears to only support one vCard per VCF. There are some
third-party products that attempt to fix this [http://www.sperrysoftware.com/Outlook/Vcard-Converter.asp]

=== URL handling ===

URL without non-standard TYPE parameter seems to be ignored.

=== ADR handling ===

Appears to not support the post-office-box sub-property of ADR.

=== Escaped Commas ===

Outlook 2003 does not strip the backslashes from escaped commas (i.e., SR-PS\, Inc.) on import.

== Windows Address Book (WAB) ==
Version 6.00.X Win98 and Win XP Pro

=== vCard ENCODING ===
UTF-8 encoded vCard import prompts error as unrecognised vCard format. US ASCII 20127 encoded vCard successfully imported

=== ADR ===
If you do NOT specify TYPE=HOME,WORK,... then no address information is imported

=== TEL ===
If you do NOT specify TYPE=HOME,WORK,... then no address information is imported

=== PHOTO ===
Does not support Images

=== NOTE ===
According to the example in the RFC spec, all commas should be escaped, but WAB does not Un-escape them, leaving \, in the notes field.

== Microsoft Entourage ==

On Mac OS X. Entourage versions 10 and 11.

=== general comments ===
* Entourage versions 10 and 11 export vCard files as UTF-16, big endian, with Mac classic line endings (a single CR). The file does contain the proper UTF-16 BE BOM at the start, making identification of the file contents simpler.

* Importing vCards: Entourage 11 will look for a BOM when importing a vCard file. It respects UTF-16 BE, UTF-16 LE, and UTF-8 BOMs. With no BOM, Entourage 11 will attempt to import the vCard file as an 8-bit stream using the current system encoding (for example, Mac Roman).

* Entourage 12 (under development) is expected to have better vCard standard conformance, exporting vCard files as UTF-8 (with individual fields properly labelled with "charset=utf-8") and using Windows (CR+LF) line endings. When importing vCard files without a BOM, it wil assume UTF-8 encoding but will respect "charset=" tags if present.

== Apple Address Book ==

On Mac OS X 10.3 (Panther) and 10.4 (Tiger).

=== general comments ===
* There are issues with importing UTF-8 vCards. Apple Address Book appears to treat .vcf files in the file system NOT as UTF-8, but rather perhaps Mac Roman?
** Workaround: Explicitly specify the UTF-8 charset for vCard properties/fields that have non-ASCII-7 characters.
* Importing multiple vCards with the same fn/n results in duplicate entries in the Address Book. Basically, Address Book assumes that every vCard present in a single .vcf file represents a different person, even if the fn/n are the same etc.
** Workarounds:
*** Only markup one hCard per person, per page (has potential implications for [[hresume|hResume]]).
*** Have the converting application/service (e.g. X2V), do automerging of hCards with the same fn/n and generate a .vcf stream with one vCard per unique fn/n.
* Apple Address Book 4.0.4 (Mac OS X 10.4) exports vCard files as UTF-16 big endian with no BOM and Mac (CR) line endings, if the vCard record contains any non-ASCII data (for example Japanese characters). If the entire vCard record can be represented in ASCII, it is exported as an ASCII encoded file with Windows (CR+LF) line endings.

=== organization vs. individual ===

Summary: FN==ORG organization semantic supported for both import and export.

For organization contact info, sets the FN and ORG to the name of the organization and N to empty on exported vCards.

Also treats imported vCards like that as organization contact info cards visibly in the UI.

=== geo (lack of support) ===

The GEO field is ignored on imported vCards. It is only saved as part of the NOTE.

=== source (lack of support) ===

The SOURCE property is not supported on imported vCards. It is only saved as part of the NOTE.

=== logo (lack of support) ===

The LOGO property is totally ignored and not even saved as part of the NOTE.

=== photo (limitations) ===

The PHOTO property can only take inline encoded data. URL values for are ignored.

=== url (limitations) ===

Only ONE URL property value is supported (whereas multiple *should* be supported, just like EMAIL).

=== adr (behaviour) ===

If you do NOT specify which type of address information it is (like HOME or WORK) it is assumed to be a WORK address.

=== categories (behaviour) ===

Behavior confirmed on versions:
* default on OSX.3
* Version 4.03 (483) on OSX.

Summary: Exports native "Groups" as vCard CATEGORIES. Ignores CATEGORIES field when importing a vCard.

The UI lets you create distinct "Groups" which you can then drag contacts into. Contacts can be in more than one group. Upon exporting a contact that is in one or more Groups, those Groups are listed in the CATEGORIES field.

However, when importing vCards, the CATEGORIES field is totally ignored by Address Book.
# It does not add vCards with a category that matches a current Group to that Group.
# It does not create new Groups for vCards with new categories.
# It does not even add the CATEGORIES to the end of the notes field.
Though presumably it SHOULD do #1 and #2. Would also be nice if it simply let you edit the groups/categories for a contact simply as a list of tags for that contact.

== Evolution ==

On Linux.

=== geo (lack of support) ===

* ichigo, Frederic to fill in details

== Nokia series 60 address book ==

=== Line endings ===

The Contacts application on Nokia series 60 handsets will only open vCards with Windows (\r\n) line endings. Any other line ending styles will cause an error message.

This is actually reasonable behaviour because the vCard spec explicitly states \r\n should be used, but many applications will accept \n delimited vCards without complaint, and may microformat services produce \n delimited output.

vcard-suggestions

2006-12-18T07:49:37Z

JakeHo:

<h1> vCard suggestions </h1>

As a result of experience using [[hcard|hCard]] to markup people, organizations, and contact information in general on [[hcard-examples-in-wild|real world websites]], we have discovered a few aspects of RFC 2426 vCard that could be improved. Thus we are documenting suggestions for improving vCard here as we find them, organized by RFC 2426 section number for improvements to current properties, and a "new" section for new properties.

; Authors: Tantek Çelik, [[User:AndyMabbett|Andy Mabbett]]

== Suggestions for Existing Properties ==

Suggestions for improvement could include new features and other such more major changes to the specification, organized under headings that reflect RFC 2426 vCard section numbers and heading. For documentation of errors, corrections, errata for vCard, please see [[vcard-errata]].

=== 3.3.1 TEL Type Definition ===

* The "type" for "TEL" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. It may be good to consider adding a "textphone" value to the "type" for "TEL".
** +0 Tantek: I think a rethinking of the taxonomy of TEL types is merited, but I am uncertain whether it is worth growing the existing limited taxonomy or instead permitting user defined TEL types and thus allowing for natural evolution of a folksonomy of TEL types.
** +1 [[User:AndyMabbett|Andy Mabbett]]: There are a limited number of types. Note also the cell vs. mobile issue.

== Suggestions for New Properties ==

===Gender===
*There is no Card property for gender. A workaround: add the tag/category "male", "female", etc. See also [[hcard-faq#How_is_gender_represented|earlier discussion]].
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]:Tags are often not appropriate, as per the cited discussion.

===Deceased===
*There is no way to mark up a person as being deceased - either by a "deceased" flag or date-of-death. A workaround: add the tag/category "deceased". See also [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007324.html mailing list post on tagging for 'deceased']
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]: Tags are often not appropriate, as per the cited e-mail. DoD is more specific (and often used in real life biographies and obituaries e.g [http://en.wikipedia.org/wiki/Vincent_van_Gogh van Gogh on Wikipedia]).

== Suggestions for handling encodings ==
The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

==Note==
On 2006-11-24, Paul Hoffman of the [http://www.imc.org/ Internet Mail Consortium], responsible for the development and promotion the vCard standard, wrote in response to an e-mail from [[User:AndyMabbett|Andy Mabbett]] informing him of this web page:
<blockquote>
There has been almost no interest in revising the vCard standard. This is due to lack of momentum, not the lack of good suggestions.
</blockquote>

== See Also ==

* [[vcard-errata|vCard errata]]
* [[hcard|hCard]]
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.

Microformats Wiki - User contributions [en]

vcard-implementations

vcard-suggestions