Résumé

  • La RFC 3044 a inscrit un ISSN existant dans le cadre des URN afin de nommer un périodique indépendamment de l’adresse web où se trouvaient alors sa notice ou son édition électronique.
  • Elle précisait que les URL enregistrées n’étaient pas pérennes. Son démonstrateur comportait donc un « URL Watcher » qui repérait les adresses rompues ou redirigées ; le dispositif de découverte mondiale restait à construire.

Une revue peut changer d’hébergeur sans changer de titre. Elle peut cesser de paraître tout en restant dans les catalogues. Publiée en janvier 2001, la RFC 3044 cherchait à dissocier cette identité durable de l’adresse où un lecteur trouverait le périodique à un instant donné. L’exemple était bref — urn:ISSN:1560-1560 — car l’International Standard Serial Number identifiait déjà les publications en série.

Cette réutilisation avait un intérêt concret. Le réseau ISSN associait déjà chaque numéro à un titre-clé construit pour lever les ambiguïtés ; il conservait les notices de publications arrêtées et ne réattribuait pas les numéros. La RFC jugeait cette persistance compatible avec les Uniform Resource Names. La comparaison lexicale était déterministe : on pouvait écarter le trait d’union et normaliser en majuscule un « x » de contrôle. Une application pouvait ainsi transporter la référence du périodique sans prendre l’adresse actuelle de l’éditeur pour son identité.

Mais une URN qui mène à une URL obsolète ne suffit pas à retrouver une revue. La RFC nommait franchement le problème : la persistance des URL stockées dans la cartographie de résolution n’était pas garantie ; il fallait les vérifier et les mettre à jour. Le « URL Watcher » devait détecter les adresses rompues ou redirigées et en consigner l’état afin d’ajuster la résolution. Il ne rendait pas les URL éternelles. Il rendait visible le travail d’entretien dont dépendait le service.

Le document décrivait un système déjà développé au Centre international de l’ISSN, mais son résumé le qualifiait de démonstrateur destiné à évaluer les conditions d’un déploiement opérationnel. Dans cette première étape, un serveur central traduisait un ISSN en une ou plusieurs URL : l’une pouvait conduire à la notice bibliographique, une autre au périodique en ligne. L’étape suivante — la résolution mondiale au moyen d’un système de découverte, par exemple NAPTR — restait une évolution à étudier. La RFC en faisait un enjeu majeur, pas un résultat acquis.

L’identifiant, la notice et la destination suivaient donc des rythmes différents. Le numéro pouvait survivre à l’arrêt de la publication ; la notice pouvait préserver son titre et ses liens ; une URL pouvait se rompre, rediriger ou être remplacée. Il n’était pas nécessaire de réattribuer l’ISSN lorsque l’adresse changeait. Mais la persistance de l’identité ne fournissait pas, à elle seule, l’accès au document.

Une comparaison actuelle est utile si l’on respecte les dates. Le Centre international de l’ISSN décrit aujourd’hui l’ISSN-L comme un numéro de liaison qui regroupe les ISSN propres aux éditions imprimées et en ligne. Cette relation aide les bases à rapprocher les éditions ; elle ne faisait pas partie du démonstrateur de 2001 tel que le décrit la RFC. Par ailleurs, l’IANA conserve une entrée issn dans sa liste des espaces de noms URN formels, tandis que le Datatracker indique le passage de la RFC 3044 au statut Historic en 2017. Ces registres répondent à des questions distinctes. Aucun ne prouve que le démonstrateur ou la résolution mondiale proposée fonctionne aujourd’hui.

La note 64 de Heng Lu, utilisée ici comme simple grille de lecture et non comme source sur le projet ISSN, éclaire le point : un document peut fournir une référence utile sans constituer à lui seul la réalité déployée. La RFC distinguait précisément le système qu’elle présentait de la découverte mondiale qu’elle envisageait encore. Sa leçon est modeste mais décisive : un nom pérenne facilite le transport d’une référence ; l’accès reste une relation entretenue entre notice, résolveur et emplacements qui changent.

Sources