Résumé

  • RFC 3368 donnait à go: deux rôles : viser un service CNRP précis, ou confier une requête de nom courant aux services choisis par le client.
  • Un lien id= lié à un serveur pouvait désigner une fiche sans contenir le nom humain que le lecteur croyait reconnaître. Syntaxe, enregistrement et résolution restaient des preuves distinctes.

En août 2002, RFC 3368 proposait un lien pour contourner une difficulté simple : les personnes retiennent des noms, tandis que les réseaux déplacent les ressources à l’aide d’identifiants et de services. Le schéma go: ne rendait pas le nom lui-même faisant autorité. Il définissait la manière dont un client devait transporter une requête CNRP vers un service.

La différence tient aux caractères qui suivent les deux-points. go://cnrp.example?Ada%20Lovelace désigne un serveur précis et lui adresse une requête. go:Ada%20Lovelace ne nomme pas de serveur ; RFC 3368 destinait cette forme à un ou plusieurs services CNRP déjà configurés dans le client. Le même nom visible pouvait donc être envoyé à des ensembles de services différents selon les machines. Le lien n’intégrait pas un annuaire universel de résolveurs.

RFC 3368 donnait aussi un autre sens à une URI ne contenant qu’un serveur : elle identifiait un service CNRP, pas une recherche particulière. Le client pouvait lui demander ses capacités au moyen de servicequery. Un serveur vide signifiait l’hôte local ; sans autre connaissance du transport, le port HTTP par défaut indiqué était 1096. Ces valeurs par défaut aidaient à amorcer un échange. Elles ne prouvaient ni qu’un serveur répondait, ni qu’il était digne de confiance, ni qu’il fonctionnait encore.

La brièveté du schéma était intentionnelle. Les requêtes CNRP disposaient d’une représentation XML, mais une requête complexe aurait rendu l’URI trop longue. RFC 3368 définissait une syntaxe plus réduite, faite d’un nom courant et de paires attribut-valeur. L’encodage UTF-8 et les échappements en pourcentage étaient prévus pour les caractères hors grammaire ; l’exemple du RFC encode ü en octets UTF-8. Les formes courtes présentées dans le texte sont pédagogiques : la grammaire ABNF fait autorité.

Le cas limite le plus important était go://cnrp.example?id=5432345. Cette URI désignait une fiche particulière sur un serveur particulier sans transporter le nom courant. La section sécurité de RFC 3368 relevait le décalage : une personne pouvait croire qu’un lien renvoyait vers la ressource alors associée à « BMW », alors que le nom « BMW » ne figurait pas dans l’URI. Un identifiant lisible par machine peut être stable et rester opaque pour la personne à qui l’on demande de lui faire confiance.

RFC 3367, le protocole compagnon, plaçait hors du périmètre initial la découverte et le choix des fournisseurs, l’enregistrement, la propriété et l’unicité des noms. L’ensemble des services configurés dans le client par RFC 3368 demeurait donc un choix local, pas une réponse mondiale à la question de savoir qui parlait au nom d’un nom. Plus tard, le registre IANA des schémas URI a inscrit go comme Permanent avec RFC 3368 en référence. Cette ligne prouve l’état de l’enregistrement, pas la prise en charge par les navigateurs, l’activité de services, le trafic ou l’adoption.

La frontière historique utile est la suivante : un lien peut identifier un service, une requête ou une fiche, mais ces objets ne sont pas interchangeables. Les notes de Heng Lu « Reality Layers » et « Running-Code Primacy » sont des grilles éditoriales déclarées pour séparer la syntaxe, le dessin enregistré et le fonctionnement observé ; elles ne sont ni des exigences du protocole ni des preuves du déploiement de go:.

Sources