vcard-suggestions

(Difference between revisions)

Jump to: navigation, search
(3.3.1 TEL Type Definition - Existing PIM software practices)
(Suggestions for SMS TEL TYPE)
Line 18: Line 18:
* The "type" for "TEL" lacks a "freephone" option. It may be good to consider adding a "freephone" value to the "type" for "TEL". Usually freephone numbers are not accessible from outside the country so it could help parsers with something?
* The "type" for "TEL" lacks a "freephone" option. It may be good to consider adding a "freephone" value to the "type" for "TEL". Usually freephone numbers are not accessible from outside the country so it could help parsers with something?
* The "type" for "TEL" lacks an "SMS short code" option. (Raised in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html e-mail, 2008-01-08 by Michael Smethurst])
* The "type" for "TEL" lacks an "SMS short code" option. (Raised in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html e-mail, 2008-01-08 by Michael Smethurst])
 +
** Seems like 'sms' TEL TYPE is a viable implementation option --[[User:Guillaume Lebleu|Guillaume]] 12:17, 8 Jan 2008 (PST).
* FYI. Some existing Personal Information Manager software practices:
* FYI. Some existing Personal Information Manager software practices:
** Mac OS X address book allows custom labels for TEL but not custom TEL TYPE per se, although for the user a custom TEL label just looks like a TEL TYPE  
** Mac OS X address book allows custom labels for TEL but not custom TEL TYPE per se, although for the user a custom TEL label just looks like a TEL TYPE  
Line 46: Line 47:
Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
-
 
== Suggestions for New Properties ==
== Suggestions for New Properties ==

Revision as of 20:17, 8 January 2008

Contents

vCard suggestions

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 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
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



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).

3.3.2 EMAIL Type Definition

3.3.3 Suggestion for Types Definition

We can't have a generic type name cause we have to localize in french. so, for us, hCard work phone number is : <div class="tel"> <span class="type">Travail</span> : <span class="value">0321596224</span> </div>

How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better : Travail : <span class="telwork">0321596224</span>

Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !

Suggestions for New Properties

Gender

Gender evidence

See gender-examples.

See also genealogy-brainstorming.

Deceased

Date of Death evidence

Instant Messaging

Subject differentiator

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. Andy Mabbett 14:30, 11 Jul 2007 (PDT)

Elevation

Global Location Number

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

Initials

For people, whose given-name is not stated (e.g. "A. N. Other"); to allow mark-up like:

   <span class="vcard">
     <span class="fn n">
       <span class="initials">A. N.</span>
       <span class="family-name">Other</span>
     </span>
   </span>

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.

Continent

adr should have an optional continent child-property.

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.

Suggestions made elsewhere

WebDAV

vCard Extensions to WebDAV (CardDAV)

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.

XEP-0154: User Profile

XEP-0154: User Profile specifies how to represent and manage profile data about IM users and other Extensible Messaging and Presence Protocol (XMPP) entities using the XMPP Data Forms extension. It has a far greater number of properties than vCard, but reinvents and re-names some of the latter's properties.

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.

See Also

vcard-suggestions was last modified: Wednesday, December 31st, 1969

Views