vcard-suggestions-fr

suggestions vCard

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

Auteurs

Tantek Çelik

Andy Mabbett

Traduction en cours

Christophe Ducamp

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.

3.3.1 TEL Définition Type

• 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 : 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.
  • +1 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 ?

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.

Suggestions pour de Nouvelles Propriétés

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 première discussion.
  • -1 Tantek : Je pense que les tags/categories sont suffisamment bien à cette heure.
  • +1 Andy Mabbett : les tags sont souvent non appropriés, comme selon la discussion citée.

Evidence du Genre

• la plupart des sites de réseaux sociaux (voir exemples de profils) publient le genre de l'individu.
• beaucoup de pages publien l'information implicite du genre, pas facilement parsables par les machines, en utilisant des noms (Andrew, Andrea), de titres (Mr, Mrs, Miss), des relations (mari, frère), des pronoms (he, she), etc. Voir aussi genealogy-brainstorming

Décès

• 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 la liste de discussion sur le tag pour 'deceased'
  • -1 Tantek : je pense que les tags/categories sont bien suffisantes à cette heure.
  • +1 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 van Gogh sur Wikipedia). Notez aussi que Persondata de Wikipedia qui s'aligne très proche de la hCard mais a des champs supplémentairs de date et lieu de naissance. Andy Mabbett 13:06, 28 Jan 2007 (PST)
  • +1 for date-of-death Ciaran McNulty : la date-de-décès est une information utile dans quelques applications (tout particulièrement la généalogie).
  • -1 pour le flag 'deceased' Ciaran McNulty : le tag peut couvrir cette sorte de tag binaire.

Evidence Date de Décès

• Toutes les entrées +56,000 du Oxford Dictionnaire National des Biographies
• La plupart des biographies sur Wikipedia des personnes décédées, par ex. Walt Disney, John Bonham (la plupart de celles-ci sur Wikipedia-EN utilisent déjà la hCard)*Find-a-Grave par ex. Karl Marx, Chico Marx
• Utilisée dans les nécrologies, par ex. Tony Norris (WMBC) ; Ivor Cutler (Guardian) ; Grahame Clark (British Archaeology)
• Utilisée sur les pages des mémoriaux de guerre, par ex. Captain Ronald Wilkinson
• Utilisée dans les biographies par ex Biography.com (Camille Monet)
• Liste de saints sur Wikipedia

Messagerie Instantanée

• Voir RFC 4770.

Subject differentiator

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

Elévation

• Voir geo-extension-elevation

Suggestions pour gérer les encodages

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.

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

• vCard errata
• hCard
• vCard mailing list - un endroit pour soulever ces problématiques et où des problématiques similaires peuvent être trouvées.