Résumé

  • RFC 3940 attribuait à chaque NormObject en circulation un numéro propre à l’émetteur afin de relier données et réparations, sans créer d’identité globale du contenu.
  • Ce numéro de 16 bits pouvait revenir après bouclage ; une identité destinée à survivre devait être définie par l’application dans NORM_INFO ou dans le contenu.

Le silence des récepteurs exigeait un repère

La multidiffusion fiable pose un problème d’échelle. Si des milliers de récepteurs confirment chaque paquet, leur succès collectif produit lui-même une tempête de contrôle. NORM choisissait le silence comme cas normal : un récepteur signalait ce qui manquait, tandis que les données de correction pouvaient réparer plusieurs pertes. Pour que cette économie fonctionne, chaque fragment, demande et réparation devait néanmoins désigner le bon objet en cours.

RFC 3940, publié à titre expérimental en novembre 2004, utilisait pour cela object_transport_id. L’émetteur faisait croître le numéro et le conservait pour toutes les transmissions et réparations du même objet. Associé à l’identifiant d’émetteur porté par le protocole, il distinguait le NormObject pendant son passage dans la session.

Le choix du mot transport n’était pas décoratif. Le repère servait au mouvement et cessait d’avoir autorité au-delà de ce mouvement.

Un fichier n’était qu’une consigne de rangement

Le modèle distinguait trois formes : données statiques en mémoire, fichier et flux sans fin. Pourtant, NORM_OBJECT_FILE ne conférait ni nom de fichier, ni chemin, ni version. Par rapport à NORM_OBJECT_DATA, il indiquait surtout au récepteur s’il devait réserver de la mémoire ou un stockage non volatil. Les deux restaient des unités finies transportées de manière identique. Même le flux pouvait porter des données statiques au choix de l’application.

Cette modestie empêche une confusion fréquente. Une catégorie opérationnelle dit comment recevoir des octets ; elle ne dit pas ce qu’ils représentent. Le protocole pouvait reconstruire tous les segments d’un bulletin sans savoir s’il s’agissait de l’édition courante, d’une copie retirée ou d’un contenu portant le même titre. La correction d’erreurs ne produisait ni provenance ni sens métier.

Le compteur revenait à son point de départ

Le champ de l’objet comptait 16 bits. Chaque émetteur administrait sa propre suite. Une valeur isolée ne suffisait donc jamais : elle prenait sens avec l’émetteur, son instance, l’état de session et la position courante dans la suite. Pour une session très longue, RFC 3940 admettait la répétition du champ et demandait au récepteur de se resynchroniser lorsqu’un numéro paraissait trop éloigné de son état.

Le texte posait ensuite une limite nette : les en-têtes NORM n’offraient aucune identification globale ou applicative du contenu. Les identifiants de transport ne valaient que pendant l’émission ou la réparation de l’objet. Leur monotonie donnait un ordre local, pas une unicité perpétuelle.

En novembre 2009, RFC 5740 remplaça RFC 3940 et fit de NORM un protocole de la filière des normes. La frontière survécut mot pour mot dans son principe. Le nouveau texte précisa même que le compteur « bouclera et sera répété » dans une session de longue durée. La normalisation du transport ne transforma donc pas son étiquette temporaire en nom d’archive.

L’application pouvait joindre une carte, pas déléguer sa mémoire

NORM_INFO permettait d’envoyer un petit contexte hors bande avec l’objet. Le type MIME constituait un exemple. Un récepteur pouvait lire cette information avant d’engager des ressources dans une réception fiable, et demander sa réparation s’il l’avait manquée. Chaque objet pouvait posséder sa propre unité INFO.

Trois limites comptaient. Le mécanisme était facultatif. Le contenu était défini par l’application. Enfin, il devait tenir dans une seule charge utile, car son caractère atomique permettait une réparation rapide. Rien n’exigeait donc un identifiant durable, une empreinte, une version ou une signature. L’application pouvait y placer un nom global, ou l’inscrire dans les données, mais elle devait en définir les règles et conserver le lien.

Le même numéro de transport attachait INFO à l’objet en circulation. Il ne garantissait pas que deux INFO portant plus tard ce numéro décrivaient le même contenu. Quand la fenêtre de réparation se fermait, garder le compteur tout en jetant l’instance et l’identité applicative revenait à conserver le ticket de consigne après avoir oublié la gare.

La fiabilité pouvait rendre l’erreur parfaitement complète

Supposons un cache indexé seulement par émetteur et numéro de 16 bits. Il perd son état, revient après un bouclage et reçoit un nouvel objet sous une ancienne clé. Les fragments sont authentiquement ceux de la transmission courante, les réparations sont complètes, mais le cache associe aux nouveaux octets l’ancien titre, l’ancien droit d’accès ou l’ancienne date d’expiration. Le transport a réussi ; l’application a commis une erreur d’identité.

Ce scénario illustre une conséquence du modèle, sans prétendre documenter un incident. Il rappelle la hiérarchie des preuves. Le contexte de session situe une transmission. Une empreinte, si l’application en fournit une, compare les octets. Un identifiant applicatif relie le transfert à un enregistrement durable. L’autorisation et la publication demandent encore d’autres décisions. Aucun niveau n’acquiert l’autorité du suivant par simple voisinage.

L’apport historique de RFC 3940 tient ainsi à une retenue. Le protocole créa exactement l’identité nécessaire pour coordonner la réparation, puis s’arrêta. Il transportait ; il ne se souvenait pas à la place de l’application.