Résumé

  • RFC 3510 a donné une adresse absolue aux services IPP et à leurs travaux, tout en reconnaissant que le passage inverse de l’URL du travail à celle de l’imprimante créatrice n’avait pas été défini.
  • L’ajout recommandé d’un segment de chemin facilitait l’interopérabilité ; il n’authentifiait pas le service, ne rendait pas le nom durable et ne prouvait ni l’acceptation du travail ni la sortie d’une feuille.

Une adresse comme ipp://example.com/printer/123 semble presque se commenter elle-même. Le dernier nombre serait le travail, le chemin précédent son imprimante. Il suffirait d’enlever un segment pour reconstruire la filiation. C’est justement cette évidence visuelle que RFC 3510 refuse de transformer en règle.

Publié en avril 2003 dans le Standards Track, le texte développe la section consacrée aux URL IPP dans RFC 2910. Il fixe l’usage du schéma ipp:, le port 631 par défaut, le type application/ipp, l’encodage, la syntaxe et les règles de comparaison. Il ne crée aucun nouveau paramètre d’URL.

Une URL ipp: localise soit un service d’impression parlant IPP, soit une ressource gérée par lui, par exemple un Job. Elle doit être absolue. Elle lie le modèle abstrait de RFC 2911 au transport HTTP défini par RFC 2910 ; un autre transport réclamerait un autre schéma. Le préfixe ne signifie donc pas seulement « impression », mais une combinaison précise de modèle et de transport.

Lorsque le port manque, il vaut 631. Lors de la comparaison, l’absence de port et :631 sont équivalents. Si aucun chemin n’est fourni, la Request-URI devient /. Les requêtes et réponses emploient application/ipp. Ces choix permettent à deux clients de commencer avec les mêmes hypothèses sans confondre deux graphies équivalentes.

Le chemin, en revanche, ne décrit pas le bâtiment. Plusieurs Printer logiques peuvent partager le même hôte. L’un peut représenter un appareil, un autre un spooler d’équilibrage, un troisième un ensemble de machines. Deux files destinées à deux personnes peuvent même fonctionner comme deux Printer indépendantes sur un seul dispositif physique.

Dans IPP, Printer désigne un objet logiciel. Il reçoit des travaux et des opérations, qu’il réside dans un spooler, une passerelle ou l’imprimante physique. Atteindre cet objet ne révèle ni le matériel final, ni une éventuelle redirection, ni la règle humaine de remise. La logique de nommage sépare les services sans rendre transparente la chaîne matérielle.

La difficulté devient explicite avec job-uri. RFC 2911 avait laissé son format exact à l’implémentation. La relation entre le printer-uri envoyé dans Print-Job et le job-uri reçu est donc, elle aussi, dépendante de l’implémentation. RFC 3510 va jusqu’à qualifier de fausse l’ancienne phrase selon laquelle le seul URI du travail permettrait d’identifier le Printer créateur : aucune transformation inverse n’avait été spécifiée.

Le document recommande alors une convention. Un Printer conforme SHOULD produire l’URL du Job en ajoutant exactement un composant au chemin de son URL de Printer. La convention donne une forme prévisible aux logiciels qui l’adoptent. Elle n’autorise pas à traiter chaque URL historique comme si elle obéissait forcément à cette construction. Une recommandation admet des exceptions justifiées, et une passerelle peut conserver un autre espace de noms.

Même dans le cas régulier, la preuve forte reste la paire d’échange. Le client doit garder le printer-uri réellement appelé, le job-uri retourné, l’identité authentifiée du serveur, la réponse et l’heure. Retrancher plus tard un morceau de chaîne apporte moins d’information. Un proxy peut réécrire un chemin ; un service peut recycler un nom. La réponse signée ou authentifiée lie le nom à son émetteur au moment utile.

La durée de vie empêche une autre confusion. RFC 3510 dit que l’URL d’un Job n’est valable et signifiante que jusqu’à l’achèvement du Job, puis éventuellement pendant une durée de persistance choisie par l’implémentation. Ce n’est pas un identifiant d’archive. Une disparition ultérieure peut signifier que l’objet a expiré, non qu’il n’a jamais existé.

La sécurité impose encore d’autres reçus. Une fausse URL peut conduire un document confidentiel vers un service malveillant. L’authentification du serveur traite cette menace. Une vraie URL peut être utilisée par un client non autorisé ; il faut alors authentifier et autoriser le client. La forme du chemin ne tranche aucun de ces deux cas.

Une passerelle IPP vers LPD crée un risque plus radical. RFC 3510 avertit qu’elle peut compromettre silencieusement les protections IPP, sans défense pratique du côté client. La décision appartient donc à l’administrateur, qui devrait éviter cette architecture. Authentifier la façade IPP ne prouve pas que la suite du trajet conserve les mêmes garanties.

L’URL ne contient pas non plus les paramètres du mécanisme d’authentification client ou du niveau de sécurité requis. Un annuaire ou un protocole de découverte peut fournir cette information. Le groupe de travail avait envisagé de nouveaux paramètres, puis les a refusés afin de préserver la compatibilité avec les nombreuses implémentations IPP/1.1 déjà livrées.

La chaîne de preuve doit rester décomposée. L’URL est syntaxiquement correcte ; l’hôte et le port répondent ; l’endpoint parle IPP sur HTTP ; le serveur est bien celui attendu ; le client possède un droit ; le Printer accepte l’opération ; le Job reçoit une URL liée à un émetteur et à une durée ; le traitement atteint un état défini ; un appareil produit une sortie ; le destinataire la reçoit. Chaque étape peut réussir sans garantir la suivante.

Cette lecture rejoint la distinction de Lu Heng entre réalité symbolique et réalité opérationnelle. Le nom normalisé rend un parcours partageable. Le code en service décide quel objet se trouve derrière le chemin, comment les Jobs sont nommés, combien de temps ils subsistent et si une passerelle intervient. La publication d’un RFC n’est ni une mesure d’adoption ni la preuve d’une impression particulière.

RFC 3510 a donc accompli quelque chose de plus sobre que la création d’une preuve universelle. Il a stabilisé l’interface de localisation et consigné la limite. Une URL de Job peut désigner un Job. Sans le contexte de l’échange et la connaissance de l’implémentation, elle ne dit pas quel Printer l’a créé.

Sources