Résumé

  • RFC 1179 documentait LPD comme pratique existante : un daemon TCP sur le port 515 recevait des commandes pour une file d’impression nommée, dont une commande lançant les travaux en attente.
  • Pendant Receive job, un premier accusé concernait le sous-ordre de fichier; le client signalait ensuite la fin des octets annoncés par un zéro, puis attendait un second accusé. Cette séquence ne certifiait pas l’impression.

Trois verbes, trois surfaces

La demande d’impression traverse des moments qui n’appartiennent pas au même acteur. Le client soumet. Le daemon reçoit et range. Un processus de file démarre ou reste inactif. Un interpréteur lit un fichier de contrôle puis un fichier de données. Enfin, un périphérique peut rendre une page. Lorsque tous ces verbes deviennent « imprimé », l’état paraît simple mais perd son objet.

Publié en août 1990, RFC 1179 ne prétendait pas normaliser l’avenir de l’impression. Le texte, de statut informationnel, décrivait un protocole de serveur d’impression existant et largement employé sur l’Internet. Cette retenue importe : LPD décrit des commandes, des formats et des réponses du daemon; il ne transforme pas une conversation réseau en observation de l’objet physique.

LPD s’appuyait sur TCP, le daemon écoutant le port 515. Toute commande ouvrait une nouvelle connexion. Un code binaire était suivi du nom ASCII de la file, puis éventuellement d’autres opérandes. Ce message n’était pas le résultat de l’opération. RFC 1179 demande de lire le nom des commandes comme une instruction adressée au daemon. Une instruction et son effet ne sont pas la même pièce de preuve.

La commande « Print any waiting jobs » le montre sans ambiguïté : elle lance le processus d’impression s’il ne tourne pas déjà. Elle ne dit pas quel travail sera choisi, que les données sont interprétables, que le papier est disponible ou qu’une page est sortie. La commande de démarrage appartient à un autre stade que la réception d’un fichier.

La réception avait deux réponses distinctes

Après l’ordre Receive job, le client pouvait envoyer un sous-ordre de fichier de contrôle ou de données. Après chaque sous-ordre, il devait attendre l’accusé du daemon. Un octet composé de zéros était positif; toute autre valeur était négative. Cette réponse concernait l’acceptation de l’étape suivante de l’échange, pas la finalité du travail.

Le fichier introduisait une frontière supplémentaire. Le sous-ordre donnait un nombre d’octets et un nom. Le client écrivait alors ce nombre d’octets sur la même connexion. Une fois cette quantité remise, il envoyait un octet zéro pour indiquer que le fichier transmis était complet; un second niveau d’accusé devait alors intervenir. Pour un fichier de données dont la longueur était fournie, la même discipline s’appliquait.

La chronologie est volontairement plus précise que le mot « upload ». Le premier accusé porte sur le sous-ordre. Le zéro du client est une déclaration sur l’achèvement de la séquence annoncée. Le second accusé est la réponse du daemon à cette frontière. Ces faits peuvent être reliés; aucun ne doit être élargi en constat d’impression.

Le nombre d’octets ne donne pas davantage le sens du document. RFC 1179 précise que le contenu du fichier de données est interprété à partir du fichier de contrôle correspondant. Les données peuvent contenir n’importe quelles valeurs sur huit bits. Leur quantité n’établit ni leur format utile, ni leur rendu, ni le sort de la page demandée.

Le contrôle ne devenait pas une identité vérifiée

Les lignes du fichier de contrôle pouvaient porter un hôte, un identifiant d’utilisateur, un nom de fichier, un format ou une demande de courrier après impression. Elles donnaient au daemon des instructions pour traiter des données. Elles n’étaient pas une biographie authentifiée de leur auteur ni un journal de conservation du document. Un numéro de travail restait un identifiant dans le modèle borné du protocole, non une identité globale durable.

La gestion de file conserve la même limite. LPD pouvait renvoyer un état court ou long et recevoir une commande de suppression comprenant une file, un agent et une liste de numéros ou de noms. RFC 1179 restreignait notamment la suppression des travaux d’autrui pour un agent autre que root. Cette règle règle une commande locale; elle ne prouve pas qui possédait le document, qui l’a consulté ou qui pouvait recevoir la sortie.

Ce que RFC 1179 offre est plus solide qu’un message de succès vague. Elle permet de dire exactement : le daemon a accepté ce sous-ordre; le client a déclaré telle séquence achevée; le daemon a répondu après cette déclaration; une commande a demandé le démarrage de la file. Pour dire qu’une page a été rendue, récupérée ou utilisée, il faut une observation d’un autre maillon.

Sources