vcard-suggestions-fr

(Difference between revisions)

Jump to: navigation, search
m ([fr: sync'd with english version])
Current revision (18:46, 20 December 2008) (view source)
m (Reverted edits by DomraCricd (Talk) to last version by ChristopheDucamp)
 
(4 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 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é selon le numéro de section de RFC 2426 pour amélioration des propriétés actuelles, et 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 {{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.
; Auteurs :  
; Auteurs :  
Line 7: Line 7:
: [[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 Définition Type===
+
=== <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 "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.
 +
 +
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]).
 +
 +
=== <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span préserve l'ID précédente-->
 +
:'''Voir : {{RFC2426-fr}} section 3.3.2'''
-
=== 3.3.2 EMAIL Définition Type ===
 
* Le "type" pour "EMAIL" manque de distinction pour différentes types d'email, par ex. '''work''' ou '''home'''.
* Le "type" pour "EMAIL" manque de distinction pour différentes types d'email, par ex. '''work''' ou '''home'''.
* Le "type" pour "EMAIL" manque de distinction pour donner une alternative à l'emil comme un formulaire de contact.
* Le "type" pour "EMAIL" manque de distinction pour donner une alternative à l'emil comme un formulaire de contact.
-
=== 3.3.3 Suggestion pour Définition de Types D ===
+
===URL Type Définition===
-
+
:'''voir : {{RFC2426-fr}} section 3.6.8'''
-
Nous ne pouvons pas avoir un nom type générique parce que nous devons localiser en français. Aussi, pour nous le numéro de téléphone d'une hCard est :
+
-
<nowiki><div class="tel">
+
-
<span class="type">Travail</span> :
+
-
<span class="value">0321596224</span>
+
-
</div></nowiki>
+
-
Comment un robot reconnaîtra ce type ? Nous ne pouvons pas spécifier chaque type dans chaque langue dans la spécification. C'est pourquoi je pense que quelque chose comme ceci serait mieux :
+
Le "type" pour "URL" manque de distinction pour diffrents types d'URL, par ex. '''work''' ou '''home'''.
-
<nowiki>Travail : <span class="telwork">0321596224</span></nowiki>
+
* En particulier, il devrait y avoir un "type" ou autre indicateur, pour une URL utilisée comme une [[OpenID-fr|OpenID]].
-
SVP, utiliser les attributs class et id SEULEMENT pour les spécifications microformats ! #cdata et #data XML sont localisés ! Merci.
+
=== 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-->
-
== Suggestions pour de Nouvelles Propriétés ==
+
====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 :
-
===Genre ===
 
-
*Il n'existe pas de propriétés de Carte pour le 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.
 
-
====Evidence du Genre====
+
<pre>
-
Voir [[gender-examples-fr|genre-exemples]].
+
initials: A. N.
 +
family-name: Autre
 +
</pre>
-
* Les sites de réseaux sociaux (voir [[profile-examples-fr|exemples de profils]]) publient le genre de l'individu. Ajoutez svp de tels sites avec des URLs spécifiques vers le site, leur UI d'édition et leurs listes de valeurs genres sur [[gender-examples-fr#sites_et_services]].
+
au lieu du plus guindé :
-
* Beaucoup de pages publient de l'information de genre implicite, pas facilement parsable par une machine - en utilisant des noms (André, Andrée), des titres (Mr, Mrs, Miss), des relations (mari, frère), des pronoms (il, elle), etc. Ajoutez svp de telles pages avec leurs URLs spécifiques et citations de l'information explicite, et les genres implicites sur la page  [[gender-examples-fr#exemples|genre-examples]].
+
<pre>
 +
  given-name:  A. N.
 +
  family-name: Autre
 +
</pre>
-
Voir aussi [[genealogy-brainstorming-fr|genealogy-brainstorming]]
+
Aussi pour les personnes dont le prénom ''et'' les initiales sont donnés :
-
===Décès ===
+
<pre>
-
*Voir [[hcard-date-of-death-fr|hcard-date-de-décès]]
+
  given-name:      Theophilus
 +
  middle-initials: P.
 +
  family-name:    Wildebeest
 +
</pre>
-
====Date de Décès évidence====
+
et :
-
*Voir [[hcard-date-of-death-fr|hcard-date-de-décès]]
+
-
===Messagerie Instantanée===
+
-
*Voir [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].
+
-
===Subject differentiator===
+
<pre>
-
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)
+
  initials:      J.
 +
  given-name:     Paul
 +
  family-name:   Getty
 +
</pre>
-
===Elévation===
+
 
 +
====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]]
*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===
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)
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)
-
===Initiales===
+
===Langues parlées===
-
Pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre") ; afin de permettre un marquage comme :
+
* ISO codes ?
 +
* Capacité ausi d'indiquer la(es) langues de contact préférée(s).
-
<pre><nowiki>
+
:Per [[User:FajRo|FajRo]]
-
<span class="vcard">
+
-
<span class="fn n">
+
-
<span class="initials">A. N.</span>
+
-
<span class="family-name">Autre</span>
+
-
</span>
+
-
</span>
+
-
</nowiki></pre>
+
-
===Alternative dates===
+
===méthode préférée de contact===
 +
Telephone, cellphone, fax, post , e-mail, IM, SMS, IRC, Twitter, etc.
-
Pour les personnages historiques, où aucune date de naissance / ou date de décès ne sont connus, une parie date "'''étendue'''" ou "'''étendue à partir de'''"+"'''étendue vers'''" serait utile.
+
:Per [[User:FajRo|FajRo]]
-
En généalogie, quelques personnes n'ont pas de date de naissance enregistrée, mais leur date de baptême est connue.
+
===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)
-
===Continent===
+
=== UN LOCCODE ===
-
<code>adr</code> devrait avoir un code optionnel <code>continent</code> en propriété enfant.
+
*[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 ==
+
== 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.
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.
Line 94: Line 154:
==Suggestions produites ailleurs==
==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===
===WebDAV===
-
[http://www.ietf.org/internet-drafts/draft-daboo-carddav-02.txt vCard Extensions to WebDAV (CardDAV)]
+
[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>
<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===
===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.
[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==
-
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 :  
+
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>
+
-
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>
+
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.
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.
Line 112: Line 178:
== Voir aussi ==
== 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