vCard suggestions

(Difference between revisions)

Jump to: navigation, search
m (Body: typo)
Current revision (21:22, 29 November 2010) (view source)
(vcard4)
 
(56 intermediate revisions not shown.)
Line 1: Line 1:
-
<h1> vCard suggestions </h1>
+
<entry-title> vCard suggestions </entry-title>
-
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 {{RFC2426}} vCard that could be improved.  Thus we are documenting suggestions for improving vCard here as we find them, organized by {{RFC2426}} section number for improvements to current properties, and a "new" section for new properties.
+
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 {{RFC2426}} vCard that could be improved.  Thus we are documenting suggestions for improving vCard here as we find them, organized by {{RFC2426}} properties, with a "new" section for new properties.
-
; Authors
+
== Suggestions for Existing Properties ==
-
:[[User:Tantek|Tantek Çelik]]
+
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]].
-
:[[User:AndyMabbett|Andy Mabbett]]
+
-
;Shortcut
+
=== BDAY ===
-
:This page may be referenced as '''<nowiki>http://microformats.org/wiki/vs</nowiki>'''
+
:'''See: {{RFC2426}} section 3.1.5
 +
The definition for BDAY says: <blockquote><p>Type value: The default is a single date value. It can also be reset to a single date-time value.</p></blockquote>
-
== Suggestions for Existing Properties ==
+
Requiring:
 +
* date value or
 +
* date-time value
 +
Is too restrictive.
-
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]].
+
For privacy/security reasons [[birthday-examples|people and sites often only publish part of a birthday]], e.g.
 +
* just the year, or
 +
* just the day and month
 +
and BDAY should be extended to allow those date variants.
 +
 
 +
There are ISO18601 syntaxes for both:
 +
* YYYY for just the year
 +
* --MMDD for just the month and day
 +
 
 +
There are examples of both on social network sites:
 +
* [[birthday-examples]]
 +
 
 +
It is reasonable to explicitly include them in an iteration of [[hCard]], and thus it is desirable to see them reflected in an iteration of vCard.
-
=== 3.3.1 TEL Type Definition ===
+
=== <span id="3.3.1_TEL_Type_Definition">TEL Type Definition</span> === <!--span preserves former ID-->
 +
:'''See: {{RFC2426}} section 3.3.1
* 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".
* 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".
Line 30: Line 46:
Note: it might be a good idea to look at the [http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04 proposed registry for "tel:" URI parameters]; especially the [http://tools.ietf.org/html/rfc3966 "phone-context" URI parameter], since it tries to solve a similar problem. (per [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html e-mail, 2008-01-08]).
Note: it might be a good idea to look at the [http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04 proposed registry for "tel:" URI parameters]; especially the [http://tools.ietf.org/html/rfc3966 "phone-context" URI parameter], since it tries to solve a similar problem. (per [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html e-mail, 2008-01-08]).
-
=== 3.3.2 EMAIL Type Definition ===
+
=== <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span preserves former ID-->
 +
 
 +
:'''See: {{RFC2426}} section 3.3.2'''
* The "type" for "EMAIL" lacks distinction for various types of email, e.g. '''work''' or '''home'''.
* The "type" for "EMAIL" lacks distinction for various types of email, e.g. '''work''' or '''home'''.
* The "type" for "EMAIL" lacks distinction for give an alternative to the e-mail like a contact form.
* The "type" for "EMAIL" lacks distinction for give an alternative to the e-mail like a contact form.
-
=== 3.3.3 Suggestion for Types Definition ===
+
===URL Type Definition===
-
Moved to [[hcard-issues#tel-type-lang]] (was not vCard specific)
+
:'''See: {{RFC2426}} section 3.6.8'''
-
== Suggestions for New Properties ==
+
* The "type" for "URL" lacks distinction for various types of URL, e.g. '''work''' or '''home'''.
-
===Gender===
+
* In particular there should be a "type" (or other indicator) for a URL used as an [[OpenID]].
-
*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]] and [[genealogy-brainstorming#Gender]].
+
-
** -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.
+
-
====Gender evidence====
+
== Suggestions for New Sub-properties ==
-
See [[gender-examples]].
+
sorted by property section number, then alphabetically by proposed sub-property.
 +
=== common to many properties ===
 +
====Language====
 +
Some (e.g. note) if not all properties should have a "language" attribute, similar to <code>lang</code> in HTML so that agents can determine how to render, and if applicable, pronounce, them.
-
* Social network sites (see [[profile-examples]]) typically publish the gender of the individual. Please add such sites with specific URLs to the site, their editing UI, and their list of gender values to [[gender-examples#sites_and_services]].
+
=== 3.1.2 N ===
 +
====Initials====
 +
"N" (See {{RFC2426}} section 3.1.2) sub-property; for people, whose given-name is not stated (e.g. "A. N. Other", whose given name might be, say, "Adrian" or "Nigel"); to allow values like:
-
* Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she),  etc. Please add such pages with specific URLs and quotes of the explicit information, and the implied genders to the [[gender-examples#examples|gender examples]] page.
+
<pre>
 +
  initials:    A. N.
 +
  family-name: Other
 +
</pre>
-
See also [[genealogy-brainstorming]].
+
instead of the more contrived:
-
===Deceased===
+
<pre>
 +
  given-name:  A. N.
 +
  family-name: Other
 +
</pre>
-
*See [[hcard-date-of-death]]
+
Also, for people whose given-name ''and'' initials are given:
-
====Date of Death evidence====
+
<pre>
 +
  given-name:      Theophilus
 +
  middle-initials: P.
 +
  family-name:    Wildebeest
 +
</pre>
-
*See [[hcard-date-of-death]]
+
and:
-
===Subject differentiator===
+
<pre>
-
*The use of "fn" and "fn org" differentiate between hCards for people and for other entities, but we perhaps need some further differentiator, between, say, organisations and venues (including buildings, governmental divisions, waypoints, etc.) at a level of granularity to be determined. [[User:AndyMabbett|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)
+
  initials:      J.
-
** This may no longer be necessary; as the [[hcard-brainstorming#Named_locations|use of "fn [child-of-adr]"]], for venues and other places, has been proposed and is being debated (see [http://microformats.org/discuss/mail/microformats-discuss/2007-December/011169.html email of 2007-12-30]. [[User:AndyMabbett|Andy Mabbett]] 14:04, 8 Jan 2008 (PST)
+
  given-name:     Paul
 +
  family-name:   Getty
 +
</pre>
-
===Elevation===
+
=== 3.2.1 ADR ===
-
Additional "geo" sub-property; aka "altitude" or "depth".
+
====Body====
-
*See [[geo-extension-elevation]]
+
"ADR" (See {{RFC2426}} section 3.2.1) sub-property; for people (e.g. in proposed moon base, Mars expedition) or places (e.g. lunar crater, Martian mountain) off-planet.
 +
* See also [[geo-extension-nonWGS84]]
-
===Vessel===
+
====Continent====
-
Additional "adr" sub-property; for people on, say, ships, oil rigs, and even space vehicles (e.g. the ISS)
+
"ADR" (See {{RFC2426}} section 3.2.1) sub-property; self-explanatory.
-
===Body===
+
====Vessel====
-
Additional "adr" sub-property; for people (e.g. in proposed moon base, Mars expedition) or places (e.g. lunar crater, Martian mountain) off-planet.
+
"ADR" (See {{RFC2426}} section 3.2.1) sub-property; for people on, say, ships, live-aboard boats, oil rigs, and even space vehicles (e.g. the ISS)
-
* See also [[geo-extension-nonWGS84]]
+
-
===Schema===
+
=== 3.4.2 GEO ===
-
Additional "geo" sub-property; for coordinates using non-WGS84 schema (terrestrial and for other bodies)
+
====Elevation====
 +
"GEO" (See {{RFC2426}} section 3.4.2) sub-property; aka "altitude" or "depth".
 +
*See [[geo-extension-elevation]]
 +
 
 +
====Schema====
 +
"GEO" (See {{RFC2426}} section 3.4.2) sub-property; for coordinates using non-WGS84 schema (terrestrial and for other bodies)
* See also [[geo-extension-nonWGS84]]
* See also [[geo-extension-nonWGS84]]
 +
 +
== Suggestions for New Properties ==
 +
Sorted alphabetically.
 +
 +
===Alternative dates===
 +
For historic figures, where no birth and/ or death dates are known a "'''flourished'''" date, or "'''flourished from'''"+"'''flourished to'''" pair, would be useful.
 +
* Real world examples with URLs must be provided for this suggestion to have any merit.
 +
 +
In genealogy, some people have no recorded birth date, but their "'''baptised'''" date is known.
 +
* Real world examples with URLs must be provided for this suggestion to have any merit.
 +
 +
===<span id="Date of Death evidence">Deceased</span>=== <!--span preserves former ID-->
 +
aka "date of death"
 +
*See [[hcard-date-of-death]]
 +
 +
===Gender===
 +
*There is no vCard property for gender.
 +
**A workaround in hCard: add the tag/category "male", "female", etc. See also [[hcard-faq#How_is_gender_represented|earlier discussion]] and [[genealogy-brainstorming#Gender]].
 +
*** -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.
 +
 +
<span id="Gender evidence">See [[gender-examples]] and [[genealogy-brainstorming]]; note also [http://www.google.com/search?q=vCard.Gender Google search for "vCard.Gender"] .</span>  <!--span preserves former ID-->
===Global Location Number===
===Global Location Number===
Global Location Number (GLN) - generally used in electronic commerce transactions [http://en.wikipedia.org/wiki/Global_Location_Number]. [[User:AndyMabbett|Andy Mabbett]] 06:43, 31 Aug 2007 (PDT)
Global Location Number (GLN) - generally used in electronic commerce transactions [http://en.wikipedia.org/wiki/Global_Location_Number]. [[User:AndyMabbett|Andy Mabbett]] 06:43, 31 Aug 2007 (PDT)
-
===Initials===
+
===Languages spoken===
-
For people, whose given-name is not stated (e.g. "A. N. Other"); to allow mark-up like:
+
* ISO codes ?
 +
* Also ability to indicate preferred contact language(s)
-
<pre><nowiki>
+
:Per [[User:FajRo|FajRo]]
-
  <span class="vcard">
+
-
    <span class="fn n">
+
-
      <span class="initials">A. N.</span>
+
-
      <span class="family-name">Other</span>
+
-
    </span>
+
-
  </span>
+
-
</nowiki></pre>
+
-
===Alternative dates===
+
===Preferred method of contact===
 +
Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.
-
For historic figures, where no birth and/ or death dates are known a "'''flourished'''" date, or "'''flourished from'''"+"'''flourished to'''" pair, would be useful.
+
:Per [[User:FajRo|FajRo]]
-
In genealogy, some people have no recorded birth date, but their "'''baptised'''" date is known.
+
===Subject differentiator===
 +
*A "type" for the vCard itself: person, organisation or place (or perhaps more granular; or user-defined)
 +
**In the [[hcard|hCard microformat]], the use of "fn" and "fn org" differentiate between hCards for people and for other entities, but we perhaps need some further differentiator, between, say, organisations and venues (including buildings, governmental divisions, waypoints, etc.) at a level of granularity to be determined. [[User:AndyMabbett|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)
 +
*** This may no longer be necessary for hCard; as the [[hcard-brainstorming#Named_locations|use of "fn [child-of-adr]"]], for venues and other places, has been proposed and is being debated (see [http://microformats.org/discuss/mail/microformats-discuss/2007-December/011169.html email of 2007-12-30]. [[User:AndyMabbett|Andy Mabbett]] 14:04, 8 Jan 2008 (PST)
 +
 
 +
=== UN LOCCODE ===
 +
*[http://www.unece.org/cefact/locode/ UN/LOCODE], the United Nations Code for Trade and Transport Locations, is a geographic coding scheme developed and maintained by United Nations Economic Commission for Europe (UNECE), a unit of the United Nations. UN/LOCODE assigns codes to locations used in trade and transport with functions such as seaports, rail and road terminals, airports, post offices and border crossing points. 
 +
**[http://en.wikipedia.org/wiki/UN/LOCODE UN/LOCODE on Wikipedia]
 +
 
 +
===DCreated===
 +
The date and time that this vcard was created. If possible this should be mandatory even if left blank to encourage usage. This will allow tools to remove older vcard entries with old contact details for the same person.
 +
 
 +
=== X-JABBER ===
-
===Continent===
+
From http://en.wikipedia.org/wiki/VCard#vCard_extensions
-
<code>adr</code> should have an optional <code>continent</code> child-property.
+
== Suggestions for handling encodings ==
== Suggestions for handling encodings ==
Line 110: Line 175:
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.
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.
-
==Suggestions made elsewhere==
+
== Rejected suggestions ==
 +
===Last-Modified===
 +
The date and time that this vCard was last modified. Allows synchronization tools to detect only those vCard in a collection which have changed since the last synchronization or backup.
 +
*  '''vCard already has a <code>REV</code> ("revised") property. Use it.'''
-
===Instant Messaging===
+
===Original source of information===
 +
A URL to a website/contact page with hCard (because a lot of business directories contains outdated contact information) - per [[User:Emerikusz|Emerikusz]]
 +
* '''vCard already has a <code>URL</code> property. In addition, the SOURCE property in vCard can be used for this specific purpose (where did the vCard come from), and in fact, [[X2V]] already supports this in its vCard output!'''
-
* See [http://www.rfc-editor.org/rfc/rfc4770.txt RFC4770: vCard Extensions for Instant Messaging (IM)]
+
==Suggestions made elsewhere==
-
 
+
See [[contact-formats]] for other contact formats.
-
===WebDAV===
+
-
 
+
-
[http://www.ietf.org/internet-drafts/draft-daboo-carddav-02.txt vCard Extensions to WebDAV (CardDAV)]
+
-
<blockquote>defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. This document defines the "addressbook-access" feature of CardDAV.</blockquote>
+
-
 
+
-
===XEP-0154: User Profile===
+
-
[http://www.xmpp.org/extensions/xep-0154.html XEP-0154: User Profile] specifies how to represent and manage profile data about IM users and other [http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol Extensible Messaging and Presence Protocol] (XMPP) entities using the XMPP Data Forms extension. It has a far greater number of properties than vCard (possibly more than vCard will ever need), and reinvents and re-names some of the latter's properties, but may have some attributes worth considering for vCard.
+
The following should be incorporated into the [[contact-formats]] page.
 +
* [http://openid.net/specs/openid-attribute-exchange-1_0.html OpenID page on Attribute Exchange] and [[attribute-exchange]].
 +
** Warning: many Attribute Exchange properties unnecessarily reinvent vCard properties.
 +
* [http://www.rfc-editor.org/rfc/rfc4770.txt RFC4770: vCard Extensions for Instant Messaging (IM)]
 +
* [http://merlot.tools.ietf.org/html/draft-daboo-carddav-03 Extensions to WebDAV (CardDAV)]
 +
** uses vCard but also adds the "addressbook-access" feature of CardDAV.
 +
* [http://www.xmpp.org/extensions/xep-0154.html XEP-0154: User Profile] specifies how to represent and manage profile data about IM users and other [http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol Extensible Messaging and Presence Protocol] (XMPP) entities using the XMPP Data Forms extension. It has a far greater number of properties than vCard (possibly more than vCard will ever need), and reinvents and re-names some of the latter's properties, but may have some attributes worth considering for vCard.
 +
*[http://xmlns.com/foaf/spec/ FOAF Vocabulary Specification 0.91] - Namespace Document 2 November 2007 - OpenID Edition
==Note==
==Note==
Line 129: Line 200:
<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>
<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>
-
However, see [[events/2007-09-18-calconnect-vcard-workshop]] for an event with vCard modification on the agenda.
+
However, see [[events/2007-09-18-calconnect-vcard-workshop]] for an event with vCard modification on the agenda. There may be some IETF work on vCard in the future.
-
== See Also ==
+
== external resources ==
 +
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.
 +
== See Also ==
* [[vcard-errata|vCard errata]]
* [[vcard-errata|vCard errata]]
* [[vcard-implementations]]
* [[vcard-implementations]]
 +
* [[vCard4]]
* [[hcard|hCard]]
* [[hcard|hCard]]
* [[hcard-brainstorming#Post_vCard_additions]]
* [[hcard-brainstorming#Post_vCard_additions]]
-
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.
 
* [[events/2007-09-18-calconnect-vcard-workshop]]
* [[events/2007-09-18-calconnect-vcard-workshop]]
 +
* <span id="3.3.3_Suggestion_for_Types_Definition"3>A [[hcard-issues#tel-type-lang|comment on the language of TEL types]], moved because it was not vCard specific</span><!--span preserves former ID-->

Current revision


As a result of experience using hCard to markup people, organizations, and contact information in general on real world websites, we have discovered a few aspects of RFC2426 vCard that could be improved. Thus we are documenting suggestions for improving vCard here as we find them, organized by RFC2426 properties, with a "new" section for new properties.

Contents

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.

BDAY

See: RFC2426 section 3.1.5
The definition for BDAY says:

Type value: The default is a single date value. It can also be reset to a single date-time value.

Requiring:

Is too restrictive.

For privacy/security reasons people and sites often only publish part of a birthday, e.g.

and BDAY should be extended to allow those date variants.

There are ISO18601 syntaxes for both:

There are examples of both on social network sites:

It is reasonable to explicitly include them in an iteration of hCard, and thus it is desirable to see them reflected in an iteration of vCard.

TEL Type Definition

See: RFC2426 section 3.3.1

Note: it might be a good idea to look at the proposed registry for "tel:" URI parameters; especially the "phone-context" URI parameter, since it tries to solve a similar problem. (per e-mail, 2008-01-08).

EMAIL Type Definition

See: RFC2426 section 3.3.2

URL Type Definition

See: RFC2426 section 3.6.8

Suggestions for New Sub-properties

sorted by property section number, then alphabetically by proposed sub-property.

common to many properties

Language

Some (e.g. note) if not all properties should have a "language" attribute, similar to lang in HTML so that agents can determine how to render, and if applicable, pronounce, them.

3.1.2 N

Initials

"N" (See RFC2426 section 3.1.2) sub-property; for people, whose given-name is not stated (e.g. "A. N. Other", whose given name might be, say, "Adrian" or "Nigel"); to allow values like:

   initials:    A. N.
   family-name: Other

instead of the more contrived:

   given-name:  A. N.
   family-name: Other

Also, for people whose given-name and initials are given:

   given-name:      Theophilus
   middle-initials: P.
   family-name:     Wildebeest

and:

   initials:       J.
   given-name:     Paul
   family-name:    Getty

3.2.1 ADR

Body

"ADR" (See RFC2426 section 3.2.1) sub-property; for people (e.g. in proposed moon base, Mars expedition) or places (e.g. lunar crater, Martian mountain) off-planet.

Continent

"ADR" (See RFC2426 section 3.2.1) sub-property; self-explanatory.

Vessel

"ADR" (See RFC2426 section 3.2.1) sub-property; for people on, say, ships, live-aboard boats, oil rigs, and even space vehicles (e.g. the ISS)

3.4.2 GEO

Elevation

"GEO" (See RFC2426 section 3.4.2) sub-property; aka "altitude" or "depth".

Schema

"GEO" (See RFC2426 section 3.4.2) sub-property; for coordinates using non-WGS84 schema (terrestrial and for other bodies)

Suggestions for New Properties

Sorted alphabetically.

Alternative dates

For historic figures, where no birth and/ or death dates are known a "flourished" date, or "flourished from"+"flourished to" pair, would be useful.

In genealogy, some people have no recorded birth date, but their "baptised" date is known.

Deceased

aka "date of death"

Gender

See gender-examples and genealogy-brainstorming; note also Google search for "vCard.Gender" .

Global Location Number

Global Location Number (GLN) - generally used in electronic commerce transactions [1]. Andy Mabbett 06:43, 31 Aug 2007 (PDT)

Languages spoken

Per FajRo

Preferred method of contact

Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.

Per FajRo

Subject differentiator

UN LOCCODE

DCreated

The date and time that this vcard was created. If possible this should be mandatory even if left blank to encourage usage. This will allow tools to remove older vcard entries with old contact details for the same person.

X-JABBER

From http://en.wikipedia.org/wiki/VCard#vCard_extensions

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.

Rejected suggestions

Last-Modified

The date and time that this vCard was last modified. Allows synchronization tools to detect only those vCard in a collection which have changed since the last synchronization or backup.

Original source of information

A URL to a website/contact page with hCard (because a lot of business directories contains outdated contact information) - per Emerikusz

Suggestions made elsewhere

See contact-formats for other contact formats.

The following should be incorporated into the contact-formats page.

Note

On 2006-11-24, Paul Hoffman of the Internet Mail Consortium, responsible for the development and promotion the vCard standard, wrote in response to an e-mail from Andy Mabbett informing him of this web page:

There has been almost no interest in revising the vCard standard. This is due to lack of momentum, not the lack of good suggestions.

However, see events/2007-09-18-calconnect-vcard-workshop for an event with vCard modification on the agenda. There may be some IETF work on vCard in the future.

external resources

See Also

vCard suggestions was last modified: Monday, November 29th, 2010

Views