Résumé

  • La première révision du projet at URI constate que les deux-points littéraux d’un DID placé dans l’authority après // ne respectent pas la grammaire générique de RFC 3986. Cette version n’est donc pas admissible à un enregistrement permanent selon RFC 7595.
  • IANA conserve depuis 2023 une inscription provisoire. Elle établit l’existence du nom dans le registre, pas un examen formel de l’IETF, une interopérabilité générale ou une identité durable du handle jusqu’aux octets du record.

Un identifiant peut avoir des utilisateurs avant d’avoir résolu sa dette syntaxique. C’est précisément la situation que le projet The "at" URI Scheme rend visible sans nier ni l’une ni l’autre réalité.

La révision 00 porte la date du 1er octobre 2026. Son en-tête vise Standards Track, mais la fiche Datatracker gelée reste une soumission individuelle sans stream, état ou niveau de standard renseigné. Cette nuance interdit trois raccourcis : ce n’est pas un RFC, ce n’est pas un document adopté par un groupe de travail et ce n’est pas la décision finale d’un expert IANA.

Le format sert à désigner un compte ou un record de l’Authenticated Transfer Protocol. Après at://, l’authority peut contenir un handle lisible ou un identifiant de compte permanent. Un chemin peut ajouter une collection et une clé de record. Dans l’écosystème prévu, cette chaîne peut être résolue et utilisée.

La difficulté vient de la forme choisie pour l’identifiant permanent. Un DID tel que did:plc:… contient plusieurs deux-points non encodés. Or RFC 3986 réserve à l’authority la structure userinfo éventuel, host, puis port éventuel. RFC 7595 exige qu’une définition permanente reste dans la syntaxe URI commune. Le projet en déduit lui-même que sa forme actuelle, avec DID multi-deux-points dans l’authority, ne peut pas obtenir l’enregistrement permanent.

Il ne faut pas transformer ce diagnostic en rejet. Un résolveur spécialisé peut parfaitement traiter l’authority comme une chaîne opaque et atteindre le dépôt. Le texte ne dit ni que l’adresse est inopérante, ni qu’une migration est décidée. Il dit que la preuve d’usage et la conformité requise pour une inscription permanente ne sont pas la même preuve.

Le registre IANA contient déjà at au statut Provisional depuis juin 2023. RFC 7595 prévoit ce statut pour un schéma utilisé ou destiné à être utilisé au-delà d’un environnement privé, avant ou en dehors de sa standardisation. La procédure est First Come First Served. Le statut permanent passe par Expert Review et par les exigences de conception de la section 3.

La note de l’expert attachée à l’entrée ajoute une autre limite. Elle explique que l’inscription provisoire n’est ni une revue formelle de l’IETF ni une recommandation générale. Elle consigne des inquiétudes sur le nom court at et mentionne atproto ou atp comme alternatives proposées. Cela pourrait compliquer une future demande permanente. Mais la même note précise qu’elle ne constitue pas une position de l’IETF ou de l’IANA.

La bonne lecture conserve donc quatre états : usage opérationnel, inscription provisoire, intention Standards Track dans un brouillon individuel, et inadmissibilité actuelle de la syntaxe au statut permanent. « Enregistré » ne signifie pas « permanent ». « Projet Standards Track » ne signifie pas « standard ». « Inadmissible dans cette version » ne signifie pas « impossible à jamais ».

Le handle illustre la même discipline. Il facilite l’affichage, mais peut changer de DID ou être réattribué. Une référence ancienne peut alors devenir invalide ou pointer vers un autre dépôt. Le projet demande de résoudre un handle vers un identifiant permanent avant conservation longue ; la documentation recommande le DID pour les références entre dépôts.

Le DID ne suffit pourtant pas à figer le contenu. L’authority représente le compte, pas forcément le serveur qui héberge le dépôt. La résolution trouve ensuite le lieu de service. Collection et clé visent un record logique dont le contenu peut changer ou disparaître. Un AT URI n’est pas content-addressed ; lorsqu’une référence forte est nécessaire, la documentation conseille d’ajouter un CID.

Un reçu exploitable doit donc relier, sans les confondre : profil et révision de syntaxe, parseur et version, handle ou DID reçu, résolution horodatée du handle, endpoint du dépôt, record et révision récupérés, CID éventuel, puis action applicative. La lumière verte du parseur n’atteste pas les sept étapes suivantes.

La matrice de bibliothèques publiée par AT Protocol est une alerte, pas un recensement universel. Elle cite Python urllib et JavaScript url-parse comme exemples compatibles, Go net/url et beaucoup de crates Rust comme exemples incompatibles avec la forme documentée. Chaque opérateur doit produire ses propres résultats versionnés.

La Primauté du code en exécution de Heng Lu protège le système qui fonctionne contre une fiction institutionnelle ; elle empêche aussi ce système de s’attribuer une approbation absente. La Spécification Initiale Minimale sépare handle, identité stable, hébergement, record et empreinte. Les Couches de Réalité empêchent qu’une entrée IANA, un parse réussi et un résultat utilisateur deviennent un seul fait.

L’enjeu de gouvernance est alors simple : chaque autorité doit rester dans son périmètre. Le protocole définit la résolution, IANA publie un statut de registre, l’examen permanent juge une syntaxe donnée, l’implémentation prouve ce qu’elle exécute, et l’application décide du niveau de preuve nécessaire avant d’agir.

Sources