Résumé

  • No Value dans le registre IANA signifie drapeau ou absence d’ensemble prédéfini ; la spécification référencée continue de définir une sémantique et des conséquences.
  • L’enregistrement du nom, la syntaxe, la validité de la valeur, la capacité du destinataire, la politique, le routage et l’issue du service sont des preuves distinctes.

L’absence de signe égal n’est pas une absence d’effet

Un normalisateur reçoit un URI tel avec un paramètre enregistré comme No Value. Il supprime ce qu’il croit être un attribut vide. Le composant suivant ne voit plus le drapeau et prend une autre décision. Le registre était correct ; le logiciel avait interprété son résumé comme la totalité de la norme.

RFC 5341 précise que cette mention couvre un paramètre utilisé comme drapeau ou dépourvu d’un ensemble de valeurs prédéfinies. Elle ne dit jamais que le paramètre est décoratif. enumdi et npdi apparaissent ainsi dans le registre actuel, mais leurs RFC respectifs expliquent ce que leur présence affirme.

Une présence reste une assertion, pas une preuve authentifiée. L’émetteur peut être non fiable, l’information périmée ou le contexte incompatible. Le contrôle doit préserver le drapeau, consulter la référence, vérifier la provenance et enregistrer l’action qu’il a effectivement déclenchée.

Le registre coordonne le vocabulaire

RFC 5341 crée un espace de noms IANA pour éviter collisions et extensions privées ambiguës. Une nouvelle entrée fournit le nom, l’existence éventuelle de valeurs prédéfinies et une spécification publique durable. Une nouvelle valeur pour un paramètre existant fournit également sa référence.

Cette gouvernance répond à « qui définit ce nom et où lire sa définition ? ». Elle ne répond pas à « cet URI concret est-il valide ? », « ce réseau l’implémente-t-il ? » ou « l’appel a-t-il abouti ? ». La ligne est un pointeur de responsabilité.

Constrained possède la même limite. Cette indication annonce que la forme ou l’ensemble est contraint, mais ne reproduit pas toutes les règles. Un nom enregistré avec une valeur mal formée reste invalide. Une valeur syntaxiquement correcte peut être ancienne, non autorisée ou refusée par la politique locale.

Le numéro est un identifiant, pas une séquence de numérotation

RFC 3966 définit le tel URI comme nom d’une ressource identifiée par un numéro. Il ne donne pas les étapes nécessaires pour joindre ce numéro, n’impose pas la sémantique de numérotation et ne désigne pas un appareil physique unique.

Le composeur transforme l’identifiant en séquence selon le terminal, le PBX et le réseau. La signalisation négocie ce qui manque. Le URI ne choisit pas voix, fax ou données. Un paramètre enregistré peut enrichir cette chaîne, sans devenir une preuve de route, de média ou de terminaison.

Un numéro local doit porter phone-context. La présence du contexte rend explicite la portée attendue. Elle ne démontre pas que tous les participants configurent ce contexte pareillement, que le numéro appartient à l’entité annoncée ou qu’un chemin existe.

Comprendre le paramètre est un reçu séparé

RFC 3966 impose qu’un destinataire ne traite pas un URI contenant un paramètre obligatoire inconnu. Cette règle interdit de confondre reconnaissance du nom et capacité d’exécution. IANA peut enregistrer une extension avant qu’un parc hétérogène la comprenne uniformément.

La télémétrie doit indiquer le paramètre reconnu, la version de référence appliquée, le caractère obligatoire, le résultat de validation et la décision finale. Une analyse qui ne conserve que « trouvé dans IANA » masque un rejet correct aussi bien qu’une acceptation incorrecte.

RFC 5341 exige en outre que le service de base continue d’être invoqué et fonctionne normalement en l’absence des extensions. Si une organisation rend le paramètre indispensable, elle crée une politique locale. Cette politique peut être légitime, mais elle ne doit pas être attribuée au registre.

Le registre vivant a une date

La table initiale de 2008 et le registre IANA actuel ne sont pas identiques. Des entrées ultérieures, notamment premium-rate et verstat, figurent aujourd’hui avec leurs références. Un parseur figé sur le RFC d’origine peut les prendre à tort pour des noms privés.

L’erreur inverse consiste à lire une capture ancienne avec la table actuelle. Une allocation présente aujourd’hui ne prouve pas le sens compris par un produit quinze ans plus tôt. Les preuves doivent donc conserver l’instant de consultation, le contenu du registre et l’empreinte de la spécification.

Sans chronologie, « enregistré » devient un adjectif intemporel. Or l’autorité IANA coordonne un état évolutif. Sa mutation est une propriété du système, pas une anomalie à cacher.

Portabilité et groupes de trunks ne s’auto-certifient pas

RFC 4694 définit npdi, rn, rn-context, cic et cic-context. RFC 4904 définit tgrp et trunk-context. Leur enregistrement empêche la collision des noms et désigne le texte normatif. Il ne prouve ni actualité du numéro de routage, ni autorisation du code opérateur, ni existence ou disponibilité d’un trunk.

enumdi signale une histoire de traitement selon RFC 4759, sans authentifier à lui seul qu’une interrogation ENUM a eu lieu. isub-encoding dispose d’une définition coordonnée, sans garantir le support du récepteur. À chaque fois, la provenance et l’observation d’exécution manquent encore.

Sources et limite de preuve

Les sources établissent les normes, leur histoire documentaire et un instantané du registre IANA. Elles ne prouvent aucun appel actuel, titulaire de numéro, identité d’appelant, produit, déploiement, route, prix ou résultat.