Résumé

  • RFC 1547 exigeait que les modes actif et inactif d'une fonction restent compatibles, chaque mise en œuvre devant savoir tenir les deux positions.
  • Pour la détection de vie, la compression ou la MTU, désactiver, refuser ou conserver la valeur par défaut constituait une issue normale du protocole.
  • Les textes PPP ultérieurs ont précisé qu'une mise en œuvre dépourvue d'une option devait encore interopérer avec celle qui la proposait.

Un document de 1989 publié en 1993

RFC 1547 porte la date de décembre 1993, mais raconte d'emblée une chronologie plus ancienne. Le document d'exigences avait été rédigé en juin 1989. Sa note historique indique qu'il avait guidé RFC 1134 puis les versions suivantes de PPP ; sa publication tardive devait compléter les archives et servir à de futurs travaux de normalisation.

Ce décalage est essentiel. Le texte n'est ni un commentaire rétrospectif sur un protocole achevé, ni la description des paquets PPP. C'est la liste des qualités qu'un protocole point à point destiné à devenir standard Internet devait posséder. RFC 1134, RFC 1171, RFC 1331, RFC 1548 puis RFC 1661 jalonnent la succession des spécifications. Leur existence ne mesure ni le déploiement ni la conformité des produits.

Les auteurs précisaient aussi que leurs exemples n'imposaient pas une solution unique. La vraie question était un test d'architecture : deux exploitants ayant des contraintes opposées pouvaient-ils toujours trouver un mode commun ?

Le mode inactif faisait partie du contrat

Une liaison point à point pouvait avoir besoin d'un contrôle de vie permanent ; une autre pouvait juger ce trafic inutile. Une ligne très bruitée pouvait profiter d'une correction d'erreurs supplémentaire ; ailleurs, ce service aurait doublé le travail des transports. La compression pouvait économiser de la capacité, mais encore fallait-il que les deux extrémités partagent un algorithme et veuillent l'utiliser.

RFC 1547 n'a pas tranché ces conflits en imposant une préférence universelle. Il a demandé que les modes activé et désactivé restent compatibles, que les mises en œuvre prennent en charge les deux et que l'utilisateur local — pas nécessairement une personne — puisse choisir dynamiquement.

L'analogie donnée avec UDP est révélatrice. Le checksum UDP possède une représentation du mode désactivé que le destinataire sait accepter. Il ne s'agissait pas de reprendre ce codage dans PPP, mais d'accorder une signification protocolaire à l'absence. Dire non à une fonction facultative ne revenait pas à parler une autre langue.

Une case à cocher ne suffit donc pas. Deux équipements peuvent chacun annoncer « on/off » et rester incompatibles si l'un traite le mode off du voisin comme une erreur. Le contrat commun doit survivre au désaccord.

Le prix discret d'un battement de cœur

La détection de vie rend la tension visible. RFC 1547 voulait un mécanisme capable de déterminer si la liaison fonctionnait et le prévoyait actif par défaut. La liaison commençait dans l'état down ; il fallait vérifier un échange bidirectionnel de paquets avant de la déclarer up.

Mais le mécanisme devait pouvoir être coupé, car certains réseaux publics facturaient le trafic de maintien en vie. Sur un circuit privé, le battement périodique accélérait la détection d'une panne. Sur un service mesuré, le même battement pouvait devenir une dépense récurrente. La différence venait de l'environnement économique, non d'une mauvaise compréhension technique.

La valeur par défaut exprimait ainsi un point de départ partagé, pas un ordre irrévocable. L'exploitant conservait la décision de coût ; le protocole conservait le sens commun du mode choisi.

Il faut aussi borner ce que prouvait l'indicateur. Un échange bidirectionnel attestait la liaison à cet instant, pas la santé d'une application. Le contrôle d'identité proposé visait les erreurs de configuration et n'était explicitement pas une authentification rigoureuse. RFC 1547 déclare ne pas traiter les questions de sécurité. Lui attribuer après coup une garantie d'autorité falsifierait la source.

Refuser la compression terminait correctement la négociation

RFC 1547 ne normalisait aucun algorithme de compression. Les systèmes pouvaient compresser s'ils y consentaient tous les deux et disposaient d'au moins un algorithme commun. La négociation devait rester simple et se terminer à coup sûr.

Le refus avait priorité. Une extrémité ne pouvait transformer son souhait de compresser en obligation pour sa voisine. Le résultat « sans compression » était complet : il fermait la négociation tout en préservant la liaison de base.

C'est ce qui empêchait une amélioration facultative de devenir un examen d'entrée caché. Si proposer un mode enrichi rendait le mode ordinaire inutilisable, l'équipement le plus capable réduirait paradoxalement l'interopérabilité. Le plancher non compressé permettait l'innovation sans exclure ceux qui ne l'adoptaient pas.

Le texte ne fournit ni taux d'adoption, ni liste d'algorithmes effectivement choisis, ni gain mesuré. Il établit plutôt les détenteurs de décision : le fabricant expose une capacité, l'exploitant choisit une politique et les deux pairs consentent au résultat.

Une valeur par défaut, puis une sortie explicite

La MTU suivait la même logique. Chaque type de liaison devait avoir une valeur par défaut d'au moins 1 500 octets. Une négociation explicite ou un accord privé pouvait en retenir une autre. Sans accord, la valeur commune restait opposable.

L'optimisation locale n'était pas interdite ; elle devait devenir visible et bilatérale. Un nombre inscrit dans la configuration d'une seule machine ne suffisait pas à créer un fait partagé.

Le document réservait au socle la transparence, le cadrage, une détection d'erreur élémentaire et une MTU de base. Il ne rendait pas universels la correction d'erreurs de liaison, le contrôle de flux ou le séquencement, puisque les protocoles de transport fournissaient déjà des fonctions voisines. Une ligne particulièrement mauvaise pouvait néanmoins ajouter une correction d'erreurs par accord privé.

La compatibilité avec tous les anciens protocoles point à point, le multipoint, le semi-duplex, le simplex et les chemins asynchrones à sept bits figuraient aussi parmi les non-exigences. Réduire le socle ne signifiait pas déclarer ces usages sans valeur ; cela évitait qu'ils deviennent le prix d'entrée de chaque liaison.

Des pairs, pas des rangs permanents

RFC 1547 refusait également les rôles fixes de maître et d'esclave, de passerelle et d'hôte. Si une procédure avait besoin de rôles différents, les extrémités pouvaient les choisir dynamiquement pour cette connexion.

Cette symétrie renforce le droit au refus. Une hiérarchie permanente permettrait au côté dominant de qualifier le choix adverse d'erreur. Des pairs commencent au contraire avec une grammaire commune et n'introduisent que les distinctions temporaires nécessaires. La négociation d'adresse réseau, comme celle de compression, devait être simple et finie.

Le mécanisme d'extension devait accueillir de futures options. Sa sûreté reposait sur le fait que l'apparition d'une option ne supprimait pas le mode antérieur.

PPP a donné un sens précis à « facultatif »

RFC 1548 et RFC 1661 ont ensuite exprimé ces principes dans la spécification PPP mûrie. Les configurations courantes reposaient sur des valeurs standard. Une amélioration présente à une extrémité pouvait être annoncée automatiquement ; l'exploitant gardait la possibilité de régler des exceptions. Le système d'options permettait à chaque pair de décrire capacités et exigences.

Leur définition d'une option est décisive : une mise en œuvre qui ne possède pas l'option doit interopérer avec celle qui la possède. Facultatif ne signifiait donc pas seulement « pas obligatoire à programmer ». Le standard devait définir une relation valide entre présence et absence.

Les textes suivants conservaient aussi une unité de réception par défaut de 1 500 octets et laissaient des alternatives aux mises en œuvre consentantes. Les échanges détaillés de LCP appartiennent à une autre histoire. Ici, l'objet est le choix préalable : le refus et le repli faisaient partie du succès.

Quatre preuves à ne pas confondre

On peut tirer une conséquence opérationnelle des documents. La capacité, l'activation locale, l'accord entre pairs et le fonctionnement effectif sont quatre faits distincts.

Une documentation peut prouver que le produit sait compresser. Une configuration peut montrer que l'exploitant l'a demandé. Une négociation achevée peut attester le consentement commun. Des paquets ou des compteurs peuvent enfin démontrer que ce mode a réellement servi. Aucune de ces pièces ne remplace automatiquement les autres.

La séparation vaut pour la liveness et la MTU. Une valeur normative ne prouve pas le réglage vivant. Un keepalive configuré ne prouve pas sa réception. Un voyant link-up ne prouve pas le résultat applicatif. Un accord privé ne prouve pas son déploiement.

Cette grille en quatre étapes est une inférence éditoriale, non une formule littérale de RFC 1547. Elle découle néanmoins d'un protocole qui donne un sens distinct à l'absence, au refus et au repli.

Le minimum protège la décision locale

La doctrine de Heng Lu — Minimum Initial Specification, Localized Future Decision et Voluntary Adoption — fournit un vocabulaire contemporain pour lire cette architecture. Un socle strict établit un ensemble de compatibilité déterministe ; les décisions suivantes restent locales ; la publication seule ne crée pas l'adoption réelle.

Sous cet angle, permettre de couper une option n'affaiblissait pas la norme. Cela renforçait le plancher afin que les choix locaux divergent sans rompre la liaison. Compression, correction d'erreurs et politique de liveness pouvaient évoluer parce qu'un refus conduisait encore à un état valable.

Cette doctrine n'est pas une preuve des intentions subjectives des auteurs de 1989. Ils n'en employaient pas les termes. C'est une comparaison de structure, clairement postérieure.

RFC 1547 établit donc un critère plus fin qu'une histoire de progrès technique : le protocole devait être jugé aussi au moment où un pair disait non. L'option pouvait disparaître ; le pair ne devait pas disparaître avec elle.

Sources