Résumé

  • Les composantes r, q et f sont exclues du calcul de l’équivalence des URN. Cette exclusion concerne la comparaison du nom, pas la suppression générale des paramètres lors de toutes les opérations.
  • La composante q est destinée à la ressource ou au système fournissant le service. Les systèmes de résolution ne doivent pas exiger sa transmission pour leur traitement.
  • Lorsqu’un localisateur possède déjà une chaîne de requête, RFC8141 n’impose pas un comportement unique pour la rencontre avec q. Les résolveurs devraient expliquer leur stratégie, sans inventer une règle mondiale de fusion.

Un nom commun ne décrit pas tout ce qui est demandé

Imaginons deux demandes concernant un même objet nommé, mais portant des paramètres différents. Selon le contrat propre à un service, l’une pourrait demander une représentation et l’autre une représentation distincte. Ce sont des situations pédagogiques, non des mots-clés universels d’URN ni des résultats observés sur un fournisseur réel.

Comparer les noms peut donner la bonne réponse : les deux demandes concernent la même ressource nommée. Il serait pourtant abusif de transformer cette réponse en garantie que les demandes complètes sont interchangeables. Le système a établi une identité ; il n’a pas interprété toute l’opération que la ressource devra traiter.

Le risque est d’autant moins visible qu’un contrôle centré sur le nom peut réussir. La ressource reconnue est la bonne, l’espace de noms est cohérent et la résolution produit une adresse. Une étape ultérieure peut néanmoins avoir perdu une distinction de service ou de représentation parce qu’elle a réutilisé la comparaison comme décision générale.

RFC8141, publié en avril 2017, sépare explicitement le nom attribué des composantes facultatives. Le premier comprend le schéma urn, un identifiant d’espace de noms et une chaîne propre à cet espace. Les composantes r, q et f n’entrent pas dans la comparaison d’équivalence, tout en conservant des destinations et des usages différents.

Cette frontière devient particulièrement intéressante lorsque l’adresse produite par la résolution contient déjà une requête. La composante q de l’URN rencontre alors des informations de requête présentes dans le localisateur. Le texte ne définit pas une fusion obligatoire. Il reconnaît plusieurs circonstances et recommande que le résolveur documente sa stratégie.

La comparaison est plus précise qu’un nettoyage général

L’équivalence URN est un traitement propre au schéma. La procédure de base convertit en minuscules le schéma urn et l’identifiant d’espace de noms. Dans la chaîne spécifique, elle met en majuscules les chiffres hexadécimaux A à F des triplets d’encodage. Elle ne convertit pas toute la chaîne spécifique en minuscules.

Les caractères encodés ne doivent pas être décodés dans cette comparaison de base. Une routine générale de normalisation d’URI peut donc faire des transformations qui ne répondent pas à la question posée ici. Le cadre de RFC3986 prévoit des comparaisons selon leurs finalités ; le traitement URN précise celle qu’il faut appliquer au nom.

Un espace de noms peut ajouter des règles qui éliminent des faux négatifs. Il ne peut pas rendre non équivalente une paire que la procédure commune considère déjà comme équivalente. L’autonomie supplémentaire s’exerce donc dans une limite : affiner l’identification sans annuler le résultat minimal partagé.

Les composantes facultatives sont ensuite ignorées pour ce calcul. « Ignorer pour comparer » ne veut pas dire « sans signification pour agir ». Une requête peut demander un service particulier ; un fragment peut sélectionner une partie d’une représentation. Ces usages ne doivent pas forcément créer un autre nom attribué.

Il faut enfin distinguer forme et attribution. Une chaîne commençant par urn: ne devient pas automatiquement un URN valide parce que sa syntaxe paraît correcte. RFC8141 suppose un espace de noms enregistré et une attribution conforme à ses règles. La comparaison ne remplace ni ces conditions ni le contrat du service.

Cette précision protège contre deux excès. On ne doit pas gonfler le résultat d’identité jusqu’à lui faire autoriser tout usage de la ressource. On ne doit pas non plus le vider de son sens parce qu’il ne décrit pas tous les résultats possibles. Il répond à une question limitée, qui mérite d’être conservée comme telle.

q ne s’adresse pas au même acteur que r

La séquence ?= introduit q. Cette composante transmet des paramètres à la ressource nommée ou au système capable de fournir le service demandé, pour interprétation par ce destinataire. Elle n’est pas la composante r, destinée aux paramètres du service de résolution.

La séparation est normative. Les systèmes de résolution, propres à un espace de noms ou plus génériques, ne doivent pas exiger que les informations de q leur soient transmises pour leur traitement. La conception de l’espace et le placement des informations devraient éviter qu’ils aient besoin de considérer q.

Cela ne signifie pas effacer ces informations avant de former toute demande destinée à la ressource. Dans le cas prévu où l’URN est résolu en URI ayant fonction de localisateur, q est copié dans la requête de cette URI. Ne pas le rendre nécessaire au traitement de résolution et le transmettre à l’étape ressource sont deux responsabilités différentes.

Les mots-clés n’ont pas une signification globale fixée par cette syntaxe. La ressource ou le système pertinent interprète le service. Des détails peuvent dépendre des arrangements de l’espace ou de la ressource. Un exemple de choix entre représentations ne définit pas un paramètre obligatoire pour toutes les organisations.

Il existe aussi une limite explicite. Quand l’URN ne se résout pas en URI ayant fonction de localisateur, l’interprétation de q reste indéfinie par cette spécification. La règle décrivant la copie ne couvre donc pas indistinctement toute architecture de résolution ou tout résultat possible.

Une formule simple comme « les requêtes ne comptent pas » effacerait ces distinctions. Elles ne comptent pas dans l’équivalence du nom ; elles ne doivent pas être exigées pour le traitement du résolveur ; elles peuvent avoir un rôle à l’étape de la ressource. Aucun de ces énoncés ne peut remplacer les deux autres.

Deux sources de requête peuvent se rencontrer

Le localisateur renvoyé peut déjà contenir une chaîne de requête. Si l’URN initial possède q, deux ensembles d’informations interviennent dans la construction de la demande. RFC8141 ne choisit pas un comportement obligatoire dans ce cas. Il ne fournit ni ordre universel d’écrasement, ni priorité générale, ni recette de concaténation.

Un choix local n’est pas illégitime parce qu’il n’est pas unique. Il devient un élément d’interopérabilité que les participants doivent pouvoir comprendre dans les circonstances couvertes. Le texte recommande la documentation de cette stratégie, plutôt qu’une supposition tirée d’un seul résultat réussi.

Le même nom peut donc rester reconnu tandis que la demande effective dépend de cette stratégie. Cette possibilité ne constitue pas un incident établi dans un produit. Elle indique ce qu’un engagement centré sur la comparaison ne peut pas garantir à un client qui utilise ensuite le service.

La portabilité a deux objets. Passer d’un résolveur à un autre peut préserver l’équivalence du nom sans préserver la façon de traiter la rencontre avec une requête déjà présente. Montrer seulement le premier résultat laisse le second sans explication. Une transition devrait préciser lequel est partagé et lequel dépend du contrat local.

La documentation permet de rendre cette décision visible sans créer une institution qui approuve chaque requête. Des descriptions communes peuvent aider les utilisateurs à comparer des stratégies. Elles ne doivent pas être présentées comme un algorithme obligatoire que le standard aurait imposé.

L’absence de stratégie expliquée est également significative. Un résolveur peut appliquer parfaitement la comparaison de base et ne pas permettre au client de prévoir cette étape ultérieure. L’étiquette « conforme » ne répond pas à toutes les questions de construction de demande. Il faut décrire l’objet précis auquel la conformité se rapporte.

Une place dans la syntaxe ne suffit pas à créer un protocole

La composante r, introduite par ?+, est destinée à transmettre des paramètres au service de résolution. Elle doit être fournie avec l’URN lors de la demande pertinente, bien qu’elle soit exclue de l’équivalence du nom. Sa destination reste différente de celle de q.

RFC8141 ne fournit lui-même que sa syntaxe et la réserve à un usage futur. Il recommande de ne pas employer r avant standardisation de sa sémantique. Un exemple hypothétique figurant dans le document n’est donc pas, par sa seule présence, un service opérationnel ou un vocabulaire complet de protocole.

Cela décrit ce que ce RFC fournit. Ce n’est pas une affirmation selon laquelle aucune spécification ultérieure ne pourrait exister. Pour attribuer un comportement concret à un service r, il faudrait son contrat applicable. Cette recherche n’a exécuté aucun service de ce type.

La composante f a une autre destination : le client, qui interprète une région ou une partie de la ressource nommée. Dans les cas couverts avec une représentation, le type de média définit la sémantique du fragment. Le fragment peut donc compter pour l’usage sans compter pour le nom.

Il ne faut pas en déduire une interprétation universelle de tous les résultats, ni faire de chaque fragment une information exigée par le résolveur. r, q et f ne forment pas une seule réserve de suffixes à jeter. Ils ne forment pas davantage un ensemble commun de permissions permettant tout usage.

Un espace de noms peut montrer deux règles distinctes

Le modèle d’enregistrement ISSN capturé donne une illustration documentaire précise. Pour l’équivalence, il autorise l’omission du tiret central et exclut les composantes Q et R. Pour la résolution, ses instructions prennent en compte tous les éléments de l’identifiant, dont le chiffre de contrôle et le tiret central.

Il décrit également la restitution du tiret quand un stockage local l’omet. La règle de comparaison et la préparation de l’identifiant pour une autre étape ne sont donc pas identiques. Aucun ISSN particulier n’a été validé ou résolu pour cet article ; le modèle daté ne vaut pas essai d’un service actuel.

La transition de 2017 expliquée par RFC8254 apporte un autre exemple limité. Les pratiques d’enregistrement ISBN et ISSN pouvaient évoluer avec leurs standards ISO sans soumission répétée des modèles à une approbation formelle de mise à jour IETF ou IANA. Cela ne permet pas de désigner la dernière édition ISO à partir du document ancien.

Ce n’est pas non plus une permission d’abolir les obligations d’attribution de n’importe quel espace. C’est une répartition des décisions : un contrat initial commun peut organiser la participation, tandis que des travaux ultérieurs restent chez les acteurs compétents. Il n’a pas besoin de devenir une autorité sur chaque paramètre de ressource.

RFC3401 apporte le contexte historique de découverte dynamique DDDS. Cette architecture n’impose pas une procédure universelle à tout résolveur URN. RFC6963 réserve quant à lui l’espace example aux illustrations, pas à la preuve qu’un nom montré possède une ressource réellement joignable.

Le cache de réponse ne compare pas seulement des noms

Un cache fondé sur l’identité peut reconnaître un objet nommé commun. Cela ne prouve pas que deux demandes sélectionnent la même réponse. Les paramètres de service, les conditions de la ressource et le choix de représentation peuvent encore intervenir. Cette analyse décrit un risque hypothétique, pas une vulnérabilité observée.

Lorsque la récupération ultérieure utilise HTTP, RFC9111 fonde la clé de cache sur au moins la méthode et l’URI cible, avec les informations pertinentes de sélection par Vary pour les réponses négociées. C’est une règle de cette étape HTTP. Ce n’est pas une obligation d’utiliser HTTP pour toute résolution URN.

La comparaison URN peut donc rester correcte tandis qu’une clé de réponse simplifiée perd une distinction de la cible finale. Substituer le seul nom à cette cible serait une autre décision, non une conséquence automatique de l’équivalence. L’effet possible est une réponse réutilisée hors de ses conditions, même si le bon objet a été identifié.

Les recommandations de RFC8820 aux auteurs de spécifications de structure URI et l’Architecture du Web de W3C éclairent la frontière. Identification, représentations, contrôle légitime et délégation ne doivent pas être confondus. Ces documents techniques ne sont pas des licences d’accès ni des autorisations juridiques de consommer une ressource.

Le cadre de Lu Heng —spécification initiale minimale, décisions futures locales et adoption volontaire— peut être appliqué ici comme lecture explicite de gouvernance. Il ne lui attribue pas la création du RFC. La comparaison commune définit un socle ; les destinataires et contrats locaux continuent d’interpréter ce qui dépasse ce socle.

La conclusion est donc une limitation utile de l’autorité du résultat. Un nom équivalent permet de reconnaître ce que la comparaison promet de reconnaître. Il ne résout pas à lui seul la requête, le service, la représentation et la stratégie lorsque des paramètres déjà présents rencontrent ceux de la demande.

Sources