vcard-suggestions-fr

(Difference between revisions)

Jump to: navigation, search
m (Deceased)
Current revision (18:46, 20 December 2008) (view source)
m (Reverted edits by DomraCricd (Talk) to last version by ChristopheDucamp)
 
(14 intermediate revisions not shown.)
Line 1: Line 1:
<h1> suggestions vCard </h1>
<h1> suggestions vCard </h1>
 +
{{TOC-right}}
 +
En tant que résultat de l'expérience d'utiliser [[hcard-fr|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr|véritables sites web du monde entier]], nous avons découvert quelques aspects de la {{RFC2426-fr}} vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés {{RFC2426-fr}} avec une section "new" pour les nouvelles propriétés.
-
En tant que résultat de l'expérience d'utiliser [[hcard-fr|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr|véritables sites web du monde entier]], nous avons découvert quelques aspects de la RFC 2426 vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé par le numéro de section de RFC RFC 2426 pour amélioration des propriétés actuelles, et une section "new" pour les nouvelles propriétés.
+
; Auteurs :
-
 
+
: [[User:Tantek|Tantek Çelik]]
-
; Auteurs : Tantek Çelik, [[User:AndyMabbett|Andy Mabbett]]
+
: [[User:AndyMabbett|Andy Mabbett]]
; Traduction en cours : [[Christophe Ducamp]]
; Traduction en cours : [[Christophe Ducamp]]
 +
 +
Raccourci :
 +
:Cette page peut être référencée sous '''<nowiki>http://microformats.org/wiki/vs-fr</nowiki>'''
== Suggestions pour les Propriétés Existantes ==
== Suggestions pour les Propriétés Existantes ==
Les suggestions pour l'amélioration pourrait inclure de nouvelles fonctionnalités et d'autre modifications majeurs à la spécification, organisées sous des titres qui reflètent les numéros de section de la RFC 2426 vCard et des titres.  Pour les erreurs de documentation, corrections, errata pour la vCard, reportez-vous svp à [[vcard-errata-fr|vcard-errata]].
Les suggestions pour l'amélioration pourrait inclure de nouvelles fonctionnalités et d'autre modifications majeurs à la spécification, organisées sous des titres qui reflètent les numéros de section de la RFC 2426 vCard et des titres.  Pour les erreurs de documentation, corrections, errata pour la vCard, reportez-vous svp à [[vcard-errata-fr|vcard-errata]].
-
=== 3.3.1 TEL Type Definition ===
+
=== <span id="3.3.1_TEL_Type_Definition">TEL Type Definition</span> === <!--span préserve l'ancienne ID-->
-
 
+
:'''Voir : {{RFC2426-fr}} section 3.3.1
* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].  Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".
* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].  Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".
** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.
** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.
** +1 [[User:AndyMabbett|Andy Mabbett]] : Il existe un nombre limité de types. Notez aussi la problématique cell vs mobile.
** +1 [[User:AndyMabbett|Andy Mabbett]] : Il existe un nombre limité de types. Notez aussi la problématique cell vs mobile.
 +
* Le "type" pour "TEL" manque d'une option "freephone". Ce pourrait être bien de considérer d'ajouter une valeur "freephone" au "type" pour "TEL". Généralement les numéros de freephone ne sont pas accessibles à partir de l'étranger ainsi cela pourrait aider les parseurs à quelque chose ?
 +
* Le "type" pour "TEL" manque d'une option "SMS short code". (Soulevé dans [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html e-mail, 2008-01-08 par Michael Smethurst])
 +
** Semble que le TEL TYPE 'sms' est une option d'implémentation viable --[[User:Guillaume Lebleu|Guillaume]] 12:17, 8 Jan 2008 (PST).
 +
* FYI. Quelques partiques existantes de logiciel Personal Information Manager :
 +
** Le Carnet d'Adresses Mac OS X permet de personnaliser les étiquettes TEL mais ne personnalise pas TEL TYPE, même si l'étiquette de personnalisation TEL ressemble à un TEL TYPE
 +
** Microsoft Outlook ne permet pas de personnaliser les valeurs TEL TYPE. Aussi Microsoft Outlook a un tel type "Company" mais malheureusement il n'est pas mappé vers quoi que ce soit dans vCard, ce qui veut dire que si vous exporter un contact avec un tel de société, il est perdu.
 +
** Windows Mobile 6 affiche SMS comme un service qui est uniquement disponible si le tel type est 'mobile'
 +
** Thunderbird 2 (Mac) ne permet pas e personnaliser les valeurs TEL TYPE.
-
== Suggestions pour de Nouvelles Propriétés ==
+
Note : ce pourrait être une bonne idée de regarder [http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04 proposed registry for "tel:" URI parameters] ; tout spécialement [http://tools.ietf.org/html/rfc3966 "phone-context" URI parameter], parce que cela essaye de résoudre un problème similaire (selon [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html e-mail, 2008-01-08]).
-
===Gender===
+
=== <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span préserve l'ID précédente-->
-
*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]].
+
:'''Voir : {{RFC2426-fr}} section 3.3.2'''
-
** -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.
+
-
===Décédé ===
+
* Le "type" pour "EMAIL" manque de distinction pour différentes types d'email, par ex. '''work''' ou '''home'''.
-
*Il n'y a pas moyen de baliser une personne comme étant décédée - soit par une marque "deceased" ou date-de-décès. Un moyen de contourner : ajouter le tag/category "deceased". Voir aussi [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007324.html la liste de discussion sur le tag pour 'deceased']
+
* Le "type" pour "EMAIL" manque de distinction pour donner une alternative à l'emil comme un formulaire de contact.
-
** -1 Tantek : je pense que les tags/categories sont bien suffisantes à cette heure.
+
 
-
** +1 [[User:AndyMabbett|Andy Mabbett]] : les tags sont souvent inappropriés, comme dans l'email cité. DoD est plus spécifique (et souvent utilisé dans la vraie vie pour les biographies et les nécrologies comme [http://en.wikipedia.org/wiki/Vincent_van_Gogh van Gogh sur Wikipedia]).
+
===URL Type Définition===
 +
:'''voir : {{RFC2426-fr}} section 3.6.8'''
 +
 
 +
Le "type" pour "URL" manque de distinction pour diffrents types d'URL, par ex. '''work''' ou '''home'''.
 +
* En particulier, il devrait y avoir un "type" ou autre indicateur, pour une URL utilisée comme une [[OpenID-fr|OpenID]].
 +
 
 +
=== Suggestions pour de Nouvelles Sous-propriétés ===
 +
<!-- triées par numéro de section propriété, puis alphabétiquement par sous-propriété proposée-->
 +
 
 +
====Initiales====
 +
N" (Voir sous propriété {{RFC2426-fr}} section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme :
 +
 
 +
 
 +
<pre>
 +
initials: A. N.
 +
family-name: Autre
 +
</pre>
 +
 
 +
au lieu du plus guindé :
 +
 
 +
<pre>
 +
  given-name:  A. N.
 +
  family-name: Autre
 +
</pre>
 +
 
 +
Aussi pour les personnes dont le prénom ''et'' les initiales sont donnés :
 +
 
 +
<pre>
 +
  given-name:      Theophilus
 +
  middle-initials: P.
 +
  family-name:    Wildebeest
 +
</pre>
 +
 
 +
et :
 +
 
 +
<pre>
 +
  initials:      J.
 +
  given-name:    Paul
 +
  family-name:    Getty
 +
</pre>
 +
 
 +
 
 +
====Body====
 +
"ADR" (voir la {{RFC2426-fr}} section 3.2.1) sous propriété ; pour les personnes (par ex dans la base lune proposée, l'expédition sur Mars) ou les lieux (par ex. cratère lunaire, montagne sur Mars) hors de la planète.
 +
* Voir aussi [[geo-extension-nonWGS84-fr]]
 +
 
 +
====Continent====
 +
"ADR" (voir {{RFC2426-fr}} section 3.2.1) sous propriété ; auto-explicatif.
 +
 
 +
====Vessel====
 +
"ADR" (voir {{RFC2426-fr}} section 3.2.1) sous-propriété ; pour les personnes, sur disons des bateaux, plateformes pétrolières et même des véhicules spatiaux (par ex l'ISS)
 +
 
 +
====Elevation====
 +
"GEO" (voir {{RFC2426-fr}} section 3.4.2) sous-propriété ; aussi connue sous "altitude" ou "depth".
 +
*Voir [[geo-extension-elevation-fr|geo-extension-elevation]]
 +
 
 +
====Schema====
 +
"GEO" (voir {{RFC2426-fr}} section 3.4.2) sous-propriété ; pour les coordonnées utilisant un schéma non-WGS84 (terrestre et pour les autres corps)
 +
* voir aussi [[geo-extension-nonWGS84]]
 +
 
 +
====Language====
 +
(par ex. note) si toutes les propriétés ne devraient pas avoir un attribut "language", similaire à <code>lang</code> en HTML de façon à ce que les agents puissent déterminer comment restituer, et si applicable, les prononcer.
 +
 
 +
== Suggestions de Nouvelles Propriétés ==
 +
<!--triées par ordre alphabétique-->
 +
 
 +
===Dates Alternatives===
 +
Pour les chiffres historiques où aucune naissance ou date de décès ne son connus une paire de dates "'''flourished'''" ou "'''flourished from'''"+"'''flourished to'''" serait utile.
 +
 
 +
En généalogie, quelques personnes n'ont pas de date de naissance enregistrée, mais leur date de baptême est connue
 +
 
 +
===<span id="Evidence date de décès">Décès</span>===
 +
aussi connue comme "date of death"
 +
*voir [[hcard-date-of-death-fr|hcard-date-of-death]]
 +
 
 +
===Genre===
 +
*Il n'existe pas de propriétés vCard pour le genre.
 +
**Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc.. Voir aussi [[hcard-faq-fr#Comment_le_genre_est_repr.C3.A9sent.C3.A9|la discussion]] et [[genealogy-brainstorming#Gender]].
 +
*** -1 Tantek : je pense que les tags/categories sont suffisamment bien à cette heure.
 +
*** +1 [[User:AndyMabbett|Andy Mabbett]] : les tags ne sont pas souvent pertinents, selon la discussion citée.
 +
 
 +
<span id="Evidence du Genre">voir [[gender-examples-fr|genre-exemples]] et [[genealogy-brainstorming]] ; remarquer aussi  [http://www.google.com/search?q=vCard.Gender recherche Google sur "vCard.Gender"] .</span> 
 +
<!--span preserves former ID-->
 +
 
 +
===Genre ===
 +
Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc. Voir aussi la [[hcard-faq-fr#Comment_le_genre_est_repr.C3.A9sent.C3.A9|première discussion]].
 +
** -1 Tantek : Je pense que les tags/categories sont suffisamment bien à cette heure.
 +
** +1 [[User:AndyMabbett|Andy Mabbett]] : les tags sont souvent non appropriés, comme selon la discussion citée.
 +
 
 +
===Global Location Number===
 +
Global Location Number (GLN) - généralement utilisé dans les transactions de commerce électronique [http://en.wikipedia.org/wiki/Global_Location_Number]. [[User:AndyMabbett|Andy Mabbett]] 06:43, 31 août 2007 (PDT)
 +
 
 +
===Langues parlées===
 +
* ISO codes ?
 +
* Capacité ausi d'indiquer la(es) langues de contact préférée(s).
 +
 
 +
:Per [[User:FajRo|FajRo]]
 +
 
 +
===méthode préférée de contact===
 +
Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.
 +
 
 +
:Per [[User:FajRo|FajRo]]
 +
 
 +
===Différenciateur de sujet===
 +
*Un "type" pour la vCard elle-même : person, organisation ou place (ou peut-être plus granulaire ou défini par l'utilisateur)
 +
**dans le [[hcard-fr|microformat hCard]], l'utilisation de "fn" et "fn org" fair la différence entre les hCards de personnes et d'autres entités, mais nous avons peut-être besoin d'un différenciateur plus approfondi, disons entres les organisations et les lieux (y compris les immeubles, les divisions gouvernementales, les points de parcours, etc.) à déterminer à un certain niveau de granularité. [[User:AndyMabbett|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)
 +
*** Ceci peut ne plus être nécessaire pour hCard ; car [[hcard-brainstorming#Named_locations|l'usage de "fn [child-of-adr]"]], pour les endroits et autres lieux a été proposé et débattu (voir [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], l'United Nations Code for Trade and Transport Locations, est un schéma de codage géographique développé et maintenu par l'UNCE (United Nations Economic Commission for Europe), une unité des Nations Unies. UN/LOCODE assigne des codes aux lieux utilisés dans le commerce et le transport avec des fonctions tels que les ports de mer, terminaux rail et routier, aéroports, bureaux de postes et points de frontières.
 +
**[http://en.wikipedia.org/wiki/UN/LOCODE UN/LOCODE on Wikipedia]
 +
 
 +
== Suggestions pour gérer les encodages  ==
 +
Le standard vCard spécifie que l'US-ASCII est supposé être l'encodage en l'absence d'un "MIME content type header" ou d'un paramètre  CHARSET qui indiquerait autre chose. Ceci a été un choix malheureux. les fichiers vCard .vcf stockés sur un système de fichiers local ne contiennent pas de header MIME et les seul moyen d'utiliser en toute confiance un autre encodage que l'ASCII est de marquer chaque champ avec le label "CHARSET=". Ceci rend le flux vCard plus compliqué que nécessaire. Ceci pourrait être simplifié par une révision du standard qui spécifie UTF-8 comme l'encodage par défaut. Ceci pourrrait fonctionner en toute sécurité avec les fichiers existant vCard vcf, qui ne contiennent pas de header MIME de contenu. Le premier champ VERSION vCard serait le même encodé soit sous ASCII ou UTF-8, ainsi les lecteurs pourraient facilement déterminer quel est l'encodage par défaut.
 +
 
 +
Pour aller plus loin, ceux qui créent des lecteurs de vCard seraient encouragés à supporter les fichiers vCard .vcf à démarrer par une séquence UTF-8 BOM. Si lest trois premiers bits du fichier sont 0xEF 0xBB 0xBF, le fichier texte est encodé UTF-8, et le lecteur de vCard devrait supposer qu'UTF-8 est le défaut. Malheureusement beaucoup de lecteurs échouent aujourd'hui à reconnaître le UTF-8 BOM et voient le fichier comme une vCard corrompue.
 +
 
 +
==Suggestions produites ailleurs==
 +
===Attribute Exchange===
 +
* Voir la [http://openid.net/specs/openid-attribute-exchange-1_0.html page OpenID sur Attribute Exchange] et [[attribute-exchange-fr]].
 +
 
 +
===Messagerie Instantanée===
 +
* Voir [http://www.rfc-editor.org/rfc/rfc4770.txt RFC4770: vCard Extensions for Instant Messaging (IM)]
 +
 
 +
===WebDAV===
 +
[http://merlot.tools.ietf.org/html/draft-daboo-carddav-03 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] spécifie comment représenter et gérer la donnée de profil concernant les utilisateurs de MI et d'autres entités [http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol Extensible Messaging and Presence Protocol] (XMPP) en utilisant l'extension XMPP Data Forms. Elle a un nombre bien plus important de propriétés qu'une vCard, mais réinvente et redonne des noms des propriétés précédentes.
 +
 
 +
===FOAF Spécification Vocabulaire===
 +
*[http://xmlns.com/foaf/spec/ FOAF Vocabulary Specification 0.91] - Namespace Document 2 November 2007 - OpenID Edition
==Note==
==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:
+
Le 24 novembre 2006, Paul Hoffman de l'[http://www.imc.org/ Internet Mail Consortium], responsable du développement et de la promotion du standard vCard, a écrit en réponse à un email provenant de [[User:AndyMabbett|Andy Mabbett]] l'informant sur sa page web : <blockquote>Il n'y a presque pas d'intérêt à réviser le standard vCard. Ceci du fait d'un manque d'énergie, pas d'un manque de bonnes 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>
+
-
== Voir aussi ==
+
Néanmoins, on pourra regarder en anglais [[events/2007-09-18-calconnect-vcard-workshop]] pour un événement avec la modification de la vCard à l'ordre du jour.
 +
== Voir aussi ==
* [[vcard-errata-fr|vCard errata]]
* [[vcard-errata-fr|vCard errata]]
 +
* [[vcard-implementations-fr|vcard-implémentations]]
* [[hcard-fr|hCard]]
* [[hcard-fr|hCard]]
 +
* [[hcard-brainstorming#Post_vCard_additions]]
* [http://www.imc.org/imc-vcard/ vCard mailing list] - un endroit pour soulever ces problématiques et où des problématiques similaires peuvent être trouvées.
* [http://www.imc.org/imc-vcard/ vCard mailing list] - un endroit pour soulever ces problématiques et où des problématiques similaires peuvent être trouvées.
 +
* [[events/2007-09-18-calconnect-vcard-workshop]]
 +
* <span id="3.3.3_Suggestion_for_Types_Definition"3>A [[hcard-issues-fr#tel-type-lang|commentaire sur le language des types TEL]], migré parce que ce n'était pas spécifique à vCard</span><!--span préserve l'ID précédente -->
 +
 +
 +
mots-clés : vcard, ietf, rfc, standard <!-- devraient être des tags, quand ce wiki permettra l'utilisation de @rel -->

Current revision

suggestions vCard

Contents

En tant que résultat de l'expérience d'utiliser hCard pour baliser les personnes, organisations et informations de contacts en général sur de véritables sites web du monde entier, nous avons découvert quelques aspects de la RFC2426 vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés RFC2426 avec une section "new" pour les nouvelles propriétés.

Auteurs 
Tantek Çelik
Andy Mabbett
Traduction en cours 
Christophe Ducamp

Raccourci :

Cette page peut être référencée sous http://microformats.org/wiki/vs-fr

Suggestions pour les Propriétés Existantes

Les suggestions pour l'amélioration pourrait inclure de nouvelles fonctionnalités et d'autre modifications majeurs à la spécification, organisées sous des titres qui reflètent les numéros de section de la RFC 2426 vCard et des titres. Pour les erreurs de documentation, corrections, errata pour la vCard, reportez-vous svp à vcard-errata.

TEL Type Definition

Voir : RFC2426 section 3.3.1

Note : ce pourrait être une bonne idée de regarder proposed registry for "tel:" URI parameters ; tout spécialement "phone-context" URI parameter, parce que cela essaye de résoudre un problème similaire (selon e-mail, 2008-01-08).

EMAIL Type Definition

Voir : RFC2426 section 3.3.2

URL Type Définition

voir : RFC2426 section 3.6.8

Le "type" pour "URL" manque de distinction pour diffrents types d'URL, par ex. work ou home.

Suggestions pour de Nouvelles Sous-propriétés

Initiales

N" (Voir sous propriété RFC2426 section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme :


initials: A. N.
family-name: Autre

au lieu du plus guindé :

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

Aussi pour les personnes dont le prénom et les initiales sont donnés :

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

et :

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


Body

"ADR" (voir la RFC2426 section 3.2.1) sous propriété ; pour les personnes (par ex dans la base lune proposée, l'expédition sur Mars) ou les lieux (par ex. cratère lunaire, montagne sur Mars) hors de la planète.

Continent

"ADR" (voir RFC2426 section 3.2.1) sous propriété ; auto-explicatif.

Vessel

"ADR" (voir RFC2426 section 3.2.1) sous-propriété ; pour les personnes, sur disons des bateaux, plateformes pétrolières et même des véhicules spatiaux (par ex l'ISS)

Elevation

"GEO" (voir RFC2426 section 3.4.2) sous-propriété ; aussi connue sous "altitude" ou "depth".

Schema

"GEO" (voir RFC2426 section 3.4.2) sous-propriété ; pour les coordonnées utilisant un schéma non-WGS84 (terrestre et pour les autres corps)

Language

(par ex. note) si toutes les propriétés ne devraient pas avoir un attribut "language", similaire à lang en HTML de façon à ce que les agents puissent déterminer comment restituer, et si applicable, les prononcer.

Suggestions de Nouvelles Propriétés

Dates Alternatives

Pour les chiffres historiques où aucune naissance ou date de décès ne son connus une paire de dates "flourished" ou "flourished from"+"flourished to" serait utile.

En généalogie, quelques personnes n'ont pas de date de naissance enregistrée, mais leur date de baptême est connue

Décès

aussi connue comme "date of death"

Genre

voir genre-exemples et genealogy-brainstorming ; remarquer aussi recherche Google sur "vCard.Gender" .

Genre

Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc. Voir aussi la première discussion.

Global Location Number

Global Location Number (GLN) - généralement utilisé dans les transactions de commerce électronique [1]. Andy Mabbett 06:43, 31 août 2007 (PDT)

Langues parlées

Per FajRo

méthode préférée de contact

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

Per FajRo

Différenciateur de sujet

UN LOCCODE

Suggestions pour gérer les encodages

Le standard vCard spécifie que l'US-ASCII est supposé être l'encodage en l'absence d'un "MIME content type header" ou d'un paramètre CHARSET qui indiquerait autre chose. Ceci a été un choix malheureux. les fichiers vCard .vcf stockés sur un système de fichiers local ne contiennent pas de header MIME et les seul moyen d'utiliser en toute confiance un autre encodage que l'ASCII est de marquer chaque champ avec le label "CHARSET=". Ceci rend le flux vCard plus compliqué que nécessaire. Ceci pourrait être simplifié par une révision du standard qui spécifie UTF-8 comme l'encodage par défaut. Ceci pourrrait fonctionner en toute sécurité avec les fichiers existant vCard vcf, qui ne contiennent pas de header MIME de contenu. Le premier champ VERSION vCard serait le même encodé soit sous ASCII ou UTF-8, ainsi les lecteurs pourraient facilement déterminer quel est l'encodage par défaut.

Pour aller plus loin, ceux qui créent des lecteurs de vCard seraient encouragés à supporter les fichiers vCard .vcf à démarrer par une séquence UTF-8 BOM. Si lest trois premiers bits du fichier sont 0xEF 0xBB 0xBF, le fichier texte est encodé UTF-8, et le lecteur de vCard devrait supposer qu'UTF-8 est le défaut. Malheureusement beaucoup de lecteurs échouent aujourd'hui à reconnaître le UTF-8 BOM et voient le fichier comme une vCard corrompue.

Suggestions produites ailleurs

Attribute Exchange

Messagerie Instantanée

WebDAV

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 spécifie comment représenter et gérer la donnée de profil concernant les utilisateurs de MI et d'autres entités Extensible Messaging and Presence Protocol (XMPP) en utilisant l'extension XMPP Data Forms. Elle a un nombre bien plus important de propriétés qu'une vCard, mais réinvente et redonne des noms des propriétés précédentes.

FOAF Spécification Vocabulaire

Note

Le 24 novembre 2006, Paul Hoffman de l'Internet Mail Consortium, responsable du développement et de la promotion du standard vCard, a écrit en réponse à un email provenant de Andy Mabbett l'informant sur sa page web :
Il n'y a presque pas d'intérêt à réviser le standard vCard. Ceci du fait d'un manque d'énergie, pas d'un manque de bonnes suggestions.

Néanmoins, on pourra regarder en anglais events/2007-09-18-calconnect-vcard-workshop pour un événement avec la modification de la vCard à l'ordre du jour.

Voir aussi


mots-clés : vcard, ietf, rfc, standard

vcard-suggestions-fr was last modified: Saturday, December 20th, 2008

Views