Résumé

  • RFC 1318 définit un MIB pour des liaisons matérielles de type imprimante parallèle, notamment Centronics et Data Products, au niveau physique et sous des MIB de services plus élevés.
  • Ses tables de signaux d’entrée et de sortie nomment Power, Online, Busy, PaperOut et Fault ; elles indiquent none, on ou off et peuvent compter les basculements entre on et off.
  • Ces objets établissent une observation ou une assertion de ligne de contrôle. Ils n’établissent ni document, ni décision de file, ni travail accepté, ni page composée, ni exemplaire remis à une personne.

Un vocabulaire familier ne formait pas un récit

Un voyant « papier absent » est utile à qui se trouve devant une machine. Il ne devient pas pour autant une preuve qu’une impression a été interrompue. Il peut concerner une liaison qui ne transporte aucun travail identifiable ; il peut apparaître avant, après ou sans rapport avec une feuille donnée ; il peut être mal interprété par celui qui ignore le matériel. Le gain de RFC 1318 est de ne pas masquer cette distance sous des mots intuitifs.

Le texte ne construit pas un protocole de soumission, de mise en attente ou de restitution. Il définit des objets de gestion pour des dispositifs matériels « parallel-printer-like » et cite les types Centronics, Data Products et des interfaces apparentées. Son emplacement est le niveau physique. Le RFC le situe sous des services tels que le Character MIB ou le PPP MIB : il décrit la connexion sur laquelle d’autres interprétations peuvent s’appuyer, non ces interprétations elles-mêmes.

Cette hiérarchie met fin à une habitude de lecture. Le câble peut être nécessaire à une impression sans être l’auteur de l’impression. Une file peut accepter ou retenir un travail sans que cette décision soit exprimée dans une ligne PaperOut. Un pilote peut fournir des octets sans garantir que le mécanisme ait produit une marque. Une feuille peut sortir sans que le MIB sache son contenu, son destinataire ou le fait qu’elle a été lue. La proximité physique des opérations ne fusionne pas leurs sources de preuve.

La table de port désignait un endroit, pas un usage

Le modèle commence avec une table de ports. Chaque entrée possède un index local, un type de matériel et un nombre de signaux d’entrée ou de sortie représentés. L’index permet au gestionnaire de retrouver une ligne ; il ne nomme ni une imprimante dans un annuaire, ni un étage, ni un service, ni un fichier. Le type donne un cadre matériel. Les comptes de signaux disent quels objets peuvent être parcourus. Rien dans cette entrée ne déclare qu’un travail est présent.

Cette retenue vaut aussi pour l’absence. Les tables d’entrée ne comportent que les signaux détectables par le logiciel. Les tables de sortie ne comportent que les signaux que le logiciel peut affirmer. RFC 1318 ne promet donc pas cinq lignes identiques pour chaque port. Une ligne absente peut signaler qu’une convention ne s’applique pas au matériel, ou que l’agent ne sait pas la détecter ou la piloter. Elle ne signifie pas que le signal observé vaut off.

La distinction paraît fine jusqu’au premier tableau de supervision simplifié. Si celui-ci traduit une ligne PaperOut inexistante par « papier disponible », il a inventé un état. S’il traite une absence de Fault comme une absence de défaut, il a changé une limite de visibilité en conclusion rassurante. Le RFC conserve none, on et off précisément afin de ne pas réduire une interface variable à une réponse binaire imaginaire.

Le nom du signal fixait son objet, non sa portée

Dans les tables, Power, Online, Busy, PaperOut et Fault sont des noms de signaux. Chaque état courant est none, on ou off. Il faut résister à la tentation d’allonger cette énumération en phrases qui ne sont pas dans l’objet.

Power à on ne prouve pas un chemin fonctionnel de bout en bout. Online à on ne prouve pas qu’un document a été offert, accepté ou interprété. Busy à on ne dit ni quel travail provoquerait l’occupation, ni si un progrès mesurable s’accomplit. PaperOut à on ne relie pas le signal à une page, un bac, une commande ou un moment précis. Fault à on n’est ni diagnostic, ni causalité, ni attribution de responsabilité. Les états off n’établissent pas l’inverse : l’absence d’un signal n’équivaut pas à un imprimé réussi.

none impose une prudence supplémentaire. Ce n’est pas un zéro bénin et ce n’est pas le mot « normal ». Dans la représentation de l’agent, c’est la possibilité qu’un signal ne soit pas applicable ou ne soit pas rapporté. Le lecteur qui a besoin d’un fait sur une page doit consulter l’endroit qui possède cette page : le mécanisme d’impression, la file, l’application, l’archive ou le destinataire. Une ligne de contrôle ne gagne pas ces autorités par association de vocabulaire.

Compter un basculement ne comptait aucun travail

Les objets paraInSigChanges et paraOutSigChanges comptent le nombre de passages d’un signal entre on et off, dans les deux sens. Cette mesure est précieuse lorsqu’une ligne oscille : elle rend visible une instabilité, permet de comparer deux périodes et indique où chercher plus loin. Sa précision n’est pas moindre parce que son ambition est limitée.

Mais le compteur ne compte pas des travaux, des documents, des pages ni des destinataires. Dix changements de Busy ne sont pas dix soumissions. Un changement de PaperOut ne révèle pas quelle feuille était engagée avant lui, ni si du papier a ensuite permis une reprise. Un changement de Fault ne consigne pas la cause de la faute ou l’efficacité d’une réparation. Un seul total accumulé ne conserve ni la durée de chaque état, ni l’ordre complet des changements, ni leurs motifs.

Une enquête qui veut employer ce chiffre conserve donc l’heure de lecture, le port, le type matériel, la direction, le nom du signal et des échantillons d’état si la chronologie compte. Elle le rapproche ensuite, sans les remplacer, de journaux de file, de pilote ou d’appareil. Un compteur donne une bonne raison d’ouvrir une question ; il ne referme pas cette question au nom d’un résultat absent de sa définition.

Voir et affirmer étaient deux autorités distinctes

La séparation entre table d’entrée et table de sortie porte aussi sur le pouvoir du logiciel. Un signal d’entrée est ce que l’agent peut détecter sur l’interface. Un signal de sortie est ce que le logiciel peut y affirmer. La symétrie des noms ne rend pas ces deux enregistrements interchangeables.

Une sortie affirmée est une action locale sur une ligne définie. Elle n’établit pas que l’autre matériel a reçu l’intention, l’a interprétée ou a réalisé ce qu’un opérateur espérait. Une entrée détectée est une observation locale. Elle n’établit pas pourquoi le périphérique a produit le signal, comment il est configuré ni ce que la file d’impression a décidé. Confondre les sens revient à prêter une autorité distante à une trace locale.

Cette prudence devient concrète quand plusieurs équipes interviennent : l’une règle un pilote, une autre exploite le dispositif, une troisième tient la file et une quatrième possède le document. Chacune doit fournir le fait qu’elle est en mesure de produire. RFC 1318 ne tranche pas leur récit ; il évite qu’une ligne de câble soit utilisée pour les faire parler d’une seule voix.

Une page imprimée était un fait ultérieur et séparé

Dire que PaperOut a changé sans qu’une page soit encore prouvée ne diminue pas le signal. Cela protège ses usages. Le signal peut être fiable comme observation matérielle. Il devient peu fiable seulement lorsqu’on le transforme en reçu de document. Inversement, une preuve de page peut exister à un autre niveau même si cette ligne particulière n’est pas représentée par le port.

Le bon relevé indique le port et son type, l’origine entrée ou sortie, le signal, l’état, la valeur de compteur, l’agent et l’instant. Une affirmation sur un travail accepté, une page rendue, un exemplaire distribué ou un lecteur exige des traces additionnelles ayant leurs propres propriétaires. La corrélation peut former une explication solide ; la substitution laisse une histoire commode mais sans auteur.

Sources et limites de preuve

Cet article s’appuie sur RFC 1318, Definitions of Managed Objects for Parallel-printer-like Hardware Devices (avril 1992). Il documente le MIB de niveau physique, la table de ports, les tables de signaux d’entrée et de sortie, les limites de détectabilité ou d’assertion, les états none/on/off et les compteurs de transitions. Il ne documente pas une imprimante active, un document, des octets transférés, une soumission ou une acceptation de travail, une page rendue ou imprimée, un contenu sur papier, un destinataire, une réparation ni un résultat applicatif.