Résumé

  • Le RFC 5328 enregistre l’espace de noms formel dvb, mais confie l’attribution des noms particuliers au processus de normalisation de DVB. La syntaxe et même la présence au catalogue ne prouvent pas qu’un récepteur dispose d’un chemin de résolution utilisable.
  • Les boîtiers à réception unidirectionnelle, les terminaux du réseau domestique, la diffusion cyclique, le multicast, HTTP et DNS n’empruntent pas le même chemin. L’authentification du nom ou de la ressource reste une information séparée du URN.

Le verdict du catalogue était exact et incomplet

Une équipe cherche urn:dvb:… dans le catalogue qu’elle considère comme autoritatif. La ligne existe. Le contrôle renvoie « valide ». Sur un poste de travail connecté, une seconde étape découvre un service et obtient une localisation. Sur le téléviseur isolé du réseau IP, rien ne suit.

Le premier verdict n’est pas devenu faux. Il portait sur l’attribution du nom. Le terminal avait besoin d’une autre preuve : un point d’entrée de découverte accessible par son canal, puis une autorité de résolution et un enregistrement utilisable.

Le tableau de bord qui fusionne ces étapes transforme un catalogue en test de disponibilité. Il fait aussi disparaître la différence entre deux classes de récepteurs. La même ressource paraît « en ligne » pour tous parce qu’un seul client a réussi.

Le préfixe enregistré ne peuple pas l’espace

La forme déclarée est urn:dvb:<NSS>. IANA enregistre l’identifiant d’espace de noms dvb. DVB attribue les noms individuels par son processus de normalisation et peut déléguer des portions de l’espace à des autorités désignées sous son régime.

Un préfixe reconnu n’est donc pas une liste de ressources. Le RFC 8141 rappelle qu’une chaîne commençant correctement par urn: ne devient pas un URN valide par la seule syntaxe : le NID doit être enregistré et la partie assignée doit respecter les règles de l’espace concerné.

La preuve minimale nomme la chaîne reçue, la règle de normalisation, la version du registre NID, l’autorité d’attribution, l’éventuelle délégation et la version du catalogue consulté. Sans cela, valid=true ne peut être reproduit.

La permanence concerne l’identité, pas un serveur

DVB s’engage à ne jamais réattribuer une chaîne déjà attribuée. Le RFC annonce aussi un engagement d’accessibilité et de permanence pour les ressources officiellement nommées.

Cet engagement organise une institution et son espace de noms. Ce n’est pas une mesure instantanée de DNS, de multicast, de HTTP ou de diffusion. Un nom indépendant de la localisation est précisément conçu pour survivre au changement d’une localisation.

Si un outil déclare le nom mort dès qu’un serveur historique ne répond plus, il lie la permanence à l’élément que l’architecture permet de remplacer. À l’inverse, conserver le nom ne permet pas d’affirmer que chaque voie d’accès fonctionne encore.

Il faut dater séparément la validité du nom, la publication du catalogue, la découverte du résolveur et l’observation du service.

Deux récepteurs, deux conditions de départ

Le RFC 5328 ne choisit pas un mécanisme universel de résolution, parce que les appareils visés n’ont ni les mêmes accès ni les mêmes capacités.

Un boîtier de télévision uniquement récepteur doit obtenir les informations de résolution dans les données de découverte transportées par le flux de diffusion. Un terminal du réseau domestique peut, lui, passer par une passerelle IP. La réussite du second ne dit rien sur la réception du premier.

Le texte décrit des enregistrements d’autorité et de résolution répétés cycliquement dans des flux de télévision numérique, des enregistrements multicast répétés via DVBSTP, ainsi qu’une livraison unicast en réponse à GET /dvb/sdns.

Chaque voie possède son propre point d’observation. Une sonde HTTP centrale ne voit pas si le carousel de diffusion a été reçu. Une capture multicast ne montre pas qu’un appareil s’est joint au groupe. Un enregistrement de résolution reçu ne prouve pas encore que la ressource désignée a été obtenue.

Le bootstrap précède la résolution

Le client doit d’abord trouver un point d’entrée Service Discovery and Selection. Le document décrit le service dvbservdsc, le port 3937 en TCP ou UDP, des adresses multicast enregistrées et des points non par défaut découverts par des enregistrements DNS SRV sous services.dvb.org.

Ces coordonnées sont des conventions partagées. L’attribution d’un port par IANA ne prouve pas qu’un processus écoute. Une adresse multicast enregistrée ne prouve pas la présence d’une route ni l’adhésion du terminal. Une réponse SRV ne garantit ni la disponibilité de la cible, ni son autorité, ni la fraîcheur de ses données.

Le reçu de bootstrap s’arrête donc au point d’entrée découvert et à l’heure de l’observation. Le reçu de résolution commence ensuite. La récupération et l’usage viennent encore après.

Le RFC 8553 a plus tard aligné l’usage des noms DNS soulignés du RFC 5328 sur le registre IANA intégré. Cette correction coordonne le nom du nœud DNS ; elle ne produit pas un service actif.

Une présence au catalogue n’authentifie rien

Le RFC 5328 dit qu’aucun mécanisme de validation intrinsèque n’est spécifié et que la présence dans un catalogue DVB indique la validité. Cette validité est celle de l’attribution sous le régime du catalogue.

Lorsqu’un URN est traduit vers une localisation, la ressource peut devoir être authentifiée. Le texte précise que l’information authentifiant le nom ou la ressource doit accompagner le URN séparément, au lieu d’être encodée dans le URN lui-même.

Ainsi, le préfixe dvb, la syntaxe, la casse normalisée, le catalogue, le transport HTTP et la réussite de la récupération ne fournissent pas à eux seuls une chaîne de confiance. Le reçu d’authentification doit identifier l’objet vérifié, le mécanisme, l’ancre de confiance, la politique et l’instant.

Une chaîne familière peut être valide mais conduire à une représentation non authentifiée. Une ressource authentique peut être servie par une voie qu’un terminal ne sait pas utiliser. Les deux dimensions ne se remplacent pas.

L’équivalence lexicale ne compare pas les résultats

La partie NSS est déclarée insensible à la casse. Deux graphies peuvent donc désigner le même nom selon la règle de comparaison.

Ce résultat ne rend pas identiques deux réponses de résolveurs, deux versions de catalogue, deux localisations ou deux contenus. Pour enquêter, il faut garder la forme littérale reçue et la forme normalisée, puis enregistrer séparément le chemin, l’époque de politique et le hash de la ressource.

Sinon une divergence réelle est masquée par une phrase vraie mais hors de propos : « les noms étaient équivalents ».

Le contact administratif peut changer seul

Le RFC 7354 a remplacé les champs d’information d’enregistrement et de déclarant par des coordonnées à jour, avec une adresse de rôle destinée à limiter les mises à jour futures. Il dit explicitement que tous les autres champs restent ceux du RFC 5328.

Le document prouve donc une maintenance administrative circonscrite. Il ne prouve pas la mise à jour d’un catalogue, d’un serveur DNS, d’un flux multicast, d’un résolveur HTTP ou d’une ressource.

La fraîcheur du contact est un signal de gouvernance utile. En faire un signal de santé du service reviendrait à attribuer au registre une observation qu’il n’a jamais réalisée.

Les exemples ne sont pas des actifs

Deux URN apparaissent dans le RFC pour illustrer la forme. Le texte avertit qu’ils ne sont pas garantis réels et servent uniquement à la pédagogie.

Un extracteur automatique qui les transforme en inventaire fabrique une attribution. L’exemple prouve la grammaire ; seul un enregistrement d’autorité et de catalogue peut prouver l’assignation. Une résolution observée et une authentification indépendante doivent encore suivre.

Cette frontière vaut aussi pour le registre IANA : il prouve que le NID existe, non que chaque chaîne imaginable sous ce NID a été attribuée.

Le dernier écran ne clôt pas le résultat

Un résolveur peut rendre une localisation, des métadonnées ou une représentation. Le client peut télécharger des octets. Il reste à savoir si le format est pris en charge, si le contenu a été authentifié, s’il est frais, si le moteur l’a rendu, si l’application l’a autorisé et si le service attendu a fonctionné.

La diversité des récepteurs décrite par le RFC rend cette séparation concrète. Une ressource adaptée à un terminal IP peut nécessiter une transformation ailleurs. Une image affichée ne prouve pas le succès d’une interaction. Une métadonnée correcte ne prouve pas l’accès au contenu qu’elle décrit.

Le URN est la clé durable qui permet de relier ces reçus. Il n’est pas leur conclusion commune.

Sources