Summary

  • Dans le format co_repair de RFC 5225, le CRC-7 couvre toute la chaîne d’en-têtes non compressés reconstruite, tandis qu’un CRC-3 distinct porte sur les champs de contrôle applicables. Ces champs peuvent ne pas participer à la décompression du paquet qui les transporte.
  • Une direction responsable sépare l’acceptation du résultat présent, l’avancement de l’état durable et l’envoi d’un retour positif. Chacune de ces décisions doit citer une preuve dont le périmètre correspond exactement à ce qu’elle autorise.

Le paradoxe d’un succès incomplet

Le paquet est arrivé. Le décompresseur a reconstitué son en-tête et le CRC-7 concorde. La chaîne de traitement peut donc annoncer une réussite. Pourtant, au même instant, certains champs de contrôle transportés par le paquet peuvent modifier le contexte utilisé pour les prochains paquets sans avoir contribué à la reconstruction qui vient de réussir.

C’est précisément pour cette dissociation que co_repair contient control_crc3_encoding. Le CRC-7 est calculé sur l’intégralité de la chaîne d’en-têtes non compressés reconstruite. Le CRC de contrôle à trois bits est calculé sur la concaténation des champs de contrôle applicables. Il ne s’agit pas de deux votes sur le même objet, mais de deux contrôles sur deux objets.

RFC 5225 avertit qu’en leur absence, la décompression peut réussir, un retour positif peut être envoyé, et les champs de contrôle peuvent néanmoins avoir été mis à jour de manière incorrecte. Le présent est valide ; l’hypothèse qui gouvernera le futur ne l’est pas nécessairement.

Le contexte est une dette envers les paquets suivants

La compression ROHC évite de répéter ce que le compresseur et le décompresseur peuvent déduire d’un contexte partagé. Ce gain transforme l’état en dépendance. Chaque mise à jour correcte rembourse une partie de la confiance accordée aux transmissions suivantes ; une mise à jour erronée déplace le coût vers un incident ultérieur.

La machine d’état de RFC 5225 maintient cette nuance. En état Repair Context, des paquets ont été décompressés avec succès mais le décompresseur ne fait pas encore confiance à l’ensemble du contexte. Un paquet protégé par le CRC-7 ou CRC-8 prévu peut rétablir Full Context. Un paquet arrivé tard peut, lui aussi, être décompressé sans actualiser l’état et sans nécessairement recevoir d’ACK. La détection d’un contexte endommagé reste dépendante de l’implémentation.

La réussite n’est donc pas une propriété uniforme. Il faut savoir quel événement a réussi, quel état a changé et quelle confiance est légitime après ce changement.

Toute preuve possède un périmètre

Dire « le CRC est bon » ne suffit pas. Il faut préciser les données qui sont entrées dans le calcul. Pour co_repair, le CRC-7 parle de l’en-tête reconstruit ; le CRC-3 parle des champs de contrôle applicables. Aucun n’est une signature cryptographique. Aucun ne prouve l’origine, la livraison à l’application, la qualité perçue ou la conformité d’un produit nommé.

Un registre exploitable doit conserver l’objet vérifié, l’état antérieur, les champs proposés, la formule de contrôle, le résultat et l’action autorisée. Sans ce sujet grammatical et opérationnel, une coche verte devient une preuve disponible pour n’importe quelle affirmation voisine.

L’erreur cachée emprunte le visage de la réussite

Une sortie immédiatement invalide échoue près de sa cause. Une sortie valide accompagnée d’une transition d’état invalide échoue plus tard. Entre les deux moments, le retour positif peut encourager les deux extrémités à poursuivre sur une prémisse commune mais fausse.

Ce retard brouille l’enquête. L’équipe examine le paquet où le symptôme apparaît, alors que la cause appartient à une transaction antérieure classée comme réussie. Les journaux détaillés ont pu être purgés, les reprises approfondir la divergence, et le retour logiciel laisser en place un état dérivé par l’ancienne version.

L’enjeu n’est donc pas seulement de détecter une erreur. Il faut préserver la causalité : quelle preuve a autorisé la sortie, quelle autre a autorisé l’écriture d’état, et quel responsable a décidé de continuer.

Trois décisions au lieu d’un bit

Pour toute opération qui produit un résultat visible et modifie un état caché, trois décisions doivent pouvoir diverger. Le résultat présent est-il acceptable ? L’état durable doit-il avancer ? Faut-il envoyer un acquittement positif ?

On peut utiliser un résultat tout en refusant l’apprentissage, le cache, la politique ou la mise à jour de contrôle qui l’accompagne. À l’inverse, une transition interne cohérente ne prouve pas que l’utilisateur a reçu le résultat attendu. Fusionner ces décisions simplifie le logiciel au prix d’une ambiguïté de gouvernance.

Ce que les sources ne démontrent pas

RFC 5225 ne documente aucune défaillance d’un opérateur mobile, d’un téléphone, d’un modem, d’un fournisseur ou d’une implémentation déterminée. Il ne donne ni part de déploiement actuelle, ni trace de paquet réelle, ni incident, ni mesure de qualité. L’enregistrement IANA confirme des identifiants, pas leur adoption.

La présence d’un contrôle séparé ne prouve pas non plus qu’une erreur touche chaque paquet de réparation. Elle établit que le premier contrôle ne couvre pas le même sujet. Une précaution de conception n’est pas un constat d’accident.

Émettre un reçu à deux volets

Le reçu de sortie doit conserver l’entrée observée, la reconstruction, le périmètre exact du contrôle, le résultat et la frontière de livraison. Le reçu de transition doit conserver l’identifiant de l’état précédent, les champs modifiés, le contrôle indépendant, la décision d’accepter ou de refuser, le retour envoyé, le nouvel identifiant d’état et le responsable de la poursuite.

Il faut aussi conserver les cas négatifs : sortie réussie mais mise à jour refusée, transition cohérente sans preuve de livraison, paquet tardif sans avancement d’état, ACK retenu, réparation demandée, contexte rétabli. Ces cas dessinent la limite réelle de la réussite.

La doctrine de Lu Heng donne ici un critère de responsabilité : la réalité d’exécution prime le récit institutionnel. Ni le nom du protocole ni celui d’une équipe ne décide. Une personne ou une fonction nommée doit répondre de l’autorité accordée à l’état futur.

Sources

Dossier normatif complémentaire

  1. RFC 5225 en texte brut
  2. Fiche d’information RFC 5225
  3. Fiche Datatracker RFC 5225
  4. Historique RFC 5225
  5. Errata RFC 5225
  6. Vue des errata intégrés RFC 5225