Résumé

  • Un profil RFC 10050 est un ensemble nommé et versionné de restrictions portant sur des propriétés, types et valeurs JSContact enregistrés. Il peut rendre le modèle plus strict, jamais plus permissif.
  • Une même carte peut satisfaire plusieurs profils et ne porte aucun champ universel déclarant celui qui s’applique. Le protocole englobant doit transmettre ou négocier le nom et la version, puis imposer ses propres règles.
  • Le registre IANA rend durable l’identité d’un profil, mais l’enregistrement ne certifie ni la qualité de sa politique ni son adéquation à un usage. Cette responsabilité reste du côté du concepteur et de l’exploitant.

Dans un journal technique, la mention « conforme au profil » paraît précise. Elle ne l’est que si l’on peut ajouter deux coordonnées : quel nom, et quelle version ? Sans elles, le résultat n’a pas de règle stable à laquelle se rattacher. Avec elles, il reste encore une question : conforme pour faire quoi ?

RFC 10050, publié comme Proposed Standard en septembre 2026, répond à la première faiblesse sans prétendre résoudre la seconde. Il crée un mécanisme d’identité pour les sous-ensembles de JSContact. Il laisse au protocole utilisateur la charge de dire quel sous-ensemble gouverne l’échange et si d’autres conditions s’ajoutent.

Une restriction, et non un format concurrent

Le modèle Card de RFC 9553 doit pouvoir représenter des contacts très différents. Une application concrète peut vouloir beaucoup moins de latitude. Un profil peut donc rendre une propriété obligatoire, interdire une propriété pourtant valide dans JSContact, limiter les types admissibles ou restreindre un domaine de valeurs.

La direction est toujours la même : vers un sous-ensemble. Un profil ne peut pas autoriser ce que le modèle de base interdit. Cette propriété maintient une hiérarchie de validation : l’objet doit d’abord être du JSContact valide, puis satisfaire les contraintes du profil choisi, avant que le protocole ne tranche selon ses règles supplémentaires.

Le profil possède un nom sensible à la casse et une version entière positive. Le couple forme son identité dans le registre IANA JSContact Profiles. Le contenu correspondant ne peut pas être remplacé silencieusement. Toute modification exige une version supérieure et l’ancienne entrée demeure consultable.

Cette permanence protège la valeur des preuves. Un test effectué sur la version 1 doit encore désigner la version 1 après l’arrivée de la version 2. Sans cette discipline, une trace de conformité changerait de signification avec le registre et les décisions historiques ne seraient plus reproductibles.

Le piège de la liste plate

Les propriétés JSContact ne sont pas toutes au premier niveau. Une propriété peut contenir un objet dont le type ouvre lui-même d’autres propriétés. RFC 10050 traite donc l’ensemble pris en charge de manière récursive. Le validateur doit suivre les types autorisés et calculer la fermeture des propriétés atteignables.

Une simple liste blanche au sommet est insuffisante. Elle peut accepter une branche interdite cachée plus bas, ou rejeter une propriété parfaitement légitime introduite par un type permis. Les pointeurs JSON de RFC 6901 donnent des adresses précises aux éléments, mais l’exactitude d’une adresse ne démontre pas que tout l’arbre a été parcouru.

Une trace exploitable devrait donc conserver davantage qu'un résultat vert : version du modèle de base, identité exacte du profil, version du validateur, chemin de propriété examiné et règle responsable du résultat.

Pourquoi la carte ne se proclame pas membre

RFC 10050 n’ajoute pas à Card une propriété générale « profile ». Il ne définit pas non plus un en-tête unique pour tous les transports. Cette absence empêche de confondre affirmation et vérification.

La même carte peut appartenir à plusieurs sous-ensembles. Une déclaration interne unique serait incomplète ; une liste de déclarations ne dirait toujours pas laquelle a été convenue pour l’échange. C’est le protocole qui connaît la négociation, les versions acceptables, la réaction aux erreurs et les exigences plus strictes. Il doit donc aussi spécifier la manière de véhiculer l’identité applicable.

Il faut conserver trois constats séparés : validité JSContact, conformité au profil identifié et validité pour le protocole. Une carte peut réussir le deuxième test puis échouer au troisième parce que le protocole interdit une propriété autorisée par le profil. Elle peut aussi être valide au sens de RFC 9553 tout en ne satisfaisant aucun profil attendu.

Ce que le registre garantit — et ce qu’il ne garantit pas

Une nouvelle inscription suit la politique Specification Required de RFC 8126. Les changements de référence passent par Expert Review et l’IETF demeure change controller. Les Designated Experts vérifient notamment l’unicité et la syntaxe du nom, l’existence des propriétés et types cités, la stabilité de la spécification et l’augmentation correcte du numéro de version.

Ils ne sont toutefois pas tenus d’évaluer le contenu substantiel du profil. L’inscription fournit un identifiant durable et une référence examinable ; elle n’accorde pas un label de sécurité, de confidentialité ou de pertinence métier. Pour des données de contact sensibles, cette limite compte : RFC 9553 invite à la minimisation, mais seul le responsable du protocole peut décider si le sous-ensemble recueille encore trop d’informations.

Lors de cette recherche, la page du registre IANA JSContact affichait une section Profiles sans inscription et des experts non assignés. Elle indiquait une dernière mise à jour au 28 mai 2026 et renvoyait encore à un Internet-Draft, alors que le RFC date de septembre. C’est une photographie datée, non une accusation : les calendriers de publication et de maintenance peuvent différer.

Cette photographie justifie néanmoins un dossier de garde. Pour chaque décision importante, conserver nom, version, copie ou empreinte de la spécification référencée, heure de consultation, version de RFC 9553, version du validateur, résultat de la fermeture récursive, mode de sélection dans le protocole et contraintes additionnelles. Un registre ultérieurement mis à jour ne doit pas effacer le contexte d'une décision passée.

Sources