Résumé

  • La description UTF-8 d'un USER_ERROR_SPEC est une aide complémentaire : RFC 5284 place l'information indispensable dans la valeur numérique associée au numéro d'entreprise et à la sous-organisation.
  • Recevoir, afficher, interpréter, agir et constater le rétablissement sont cinq preuves différentes; un libellé convaincant ne les fusionne pas.

Une alerte arrive avec une phrase parfaitement claire : « capacité de commutation insuffisante ». L'écran l'affiche sans erreur, l'équipe la comprend et le ticket reprend ces mots. Pourtant, aucune de ces opérations ne prouve que la chaîne automatique a identifié le bon état interne. Le texte pourrait être différent dans une autre version, tronqué sur un ancien terminal ou impropre à l'affichage sur un équipement limité.

RFC 5284 anticipe ce problème. Son champ Error Description utilise UTF-8/Net-Unicode, mais la norme le qualifie de complémentaire. L'information essentielle à l'exploitation doit se trouver dans le User Error Value, interprété à l'intérieur d'un espace défini par un Enterprise Number et, si nécessaire, un Sub Org. Le texte explique; le triplet identifie. Une politique locale autorise éventuellement une action. Une observation séparée dit si cette action a eu l'effet recherché.

Cette hiérarchie protège à la fois l'humain et la machine. Elle évite de transformer une phrase libre en interface de commande, tout en permettant à une organisation de transmettre une indication détaillée au-delà des codes RSVP mondiaux. Elle rappelle surtout qu'une erreur bien racontée n'est pas encore une décision bien exécutée.

Deux objets, deux fonctions

Les messages PathErr et ResvErr de RSVP, ainsi que Notify dans RSVP-TE, doivent déjà contenir l'objet standard ERROR_SPEC. RFC 5284 ne retire pas cette obligation. Il ajoute USER_ERROR_SPEC à côté du premier objet afin de porter des détails définis par l'utilisateur.

Si un code standard convient, le nouvel objet peut le compléter. Sinon, la norme attribue le code 33, User Error Spec, dont la sous-valeur 0 indique que les précisions se trouvent dans l'objet ajouté. Employer le code 33 sans cet objet rend le message mal formé. Le code extérieur ne remplace donc jamais son contenu, et le contenu privé ne dispense jamais du cadre standard.

La portée des messages est tout aussi précise. L'extension peut accompagner PathErr, ResvErr ou Notify. Sur un autre type de message, elle doit être traitée comme mal formée. ResvConf contient bien un ERROR_SPEC, mais l'usage qu'il en fait ne comporte pas de code et de valeur significatifs; RFC 5284 ne s'y applique pas.

Ces règles donnent deux reçus vérifiables. Le premier établit qu'un message d'erreur RSVP possède sa structure obligatoire. Le second établit qu'un détail privé cohérent l'accompagne. Un journal qui ne garde que le code 33 perd la cause. Un journal qui ne garde que la phrase privée perd son contexte protocolaire.

Le triplet est l'identité opérationnelle

Le premier champ de l'objet est un numéro d'entreprise privé de 32 bits attribué par l'IANA. Vient ensuite un identifiant de sous-organisation sur 8 bits, prévu notamment pour séparer les espaces d'équipes qui développent en parallèle. En l'absence de ce besoin, la valeur recommandée est zéro. La valeur d'erreur proprement dite occupe 16 bits.

Le nombre 17 n'a ainsi aucun sens autonome. Il n'acquiert une définition qu'avec l'organisation et la sous-organisation qui l'ont attribué. Deux entreprises peuvent employer 17 pour des situations sans rapport. Deux équipes d'une même entreprise peuvent aussi le faire. Une plateforme qui agrège seulement la valeur numérique fabrique des collisions et les présente ensuite comme une taxonomie commune.

Le registre IANA résout l'identité de l'espace supérieur. Il ne publie pas nécessairement la table privée de toutes les valeurs internes, n'authentifie pas l'émetteur d'un message et ne décide pas quelle réaction est sûre. Le récepteur doit encore vérifier la protection du message RSVP, disposer de la bonne version du dictionnaire privé et appliquer sa propre autorisation.

Il faut conserver cette version. Si une mise à jour réaffecte une valeur, une analyse ultérieure ne doit pas relire un incident ancien avec la table actuelle. Le reçu durable comprend les octets de l'objet, le triplet complet, la version de la table utilisée, l'identité du décodeur et le moment de l'interprétation.

La chaîne de caractères ne doit pas devenir une API cachée

La description est rembourrée par des octets nuls jusqu'à un multiple de quatre; sa longueur déclarée exclut ce rembourrage, et une longueur nulle est valide. RFC 5284 recommande, lorsque c'est possible, une ligne en caractères US-ASCII imprimables afin de faciliter l'usage, tout en exigeant l'encodage UTF-8/Net-Unicode.

Cette souplesse a une conséquence directe. Certains récepteurs ne sauront pas afficher tous les caractères. Ils doivent pouvoir échapper les caractères Unicode selon RFC 5137. Une automatisation qui recherche des mots dans la phrase dépendrait donc de la langue, du rendu, de l'échappement et des choix de version. Elle confondrait une aide éditoriale avec un identifiant stable.

La bonne séparation est simple. Le moteur utilise le triplet numérique et une table explicitement approuvée. L'interface montre une explication destinée à l'humain. Le dossier de preuve conserve les octets d'origine. La vue d'exploitation assainit ce qu'elle affiche.

Ce dernier point est une frontière de sécurité. Une chaîne destinée à un terminal ou à un journal peut contenir un dépassement ou des caractères de contrôle. La conserver sans modification dans la preuve n'oblige pas à l'injecter telle quelle dans une console. Inversement, remplacer les données d'origine par la version assainie détruirait la possibilité de comprendre ce qui a réellement circulé.

La forme TLV ne mondialise pas le contenu

L'objet accepte aussi des sous-objets propres à l'utilisateur. Leur enveloppe suit le modèle type-longueur-valeur. La longueur totale inclut les champs Type et Length, vaut au moins quatre octets et reste un multiple de quatre. Cette discipline permet à une implémentation de parcourir ou d'ignorer proprement une structure inconnue.

Mais le Type est attribué par l'organisation ou la sous-organisation, qui définit aussi le format et le sens de Value. La grammaire est commune; le vocabulaire reste local. Un équipement générique peut préserver le sous-objet sans en comprendre la sémantique.

Cette combinaison est plus robuste qu'une prétendue universalité. Le protocole sait où commence et finit l'extension. Le numéro d'entreprise indique qui possède l'espace. Une spécification privée donne la signification. Le récepteur choisit, selon une politique observable, s'il fait confiance à cette spécification et s'il autorise une conséquence.

Le transit est volontairement agnostique

USER_ERROR_SPEC reçoit Class 194 et le C-Type 1. Cette classe appartient à la plage 192–247 de RSVP : une implémentation qui ne reconnaît pas l'objet le transmet sans le modifier. Une ancienne version peut donc ne rien savoir du détail privé et néanmoins ne pas l'effacer.

Le résultat n'est pas une compréhension distribuée. À chaque nœud non averti, la preuve s'arrête à la conservation des octets. L'objet peut traverser quatre routeurs, puis être interprété uniquement au cinquième. Compter cinq « acceptations » parce que cinq équipements l'ont relayé reviendrait à confondre le facteur postal avec le destinataire.

La règle sur les répétitions renforce cette prudence. Une implémentation devrait ignorer les occurrences répétées et les transmettre sans modification lorsqu'elle relaie le message. Deux copies n'expriment donc ni deux autorités ni une gravité doublée. Elles constituent un fait de forme à consigner, pas une instruction à amplifier.

Du journal au rétablissement, quatre sauts restent à prouver

RFC 5284 recommande au récepteur de consigner au minimum le numéro d'entreprise, la sous-organisation, la valeur et la description. S'il sait interpréter le contenu, il devrait agir davantage selon l'erreur signalée. La formulation laisse apparaître une progression plutôt qu'un état binaire.

Après la réception viennent au moins quatre questions : la table privée a-t-elle produit une interprétation; la politique locale a-t-elle autorisé une action; l'action a-t-elle été exécutée; une mesure indépendante a-t-elle confirmé le changement de condition? Une panne peut survenir à chaque bord. Le dictionnaire peut manquer. L'autorisation peut refuser une commande dangereuse. L'actionneur peut échouer. Le symptôme peut disparaître puis revenir.

Une interface unique marquée « traitée » supprime précisément les informations dont l'équipe a besoin pour localiser cette rupture. Un meilleur modèle garde un reçu par transition, avec l'acteur, l'entrée, la version de politique, l'heure et le résultat. Le message privé reste alors une observation exploitable, non une autorité empruntée.