Résumé

  • À l’origine, la RFC 3196 laissait chaque implémentation choisir si elle recevait tout le document avant la réponse finale de Print-Job. L’erratum technique 2924 a supprimé cette latitude : toutes les données doivent être reçues avant cette réponse.
  • La règle vise la réponse IPP finale, en succès comme en erreur. Un 100 Continue HTTP, une erreur de transport anticipée, la création d’un travail et l’impression matérielle restent des événements distincts.

La réponse qui partait avant le document

IPP devait faire de l’impression un service réseau, plutôt qu’un périphérique directement relié à un poste. Le client pouvait soumettre une opération par HTTP ; pour Print-Job, le corps transportait aussi le document. La réponse contenait un statut IPP et, en cas de succès, des identifiants de travail. Mais une question simple se cachait dans cet échange : à quel moment le serveur peut-il annoncer le résultat d’une requête dont le corps est encore en transit ?

La RFC 3196, guide de mise en œuvre IPP/1.1 publié en novembre 2001, répondait d’abord que la réception complète avant la réponse finale dépendait de l’implémentation. En 2011, l’erratum 2924 a remplacé cette phrase : l’imprimante DOIT recevoir toutes les données du document avant de renvoyer la réponse de succès ou d’erreur. Ce n’est pas une nouvelle fonction d’impression. C’est une frontière plus nette pour ce que signifie une réponse finale lorsque la requête comprend un document volumineux.

La distinction est particulièrement utile pour les téléversements en flux. Si l’application annonce le résultat alors que des données restent à envoyer, le client ne sait plus clairement si le document incomplet a été consommé, si un travail existe, ni s’il faut réessayer. L’erratum place cette responsabilité du côté de l’imprimante pour la réponse IPP finale.

Trois signaux qui ne se remplacent pas

Il faut toutefois lire la correction dans son périmètre. 100 Continue est une réponse HTTP provisoire : le client peut poursuivre l’envoi. Elle ne signifie pas que l’opération IPP a réussi. HTTP peut aussi signaler une erreur finale anticipée dans certains cas où la méthode ne sera pas exécutée ; la gestion du corps et de la connexion relève alors du transport. L’erratum ne transforme pas chaque signal précoce en violation.

La réussite de Print-Job ne prouve pas davantage qu’une feuille est sortie. Elle peut fournir un job-id et un job-uri, grâce auxquels le client suivra ensuite l’état du travail. Les RFC 8010 et 8011, publiées en 2017, ont remplacé les RFC 2910 et 2911 et maintiennent cette séparation entre transport HTTP, opération IPP et cycle de vie du travail. Réception du document, acceptation d’un travail, traitement, impression et remise à un utilisateur sont des étapes différentes.

La chronologie documentaire est précise : la RFC 3196 était un guide informatif, pas une nouvelle norme de protocole. L’erratum 2924, signalé par Michael Sweet en août 2011 et vérifié par Peter Saint-Andre en novembre, est classé « Technical » par l’éditeur des RFC. Les textes établissent la correction, pas son adoption par les produits, les pratiques du secteur ou un incident particulier. Il n’existe donc pas ici de récit d’une panne démontrée.

La leçon tient dans une question de preuve : quelle couche a confirmé quoi ? Le début d’un transfert ne prouve pas la réception du document ; un identifiant de travail ne prouve pas la sortie papier. La correction ferme une ambiguïté précise sans prétendre résoudre toutes les autres.

Sources

Les sources documentent une règle et son historique éditorial. Elles ne démontrent ni taux d’adoption, ni performances mesurées, ni comportement d’un produit, ni panne concrète, ni impression matérielle réussie.