Résumé

  • Chaque History Number choisit un état de compression négocié ; l’ordre, les vérifications et le dialogue de remise à zéro sont indépendants d’un historique à l’autre.
  • C/U=0 décrit la forme du champ Data. Process-Uncompressed peut néanmoins faire avancer l’historique des deux pairs à partir de ce datagramme en clair.
  • Le numéro de séquence, le LCB et Reset-Ack ont des portées différentes. Ils ne recréent ni les données supprimées ni la preuve de remise à la couche supérieure PPP.

Le coût caché de « non compressé »

Une trace réseau présente volontiers C/U=0 comme un contournement du compresseur. RFC 1967 impose une lecture plus fine. En mode Process-Uncompressed, le compresseur et le décompresseur traitent aussi le datagramme non compressé afin de mettre à jour le même historique. Le paquet courant économise l’expansion, mais prépare les gains futurs.

En mode None, le récepteur ne touche pas à l’historique. Si l’émetteur l’a déjà modifié pendant une tentative de compression avant de choisir l’envoi brut, il doit l’effacer avant le datagramme suivant. La forme transmise ne révèle donc pas, seule, la continuité de l’état.

Le dossier RFC Editor et le Datatracker IETF datent le texte d’août 1996 et le classent Informational. Le document indique expressément qu’il ne définit pas une norme Internet.

Une mémoire découpée en domaines de panne

History Count 0 réinitialise l’unique tampon au début de chaque datagramme et oblige l’émetteur à poser R-A partout. La perte d’un paquet ne contamine plus un historique interpaquets, et l’ordre cesse d’être une dépendance. Cette simplicité paie une compression plus faible.

Avec un historique, la mémoire continue. À partir de deux, chaque History Number possède son tampon, son état de contrôle et sa signalisation. Seuls les paquets d’un même numéro doivent rester ordonnés. Le champ disparaît sous deux historiques, occupe un octet jusqu’à 255, puis deux. Dès qu’un sens utilise plusieurs historiques, il figure dans tous les paquets, compressés ou non, des deux sens.

Le RFC propose qu’un historique puisse représenter une connexion logique. Il ne définit pourtant ni client, ni cinq-tuplets, ni transaction. Le numéro nomme un tampon ; toute identité métier vient d’une table d’implémentation qu’il faut conserver séparément.

DCP place la resynchronisation dans le prochain trafic

Le profil s’appuie sur la famille Stac LZS non-DCP décrite par RFC 1974, puis ajoute un en-tête DCP avec C/U, R-R et R-A. Contrairement au mécanisme général de RFC 1962, ces bits appartiennent au History Number du paquet et sont lus avant ses données.

Après un échec de réception, le décompresseur envoie R-R pour l’historique fautif. Le paquet peut aussi transporter des données locales dans l’autre sens. Le pair efface alors le compresseur visé et renvoie R-A sur un paquet qui contient obligatoirement des données ; faute de données prêtes, il attend.

R-A ne signifie pas « données récupérées ». Il affirme que l’historique était vide juste avant la transformation du Data de ce paquet. Le compteur de séquence de l’émetteur continue ; le récepteur recale sa référence sur ce paquet. Entre l’échec et R-A, il jette les paquets du même historique, quitte à répéter R-R. Les autres historiques et le sens inverse peuvent avancer.

L’anti-expansion répartit deux factures

Stac LZS peut augmenter la taille jusqu’à 12,5 %. Si le résultat et son en-tête dépassent le MRU du pair, l’émetteur doit utiliser un paquet LZS-DCP non compressé. Avec None, conserver l’historique impose d’envoyer le résultat gonflé ; préserver la taille immédiate impose de revenir au brut et d’effacer la mémoire. Process-Uncompressed conserve simultanément la taille courante et la mémoire future en traitant les octets bruts des deux côtés.

Cette mécanique n’est pas celle de RFC 1977. BSD Compress, LZW et CLEAR forment un autre contrat, déjà réservé à une autre étude.

Les contrôles ne se remplacent pas

Le numéro de séquence, relatif à l’historique, part de 1 et progresse modulo 256 pour les paquets avec Data. Il détecte une progression inattendue, pas une altération de contenu. Le LCB calcule un XOR sur le datagramme original puis sur le résultat décompressé. Il n’existe que pour les paquets compressés et tient sur un octet : utile contre certains défauts, insuffisant comme garantie cryptographique.

Le FCS de liaison et le mode fiable de RFC 1663 répondent encore à d’autres questions. Le registre IANA PPP prouve l’attribution de 0x00FD, 0x00FB et 0x80FD, non leur emploi correct dans une session donnée.

Même une décompression réussie ne prouve pas que le paquet reconstruit a été accepté puis remis par PPP selon RFC 1661, encore moins qu’une application l’a traité. Les séquences Multilink, les bits B/E et le réassemblage de RFC 1990 restent une surface distincte du History Number.

La page des errata n’a pas livré de contenu exploitable lors de la collecte ; nous ne déclarons donc pas l’absence d’errata. RFC 1967 ne traite pas non plus les questions de sécurité.

Les essais de Heng Lu sur la primauté du code exécuté, la spécification initiale minimale, les couches de réalité et la réalité plutôt que le plaidoyer servent ici de discipline éditoriale : borner un signal à ce qu’il exécute et vérifier. Ils ne constituent pas des sources historiques sur LZS-DCP.