Groupe de travail Réseau T. Hastings, Ed.Request for Comments : 3997 Xerox CorporationCatégorie : Information R. K. deBryMars 2005 Utah Valley State College H. Lewis IBM Corporation Protocole d’impression Internet (IPP) : Prescriptions pour les notifications IPP
Statut du présent Mémo
Le présent mémo apporte des informations pour la communauté de l’Internet. Il ne spécifie en aucune façon une norme Internet. La distribution du présent mémo n’est pas soumise à restrictions. Déclaration de copyright
Copyright (C) The Internet Society (2005).
Résumé
Le présent document fait partie d’un ensemble qui décrit tous les aspects du protocole d’impression sur Internet (PPP, Internet Printing Protocol). IPP est un protocole de niveau application qui peut être utilisé pour de l’impression distribuée sur l’Internet. IPP comporte de nombreuses parties, mais les principaux composants architecturaux sont le modèle, le protocole et une interface avec les services d’annuaire. Le présent document fournit une explication des exigences pour les notifications en tant que partie facultative d’un service IPP. Table des matières
2.1 Utilisateur final soumettant
une tâche
2.4. Application de soumission de
tâche
2.8 Mandataire de récepteur de
tâche
2.11 Récepteur de notification
2.12 Agent récepteur de notification
2.15 Abonnement de notification
2.16 Attributs de notification
2.17 Méthode de livraison de
notification (ou en abrégé Méthode de livraison)
2.19 Notification à transmission
différée
2.20 Notifications à livraison
fiable
2.21 Notification sur transport non
fiable
2.22 Notification à destination
humaine
2.23 Notification à destination
machine
5. Considérations sur la sécurité
pour les prescriptions sur les notifications IPP
6. Considérations sur
l’internationalisation
9. Appendice A : Description des
documents IPP de base
Le présent document fait partie d’un ensemble qui décrit tous les aspects du protocole d’impression sur Internet (IPP, Internet Printing Protocol). IPP est un protocole de niveau application qui peut être utilisé pour de l’impression distribuée sur l’Internet. IPP comporte de nombreuses parties, mais les principaux composants architecturaux sont le modèle, le protocole et une interface avec les services d’annuaire. Le présent document fournit une explication des exigences pour les notifications en tant que partie facultative d’un service IPP.Voir à la section 10 la description des documents IPP de base. La portée du présent document de prescriptions couvre les fonctionnalités utilisées par les types d’utilisateurs IPP suivants : utilisateurs finaux, administrateurs d’imprimante, et opérateurs. Voir à la [RFC3995] les extensions au protocole 1.0 d’impression sur Internet (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], [RFC2910], et les versions futures. Il est nécessaire de définir un ensemble de termes pour être capable d’exprimer clairement les prescriptions pour les services de notification dans un système IPP. Utilisateur final humain qui soumet une tâche d’impression à une imprimante IPP. Cette personne peut être ou n’être pas au sein du même domaine de sécurité que l’imprimante. Elle peut être géographiquement proche de l’imprimante ou non.
Utilisateur humain qui a établi la politique pour le système d’impression et le configure.
Utilisateur humain qui transporte la politique établie par l’administrateur et contrôle le fonctionnement quotidien du système d’impression.
Application (par exemple, une application par lots) agissant au nom d’un utilisateur final soumettant une tâche, qui soumet une tâche d’impression à une imprimante IPP. L’application peut être ou non au sein du même domaine de sécurité que l’imprimante. Cette application peut être géographiquement proche de l’imprimante ou non.
Pour les besoins de cette discussion, ensemble des composants de réseau qui peuvent communiquer sans passer par un mandataire ou pare-feu. Un domaine de sécurité peut être géographiquement très grand ; par exemple, n’importe où au sein de example.com.
Composant logiciel qui envoie les demandes IPP à un objet imprimante IPP et accepte les réponses IPP venant d’une imprimante IPP.
Humain qui est le consommateur ultime du travail d’impression. Dans de nombreux cas, ce sera la même personne que l’utilisateur final soumettant la tâche, mais ce n’est pas forcément le cas. Par exemple, si j’utilise IPP pour imprimer un document sur une imprimante du bureau d’une relation d’affaire, je suis l’utilisateur final soumettant la tâche, et la personne à qui je destine le document dans le bureau de ma relation d’affaire est le récepteur de tâche. Dans la mesure où le but d’IPP est d’être capable d’imprimer près du récepteur de tâche, on s’attend normalement à ce que cette personne soit dans le même domaine de sécurité que l’imprimante, géographiquement proche. Cependant, cela peut n’être pas toujours le cas. Par exemple, je soumets une tâche d’impression à travers l’Internet à la boutique d’impression XYZ. Je suis à la fois l’utilisateur final soumettant la tâche et le récepteur de tâche, mais ne suis ni près ni dans le même domaine de sécurité que l’imprimante.
Personne agissant au nom du récepteur de tâche. Le mandataire du récepteur de tâche ramasse physiquement le document imprimé sur l’imprimante si le récepteur de tâche ne peut le faire. Le mandataire est par définition géographiquement proche et dans le même domaine de sécurité que l’imprimante. Par exemple, je soumets de chez moi une tâche d’impression à effectuer sur une imprimante à mon lieu de travail. J’aimerais que ma secrétaire ramasse le document imprimé et le mette sur mon bureau. Dans ce cas, j’agis à la fois comme utilisateur final soumettant la tâche et comme récepteur de tâche. Ma secrétaire agit comme mandataire du récepteur de tâche.
Client qui demande à l’imprimante IPP d’envoyer des notifications d’événement à un ou plusieurs récepteurs de notification. Un abonné de notification peut être un utilisateur final soumettant la tâche ou un utilisateur final, un opérateur, ou un administrateur qui ne soumet pas de tâche.
Entité qui envoie des notifications d’événement.
Entité qui reçoit des notifications IPP au sujet d’événements de tâche et/ou d’imprimante. Un récepteur de notification peut être un utilisateur final soumettant la tâche, une application soumettant une tâche, un récepteur de tâche, un mandataire de récepteur de tâche, un opérateur, un administrateur, etc., son représentant, un fichier d’enregistrement, une application collectant des statistiques d’utilisation, ou d’autres entités actives ou passives.
Programme qui reçoit les notifications d’événement au nom du récepteur de notification. L’agent peut effectuer certaines actions au nom du récepteur, transmettre la notification au récepteur via certains moyens de remplacement (par exemple, localiser le récepteur), ou mettre la notification en file d’attente pour une restitution ultérieure au récepteur.
Un événement est une occurrence (attendue ou inattendue) d’un changement d’état, de condition ou de configuration d’un objet tâche ou imprimante au sein du système d’impression.
Lorsque survient un événement, une notification d’événement est générée qui décrit pleinement l’événement (ce qu’était l’événement, où il est arrivé, quand il est arrivé, etc.). Les notifications d’événement sont délivrées à tous les récepteurs de notification qui sont abonnés à cet événement, s’il en est. La notification d’événement est délivrée à l’adresse du récepteur de notification en utilisant la méthode de livraison de notification définie dans l’abonnement. Cependant, une notification d’événement n’est envoyée QUE SI il y a un abonnement correspondant. Un abonnement de notification est une demande faite par une abonné de notification à l’imprimante IPP d’envoyer des notifications d’événement au ou aux récepteurs de notification spécifiés quand survient un événement.
Les objets IPP (par exemple, une tâche d’impression) à partir desquels les notifications sont envoyées peuvent avoir des attributs associés. Un utilisateur peut vouloir en avoir un ou plusieurs retournés en accompagnement d’une notification particulière. En général, cela peut inclure tout attribut associé à l’objet qui émet la notification. A titre d’exemples :
nombre
de tâches intervenantes
job-k-octets
job-k-octets
traité
tâches
d’impressions
tâches
d’impressions interprétées
tâches
d’impressions terminées
copies
en cours d’impressions terminées (MIB de tâche)
numéro
de copie de feuille terminée (MIB de tâche)
numéro
de document de feuilles terminées (MIB de tâche)
copies
demandées
type
de copie
destination
de sortie
causes
de l’état de tâche
ID de
tâche
URI
d’imprimante
ID
d’abonnement (pour un abonnement indépendant de la tâche)
Les notifications d’événement sont délivrées en utilisant une méthode de livraison. Un exemple de méthode de livraison est la messagerie électronique.
Notifications envoyées au récepteur de notification ou à l’agent du récepteur de notification de telle sorte que la notification arrive immédiatement, dans les limites normales d’adressage, d’acheminement, d’encombrement du réseau et de qualité de service.
Notifications qui ne sont pas nécessairement délivrées immédiatement au récepteur de notification mais sont mises en file d’attente pour livraison par une application réseau intermédiaire, pour restitution ultérieure. La messagerie électronique est un exemple de méthode de livraison de notification à transmission différée.
Notifications qui sont délivrées par un flux de livraison de paquets ou de caractères fiable, avec accusé de réception et réessai, de sorte que la livraison de la notification soit garantie dans des limites de temps déterminées. Par exemple, si le récepteur de notification s’est déconnecté et est rentré chez lui pour la journée, une notification immédiate ne peut être garantie, même envoyée sur un transport fiable, parce qu’il n’y a rien pour la recevoir. La livraison garantie exige à la fois une notification à transmission différée et un transport fiable.
Les notifications sont délivrées via l’adresse de transport fondamentale et le cadre d’acheminement, mais aucun accusé de réception ni réessai n’est exigé. Les communications de traitement à traitement, s’il en est d’impliquées, sont sans contrainte.
Notifications destinées uniquement à l’usage des utilisateurs finaux humains. La messagerie électronique serait un exemple de notification à destination humaine, bien qu’elle puisse aussi contenir des notifications à destination machine.
Notifications destinées uniquement à l’usage d’un programme, tel qu’un client IPP. Les notifications à destination machine peuvent ne pas contenir d’informations lisibles par l’homme. A-t on besoin à la fois de l’homme et de la machine ? Ce qui est à destination machine est destiné uniquement à l’inter-applications. Le récepteur de notification pourrait traiter la notification d’événement à destination machine pour la passer en format lisible par l’homme.
Une notification mixte contient à la fois des informations à destination humaine et à destination machine. 1. Assis dans mon bureau, je soumets une tâche d’impression à l’imprimante du couloir. Je suis dans le même domaine de sécurité que l’imprimante, et, bien sûr, géographiquement proche. Je veux savoir immédiatement quand ma tâche d’impression sera terminée (ou s’il y a un problème) parce que le document sur lequel je travaille est urgent. Je soumets la tâche d’impression avec les attributs suivants :
- récepteur de notification : moi
- événements de notification : tous
- attributs de notification : causes d’état de tâche
- type de notification : immédiate
2. Travaillant depuis chez moi, je soumets une tâche d’impression à la même imprimante que dans l’exemple précédent. Cependant, je ne suis pas au bureau, je ne peux pas obtenir physiquement le dossier d’impression ou en faire quoi que ce soit. Il peut attendre jusqu’à ce que j’aille au bureau cet après midi. Cependant, j’aimerais que ma secrétaire prenne la sortie de l’imprimante et la mette sur mon bureau de façon qu’elle ne soit pas perdue ou déclassée. J’aimerais aussi qu’une notification en différé soit envoyée à ma messagerie électronique de façon que quand j’arriverai au bureau, je puisse dire s’il y a eu un problème avec mon travail d’impression. Je soumets une tâche d’impression avec les attributs suivants :
- récepteur de notification : ma secrétaire
- événements de notification : impression terminée
- type de notification : immédiate
- récepteur de notification : moi
- événements de notification : impression terminée
- attributs de notification : impressions terminées
- type de notification : en différé
3. Assis à mon bureau, je soumets une tâche d’impression à un client d’une compagnie d’ingénierie avec laquelle travaille quotidiennement mon entreprise. La compagnie d’ingénierie est en Belgique. J’aimerais que mon client sache quand l’impression est terminée afin qu’il puisse la prendre sur l’imprimante dans ses locaux. Il est important qu’il puisse le relire tout de suite et me renvoie ses commentaires. Je soumets la tâche d’impression avec les attributs suivants :
- récepteur
de notification :
client à la compagnie d’ingénierie
- événements
de notification :
impression terminée
- type
de notification :
immédiate
- langue de notification : français
4. D’une chambre d’hôtel, j’envoie une tâche d’impression à un magasin Kinko, dans la ville où je travaille, afin d’obtenir l’impression d’un rapport pour la réunion à laquelle j’ai participé ce matin. Comme je sors pour dîner après avoir soumis cette tâche, une notification immédiate me laisse froid. Cependant, j’aimerais vérifier dans la matinée avant d’aller au magasin Kinko pour savoir si le fichier a été imprimé. Une notification par message électronique est suffisante pour cela. Je soumets la tâche d’impression avec les attributs suivants :
- récepteur
de notification :
moi
- événements
de notification :
impression terminée
- type
de notification :
en différé
5. J’imprime un gros fichier complexe. Je veux avoir un retour immédiat sur la progression de la tâche d’impression en cours. Je soumets la tâche d’impression avec les attributs suivants :
- récepteur
de notification :
moi
- type
de notification :
immédiate
- événements
de notification :
toutes transitions d’état
- attributs de notification : impression
terminée
6. Je suis un opérateur et une de mes tâches est de maintenir l’imprimante en fonction. Je m’abonne indépendamment d’une soumission de tâche de sorte que ma souscription dure plus longtemps que toute tâche particulière. Je m’abonne avec les attributs suivants :
- récepteur de
notification : moi
- type de notification : immédiate
- événements de
notification : toutes
transitions d’état de l’imprimante
- attributs de notification : états de l’imprimante, causes
d’état de l’imprimante, mise sous tension de l’appareil, mise hors tension de
l’appareil.
7. Je suis une application de collecte de statistiques d’utilisation. Je m’abonne indépendamment d’une soumission de tâche de sorte que mon abonnement dure plus longtemps que toute tâche particulière. Mon abonnement peut persister pendant plusieurs cycles d’alimentation. Je m’abonne avec les attributs suivants :
- récepteur de
notification : moi
- type de notification : immédiate
- événements de
notification : tâche
terminée
- attributs de notification : Impression terminée, feuilles
terminées, heure de soumission, heure de début, heure de fin, propriétaire de
la tâche, taille de la tâche en octets, etc.
8. Je suis un programme d’application client qui affiche une liste des tâches actuellement en file d’attente d’impression sur une imprimante. J’affiche le "nom de tâche", "état de tâche", "causes d’état de tâche", "compte de pages", et "tâches à intervenir", pour les tâches de l’utilisateur ou pour toutes les tâches. La fenêtre d’affichage de la liste des tâches reste ouverte pendant une durée indépendante, et il est souhaité qu’elle représente l’état en cours de la file d’attente. Il est souhaité que l’application n’effectue qu’une interrogation lente afin de récupérer toute notification manquée. Ainsi, le mécanisme de délivrance d’événement donne les moyens de mettre à jour l’écran sur tous les changements nécessaires, y compris de demander des attributs qui pourraient n’être pas délivrés dans la notification. 9. Je suis un programme d’application client qui affiche une liste des imprimantes. Pour chaque imprimante, j’affiche l’état et la configuration en cours. La fenêtre affichant la liste d’imprimante reste ouverte pendant une durée indépendante, et il est souhaité qu’elle représente l’état en cours de chaque imprimante. Il est souhaité que l’application ait seulement besoin d’effectuer une interrogation lente afin de récupérer toute notification manquée. Ainsi, le mécanisme de délivrance d’événement donne les moyens de mettre l’écran à jour sur tous les changements nécessaires, y compris de demander des attributs qui pourraient n’être pas délivrés dans la notification. 10. Je suis un serveur IPP qui contrôle un ou plusieurs appareils et qui met en œuvre un objet imprimante IPP pour représenter chaque appareil. Je veux prendre en charge la notification IPP pour chaque objet imprimante IPP que je mets en œuvre. Beaucoup de ces appareils ne prennent pas en charge la notification (ou IPP). J’ai donc besoin de prendre en charge moi-même la sémantique de notification IPP spécifiée pour chaque objet imprimante IPP au nom de chacun des appareils que représente chacun des objets imprimante IPP. Lorsque j’accepte une demande de création de tâche IPP, je la convertis en ce que l’appareil va accepter. Dans certains cas, je dois interroger les appareils afin d’être informé de leur tâche, de l’état de l’appareil, et des changements d’état, pour être capable d’envoyer les notifications IPP aux récepteurs de notification abonnés. 11. Je suis un serveur IPP qui contrôle un ou plusieurs appareils et qui met en œuvre un objet imprimante IPP pour représenter chaque appareil. Je veux prendre en charge la notification IPP pour chaque objet imprimante IPP que je mets en œuvre. Ces appareils acceptent tous IPP, y compris la notification IPP. Je voudrais que le choix par défaut pour la prise en charge de la notification IPP pour ces objets soit (1) par transmission de la notification aux imprimantes IPP qui sont sous mon seul contrôle et les voir envoyer les notifications aux récepteurs de notification prévus sans que j’y sois impliqué, ou (2) en remplacent la notification soumise avec la tâche pour m’indiquer comme récepteur de notification ; à mon tour, je vais transmettre les notifications demandées par mes clients aux récepteurs de notification. La plus grande partie du reste du contenu de la tâche IPP que j’envoie aux imprimantes IPP que je contrôle sera la même que ce que je reçois de mes clients IPP. 12. Je suis un serveur IPP qui contrôle un ou plusieurs appareils et qui met en œuvre un objet imprimante IPP pour représenter chaque appareil. Je veux prendre en charge la notification IPP pour chaque objet imprimante IPP que je mets en œuvre. Ces appareils acceptent tous IPP, y compris la notification IPP. Comme ces imprimantes IPP PEUVENT aussi être contrôlées par d’autres serveurs (en utilisant IPP ou d’autres protocoles), je veux seulement les événements de tâche pour les tâches que j’ai envoyées, mais je veux tout le temps les événements d’imprimante, de sorte que je puisse indiquer l’état d’imprimante approprié à mes clients. Donc je souscris à ces imprimantes IPP pour les événements d’imprimante avec un abonnement à long terme, avec moi-même comme récepteur de notification. Lorsque j’obtiens une demande de création de tâche, je décide à quelle imprimante IPP envoyer le travail. Lorsque je fais ainsi, j’ajoute aussi un abonnement de tâche pour les événements de tâche, avec moi-même comme récepteur de notification pour les abonnements de tâche des tâches fournies par mes clients (cette utilisation est appelée "portage"). Ces imprimantes IPP retirent automatiquement leurs abonnements de tâche lorsque la tâche se termine, de même que pour tous les abonnements de tâche, de sorte que je n’obtiens plus d’événement de tâche lorsque mes tâches sont terminées. Les prescriptions suivantes sont destinées à être satisfaites par la spécification de notification IPP (et non par la mise en œuvre). Ce qui suit est vrai pour le document de spécification de notification IPP qui en résulte : 1. Il doit indiquer lesquelles de ces prescriptions sont EXIGÉES et lesquelles sont FACULTATIVES pour une mise en œuvre conforme à la prise en charge. Voir au paragraphe 12.1 de la [RFC2911] la définition de ces importants termes de conformité. 2. Il doit être conçu de sorte qu’une imprimante IPP puisse prendre en charge de façon transparente la sémantique de notification IPP en utilisant les services de notification par un tiers qui existent aujourd’hui ou qui pourraient être normalisés à l’avenir. 3. Il doit définir pour un utilisateur final qui soumet une tâche les moyens de spécifier zéro ou plusieurs récepteurs de notification lorsqu’il soumet une tâche d’impression. Un soumissionnaire ne pourra pas empêcher les abonnements hors bande de personnes autorisées, telles que les opérateurs. 4. Il doit définir les moyens, lorsqu’il spécifie un récepteur de notification, pour un abonné à la notification, de spécifier un ou plusieurs événements de notification pour ce récepteur de notification, sous réserve des contraintes administratives et de politique de sécurité. Tout ce qui suit constitue des événements de tâche ou d’imprimante pour lesquels un utilisateur final qui soumet une tâche peut spécifier que des notifications soient envoyées :
- toute alerte standard MIB d’imprimante
- tâche reçue (transition de Inconnu à En instance)
- tâche commencée (transition de En instance à En cours)
- Page terminée (la page est mise en pile)
- copie colligée terminée (la dernière feuille de la copie colligée
est mise en pile)
- tâche terminée (transition de En cours ou Fin de traitement à
Terminé)
- tâche avortée (transition de En instance, Maintien en instance,
En cours, ou Arrêt de traitement à Avorté)
- Tâche annulée (transition de En instance, Maintien en instance,
En cours ou Maintien en cours à Annulé)
- Autres changements d’état de tâche, tels que pause, purge
- Problèmes de l’appareil auquel la tâche est destinée
- Problèmes de tâche (interprète)
5. Il doit définir comment s’abonne un utilisateur final ou opérateur pour
- tout ensemble d’événements de tâche pour
une tâche spécifique, ou
- tout ensemble d’événement d’imprimante
alors qu’une tâche spécifique n’est pas terminée.
6. Il doit définir comment un utilisateur final ou opérateur s’abonne pour ce qui suit sans avoir à soumettre une tâche :
- tout ensemble d’événements d’imprimante
pour une période déterminée.
- tout ensemble d’événements de tâche pour
toutes tâches, sans contrôle sur ces tâches.
7. Il doit définir comment l’abonné à la notification peut spécifier la notation immédiate ou en différé indépendamment pour chaque récepteur de notification. Le moyen peut être explicite, ou impliqué par la méthode de livraison choisie par l’utilisateur final qui soumet la tâche. 8. Il doit définir les méthodes communes de livraison : par exemple, messagerie électronique. 9. Il doit définir comment une imprimante IPP valide sa capacité à délivrer un événement en utilisant le schéma de livraison spécifié. S’il ne prend pas en charge le schéma spécifié, ou si le schéma spécifié est invalide pour une raison quelconque, l’imprimante IPP accepte alors et effectue de toutes façons la demande et indique les valeurs d’attribut non prises en charge. Il n’est pas exigé que l’imprimante IPP qui reçoit la demande d’impression valide l’identité d’un récepteur de notification, ou la capacité du système à délivrer en événement à ce récepteur, comme demandé (par exemple, si le récepteur de notification ne travaille pas ce jour là). 10. Il doit définir une classe de méthodes de livraison de notification d’événement IPP qui puisse traverser les pare-feu des entreprises. Cependant, une imprimante IPP n’a pas besoin de garantir la livraison de la notification à travers un pare-feu avant d’accepter une tâche d’impression. 11. Il peut définir un moyen de délivrer une notification au client soumettant lorsque la livraison d’une notification d’événement à un récepteur de notification spécifié échoue. Il peut être fourni un moyen de secours des abonnés pour déterminer si les notifications ont échoué (c’est-à-dire, par interrogation). 12. Il doit définir un mécanisme pour que la source de notification localise les notifications à destination humaine. 13. Il peut définir une façon de spécifier si la livraison d’événement requiert qu’un accusé de réception soit renvoyé à la source de notification. 14. Il doit y avoir un mécanisme défini pour empêcher la péremption des souscriptions indépendantes des tâches et que leur retrait n’exige pas d’intervention humaine. Cependant, un abonnement ne doit pas être réputé périmé seulement s’il est incapable de délivrer une notification d’événement, car des problèmes temporaires de délivrance de notification doivent être tolérés. 15. Il doit être défini un mécanisme par lequel un abonné à événement soit capable d’ajouter un abonnement d’événement à une tâche après la soumission de la tâche. 16. Il doit être défini un mécanisme par lequel un client soit capable d’annuler un abonnement d’événement sur une tâche ou imprimante après que la tâche ait été soumise. 17. Il doit être défini un mécanisme par lequel un client puisse obtenir l’ensemble des abonnements en cours. Le plus gros problème de sécurité est de loin l’abus de notification : l’envoi de notifications non désirées à des tiers (c’est-à-dire le spam). Le problème est empiré par les adresses de notification qui peuvent être redistribuées à plusieurs parties (par exemple, sur des listes de diffusion). Il existe des scénarios dans lesquels la notification à un tiers est exigée (voir les scénarios 2 et 3). La solution entièrement sécurisée exigerait un accord actif de tous les récepteurs avant que quoi que ce soit ne soit envoyé. Cependant, la prescription 9 ("Il n’est pas exigé que l’imprimante IPP qui reçoit la demande d’impression valide l’identité d’un récepteur d’événement") milite contre cela. Certains systèmes peuvent décider d’interdire les notifications à tierce partie (modèle de télécopie traditionnel). Les mêmes problèmes de sécurité se présentent lorsque les clients soumettent des demandes de notification à l’imprimante IPP lorsqu’ils soumettent une demande de tâche d’impression IPP/1.1. Le même mécanisme qu’utilisé par IPP/1.1 peut donc être utilisé par la soumission de notification client. Les opérations qui requièrent l’authentification peuvent utiliser l’authentification HTTP. Les opérations qui requièrent la confidentialité peuvent utiliser la confidentialité HTTP/TLS. Le modèle de contrôle d’accès à la notification devrait être similaire au modèle de contrôle d’accès IPP. La création d’un abonnement à la notification est associée à un usager. Seul le créateur ou un opérateur peut annuler l’abonnement. Le système peut limiter la liste des éléments à ceux qui sont la propriété de l’usager. Certains abonnements (par exemple, ceux qui ont une durée de vie plus longue qu’une tâche) ne peuvent être faits que par des usagers privilégiés (opérateurs et/ou administrateurs), si c’est la politique d’autorisation. Les problèmes de sécurité standard (livraison au bon usager, confidentialité du contenu, contenu non altéré) s’appliquent à la livraison de notification. IPP devrait utiliser les mécanismes de sécurité de la méthode de livraison utilisée. Certains mécanismes de livraison sont plus sécurisés que d’autres. Des notifications intelligentes devraient donc utiliser la méthode de livraison qui a la meilleure sécurité. La notification à destination humaine doit être localisée dans le langage naturel et le charset que l’abonné à la notification spécifie à l’intérieur du choix des langages naturels et charsets qu’accepte l’imprimante IPP. La notification à destination machine utilise le type de support MIME "application/ipp". Il contient des attributs dont il est nécessaire que les valeurs de texte soient dans le langage naturel et le charset spécifiés par l’abonné à la notification à l’intérieur du choix de langages naturels et de charsets acceptés par l’imprimante IPP. Voir la [RFC2566]. Certaines méthodes de délivrance de notification ont été enregistrées auprès de l’IANA pour être utilisées dans les URL. Elles seront définies dans d’autres documents. [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., et J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport"(Protocole /1.1 d’impression sur Internet : codage et transport), RFC 2910, septembre 2000. [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., et P. Powell, "Internet Printing Protocol/1.1: Model and Semantics"(Protocole /1.1 d’impression sur Internet : modèle et sémantique), RFC 2911, septembre 2000. [RFC3995] Herriot, R. et T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions"(Protocole d’impression sur Internet (IPP) : notifications d’événement et abonnement), RFC 3995, mars 2005. [RFC2565] Herriot, R., Butler, S., Moore, P., et R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport"(Protocole /1.0 d’impression sur Internet : codage et transport), RFC 2565, avril 1999. [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., et P. Powell, "Internet Printing Protocol/1.0: Model and Semantics"(Protocole /1.0 d’impression sur Internet : modèle et sémantique), RFC 2566, avril 1999. [RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol"(Objectifs de conception pour un protocole d’impression sur Internet), RFC 2567, avril 1999. [RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol" (Arguments pour la structure, le modèle et le protocole du Protocole d’impression sur Internet), RFC 568, avril 1999. [RFC2569] Herriot, R., Hastings, T., Jacobs, N., et J. Martin, "Mapping between LPD and IPP Protocols" (Transposition entre les protocoles LPD et IPP), RFC 2569, avril 1999. [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C.,et H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide" (Protocole /1.1 d’impression sur Internet : Guide de mise en oeuvre), RFC 3196, novembre 2001. L’ensemble de base des documents IPP comporte :
Objectifs de conception pour un protocole d’impression sur Internet [RFC2567]
Fondements de la structure, modèle et protocole du protocole d’impression sur Internet [RFC2568]
Protocole/1.1 d’impression sur Internet : Modèle et sémantique [RFC2911]
Protocole/1.1 d’impression sur Internet : Codage et transport [RFC2910]
Protocole/1.1 d’impression sur Internet : Guide de mise en œuvre [RFC3196]
Transposition entre les protocoles LPD et IPP [RFC2569]
Le document "Objectifs de conception pour un protocole d’impression sur Internet" porte un vaste regard sur la fonction d’impression distribuée, et énumère des scénarios réels qui aident à clarifier les caractéristiques qu’il est nécessaire d’inclure dans un protocole d’impression pour l’Internet. Il identifie les exigences pour trois types d’utilisateurs : utilisateur final, opérateur, et administrateur. Il fait intervenir un sous ensemble d’exigences d’utilisateur final qui sont satisfaites dans IPP/1.0 [RFC2566, RFC2565]. Quelques opérations d’opérateur FACULTATIVES ont été ajoutées à IPP/1.1 [RFC2911, RFC2910].
Le document "Fondements de la structure, modèle et protocole du protocole d’impression sur Internet" décrit IPP d’un point de vue plus élevé et définit la mission des divers documents qui forment la série des documents de spécification d’IPP. Il donne les fondements des décisions majeures du groupe de travail IPP de l’IETF.
Le document "Protocole/1.1 d’impression sur Internet : Modèle et sémantique" décrit un modèle simplifié avec des objets abstraits, leurs attributs, et leurs opérations. Le modèle introduit une imprimante et une tâche. La tâche prend en charge plusieurs documents par tâche. Le document modèle traite aussi de la façon dont les questions de sécurité, d’internationalisation, et d’annuaire sont traitées.
Le document "Protocole/1.1 d’impression sur Internet : Codage et transport" est une transposition formelle des opérations abstraites et des attributs définis dans le document modèle sur HTTP/1.1 [RFC2616]. Il définit aussi les règles de codage pour un nouveau type de support MIME Internet appelé "application/ipp". Ce document définit aussi les règles de transport sur HTTP d’un corps de message dont le type de contenu est "application/ipp". Ce document définit le schéma 'ipp' pour l’identification des imprimantes et des tâches IPP.
Le document "Protocole/1.1 d’impression sur Internet : Guide de mise en oeuvre" donne des directives et conseils pour la mise en œuvre de clients et objets IPP. Il est destiné à les aider à comprendre IPP/1.1 et à fournir des considérations propres à les assister dans la conception de leurs mises en œuvre de client et/ou objet IPP. Par exemple, il donne un ordre de traitement normal d’une demande, avec la vérification d’erreur. Les motifs de certaines décisions de la spécification y figurent aussi.
Le document "Transposition entre protocoles LPD et IPP" donne quelques conseils à ceux qui mettent en œuvre des passerelles entre des mises en oeuvre IPP et LPD (Line Printer Daemon).
Adresse des auteurs
Tom Hastings (editor) |
Tomas Hastings |
Xerox Corporation |
Xerox Corporation |
701 S Aviation Blvd, ESAE 242 |
701 S Aviation Blvd, ESAE 242 |
El Segundo, CA 90245 |
El Segundo, CA
90245 |
tél : 310-333-6413 |
tél :: 310-333-6413 |
Fax: 310-333-6342 |
fax: 310-333-6342 |
mél : hastings@cp10.es.xerox.com |
mél: hastings@cp10.es.xerox.com |
|
Robert Herriot |
Harry Lewis |
Roger deBry |
|
Global Workflow Solutions |
IBM Corporation |
Utah Valley State College |
|
706 Colorado Ave. |
6300 Diagonal Hwy |
|
|
Palo Alto, CA 94303 |
Boulder, CO 80301 |
|
|
tél : 650-324-4000 |
tél : (303) 924-5337 |
tél : (801) 863-8848 |
|
mél : bob@herriot.com |
mél : harryl@us.ibm.com |
mél debryro@uvsc.edu |
Déclaration de copyright
Copyright (C) The Internet Society (2005).
Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.
Le présent document et les informations y contenues sont
fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION
QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET
SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES,
EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE
L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE
GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.
Propriété
intellectuelle
L’IETF ne prend pas position sur la validité et la portée de
tout droit de propriété intellectuelle ou autres droits qui pourrait être
revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie
décrite dans le présent document ou sur la mesure dans laquelle toute licence
sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne
prétend avoir accompli aucun effort pour identifier de tels droits. Les informations
sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC
figurent dans les BCP 78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF
et toutes assurances de disponibilité de licences, ou le résultat de tentatives
faites pour obtenir une licence ou permission générale d’utilisation de tels
droits de propriété par ceux qui mettent en œuvre ou utilisent la présente
spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à
http://www.ietf.org/ipr.
L’IETF invite toute partie intéressée à porter son attention
sur tous copyrights, licences ou applications de licence, ou autres droits de
propriété qui pourraient couvrir les technologies qui peuvent être nécessaires
pour mettre en œuvre la présente norme. Prière d’adresser les informations à
l’IETF à ietf- ipr@ietf.org.
Remerciement
Le financement de la fonction d’édition des RFC est
actuellement fourni par Internet Society.