|
Groupe de travail Réseau |
R. Herriot |
|
Request for Comments : 3996 |
Global Workflow Solutions |
|
Catégorie : Standards Track |
T. Hastings |
|
Mise à jour de : 2911, 2910 |
Xerox Corporation |
Mars 2005 H. Lewis
IBM Corp.
Protocole d’impression Internet (IPP) : Méthode de livraison 'ippget' pour les notifications d’événement
Statut du présent Mémo
Le présent
document spécifie un protocole de normalisation Internet pour la communauté
Internet, et appelle à discussion et suggestions en vue de son amélioration.
Prière de se rapporter à l’édition en cours des "Internet Official
Protocol Standards" (normes
officielles du protocole Internet) (STD 1) pour connaître l’état de la
normalisation et le statut du présent protocole. 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 décrit une extension au Protocole 1.1 d’impression sur Internet : Modèle et sémantique (RFC 2911, RFC 2910). Le présent document spécifie la méthode de livraison tirée 'ippget' à utiliser avec la spécification "Protocole d’impression Internet (IPP) : Notifications d’événement et abonnements" (RFC 3995). Cette méthode de livraison IPPGET est EXIGÉE pour tous les clients et imprimantes qui prennent en charge la RFC 3995. Le récepteur de notification, agissant comme client, atteint (tire) les notifications d’événement en utilisant l’opération Obtenir les notifications définie dans le présent document.
Table des matières
1. Introduction................................................................................................................................................................................ 3
2. Terminologie.............................................................................................................................................................................. 3
2.1. Terminologie
de conformité.......................................................................................................................................... 3
2.2. Autres
termes................................................................................................................................................................... 3
3. Modèle
et fonctionnement........................................................................................................................................................ 4
4. Informations
générales............................................................................................................................................................ 4
5. Opération
Get-Notifications.................................................................................................................................................... 5
5.1. Demande
Get-Notifications.......................................................................................................................................... 6
5.1.1 notify-subscription-ids (1setOf integer(1:MAX))................................................................................................. 7
5.1.2 notify-sequence-numbers (1setOf integer(1:MAX))............................................................................................ 7
5.1.3 notify-wait (booléen)................................................................................................................................................. 8
5.2 Réponse
à Get-Notifications......................................................................................................................................... 8
5.2.1 notify-get-interval (entier de 0 à MAX)................................................................................................................ 10
5.2.2 printer-up-time (entier de 1 à MAX)...................................................................................................................... 11
6. Informations
supplémentaires sur les attributs de gabarit d’abonnement.................................................................. 13
6.1 notify-pull-method
(mot clé de type2)...................................................................................................................... 13
7. Attributs
de description d’abonnement............................................................................................................................... 13
8. Attributs
de description d’imprimante supplémentaires................................................................................................. 14
8.1 ippget-event-life
(entier(15:MAX)).......................................................................................................................... 14
9. Nouvelles
valeurs pour les attributs de description d’imprimante existants............................................................... 15
9.1 notify-pull-method-supported
(1setOf type2 keyword)......................................................................................... 15
9.2 operations-supported
(1setOf énumération de type2).......................................................................................... 15
10. Nouveaux
codes d’état....................................................................................................................................................... 15
10.1 successful-ok-events-complete
(0x0007)................................................................................................................. 15
11. Codage
et transport........................................................................................................................................................... 15
12. Exigences
de conformité................................................................................................................................................... 17
12.1 Conformité
des imprimantes IPP............................................................................................................................... 17
12.2 Conformité
des clients IPP......................................................................................................................................... 17
13. Références
normatives..................................................................................................................................................... 18
14. Références
informatives.................................................................................................................................................. 18
15. Considérations
relatives à l’IANA................................................................................................................................. 19
15.1 Enregistrements
d’attributs........................................................................................................................................ 19
15.2 Enregistrements
des valeurs d’attribut de méthode de livraison et de mot clé supplémentaire
pour les attributs existants 19
15.3 Valeurs
d’attribut d’énumération supplémentaires.............................................................................................. 19
15.4 Enregistrements
d’opérations.................................................................................................................................... 20
15.5 Enregistrement
de code d’état................................................................................................................................... 20
16. Considérations
d’internationalisation........................................................................................................................... 20
17. Considérations
sur la sécurité....................................................................................................................................... 20
17.1 Droits
d’accès du client récepteur de notification................................................................................................ 21
17.2 Menaces
sur la sécurité des imprimantes................................................................................................................ 21
17.3 Menaces
sur la sécurité du récepteur de notification........................................................................................... 21
17.4 Exigences
de sécurité pour les imprimantes........................................................................................................... 22
17.5 Exigences
de sécurité pour les clients...................................................................................................................... 22
18 Description
des documents de base IPP (pour information)............................................................................................ 22
19 Contributeurs.......................................................................................................................................................................... 23
Le présent document décrit une extension au protocole 1.1 d’impression sur Internet : Modèle et sémantique [RFC 2911], [RFC 2910]. Le présent document spécifie la méthode de livraison tirée 'ippget' à utiliser avec la spécification " Protocole d’impression sur Internet (IPP) : Notifications d’événement et abonnements" [RFC3995]. Cette méthode de livraison IPPGET est EXIGEE pour tous les clients et imprimantes qui prennent en charge la [RFC3995]. Le récepteur de notification, agissant comme un client, atteint (tire) les notifications d’événement en utilisant l’opération Obtenir les notifications définie dans le présent document. Voir à la section 21 du présent document la description des documents IPP de base. La description du modèle de notification d’événement IPP figure dans la [RFC3995].
Avec cette méthode de livraison tirée, lorsque survient un événement, l’imprimante sauvegarde la Notification d’événement durant une période de temps appelée Durée de vie d’événement. Le récepteur de notification atteint (tire) les notifications d’événement en utilisant l’opération Obtenir les notifications. Cette opération amène l’imprimante à retourner toutes les notifications d’événement détenues pour le ou les objets d’abonnement spécifiés. Si le récepteur de notification a choisi l’option Mode d’attente d’événement pour attendre des notifications d’événement supplémentaires, l’imprimante PEUT continuer à retourner des notifications d’événement au récepteur de notification comme réponses asynchrones à Obtenir les notifications alors que les événements surviennent en utilisant la transaction générée par le récepteur de notification.
Le récepteur de notification peut terminer le Mode d’attente d’événement (sans fermer la connexion) en fournissant l’attribut "notify-wait" (notifier l’attente) (booléen) avec la valeur 'faux' dans une demande Obtenir les notifications ultérieure. De même, l’imprimante peut terminer le Mode d’attente d’événement (sans fermer la connexion) en retournant l’attribut d’opération "notify-get-interval" (notifier d’obtenir les intervalles) (entier) dans une réponse à Obtenir les notifications qui dit au récepteur de notification combien de temps attendre avant de réessayer.
La présente section définit les termes suivants qui sont utilisés tout au long du document :
Les termes en majuscules, tels que DOIT, NE DOIT PAS, EXIGE, DEVRAIT, NE DEVRAIT PAS, PEUT, PEUT NE PAS, et FACULTATIF, ont une signification particulière qui se rapporte à la conformité telle que définie dans la RFC 2119 et au paragraphe 12.1 de la [RFC2911]. Si une mise en œuvre prend en charge l’extension définie dans le présent document, ces termes s’appliquent alors ; autrement, ils ne s’appliquent pas. Ces termes définissent seulement la conformité au présent document ; ils n’affectent pas la conformité aux autres documents, sauf déclaré explicitement par ailleurs.
Le présent document utilise la même terminologie que la [RFC2911], comme "client", "imprimante", "attribut", "valeur d’attribut", "mot clé", "opération", "demande", "réponse", "administrateur", "opérateur", et "prise en charge", avec la même signification. Le présent document utilise aussi la terminologie définie dans la [RFC3995], à savoir "abonnement (objet)", "récepteur de notification", "événement", "notification d’événement", "notification d’événement composé", "durée de vie d’événement", et "groupe d’attribut de notification d’événement", avec la même signification. De plus, le présent document définit les termes suivants pour ses propres besoins :
Mode attente d’événement : mode demandé par un client récepteur de notification dans sa demande Obtenir les notifications et accordé par une imprimante pour garder la connexion établie pendant que l’imprimante envoie les réponses ultérieures à l’opération Obtenir les notifications au récepteur de notification sous la forme de notifications d’événement au fur et à mesure qu’elles surviennent.
Dans une opération de création d’abonnement, lorsque l’attribut "notifier la méthode tirée" est présent et a la valeur de mot clé "ippget", le client demande que l’imprimante utilise la méthode de livraison tirée "ippget" pour les notifications d’événement associées au nouvel objet d’abonnement.
Lorsqu’un événement survient, l’imprimante DOIT générer une notification d’événement et DOIT lui allouer sa durée de vie d’événement. L’imprimante DOIT conserver une notification d’événement pendant la durée de vie d’événement qui lui est allouée.
Lorsqu’un récepteur de récepteur de notification veut recevoir des notifications d’événement pour un objet d’abonnement, il effectue l’opération Obtenir les notifications en fournissant l’identifiant d’abonnement de l’objet d’abonnement, ce qui amène l’imprimante à retourner toutes les notifications d’événement conservées non expirées pour cet objet d’abonnement. Si le récepteur de notification a choisi l’option Mode d’attente d’événement pour attendre des notifications d’événement supplémentaires, la réponse à la demande Obtenir les notifications continue indéfiniment tant que l’imprimante continue à envoyer des notifications d’événement dans la réponse alors que surviennent des événements pour cet objet d’abonnement.
Lorsque le récepteur de notification demande des notifications d’événement pour des objets d’abonnement par tâche, le récepteur de notification effectue normalement l’opération Obtenir les notifications dans la seconde ou il effectue l’opération de création d’abonnement. Parce que l’imprimante DOIT sauvegarder les notifications d’événement pendant au moins 15 secondes (voir le paragraphe 8.1), le récepteur de notification ne manquera vraisemblablement aucune notification d’événement survenant entre la création d’abonnement et l’opération Obtenir les notifications.
La méthode de livraison ‘ippget’ est principalement conçue pour (1) un client qui veut obtenir les événements (de l’objet d’abonnement par tâche de la tâche) pour une tâche qu’il a soumise et (2) un client privilégié qui veut obtenir tous les événements par tâche ou par imprimante d’un objet d’abonnement par imprimante.
Si une imprimante prend en charge cette méthode de livraison, ses caractéristiques sont les suivantes :
Tableau 1. Informations sur la méthode de livraison
|
Réalisation
des exigences de conformité de la méthode |
Méthode de
livraison |
|
1. Quel est le nom de schéma d’URL pour la
méthode de livraison poussée, ou le nom de méthode de mot clé pour la méthode
de livraison tirée ? |
Nom de méthode de mot clé 'ippget' |
|
2. La prise en charge de la méthode de
livraison pour une imprimante IPP est elle EXIGÉE, RECOMMANDÉE, ou
FACULTATIVE ? |
EXIGÉE |
|
3. Quels protocoles de transport et de
livraison l’imprimante utilise-t-elle pour délivrer le contenu de
notification d’événement ; c’est-à-dire, quelle est la pile de réseau
complète ? |
IPP avec une nouvelle opération. |
|
4. Peut-on combiner plusieurs notifications
d’événement en une notification d’événement composée ? |
Oui. |
|
5. La méthode de livraison est elle initiée
par le récepteur de notification (tirée), ou par l’imprimante (poussée) ? |
Cette méthode de livraison est une méthode
tirée avec des aspects de méthode poussée, bien que l’imprimante n’initie pas
l’opération. |
|
6. Le contenu de la notification
d’événement est-il à destination machine ou à destination humaine ? |
A destination machine. |
|
7. Quelle section de ce document répond aux
questions suivantes ? Pour une notification d’événement à destination
machine, quelle est la représentation et quel est le
codages des valeurs définies au paragraphe 9.1 de [RFC3995], et quels en sont
les exigences de conformité ? Pour une notification d’événement à destination
humaine, quels sont la représentation et le codage des éléments d’information
définis au paragraphe 9.2 de [RFC3995], et quels en
sont les exigences de conformité ? |
Section 5. |
|
8.
Quels sont le délai de latence et la fiabilité du protocole de transport et
de livraison ? |
Les
mêmes que pour IPP et que pour le transport HTTP sous jacent. |
|
9.
Quels sont les aspects de sécurité du protocole de transport et de livraison
; par exemple, comment est-il traité dans les pare-feu ? |
Comme
pour IPP et le transport HTTP sous jacent et dans la même direction, donc pas
de nouvelles considérations sur les pare feu. |
|
10.
Quelles sont les restrictions sur la longueur du contenu ? |
Aucune. |
|
11.
Quelles sont les valeurs supplémentaires ou éléments d’information qu’une
imprimante envoie dans un contenu de notification d’événement et ses
exigences de conformité ? |
Aucune. |
|
12.
Quels sont les attributs supplémentaires de gabarit d’abonnement et/ou de
description d’abonnement et leurs exigences de conformité ? |
Aucune. |
|
13.
Quels sont les attributs supplémentaires de description d’imprimante et leurs
exigences de conformité ? |
"ipp-event-life"
(entier (15: MAX)) |
Cette opération est produite par un client agissant comme récepteur de notification qui demande à l’imprimante de retourner toutes les notifications d’événement conservées pour le ou les objets d’abonnement identifiés.
Une imprimante DOIT prendre en charge cette opération, DOIT accepter la demande dans tout état (voir la [RFC2911] attributs "état d’imprimante" et "cause d’état d’imprimante"), et DOIT rester dans le même état avec les mêmes valeurs de "cause d’état d’imprimante".
Lorsqu’une imprimante effectue cette opération, elle DOIT retourner toutes, et seulement elles, les notifications d’événement
1. dont l’attribut de description d’abonnement d’objet d’abonnement associé "notifier l’identifiant d’abonnement" est égal à une des valeurs de l’attribut d’opération "notifier les identifiants d’abonnement" (1setOf entier de 1 à MAX) ET
2. dont l’objet d’abonnement associé contient l’attribut "notifier la méthode tirée" et a la valeur de mot clé 'ippget', ET
3. dont "notifier le numéro de séquence" est égal ou supérieur à la valeur correspondante de l’attribut d’opération "notifier les numéros de séquence" (1setOf entier de 1 à MAX) s’il est fourni ET
4. dont la durée de vie d’événement n’a pas encore expiré ET
5. où le client récepteur de notification a les droits d’accès en lecture sur l’objet d’abonnement identifié (voir ci-dessous le paragraphe sur les droits d’accès).
Le client récepteur de notification DOIT soit (a) demander le mode d’attente d’événement en fournissant l’attribut d’opération "notifier l’attente" avec la valeur 'vrai', soit (b) supprimer Mode d’attente d’événement en omettant l’attribut d’opération "notifier l’attente" ou en le fournissant avec une valeur de 'faux'. Pour terminer ensuite le Mode d’attente d’événement, le client récepteur de notification DOIT clore la connexion. Pour terminer le mode d’attente d’événement, l’imprimante DOIT soit (a) retourner l’attribut d’opération "notifier d’obtenir l’intervalle" dans une réponse à Obtenir les notifications (comportement RECOMMANDÉ) soit (b) clore la connexion. Les attributs d’opération "notifier d’obtenir l’intervalle" dit au récepteur de notification combien de temps il doit attendre avant d’essayer la demande Obtenir les notifications suivante.
Droits d’accès : L’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT être (1) le propriétaire de chaque objet d’abonnement identifié par l’attribut d’opération "notifier les identifiants d’abonnement" (voir au paragraphe 5.1.1), (2) un opérateur ou administrateur de l’imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à demander les notifications d’événement à partir du ou des objets d’abonnement cibles. Autrement, l’imprimante IPP DOIT rejeter l’opération et retourner le code d’état 'erreur client, interdit', 'erreur client, non authentifié', ou 'erreur client, non autorisé', selon le cas approprié. De plus, la politique de sécurité de l’imprimante PEUT limiter les attributs retournés par l’opération Obtenir les notifications, d’une façon similaire à celle de l’opération Obtenir les attributs de tâche (voir la fin du paragraphe 3.3.4.2 de la [RFC2911]).
Les groupes d’attributs suivants font partie de la demande Obtenir les notifications :
Groupe 1 : Attributs d’opération
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language", comme décrit au paragraphe 3.1.4.1 de la [RFC2911].
Cible :
L’attribut d’opération "printer-uri" (uri) qui est la cible de cette opération comme décrit au paragraphe 3.1.5 de la [RFC2911].
Nom de l’utilisateur demandeur :
L’attribut "requesting-user-name" (name(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3 de la [RFC2911].
Cet attribut identifie un ou plusieurs objets d’abonnement pour lesquels des événements sont demandés. Le client DOIT fournir cet attribut avec au moins une valeur. L’objet imprimante DOIT prendre en charge cet attribut avec plusieurs valeurs.
Si aucun objet d’abonnement n’existe avec l’identifiant fourni, ou si l’objet d’abonnement identifié ne contient pas l’attribut "notifier la méthode tirée" avec la valeur de mot clé 'ippget', l’imprimante DOIT retourner le code d’état 'erreur client, introuvable'.
Note : Les noms de "notifier les identifiants d’abonnement" et de "notifier les numéros de séquence" se terminent tous deux au pluriel, car ils sont multi valeurs. Cependant, il y a d’autres occurrences de ces noms d’attribut au singulier qui sont mono valeur.
Cet attribut spécifie une ou plusieurs des plus faibles valeurs de numéro de séquence de notification d’événement pour les objets d’abonnement identifiés par les valeurs correspondantes de l’attribut d’opération "notifier les identifiants d’abonnement". Le récepteur de notification DEVRAIT fournir cet attribut, et le nombre de valeurs DEVRAIT être le même que celui de l’attribut "notifier les identifiants d’abonnement". L’imprimante DOIT prendre en charge cet attribut avec plusieurs valeurs.
L’imprimante NE DOIT PAS retourner des événements Notification avec des numéros de séquence plus faibles pour l’objet d’abonnement correspondant. Donc, en fournissant les valeurs appropriées pour cet attribut, le récepteur de notification peut empêcher d’obtenir les mêmes Notifications d’événement qu’à partir d’un objet d’abonnement qui avait été retourné sur une précédente demande Obtenir les notifications. Le récepteur de notification DEVRAIT se souvenir de la plus forte valeur de "notifier le numéro de séquence" retournée pour chaque objet d’abonnement demandé et DEVRAIT passer cette valeur pour chaque objet d’abonnement demandé à la demande Obtenir les notifications suivante.
Si le récepteur de notification fournit moins de valeurs pour cet attribut (y compris l’omission de cet attribut) qu’il ne le fait pour l’attribut d’opération "notifier les identifiants d’abonnement", l’imprimante suppose une valeur de '1' pour chaque valeur manquante. Une valeur de '1' amène l’imprimante à retourner toute notification d’événement non expirée pour cet objet d’abonnement, car '1' est le numéro de séquence le plus faible possible. Si le récepteur de notification fournit plus de valeurs pour cet attribut que le nombre de valeurs pour l’attribut d’opération "notifier les identifiants d’abonnement", l’imprimante ignore les valeurs excédentaires.
Note : Si un récepteur de notification effectue deux opérations Obtenir les notifications consécutives avec la même valeur pour "notifier le numéro de séquence" (ou omet l’attribut), la valeur d’horodatage de la première notification d’événement dans la seconde réponse à Obtenir les notifications peut être inférieure à celle de l’horodatage de la dernière notification d’événement dans la première réponse à Obtenir les notifications. Cela arrive parce que l’imprimante envoie toutes les notifications d’événement non expirées qui ont un numéro de séquence égal ou supérieur conformément à l’ordre spécifié dans la [RFC3995], et certaines notifications d’événement provenant de la première opération Obtenir les notifications peuvent n’être pas arrivées à expiration au moment où survient la seconde opération Obtenir les notifications.
Cette valeur indique si le récepteur de notification veut le mode d’attente d’événement. Le client PEUT fournir cet attribut. L’objet imprimante DOIT prendre en charge les deux valeurs de cet attribut.
Si le client fournit la valeur 'faux' ou omet cet attribut, le client ne demande pas le mode d’attente d’événement. Si la valeur est 'vrai', le client demande le mode d’attente d’événement. Voir les règles de Mode d’attente d’événement au début du paragraphe 5.2.
L’imprimante a les options suivantes pour répondre à une demande Obtenir les notifications :
1. L’imprimante peut rejeter la demande et retourner le code d’état 'erreur serveur, occupé' si l’imprimante est trop occupée pour accepter cette opération à ce moment. Dans ce cas, l’imprimante DOIT retourner l’attribut d’opération "obtenir l’intervalle de notification" pour indiquer quand le client DEVRAIT réessayer.
2. Si le récepteur de notification n’a pas demandé le mode d’attente d’événement ("notifier mode d’attente" = 'faux' ou omis), l’imprimante DOIT immédiatement retourner toutes les notifications d’événement qu’elle garde à ce moment dans le ou les objets d’abonnement demandés et DOIT retourner l’attribut d’opération "notifier obtenir l’intervalle" avec le nombre de secondes à partir du présent, auquel le récepteur de notification DEVRAIT répéter la demande Obtenir les notifications pour obtenir les futures notifications d’événement.
3. Si le récepteur de notification a demandé le mode d’attente d’événement ("notifier mode d’attente" = 'vrai'), l’imprimante DOIT immédiatement retourner toutes les Notifications d’événement qu’elle détient à ce moment dans le ou les objets d’abonnement demandés et DOIT continuer à retourner les notifications d’événement comme elles surviennent jusqu’à ce que tous les objets d’abonnement demandés soient annulés. Un objet d’abonnement est annulé soit via l’opération Annuler l’abonnement soit par l’imprimante (par exemple, l’objet d’abonnement est annulé lorsque la tâche associée se termine et n’est plus dans la phase Rétention de tâche ou Historique de tâches ; voir au paragraphe 8.1 la discussion sur l’attribut "ippget-event-life (entier de 15 à MAX)").
Cependant, l’imprimante PEUT décider à tout moment de terminer Mode d’attente d’événement, y compris dans la première réponse. Dans ce cas, l’imprimante DOIT retourner l’attribut d’opération "notifier l’intervalle d’obtention". Cet attribut indique que l’imprimante souhaite quitter le Mode d’attente d’événement et le nombre de secondes dans le futur auquel le récepteur de notification DEVRAIT réessayer l’opération Obtenir les notifications. Le récepteur de notification DOIT accepter cette réponse et DOIT se déconnecter. Si le récepteur de notification ne se déconnecte pas, l’imprimante DEVRAIT le faire.
Du point de vue du récepteur de notification, la réponse apparaît dans une salve initiale de données, qui inclut le groupe d’attributs d’opération et un groupe d’attributs de notification d’événement par notification d’événement que conserve l’imprimante. Après la salve initiale de données, si le récepteur de notification a choisi l’option Mode d’attente d’événement pour attendre des notifications d’événement supplémentaires, le récepteur de notification reçoit des groupes d’attributs de notification d’événement occasionnels. Les serveurs mandataires peuvent différer certaines notifications d’événement ou provoquer la survenance de fins de temporisations. Le client DOIT être préparé à effectuer à nouveau l’opération Obtenir les notifications lorsque surviennent des fins de temporisation.
Chaque attribut est codé en utilisant les règles IPP pour les attributs de codage [RFC2910] et PEUT être codé dans n’importe quel ordre. Note : la réponse Obtenir les tâches dans la [RFC2911] agit comme modèle pour coder plusieurs groupes d’attributs. Voir à la section 11 les règles de codage et de transport.
Les groupes d’attributs suivants font partie de la réponse à Obtenir les notifications :
Groupe 1 : Attributs de fonctionnement
Message d’état : En plus du code d’état EXIGÉ retourné dans chaque réponse, la réponse inclut FACULTATIVEMENT un attribut d’opération "message d’état" (texte(255)) et/ou "message d’état détaillé" (texte(MAX)), comme décrit à la section 13 et au paragraphe 3.1.6 de la [RFC2911]. L’imprimante peut retourner tout code d’état défini dans la [RFC2911]. Si le code d’état n’est pas 'réussite-xxx', l’imprimante NE DOIT PAS retourner de groupe d’attribut de notification d’événement. Ci après figurent les descriptions des codes d’état importants :
réussite-ok : La réponse contient toute les notifications d’événement associées aux identifiants d’abonnement spécifiés qui ont été fournis dans l’attribut d’opération "notifier les identifiants d’abonnement" de la demande. Si les objets d’abonnement demandés n’avaient pas de notification d’événement associée, la réponse DOIT contenir zéro notification d’événement.
réussite-ok-événements-terminés : Indique que ce retour est le dernier pour tous les objets d’abonnement qui correspondent à la demande, que des notifications d’événement soient retournées ou non. Cette condition survient pour Mode d’attente d’événement avec des récepteurs de notification qui attendent des réponses lorsque (1) l’objet d’abonnement est annulé par une opération Annuler l’abonnement, (2) l’objet d’abonnement est supprimé, lorsque arrive à expiration la durée de location de l’abonnement par imprimante, ou (3) l’événement 'fin de tâche' survient pour un abonnement par tâche. Cette condition survient aussi pour une demande Obtenir les notifications que fait un récepteur de notification après l’achèvement de la tâche, mais avant l’expiration de la durée de vie d’événement. Voir au paragraphe 10.1.
erreur client, introuvable : L’imprimante n’a pas d’objets d’abonnement dont l’attribut "notifier l’identifiant d’abonnement" égale une des valeurs de l’attribut d’opération "notifier les identifiants d’abonnement" fournies, ou l’objet d’abonnement identifié ne contient pas l’attribut "notifier la méthode tirée" avec la valeur de mot clé 'ippget'.
erreur serveur, occupé : L’imprimante est trop occupée pour accepter cette opération. L’imprimante DEVRAIT retourner l’attribut d’opération "notifier l’intervalle d’obtention" dans les attributs d’opération de la réponse ; puis le récepteur de notification DEVRAIT attendre pendant le nombre de secondes spécifié par l’attribut d’opération "notifier l’intervalle d’obtention" avant de recommencer à effectuer cette opération. Si l’attribut d’opération "notifier l’intervalle d’obtention" n’est pas présent, le récepteur de notification DEVRAIT utiliser les algorithmes normaux de réduction de puissance du réseau pour déterminer quand effectuer cette opération à nouveau.
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language", comme décrit au paragraphe 3.1.4.2 de la [RFC2911]. L’imprimante DOIT utiliser, respectivement, les valeurs de "notifier le charset" et "notifier le langage naturel", d’un objet d’abonnement associé aux notifications d’événement dans la réponse. Normalement, il y a seulement un objet d’abonnement correspondant, ou la valeur des attributs "notifier le charset" et "notifier le langage naturel" est la même dans tous les objets d’abonnement. Si non, l’imprimante DOIT prendre un objet d’abonnement à partir duquel obtenir la valeur de ces attributs. L’algorithme de prise de l’objet d’abonnement dépend de la mise en oeuvre. Le choix du langage naturel ne pose pas de problème car les valeurs 'texte' et 'nom' peuvent outrepasser l’attribut d’opération "attributs de langage naturel". Le choix du charset par l’imprimante est critique parce qu’un mauvais choix peut la rendre incapable d’envoyer des valeurs de 'texte' et de 'nom' appropriées.
La valeur de cet attribut d’opération est le nombre de secondes pendant lequel le récepteur de notification DEVRAIT attendre avant de réessayer l’opération Obtenir les notifications. L’imprimante DOIT retourner cet attribut d’opération si (1) elle est trop occupée pour retourner des événements, (2) le client récepteur de notification n’a pas demandé le mode d’attente d’événement, ou si (3) l’imprimante termine le mode d’attente d’événement. Le client DOIT accepter cet attribut et DEVRAIT recommencer l’opération Obtenir les notifications (avec ou sans "notifier l’attente" = 'vrai') au nombre de secondes indiqué dans le futur afin d’obtenir plus de notifications d’événement. Cette valeur est destinée à aider le client à être un bon citoyen du réseau.
La valeur de cet attribut DOIT être au moins aussi grande que celle de l’attribut de description d’imprimante "durée de vie de l’événement ippget" de l’imprimante (voir au paragraphe 8.1). L’imprimante PEUT retourner une valeur plus grande que celle de l’attribut de description d’imprimante "durée de vie de l’événement ippget" pourvu que l’imprimante augmente la durée de vie de l’événement pour cet objet d’abonnement de sorte que les récepteurs de notification prennent en compte la plus grande valeur et que l’interrogation à intervalles plus grands ne manque pas d’événements. Note : La mise en œuvre d’un tel algorithme exige des attributs cachés dans l’objet d’abonnement qui DÉPENDENT DE LA MISE EN ŒUVRE.
Si l’imprimante veut rester en mode d’attente d’événement, l’imprimante NE DOIT PAS alors retourner cet attribut dans la réponse.
Un tableau complet des combinaisons de "notifier l’attente", "code d’état", "notifier l’intervalle d’obtention", et des groupes d’attributs de notification d’événement pour les réponses à Obtenir la notification initiale (attente et pas d’attente) et des réponses suivantes à Mode d’attente d’événement (qui peuvent rester en Mode d’attente d’événement ou peuvent demander au récepteur de notification de quitter le mode d’attente d’événement) :
Tableau 2. Combinaisons de "notifier l’attente", "code d’état", et "notifier l’intervalle d’obtention"
|
Le client
envoie "notifier
l’attente" |
L’imprimante
retourne : "code
d’état" |
L’imprimante
retourne : "notifier
l’intervalle d’obtention" |
Groupes
d’attributs de
notification d’événement |
|
1.
'faux'* |
'réussite-ok' |
DOIT retourner N |
peut être |
|
2.
'faux'* |
'introuvable' |
NE DOIT PAS |
NE DOIT PAS |
|
3.
'faux'* |
'occupé' |
DOIT retourner N |
NE DOIT PAS |
|
4.
'faux'* |
'événements-terminés' |
NE DOIT PAS |
'fin de tâche' |
|
5.
'vrai' |
'réussite-ok' |
NE DOIT PAS |
DOIT |
|
6.
'vrai' |
'réussite-ok' |
DOIT retourner N |
peut être |
|
7.
'vrai' |
'introuvable' |
NE DOIT PAS |
NE DOIT PAS |
|
8.
'vrai' |
'occupé' |
DOIT retourner N |
NE DOIT PAS |
|
9.
'vrai' |
'événements-terminés' |
NE DOIT PAS |
'fin de tâche' ou
peut être autre |
* 'faux' ou le client omet l’attribut "notifier l’attente".
Explication :
1-4 : Le client ne demande pas le mode d’attente d’événement.
5-9 : Le client demande le mode d’attente d’événement.
2,7 : objet d’abonnement introuvable, ou annulé précédemment ; le client NE DEVRAIT PAS réessayer.
3,8 : Serveur occupé, dit au client d’essayer plus tard ; le client devrait réessayer dans N secondes.
4 : Le client interroge après la fin de tâche, mais avant l’expiration de la durée de vie d’événement, et obtient l’événement 'tâche terminée', de sorte que le client ne devrait pas se soucier de réessayer ; le client NE DEVRAIT PAS réessayer plus tard.
5 : L’imprimante retourne une ou plusieurs notifications d’événement et est d’accord pour rester en Mode d’attente d’événement ; le client attend plus de notifications d’événement en retour.
6 : L’imprimante veut quitter le mode d’attente d’événement. Peut arriver sur la première réponse (avec ou sans notifications d’événement) ou sur une réponse suivante avec ou sans notifications d’événement ; le client DEVRAIT réessayer dans N secondes.
9 : Soit (1) l’imprimante retourne l’événement 'tâche terminée', soit (2) l’objet d’abonnement a été annulé par un Annuler la tâche ou l’abonnement par imprimante est arrivé à expiration sans être renouvelé. Pour le cas (1), au moins une notification d’événement DOIT être retournée ; pour le cas (2), il est peu vraisemblable qu’aucune notification d’événement soit retournée, et le client NE DEVRAIT PAS réessayer.
La valeur de cet attribut est l’attribut "printer-up-time" de l’imprimante au moment où l’imprimante envoie cette réponse. L’imprimante DOIT retourner cet attribut. Parce que chaque notification d’événement contient aussi la valeur de cet attribut lorsque l’événement est survenu, la valeur de cet attribut permet à un récepteur de notification de savoir quand chaque notification d’événement est survenue par rapport au moment de cette réponse.
Groupe 2 : Attributs non pris en charge
Voir la [RFC2911], paragraphe 3.1.7, pour des précisions sur le retour des attributs non pris en charge.
Groupes 3 à N : Attributs de notification d’événement
L’imprimante répond par un groupe d’attributs de notification d’événement par notification d’événement correspondante. La réponse entière est considérée comme une seule notification d’événement composée (voir la [RFC3995]). Les notifications d’événement correspondantes sont toutes des notifications d’événement non arrivées à expiration associées aux objets d’abonnement correspondants et DOIVENT suivre les exigences "d’ordre de notification d’événement" pour les notifications d’événement au sein d’une notification d’événement composée spécifiée à la section 9 de la [RFC3995]. En d’autres termes, l’imprimante DOIT ordonner ces groupes de notification d’événement en ordre d’horodatage ascendant (et de numéro de séquence) pour un objet d’abonnement. Si des notifications d’événement pour plusieurs objets d’abonnement sont retournées, les événements Notification pour le prochain objet d’abonnement suivent dans l’ordre ascendant d’horodatage, etc.
Chaque groupe de notification d’événement DOIT contenir tous les attributs spécifiés au paragraphe9.1 ("Contenu des notifications d’événement à destination machine") de la [RFC3995], avec les exceptions notées par des astérisques dans les tableaux ci-dessous.
Les tableaux ci-dessous sont identiques à ceux du paragraphe 9.1 ("Contenu des notifications d’événement à destination machine") de la [RFC3995], excepté que chaque cellule de la colonne "Envoi" est "DOIT".
Si plus d’une notification d’événement est retournée et que leur état n’est pas le même, l’imprimante DOIT alors retourner un attribut "notifier le code d’état" dans chaque groupe d’attribut de notification d’événement pour indiquer les différentes valeurs d’état.
Pour une notification d’événement pour tous événements, l’imprimante inclut les attributs indiqués au Tableau 3.
Tableau 3. Attributs dans le contenu de notification d’événement
|
Valeur de source |
Envoi |
Objet de source |
|
notifier l’identifiant d’abonnement (entier(1:MAX)) |
DOIT |
abonnement |
|
notifier l’uri d’imprimante (uri) |
DOIT |
abonnement |
|
notifier les événements abonnés (mot clé type2) |
DOIT |
notification d’événement |
|
printer-up-time (entier(1:MAX)) * |
DOIT |
imprimante |
|
heure en cours à l’imprimante (date et heure) |
DOIT ** |
imprimante |
|
Notifier numéro de séquence (entier (0:MAX)) |
DOIT |
abonnement |
|
Notifier charset (charset) |
DOIT |
abonnement |
|
Notifier langage naturel (langage naturel) |
DOIT |
abonnement |
|
Notifier données d’utilisateur (chaîne d’octet(63)) |
DOIT *** |
abonnement |
|
Notifier le texte (texte) |
DOIT |
notification d’événement |
|
attributs des "notifier les attributs" |
DOIT **** |
attribut d’imprimante |
|
attributs des "notifier les attributs" |
DOIT **** |
attribut de tâche |
|
attributs des "notifier les attributs" |
DOIT **** |
attribut d’abonnement |
* Comme spécifié à la section 9 de la [RFC3995], la valeur de l’attribut "printer-up-time" envoyé dans chaque notification d’événement DOIT être l’heure à laquelle est survenu l’événement, et non l’heure d’envoi de la notification d’événement.
** L’imprimante DOIT envoyer l’attribut "heure en cours à l’imprimante" si et seulement si elle prend en charge l’attribut "heure en cours à l’imprimante" à l’objet imprimante.
*** Si l’objet d’abonnement associé ne contient pas d’attribut "notifier les données d’utilisateur", l’imprimante DOIT envoyer une chaîne d’octets de longueur 0.
**** Si l’attribut "notifier les attributs" est présent sur l’objet d’abonnement, l’imprimante DOIT envoyer tous les attributs spécifiés par l’attribut "notifier les attributs". Note : si l’imprimante ne prend pas en charge l’attribut "notifier les attributs", il n’est pas présent sur l’objet d’abonnement associé.
Pour les notifications d’événement d’événements de tâche, l’imprimante inclut les attributs supplémentaires indiqués au Tableau 4.
Tableau 4. Attributs supplémentaires dans le contenu de notification d’événement pour les événements de tâche
|
Valeur de source |
Envoi |
Objet de source |
|
Identifiant de tâche (entier(1:MAX)) |
DOIT |
tâche |
|
Etat de tâche (énumération de type1) |
DOIT |
tâche |
|
Causes de l’état de tâche (1setOf mot clé de type2) |
DOIT |
tâche |
|
tâches d’impressions terminées (entier(0:MAX)) |
DOIT * |
tâche |
* L’imprimante ne DOIT envoyer l’attribut "tâches d’impressions terminées" dans une notification d’événement que pour les combinaisons d’événements et d’événements abonnés indiqués au Tableau 5.
Tableau 5. Combinaisons d’événements et d’événements abonnés pour "tâches d’impression terminées"
|
Evénement de tâche |
Evénement de tâche
abonné |
|
'avancement de tâche' |
'avancement de tâche' |
|
'tâche terminée' |
'tâche terminée' |
|
'tâche terminée' |
'changement d’état de tâche' |
Pour une notification d’événement d’événements d’imprimante, l’imprimante inclut les attributs supplémentaires indiqués au Tableau 6.
Tableau 6. Attributs supplémentaires dans le contenu de notification d’événement pour les événements d’imprimante
|
Valeur de source |
Envoi |
Objet de source |
|
état d’imprimante (énumération de type1) |
DOIT |
imprimante |
|
causes d’état d’imprimante (1setOf mot clé de type2) |
DOIT |
imprimante |
|
l’imprimante accepte les tâches (booléen) |
DOIT |
imprimante |
La méthode de livraison ‘ippget’ ne définit aucun attribut supplémentaire de gabarit d’abonnement et ses exigences de conformité pour les attributs de gabarit d’abonnement sont définis dans la [RFC3995]. La présente section définit des informations supplémentaires sur les attributs de gabarit d’abonnement définis dans la [RFC3995].
Cet attribut de gabarit d’abonnement identifie la méthode de livraison tirée à utiliser pour l’objet d’abonnement (voir la [RFC3995]). Pour prendre en charge la méthode de livraison tirée 'ippget' définie dans le présent document, l’imprimante DOIT prendre en charge cet attribut avec la valeur de mot clé suivante :
'ippget' : indique que la méthode de livraison tirée 'ippget' est à utiliser pour cet objet d’abonnement.
Les exigences de conformité de la méthode de livraison ‘ippget’ pour les attributs de description d’abonnement sont définies dans la [RFC3995]. La méthode de livraison ‘ippget’ ne définit aucun attribut de description d’abonnement supplémentaire.
La présente section définit des attributs de description d’imprimante supplémentaires à utiliser avec la méthode de livraison ‘ippget’.
Cet attribut de description d’imprimante spécifie la valeur de durée de vie d’événement que l’imprimante alloue à chaque événement ; c’est-à-dire, le nombre de secondes après la survenue d’un événement durant lesquelles une imprimante va retourner cet événement dans une notification d’événement d’une réponse à Obtenir les notifications. Après l’expiration de la durée de vie d’événement pour cet événement, l’imprimante ne PEUT plus retourner une notification d’événement pour cet événement dans une réponse à Obtenir les notifications.
L’imprimante DOIT prendre en charge cet attribut si elle prend en charge la méthode de livraison ‘ippget’. La valeur DOIT être 15 ou plus (au moins 15 secondes), et 60 (secondes) est la valeur RECOMMANDÉE pour s’aligner sur les objets jmGeneralJobPersistence et jmGeneralAttributePersistence du MIB de surveillance de tâche PWG de la [RFC2707].
Par exemple, en supposant ce qui suit :
1. un client effectue une opération Création de tâche qui crée un objet d’abonnement associé à la méthode de livraison ‘ippget’ ;
2. un événement associé à la nouvelle tâche survient immédiatement après la création de l’objet d’abonnement ;
3. le même client ou un autre client effectue une opération Obtenir les notifications de sorte que le client est connecté N secondes après l’opération Création de tâche.
Alors, si N est inférieur à la valeur de cet attribut, le ou les clients effectuant l’opération Obtenir les notifications peut s’attendre à ne manquer aucune Notification d’événement, interdisant tout manque d’espace mémoire imprévu de l’imprimante. Note : le client DOIT initialiser les Obtenir les notifications à un temps suffisamment inférieur à N secondes pour tenir compte du délai de latence du réseau de sorte qu’il soit connecté à l’imprimante avant que N secondes ne s’écoulent.
Si une imprimante prend en charge la méthode de livraison ‘ippget’, elle DOIT garder les objets tâche 'terminé', 'annulé', ou 'avorté' dans les phases de Rétention de tâche et/ou Historique de tâche pendant au moins aussi longtemps que la valeur de cet attribut. L’imprimante PEUT conserver des tâches plus longtemps que cette valeur. Voir au paragraphe 4.3.7.1 de la [RFC2911], et la discussion dans la [RFC3995] (concernant l’événement 'tâche terminée'). Cette dernière explique qu’un récepteur de notification peut interroger les tâches après avoir reçu une notification d’événement 'tâche terminée' afin de trouver d’autres informations sur la tâche qui est 'terminée', 'avortée', ou 'annulée'. Cependant, cet attribut n’a pas d’effet sur l’opération Annuler l’abonnement, qui supprime l’objet d’abonnement immédiatement qu’il contienne ou non l’attribut "notifier la méthode tirée" avec la valeur de mot clé 'ippget'. Immédiatement après cela, les réponses à Obtenir les notifications NE DOIVENT PAS contenir de notifications d’événement associées à l’objet d’abonnement annulé.
La présente section définit des valeurs supplémentaires pour les attributs existants de description d’imprimante, comme définit dans la [RFC3995].
La valeur de mot clé suivante pour l’attribut "notifier la méthode tirée prise en charge" est ajoutée afin de prendre en charge la nouvelle méthode de livraison définie dans le présent document :
'ippgget' : méthode de livraison tirée de notification IPP définie dans le présent document.
Le Tableau 7 fait la liste des valeurs de "identifiant d’opération" définies afin de prendre en charge la nouvelle opération Obtenir les notifications définie dans le présent document.
Tableau 7. Allocation de l’identifiant d’opération
|
Valeur |
Nom d’opération |
|
0x001C |
Get-Notifications |
Le code d’état suivant est défini comme extension pour cette méthode de livraison et il est retourné comme le code d’état de l’opération Obtenir les notifications dans le groupe 1 ou les groupes 3 à N (voir le paragraphe 5.2).
L’imprimante DOIT retourner le code d’état 'réussite-ok, événements terminés' pour indiquer lorsque cette réponse à Obtenir des notifications est la dernière réponse pour un objet d’abonnement, que des notifications d’événement soient retournées ou non. Cette condition survient pour le mode d’attente d’événement avec les récepteurs de notification qui attendent des réponses lorsque (1) l’objet d’abonnement est annulé par une opération Annuler l’abonnement, (2) l’objet d’abonnement est supprimé, quand la location d’abonnement par imprimante arrive à expiration, ou (3) l’événement 'tâche terminée' survient pour un abonnement par tâche. Cette condition survient aussi pour une demande Obtenir les notifications que fait un récepteur de notification près l’achèvement de la tâche, mais avant l’expiration de la durée de vie de l’événement.
La présente section définit les questions de codage et de transport pour cette méthode de livraison sur la base de la [RFC2910].
Le codage d’une réponse à Obtenir les notifications est effectué après la réponse à Obtenir les tâches (voir la [RFC2911]). Dans une réponse à Obtenir les notifications, chaque groupe d’attributs de notification d’événement DOIT débuter par une 'étiquette d’attributs de notification d’événement' (voir la section "Codage des étiquettes d’attribut supplémentaires" dans la [RFC3995]), et finir par une 'étiquette de fin des attributs'. De plus, pour le mode d’attente d’événement, ce qui se rapport au multi partie sert à séparer chaque réponse multiple (dans le temps) en une seule demande Obtenir les notifications.
L’imprimante retourne la réponse à Obtenir les notifications comme suit :
1. Si le client Récepteur de notification n’a pas demandé le mode d’attente d’événement ("notifier l’attente" = 'faux' ou omis), l’imprimante envoie la réponse avec un 'fin d’étiquette d’attributs' (voir le codage de Obtenir les tâches dans la [RFC2911]), comme dans toute réponse d’opération.
2. Si le client Récepteur de notification demande le mode d’attente d’événement ("notifier l’attente" = 'vrai') et si l’imprimante souhaite satisfaire la demande, l’imprimante DOIT retourner la réponse comme une partie application/ipp à l’intérieur d’un type de support MIME multi partie. Lorsque surviennent un ou plusieurs événements supplémentaires, l’imprimante retourne chacun comme un groupe supplémentaire de notification d’événement en utilisant une partie distincte d’application/ipp sous le type se rapportant à multi part.
3. Si le client a demandé le mode d’attente d’événement ("notifier l’attente" = 'vrai'), mais que l’imprimante ne souhaite pas satisfaire la demande dans la réponse initiale et veut que le client interroge explicitement les notifications d’événement, l’imprimante DOIT retourner l’attribut d’opération "notifier obtenir l’intervalle" (voir le paragraphe 5.2.1). L’imprimante retourne la réponse comme une partie application/ipp qui PEUT être à l’intérieur d’un type se rapportant à multi-partie. Le client DOIT accepter cette réponse et reformuler la demande Obtenir les notifications dans un délai indiqué par la valeur de l’attribut "notifier obtenir l’intervalle".
4. Si le client a demandé le mode d’attente d’événement ("notifier l’attente" = 'vrai'), et si l’imprimante a d’abord satisfait la demande mais souhaite ensuite quitter le mode d’attente d’événement, l’imprimante DOIT retourner l’attribut d’opération "notifier obtenir l’intervalle" (voir le paragraphe 5.2.1). L’imprimante retourne la réponse comme une partie d’application/ipp qui DOIT être à l’intérieur d’un type se rapportant à multi partie.
NOTE : Si un récepteur de notification échoue à recevoir une réponse, il peut redemander à l’imprimante les mêmes notifications d’événement. Le récepteur de notification va recevoir les mêmes notifications d’événement qu’il aurait dû recevoir la première fois, excepté les notifications d’événement qui sont arrivées à expiration dans l’intervalle.
L’imprimante PEUT regrouper les réponses, mais cela n’a pas d’incidence sur la sémantique IPP.
Cette méthode de livraison de notification utilise le transport et codage IPP de la [RFC2910] pour l’opération Obtenir les notifications avec l’extension suivante, allouée dans la [RFC3995] :
Tableau 8. Valeur de "étiquette des attributs de notification d’événement"
|
Valeur d’étiquette (Hex) |
Signification |
|
0x07 |
"event-notification-attributes-tag" |
La présente section fait la liste des exigences de conformité pour les clients et les imprimantes.
Il est FACULTATIF pour une imprimante de prendre en charge les notifications IPP telles que définies dans la [RFC3995]. Cependant, si une imprimante prend en charge les notifications IPP, l’imprimante DOIT prendre en charge la méthode de livraison ‘ippget’, comme défini dans le présent document, comme une de ses méthodes de livraison. Les imprimantes IPP qui sont conformes à la présente spécification :
1. DOIVENT satisfaire aux exigences de conformité définies dans la [RFC3995] pour une méthode de livraison tirée ;
2. DOIVENT prendre en charge l’opération Obtenir les notifications définie à la section 5, y compris le mode d’attente d’événement ;
3. DOIVENT prendre en charge les attributs d’objet Gabarit d’abonnement, comme défini à la section 6 ;
4. DOIVENT prendre en charge les attributs d’objet Description d’abonnement, comme défini à la section 7 ;
5. DOIVENT prendre en charge l’attribut de description d’imprimante "durée de vie d’événement ippget" défini au paragraphe 8.1, y compris de conserver les tâches dans les phase Rétention de tâche et/ou Historique des tâches pour au moins aussi longtemps que la valeur spécifiée par le "durée de vie d’événement ippget" de l’imprimante ;
6. DOIVENT prendre en charge les valeurs supplémentaires des attributs de description d’imprimante IPP/1.1 définis dans la section 9 ;
7. DOIVENT prendre en charge le code d’état 'réussite-ok, événements terminés', comme décrit au paragraphe 10.1 ;
8. DOIVENT surveiller les demandes d’opération IPP Obtenir les notifications sur le port bien connu 631 alloué par l’IANA, sauf configuration explicite par les administrateurs du système ou les politiques du site ;
9. NE DEVRAIT PAS surveiller les demandes d’opération IPP Obtenir les notifications sur tout autre port, sauf configuration explicite par les administrateurs du système ou les politiques du site ; et
10. DOIVENT satisfaire aux exigences de conformité à la sécurité établies au paragraphe 18.4.
Il est FACULTATIF pour un client IPP de prendre en charge les notifications IPP telles que définies dans la [RFC3995]. Cependant, si un client prend en charge les notifications IPP, le client DOIT prendre en charge la méthode de livraison ‘ippget’ telle que définie dans le présent document comme une de ses méthodes de livraison. Les clients IPP qui se conforment à la présente spécification :
1. DOIVENT créer des objets d’abonnement en envoyant des demandes d’opération de création d’abonnement contenant l’attribut "notifier la méthode tirée" (par opposition à l’attribut "notifier l’uri du récepteur") en utilisant la valeur de mot clé 'ippget' (voir les paragraphes 6.1 et 15.2) ;
2. DOIT envoyer les demandes d’opération IPP Obtenir les notifications (voir le paragraphe 5.1) via le port spécifié dans l’URL 'ipp' associé (s’il est présent) ou autrement le port bien connu 631 alloué par l’IANA ;
3. DOIT convertir les URL 'ipp' associés pour utilisation dans les opérations IPP Obtenir les notifications en leurs formes correspondantes d’URL 'http' pour utilisation dans la couche http, conformément aux règles de la section 5, "Schéma d’URL IPP", de la [RFC2910] ; et
4. DOIT satisfaire aux exigences de conformité à la sécurité établies au paragraphe 18.5.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" (Mots clé à utiliser dans les RFC pour indiquer les niveaux d’exigence), BCP 14, RFC 2119, mars 1997.
[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. and 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., and 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 2568, avril 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols" (Transposition entre les protocoles LPD et IPP), RFC 2569, avril 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1" (Protocole de transfert hypertexte – HTTP/1.1), RFC 2616, juin 1999.
[RFC2707] Bergman, R., Hastings, T., Isaacson, S., and H. Lewis, "Job Monitoring MIB - V1.0" (MIB de surveillance de tâche – V1.0), RFC 2707, novembre 1999.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and 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.
[RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, "Internet Printing Protocol (IPP): Requirements for IPP Notifications" (Protocole d’impression sur Internet (IPP)°: Exigences pour les notifications IPP), RFC 3997, mars 2005.
La présente section contient les informations exactes que l’IANA a ajouté aux registres IPP conformément aux procédures définies à la section 6 de la [RFC2911]. Ces enregistrements ont été publiés dans le registre http://www.iana.org/assignments/ipp-registrations.
Le tableau suivant fait la liste des attributs définis dans le présent document. Cela a été enregistré conformément aux procédures du paragraphe 6.2 de la RFC 2911 [RFC2911].
|
Attributs
de description d’imprimante |
Référence |
Section |
|
ippget-event-life
(integer(15:MAX)) |
[RFC3996] |
8.1 |
La présente section fait la listes des enregistrements de valeur d’attribut de mot clé supplémentaires à utiliser avec les attributs existants définis dans d’autres documents. Ils ont été enregistrés conformément aux procédures du paragraphe 6.1 de la [RFC2911]. Conformément au paragraphe 24.7.3 de la [RFC3995], les enregistrements de méthode de livraison tirée sont les enregistrements de valeur d’attribut de mot clé pour les attributs "notifier la méthode tirée" et "notifier la méthode tirée prise en charge".
|
Valeurs
d’attribut (syntaxe d’attribut) |
Référence |
Section |
|
notifier
la méthode tirée (mot clé de type2) |
[RFC3995] |
5.3.2 |
|
notifier
la méthode tirée prise en charge (1setOf mot clé de type2) |
[RFC3995] |
5.3.2.1 |
|
Ippget |
[RFC3996] |
9.1 |
Le tableau suivant fait la liste des valeurs d’attribut enum définies dans le présent document. Celles-ci ont été enregistrées conformément aux procédures du paragraphe 6.1 de la [RFC2911].
|
Valeur
de l’attribut (syntaxe d’attribut)
Nom de l’attribut |
Référence |
Section |
|
opérations
prise en charge (1setOf énumération de type2) |
[RFC2911] |
4.4.15 |
|
0x001C Obtenir
les notifications |
[RFC3996] |
9.2 |
Le tableau suivant fait la liste des opérations définies dans le présent document. Cela a été enregistré conformément aux procédures du paragraphe 6.4 de la RFC 2911 [RFC2911].
|
Opérations: |
Référence |
Section |
|
Obtenir
les notifications |
[RFC3996] |
5 |
Le tableau suivant fait la liste des codes d’état définis dans le présent document. Cela a été enregistré conformément aux procédures du paragraphe 6.6 de la [RFC2911].
|
Codes
d’état : |
Référence |
Section |
|
réussite-ok,
événements terminés (0x0007) |
[RFC3996] |
10.1 |
L’imprimante IPP DOIT localiser l’attribut "notifier le texte" comme spécifié à la section 14 de la [RFC3995].
De plus, lorsque le client reçoit la réponse à Obtenir les notifications, il est censé localiser les attributs qui ont l’attribut 'mot clé' conforme au charset et au langage naturel requis dans la demande Obtenir les notifications.
Le document Modèle et sémantique IPP [RFC2911, section 8] discute des exigences de sécurité de haut niveau (authentification du client, authentification du serveur et confidentialité du fonctionnement). Le document Transport et codage IPP [RFC2910, section 8] discute des exigences de sécurité pour le protocole IPP. L’authentification du client est le mécanisme par lequel le client prouve son identité au serveur d’une manière sécurisée. L’authentification du serveur est le mécanisme par lequel le serveur prouve son identité au client d’une manière sécurisée. La confidentialité du fonctionnement se définit comme un mécanisme pour la protection des opérations contre l’espionnage.
La méthode de livraison ‘ippget’ avec ses opérations Obtenir les notifications élève les mécanismes de sécurité qui sont utilisés dans IPP/1.1 [RFC2910 et RFC2911] sans ajouter aucun mécanisme de sécurité supplémentaire afin de maintenir la même prise en charge de la sécurité que dans IPP/1.1.
Le modèle de contrôle d’accès pour l’opération Obtenir les notifications définie dans le présent document est le même que le modèle de contrôle d’accès pour l’opération Obtenir les attributs de tâche (voir le paragraphe 3.2.6 de la [RFC2911]). La principale différence est que l’opération Obtenir les notifications vise les objets d’abonnement plutôt que les objets tâche, et qu’un groupe d’attributs retourné contient les attributs de notification d’événement plutôt que les attributs d’objet tâche.
Le client récepteur de notification DOIT avoir les droits d’accès suivants à l’objet d’abonnement visé par la demande d’opération Obtenir les notifications :
L’utilisateur authentifié (voir la paragraphe 8.3 de la [RFC2911]) effectuant cette opération DOIT être (1) le propriétaire de chaque objet d’abonnement identifié par l’attribut d’opération "notifier les identifiants d’abonnement" (voir le paragraphe 5.1.1), (2) un opérateur ou administrateur de l’imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) autrement autorisé par alla politique de sécurité configurée par l’administrateur de l’imprimante à demander des notifications d’événement à partir du ou des objets d’abonnement visés. De plus, la politique de sécurité de l’imprimante PEUT limiter les attributs retournés par l’opération Obtenir les notifications, de façon similaire à celle de l’opération Obtenir les attributs de tâche (voir la [RFC2911], fin du paragraphe 3.3.4.2).
Parce que l’opération Obtenir les notifications est envoyée dans la même direction que les opérations Création de tâche, et généralement par le même client, cette méthode de livraison de notification d’événement ne pose aucune question supplémentaire d’authentification, d’autorisation, de confidentialité, de pare-feu, ou d’allocation de port en plus de celles des opérations des attributs Obtenir les attributs de tâche et Obtenir les attributs d’imprimante d’IPP (voir les paragraphes 3.2.6 et 3.2.5 de la [RFC2911]).
Notifications d’événement non désirées (spam) : à la différence des méthodes de livraisons poussées de notification d’événement dans lesquelles l’imprimante IPP prend l’initiative de la notification d’événement, avec la méthode de livraison tirée définie dans le présent document, le récepteur de notification est le client qui initie l’opération Obtenir les notifications (voir la section 5). Donc, avec cette méthode il n’y a aucun risque de notifications "spam".
Note : Lorsqu’un client reste connecté à une imprimante en utilisant le mode d’attente d’événement (voir le paragraphe section 5.1.3) afin de recevoir les notifications d’événement au fur et à mesure qu’elle surviennent, il peut fermer à tout moment la connexion IPP et ainsi éviter de futures notifications d’événement non désirées.
Il es vrai que le client a le contrôle sur la demande des notifications d’événement. Cependant, si le client s’abonne à un événement et fait une demande Obtenir les notifications, il obtient tous les événements pour l’objet d’abonnement dans la gamme de numéros de séquence (voir le paragraphe 5.1.2), et non pas seulement ceux qu’il veut. Si un client s’abonne à un événement de tâche d’abonnement par imprimante, tel que 'tâche terminée', et que quelqu’un commence alors et annule des milliers de tâches, le client devra alors recevoir ces événements en plus de ceux qui l’intéressent. Un client peut se protéger mieux en s’abonnant à ses propres tâches en utilisant un abonnement par tâche, plutôt que de créer un abonnement par imprimante dont les événements de tâche s’appliquent à toutes les tâches.
Pour l’opération Obtenir les notifications définie dans le présent document, s’appliquent les mêmes exigences de sécurité d’imprimante qui figurent à la section 8 de la [RFC2910] pour la prise en charge et l’utilisation de l’authentification de client, l’authentification du serveur le la confidentialité du fonctionnement pour toutes les opérations IPP.
Pour l’opération Obtenir les notifications définie dans le présent document, s’appliquent les mêmes exigences de sécurité de client qui figurent à la section 8 de la [RFC2910] pour la prise en charge et l’utilisation de l’authentification de client, l’authentification du serveur le la confidentialité du fonctionnement pour toutes les opérations IPP.
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’ETF.
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).
Carl Kugler et Harry Lewis ont contribué à l’idée de base d’une "interrogation intelligente" dans la bande couplée à des réponses multiples pour une seule opération sur la même connexion, avec une réponse pour chaque événement dès qu’il survient. Sans leur persuasion et leur persévérance, nous ne serions pas arrivés à cette spécification de méthode de livraison et n’aurions pas été capables de nous mettre d’accord sur une seule méthode de livraison EXIGÉE pour IPP.
Carl Kugler
IBM Corporation
6300 Diagonal Highway
Boulder, CO 80301
mél : kugler@us.ibm.com
Adresse des auteurs
|
Robert Herriot |
Tomas Hastings |
Harry Lewis |
|
Global Workflow Solutions |
Xerox Corporation |
IBM Corporation |
|
706 Colorado Ave. |
701 S Aviation Blvd, ESAE 242 |
6300 Diagonal Hwy |
|
Palo Alto, CA 94303 |
El Segundo, CA 90245 |
Boulder, CO 80301 |
|
tél : 650-324-4000 |
tél ::
310-333-6413 |
tél :: (303)
924-5337 |
|
mél: bob@herriot.com |
Mél: hastings@cp10.es.xerox.com |
email: harryl@us.ibm.com |
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.