vcard-suggestions: Difference between revisions
(rejected "Original source of information" - vCard already has URL and SOURCE which is sufficient for this.) |
|||
Line 125: | Line 125: | ||
:Per [[User:FajRo|FajRo]] | :Per [[User:FajRo|FajRo]] | ||
===Preferred method of contact=== | ===Preferred method of contact=== | ||
Line 158: | Line 152: | ||
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. | 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.''' | * '''vCard already has a <code>REV</code> ("revised") property. Use it.''' | ||
===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!''' | |||
==Suggestions made elsewhere== | ==Suggestions made elsewhere== |
Revision as of 19:29, 20 May 2009
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 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.
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.
TEL Type Definition
- 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: 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 Andy Mabbett: There are a limited number of types. Note also the cell vs. mobile issue.
- 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 e-mail, 2008-01-08 by Michael Smethurst)
- Seems like 'sms' TEL TYPE is a viable implementation option --Guillaume 12:17, 8 Jan 2008 (PST).
- 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
- Microsoft Outlook does not allow custom TEL TYPE values. Also, Microsoft Outlook has a "Company" telephone type, but unfortunately it isn't mapped to anything in vCard i.e. if you export a contact with a company tel, it is lost.
- Windows Mobile 6 displays SMS as a service that is only available if the telephone type is 'mobile'.
- Thunderbird 2 (Mac) does not allow custom TEL TYPE values.
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
- 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.
URL Type Definition
- See: RFC2426 section 3.6.8
- The "type" for "URL" lacks distinction for various types of URL, e.g. work or home.
- In particular there should be a "type" (or other indicator) for a URL used as an OpenID.
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.
- See also geo-extension-nonWGS84
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)
- 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.
Deceased
aka "date of death"
Gender
- There is no vCard property for gender.
- A workaround in hCard: add the tag/category "male", "female", etc. See also earlier discussion and genealogy-brainstorming#Gender.
- -1 Tantek: I think tags/categories are good enough for now.
- +1 Andy Mabbett:Tags are often not appropriate, as per the cited discussion.
- A workaround in hCard: add the tag/category "male", "female", etc. See also earlier discussion and genealogy-brainstorming#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
- ISO codes ?
- Also ability to indicate preferred contact language(s)
- Per FajRo
Preferred method of contact
Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.
- Per FajRo
Subject differentiator
- A "type" for the vCard itself: person, organisation or place (or perhaps more granular; or user-defined)
- In the 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. Andy Mabbett 14:30, 11 Jul 2007 (PDT)
- This may no longer be necessary for hCard; as the use of "fn [child-of-adr]", for venues and other places, has been proposed and is being debated (see email of 2007-12-30. Andy Mabbett 14:04, 8 Jan 2008 (PST)
- In the 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. Andy Mabbett 14:30, 11 Jul 2007 (PDT)
UN LOCCODE
- 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.
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.
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.
- vCard already has a
REV
("revised") property. Use it.
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
- vCard already has a
URL
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!
Suggestions made elsewhere
See contact-formats for other contact formats.
The following should be incorporated into the contact-formats page.
- OpenID page on Attribute Exchange and attribute-exchange.
- Warning: many Attribute Exchange properties unnecessarily reinvent vCard properties.
- RFC4770: vCard Extensions for Instant Messaging (IM)
- Extensions to WebDAV (CardDAV)
- uses vCard but also adds the "addressbook-access" feature of CardDAV.
- 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 (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.
- FOAF Vocabulary Specification 0.91 - Namespace Document 2 November 2007 - OpenID Edition
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.
See Also
- vCard errata
- vcard-implementations
- hCard
- hcard-brainstorming#Post_vCard_additions
- vCard mailing list - a place to raise these issues, and where similar issues can be found.
- events/2007-09-18-calconnect-vcard-workshop
- A comment on the language of TEL types, moved because it was not vCard specific