Résumé

  • RFC 3380 traitait une requête Set-Job-Attributes prise en charge comme un nouvel état complet, pas comme une liste de champs que l’imprimante pouvait appliquer en partie.
  • Une valeur non prise en charge ou contradictoire imposait le rejet de toute la requête et la conservation du travail, sans annuler l’impression ni prouver ce qui serait sorti sur papier.

En septembre 2002, l’impression sur Internet gagnait une interface d’administration plus précise. IPP 1.1 permettait de créer et d’interroger des travaux, mais un utilisateur ou un opérateur pouvait découvrir après l’envoi qu’il manquait une finition. RFC 3380 proposait, de manière facultative, de modifier les attributs du travail existant plutôt que de l’annuler et de le soumettre à nouveau.

Cette facilité avait une limite nette. L’imprimante devait évaluer les attributs proposés avec ceux que le client ne modifiait pas. RFC 3380 posait une question contrefactuelle : un nouveau travail doté de cet ensemble complet aurait-il été accepté avec ipp-attribute-fidelity=true ? Si oui, la modification devait être acceptée. Sinon, elle devait être rejetée et le travail existant rester inchangé. Un attribut inconnu, une valeur impossible à définir ou un conflit avec un autre attribut ne pouvait pas être « sauvé » en appliquant seulement les champs faciles. La requête était indivisible.

La règle allait au-delà d’un message d’erreur commode : elle empêchait le client de prendre un travail partiellement modifié pour l’état qu’il avait demandé. La réponse pouvait désigner les attributs invalides tandis que l’objet Job restait dans son état précédent. L’autorisation constituait une vérification distincte : le demandeur authentifié devait être le propriétaire du travail, un opérateur ou un administrateur. Le droit de demander ne rendait pas valide une combinaison incorrecte.

Le même document rendait atomiques les modifications de configuration de l’imprimante et ajoutait Get-Printer-Supported-Values pour découvrir les valeurs acceptées pour certains attributs modifiables. Il permettait aussi à printer-xri-supported de mettre à jour ensemble des descriptions liées d’URI, d’authentification et de sécurité. Mais les opérations Set demeuraient facultatives. La norme décrit un contrat de transition ; elle ne prouve ni la prise en charge par une imprimante donnée, ni l’usage par un client, ni l’arrivée d’une feuille imprimée.

La distinction est importante à côté de RFC 3196. Son erratum vérifié porte sur le moment où l’imprimante peut renvoyer une réponse finale après réception des données du document. RFC 3380 porte sur la modification des attributs d’un travail. Une mise à jour acceptée ou rejetée ne dit pas si le document a été reçu, traité ou imprimé. L’événement de protocole constate un changement d’état, pas un résultat dans la salle d’impression.

Textes primaires : RFC 3380, modèle et sémantique IPP/1.1, RFC 2911 et RFC 3196. RFC 3380 était une extension facultative ; ces textes établissent le contrat, pas son déploiement ni son interopérabilité.

Sources