|
Groupe de travail Réseau |
R. Herriot |
|
Request for Comments : 3995 |
Global Workflow Solutions |
|
Catégorie : Standards Track |
T. Hastings |
|
Mise à jour de : 2911, 2910 |
Xerox Corporation |
Mars 2005
Protocole d’impression Internet (IPP) : Notifications d’événements et abonnements
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 FACULTATIVE au protocole d’impression Internet/1.1 : Modèle et sémantique (RFC 2911, RFC 2910). Cette extension permet à un client de s’abonner aux événements relatifs à l’impression. Les abonnements sont modélisés comme objets d’abonnement. L’objet d’abonnement spécifie que lorsque survient un des événements spécifiés, l’imprimante délivre une Notification d’événement asynchrone au récepteur de notification spécifié via la méthode spécifiée de livraison poussée ou tirée (c’est-à-dire, le protocole).
Un client associe les objets d’abonnement à une tâche particulière en effectuant l’opération Create-Job-Subscriptions (créer des abonnements de tâches) ou en soumettant une tâche avec des informations d’abonnement. Un client associe des objets d’abonnement à l’imprimante en effectuant une opération Create-Printer-Subscriptions (créer des abonnements d’imprimante). Quatre autres opérations sont définies pour les objets d’abonnement : Get-Subscriptions-Attributes (obtenir des attributs d’abonnement), Get-Subscriptions (obtenir des abonnements), Renew-Subscription (renouveler l’abonnement), et Cancel-Subscription (annuler l’abonnement).
Table des matières
1.1 Généralités sur la notification
2.1 Modèle pour Notification Simple
(normatif)
2.2 Modèles supplémentaires pour
Notification (Informatifs)
3.1 Terminologie de conformité
4.1 Objets d’abonnement imprimante et
par-imprimante
4.2 Objets d’abonnement imprimante,
tâche et par-tâche
5.1 Règles de prise en charge des
attributs de gabarit d’abonnement
5.2 Règles de traitement des attributs
de gabarit d’abonnement
5.3 Les attributs de gabarit d’abonnement
5.3.1 notify-recipient-uri (uri)
5.3.2 notify-pull-method (type2
keyword)
5.3.3 notify-events (1setOf type2
keyword)
5.3.4 notify-attributes (1setOf type2
keyword)
5.3.5 notify-user-data
(octetString(63))
5.3.6 notify-charset (charset)
5.3.7 notify-natural-language
(naturalLanguage)
5.3.8 notify-lease-duration (entier de
0 à 67108863)
5.3.9 notify-time-interval (entier de 0
à MAX)
5.4 Attributs de description
d’abonnement
5.4.1 notify-subscription-id (entier de
1 à MAX))
5.4.2 notify-sequence-number (entier de
0 à MAX)
5.4.3 notify-lease-expiration-time
(entier de 0 à MAX)
5.4.4 notify-printer-up-time (entier de
1 à MAX)
5.4.5 notify-printer-uri (uri)
5.4.6 notify-job-id (entier de 1 à MAX)
5.4.7 notify-subscriber-user-name
(name(MAX))
6 Attributs de description
d’imprimante en rapport avec la notification
6.1 printer-state-change-time (entier
de 1 à MAX)
6.2 printer-state-change-date-time
(date et heure)
7 Nouvelles valeurs pour les
attributs existants de description d’imprimante
7.1 operations-supported (1setOf type2
enum)
8 Attributs pour les seules
notification d’événements
8.1 notify-subscribed-event (type2
keyword)
9 Contenu de notification d’événement
9.1 Contenu des notifications
d’événement à destination machine
9.1.1 Contenu de notification
d’événement commun à tous les événements
9.1.2 Contenu supplémentaire de notification
d’événement pour événements de tâche
9.1.3 Contenu supplémentaire de
notification d’événement pour événements d’imprimante
9.2 Contenu de notification
d’événement à destination humaine
9.2.1 Contenu de notification
d’événement commun à tous les événements
9.2.2 Contenu supplémentaire de
notification d’événement pour les événements de tâche
9.2.3 Contenu supplémentaire de
notification d’événement pour les événements d’imprimante
11 Opérations pour Notification
11.1 Opérations de création d’abonnement
11.1.1 Opération Créer des abonnements de
tâche
11.1.2 Opération Create-Printer-Subscriptions
11.1.3 Opération de création de tâche -
extensions pour Notification
11.2.1 Opération Restart-Job - extensions
pour Notification
11.2.2 Opération Validate-Job - extensions
pour Notification
11.2.3 Get-Printer-Attributes - extensions
pour Notification
11.2.4 Opération
Get-Subscription-Attributes
11.2.5 Opération Get-Subscriptions
11.2.6 Opération Renew-Subscription
11.2.7 Opération Cancel-Subscription
12.1 successful-ok-ignored-subscriptions
(0x0003)
12.2 client-error-ignored-all-subscriptions
(0x0414)
13 Codes d’état dans les groupes
d’attributs d’abonnement
13.1 client-error-uri-scheme-not-supported
(0x040C)
13.2 client-error-attributes-or-values-not-supported
(0x040B)
13.3 client-error-too-many-subscriptions
(0x0415)
13.4 successful-ok-too-many-events
(0x0005)
13.5 successful-ok-ignored-or-substituted-attributes
(0x0001)
14 Codages des étiquettes d’attribut
supplémentaire
15.1 Exigences de conformité pour les
clients
15.2 Exigences de conformité pour les
imprimantes
16 Modèle pour Notification avec des
imprimantes en cascade (pour information)
17 Modèle distribué pour
Notification (pour information)
18 Récepteur de notification étendu
(pour information)
19 Modèle d’objet pour Notification
(Normatif)
19.2 Objet imprimante et objets
d’abonnement par imprimante
19.3 Objet tâche et objets d’abonnement
par tâche
20 Objets d’abonnement par tâche et
par imprimante (normatif)
23.1 Enregistrement d’attribut
23.2 Enregistrements des valeurs
d’attribut d’énumération supplémentaires au sein du registre IPP
23.3 Enregistrements d’opérations
23.4 Enregistrements de code d’état
23.5 Enregistrements d’étiquette de
groupe d’attribut
23.6 Enregistrements d’événements
23.7 Enregistrements des méthodes de
livraison de notification d’événement
23.7.1 Exigences pour l’enregistrement des
méthodes de livraison de notification d’événement
23.7.3 Enregistrement de document de
méthode de livraison
23.7.4 Gabarit d’enregistrement
24 Considérations internationales
25 Considérations sur la sécurité
25.2 Menaces sur la sécurité des
imprimantes
25.3 Menaces sur la sécurité du récepteur
de notification
26 Description des documents de base
IPP (pour information)
Tableaux
Figures
La présente spécification de notification IPP est une extension FACULTATIVE au protocole d’impression Internet/1.1 : Modèle et sémantique [RFC2911, RFC2910]. Voir à l’Appendice 29 une description des documents IPP de base. Le présent document combiné avec les documents suivants est destiné à satisfaire les plus importantes exigences de notification décrites dans la [RFC3997] :
Protocole d’impression Internet (IPP) : "Attributs d’avancement de tâche" [RFC3381]
Protocole d’impression Internet (IPP) : "Méthode de livraison 'ippget' pour les notifications d’événement" [RFC3996]
La présente spécification EXIGE que les clients et les imprimantes prennent en charge la méthode de livraison poussée 'ippget' [RFC3996]. Les clients et les mises en œuvre d’imprimante conformes PEUVENT aussi prendre en charge des méthodes de livraison poussées ou tirées supplémentaires.
Note : le présent document ne définit lui-même aucune méthode de livraison , mais définit les règles de conformité pour les documents de méthode de livraison et leur enregistrement auprès de l’IANA (voir au paragraphe 23.7.3).
Se reporter à la Table des matières pour la disposition du présent document.
Le présent document définit les opérations qu’un client peut effectuer afin de créer des objets d’abonnement dans une imprimante et transporter sur eux d’autres opérations. Un objet d’abonnement représente un abonnement abstrait. L’objet d’abonnement spécifie que quand survient un des événements spécifiés, l’imprimante délivre une notification d’événement asynchrone au récepteur de notification spécifié via la méthode de livraison spécifiée (c’est-à-dire, le protocole).
Lorsqu’un client (qu’on appelle client d’abonnement) effectue une opération qui crée un objet d’abonnement, l’opération contient un ou plusieurs groupes d’attributs de gabarit d’abonnement. Chacun de ces groupes contient les informations utilisées par l’imprimante pour initialiser un objet d’abonnement nouvellement créé. L’imprimante crée un objet d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement de l’opération. Ce groupe est comme le groupe d’attributs de gabarit de tâche défini dans la [RFC2911].
Ce qui suit est un exemple des informations contenues dans un groupe d’attributs de gabarit d’abonnement (voir à la section 5 les précisions sur les attributs d’objet d’abonnement) :
1. Les noms des événements abonnés qui sont intéressants pour le récepteur de notification.
2. L’adresse (URL) d’un récepteur de notification pour une méthode de livraison Poussée ou la méthode pour une méthode de livraison Tirée.
3. La méthode de livraison (c’est-à-dire, le protocole) qu’utilise l’imprimante pour délivrer la notification d’événement.
4. Certaines données opaques que l’imprimante délivre au récepteur de notification dans la notification d’événement. Par exemple, le récepteur de notification peut utiliser ces données opaques comme adresse de transmission pour la notification d’événement.
5. Le charset (ensemble de caractères) à utiliser dans les champs de texte au sein d’une notification d’événement
6. Le langage naturel à utiliser dans les champs de texte de la notification d’événement
7. Le temps d’occupation demandé en secondes pour l’objet d’abonnement
Une opération qui crée un objet d’abonnement s’appelle une opération de création d’abonnement. Ces opérations incluent les opérations suivantes (voir au paragraphe 11.1 pour d’autres précisions) :
- Opération de création de tâche (Create-Job) : Lorsqu’un client effectue une telle opération (Print-Job, Print-URI, et Create-Job), il peut inclure zéro ou plus groupes d’attributs de gabarit d’abonnement dans la demande. L’imprimante crée un Objet d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement dans la demande, et l’imprimante associe chacun de ces Objets d’abonnement à la tâche nouvellement créée. Le présent document étend ces définitions d’opérations de la [RFC2911] en ajoutant des groupes d’attributs de gabarit d’abonnement dans la demande et des groupes d’attributs d’abonnement dans la réponse.
- Opération d’abonnement de création de tâche (Create-Job-Subscriptions) : Un client peut inclure un ou plusieurs groupes d’attributs de gabarit d’abonnement dans la demande. L’imprimante crée un objet d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement et l’associe à la tâche qui est le but de cette opération.
- Opération d’abonnement de création d’imprimante (Create-Printer-Subscriptions) : Un client peut inclure un ou plusieurs groupes d’attributs de gabarit d’abonnement dans la demande. L’imprimante crée un objet d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement et l’associe à l’imprimante qui est la cible de cette opération.
Pour chacune des opérations ci-dessus :
- l’imprimante associe un objet d’abonnement à l’imprimante ou une tâche spécifique. Lorsqu’un objet d’abonnement est associé à un objet tâche, il est appelé objet d’abonnement par tâche. Lorsqu’un objet d’abonnement est associé à un objet imprimante, il est appelé objet d’abonnement par imprimante.
- la réponse contient un groupe d’attributs d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement de la demande et dans le même ordre. Lorsque l’imprimante réussit à créer un Objet d’abonnement, son groupe d’attributs d’abonnement correspondant contient l’attribut "notify-subscription-id" (identifiant d’abonnement de notification). Cet attribut identifie de façon univoque l’objet d’abonnement et il est analogue à un "job-id" (identifiant de tâche) pour un objet tâche. Certaines des opérations décrites ci-dessous utilisent le "notify-subscription-id" pour identifier l’objet d’abonnement cible.
Le présent document définit les opérations supplémentaires suivantes (voir au paragraphe 11.2 pour d’autres précisions) :
- opération Restart-Job (recommencer la tâche) : Lorsqu’un client effectue l’opération Restart-Job [RFC2911], l’imprimante réutilise la même tâche et ses objets d’abonnement.
- opération Validate-Job (valider la tâche) : Lorsqu’un client effectue cette opération, il peut inclure zéro ou plus groupes d’attributs de gabarit d’abonnement dans la demande. L’imprimante détermine si elle pourrait créer un objet d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement dans la demande. Le présent document étend cette définition d’opération de la [RFC2911] en ajoutant des groupes d’attributs de gabarit d’abonnement dans la demande et des groupes d’attributs d’abonnement dans la réponse.
- opération Get-Subscription-Attributes (obtenir les attributs d’abonnement) : Cette opération permet à un client d’obtenir les attributs spécifiés d’un objet d’abonnement cible.
- opération Get-Subscriptions (obtenir les abonnements) : Cette opération permet à un client d’obtenir les attributs spécifiés de tous les objet d’abonnements associés à l’imprimante ou à une tâche spécifiée.
- opération Renew-Subscription (renouveler l’abonnement) : Cette opération renouvelle la location sur l’objet d’abonnement par imprimante cible avant qu’il n’expire. Un objet d’abonnement par imprimante nouvellement créé reçoit une location initale. Il est du devoir du client d’utiliser suffisamment fréquement cette opération pour préserver un objet d’abonnement par imprimante. L’imprimante supprime un objet d’abonnement par imprimante lorsque sa location arrive à expiration. Un objet d’abonnement par tâche dure exactement aussi longtemps que son objet tâche associé et n’a donc pas de location.
- opération Cancel-Subscription (supprimer l’abonnement) : Cette opération (1) annule la location de l’objet d’abonnement par imprimante spécifié et ainsi supprime l’objet d’abonnement par imprimante ou (2) supprime l’objet d’abonnement par tâche.
Lorsque survient un événement, l’imprimante trouve tous les objets d’abonnement qui surveillent cet événement (voir au paragraphe 9 des précisions sur comment trouver de tels objets d’abonnement). Pour chacun de ces objets d’abonnement, l’imprimante :
a) génère une notification d’événement avec les informations spécifiées à la section 9, ET
b) soit :
i) Si la méthode de livraison est une méthode de livraison poussée comme indiqué par la présence de l’attribut "notify-recipient-uri" de l’objet d’abonnement, délivre la notification d’événement en utilisant la méthode de livraison et l’adresse cible identifiée dans l’attribut "notify-recipient-uri" de l’objet d’abonnement, OU
ii) Si la méthode de livraison est une méthode de livraison tirée comme indiqué par la présence de l’attribut "notify-pull- method" de l’objet d’abonnement, sauvegarde la notification d’événement pour une période de temps appelée durée de vie d’événement définie par la méthode de livraison, c’est-à-dire que le récepteur de notification est censé amener les notifications d’événement.
Au titre d’une opération de création d’abonnement, une imprimante IPP (c’est-à-dire, localisée dans un appareil extérieur ou un serveur) crée un ou plusieurs objets d’abonnement. Dans une opération de création d’abonnement, le client spécifie le récepteur de notification auquel l’imprimante doit délivrer les notifications d’événement. Un récepteur de notification peut être le Client abonné ou une tierce partie.
La Figure 1 donne le modèle de notification pour une relation simple Client-imprimante.
Imprimante incorporée :
Appareil extérieur ou serveur
PDA, de bureau, ou serveur +---------------+
+--------+ | ########### |
| client |-----Opération ---------># Objet # |
+--------+ de création d’abonnement| #imprimante# |
+------------+ | #####|##### |
|Récepteur de| +-------|--------+
|notification|<----notifications d’événement IPP -----+
+------------+ (événements de tâche et/ou d’imprimante)+
Figure 1 - Modèle pour Notification
Des modèles supplémentaires ont été proposés (voir aux Appendices 16, 17, et 18).
La présente section définit la terminologie utilisée tout au long du présent document. D’autres éléments de terminologie sont définis dans la [RFC2911].
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.
Note : une caractéristique qui est FACULTATIVE dans le présent document devient EXIGÉ si l’imprimante met en œuvre une méthode de livraison qui EXIGE la caractéristique.
READ-ONLY (LECTURE SEULE)- adjectif utilisé dans une définition d’attribut pour indiquer qu’une imprimante IPP NE DOIT PAS permettre que la valeur de l’attribut soit modifiée.
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". De plus, les termes suivants sont définis pour leur utilisation dans le présent document et les documents de méthode de livraison :
notification d’événement composée - deux ou plus notifications d’événement que délivre une imprimante avec une seule demande ou réponse. Les documents de méthode de livraison spécifient si la méthode de livraison prend en charge les notifications d’événement composées.
méthode de livraison – mécanisme par lequel l’imprimante délivre une notification d’événement.
document de méthode de livraison - document, distinct du présent document, qui définit une méthode de livraison.
événement - occurrence (attendue ou inattendue) au sein du système d’impression d’un changement d’état, de condition, ou de configuration d’un objet tâche ou imprimante. Un événement ne survient qu’à un seul instant dans le temps et ne s’étend pas à la durée dans le temps de l’événement physique. Par exemple, bourrage (jam-occurred) et fin de bourrage (jam-cleared) sont deux événements distincts, instantanés, quand bien même le bourrage dure un certain temps.
durée d’événement (Event Life) - Pour une méthode de livraison tirée, la durée en secondes après la survenance d’un événement pendant laquelle l’imprimante va conserver cet événement pour la livraison dans une notification d’événement. Après l’expiration de la durée d’événement, l’imprimante ne délivrera plus de notification d’événement pour cet événement dans une telle réponse.
notification d’événement - information sur un événement que l’imprimante délivre quand survient un événement.
groupe d’attributs de notification d’événement – groupe d’attributs qui est utilisé pour délivrer une notification d’événement dans une demande (méthodes de livraison poussées) ou dans une réponse (méthodes de livraison tirées).
notification d’événement destinée à l’homme – texte localisé destiné uniquement à l’homme. Il n’y a pas de format normalisé et donc les programmes ne devraient pas essayer d’analyser ce texte.
opération de création de tâche - une des opérations qui créent un objet tâche : tâche d’impression (Print-Job), URI d’impression (Print-URI) et création de tâche (Create-Job). L’opération tâche de redémarrage (Restart-Job) de la [RFC2911] n’est pas considérée comme une opération de création de tâche, dans la mesure où l’imprimante réutilise l’objet tâche existant. L’opération valider la tâche (Validate-Job) n’est pas considérée comme une opération de création de tâche parce qu’aucun objet tâche n’est créé. Donc, lorsqu’une déclaration s’applique aussi à l’opération Restart-Job et/ou Validate-Job, elles sont mentionnées explicitement.
événement de tâche (Job Event) – événement causé par un changement dans une tâche particulière sur l’imprimante, par exemple, 'fin de tâche'.
notification d’événement à destination machine - octets à destination du programme. Les octets sont formatés conformément au document de méthode de livraison.
notification – lorsqu’elle n’est pas dans les phrases 'notification d’événement' et 'récepteur de notification' – c’est le concept de la présente spécification, c’est-à-dire, événements, objets d’abonnement, et notifications d’événement.
récepteur de notification - entité à laquelle l’imprimante délivre une notification d’événement. Pour les méthodes de livraison poussées, l’imprimante IPP envoie les notifications à un récepteur de notification. Pour les méthodes de livraison tirées, le récepteur de notification agit dans le rôle d’un client IPP et demande les notifications d’événement et donc les termes "client" et "récepteur de notification" sont utilisés de façon interchangeable selon les méthodes de livraison. Pour un exemple, voir la [RFC3996].
objet d’abonnement par tâche - objet d’abonnement associé à une seule tâche. L’opération créer des abonnements de tâche (Create-Job-Subscriptions) et l’opération de création de tâches créent un tel objet.
objet d’abonnement par imprimante - objet d’abonnement associé à l’imprimante comme un tout. L’opération créer des abonnements d’imprimante (Create-Printer- Subscriptions) crée un tel objet.
événement d’imprimante (Printer Event) – événement causé par un changement dans l’imprimante qui n’est pas spécifique d’une tâche, par exemple, 'changement d’état de l’imprimante'.
méthode de livraison tirée - l’imprimante sauvegarde les notifications d’événement pour la durée de vie de certain événement et attend que le récepteur de notification demande les notifications d’événement. L’imprimante délivre les notifications d’événement dans une réponse à une telle demande.
méthode de livraison poussée - l’imprimante délivre la notification d’événement peu après la survenance d’un événement.
événement abonné –événement que le client abonné juge intéressant en lui donnant une valeur dans l’attribut "événements notifiés" sur un objet d’abonnement.
événement de tâche abonné (Subscribed Job Event) - événement abonné qui est un événement de tâche.
événement d’imprimante abonné (Subscribed Printer Event) - événement abonné qui est un événement d’imprimante.
client abonné (Subscribing Client) - client qui crée l’objet d’abonnement.
groupe d’attributs d’abonnement - groupe d’attributs dans une réponse qui contient les attributs d’objet d’abonnement.
opération de création d’abonnement - opération qui crée un objet d’abonnement : Opération de création de tâches, opération Create-Job-Subscriptions (créer des abonnements de tâches), opération Create-Printer-Subscriptions (créer des abonnements d’imprimante). Dans le contexte d’une opération de création de tâche, une opération de création d’abonnement est la partie de l’opération de création de tâche qui crée un ou plusieurs objets d’abonnement. L’opération Restart-Job (redémarrer la tâche) [RFC2911] n’est pas considérée comme une opération de création d’abonnement, dans la mesure où l’imprimante réutilise les objets d’abonnement existants de la tâche, plutôt que de créer de nouveaux objets d’abonnement.
demande de création d’abonnement - La portion demande d’une opération de création d’abonnement.
attributs de description d’abonnement - attributs d’objet d’abonnement que fournit une imprimante durant une opération de création d’abonnement.
objet d’abonnement - objet contenant un ensemble d’attributs qui indiquent : le récepteur de notification (seulement pour la méthode de livraison poussée), la méthode de livraison, les événements abonnés qui causent la livraison d’une notification d’événement par l’imprimante, et les informations à inclure dans une notification d’événement.
attributs de gabarit d’abonnement – attributs d’objet d’abonnement qu’un client peut fournir dans une opération de création d’abonnement et attributs d’objet imprimante associés qui spécifient les valeurs prises en charge et par défaut pour les attributs d’objet d’abonnement.
groupe d’attributs de gabarit d’abonnement - groupe d’attributs d’une demande qui contient les attributs d’objet d’abonnement qui sont les attributs de gabarit d’abonnement.
La présente section définit les relations d’objet entre l’imprimante, la tâche, et les objets d’abonnement. Elle ne définit pas la mise en œuvre. Pour une illustration de ces relations, voir l’Appendice 19.
1. Un objet imprimante peut être associé à zéro ou plus objets d’abonnement par imprimante.
2. Chaque objet d’abonnement par imprimante est associé à exactement un objet imprimante.
1. Un objet imprimante est associé à zéro ou plus objets tâche.
2. Chaque objet tâche est associé à exactement un objet imprimante.
3. Un objet tâche est associé à zéro ou plus objets d’abonnement par tâche.
4. Chaque objet d’abonnement par tâche est associé à exactement un objet tâche.
Un Client abonné crée un objet d’abonnement par une opération de création d’abonnement afin d’indiquer son intérêt pour certains événements. Voir à la section 11 la description de ces opérations. Lorsqu’un événement survient, l’objet d’abonnement spécifie à l’imprimante où livrer les notifications d’événement pour la seule méthode de livraisons poussée, comment les livrer, et ce qu’il convient d’y inclure. Voir la section 9 pour des précisions sur le contenu d’une notification d’événement.
En utilisant les attributs de gabarit de tâche comme modèle (voir le paragraphe 4.2 de la [RFC2911]), les attributs d’un objet d’abonnement sont divisés en deux catégories : attributs de gabarit d’abonnement et attributs de description d’abonnement.
Les attributs de gabarit d’abonnement sont à leur tour, comme les attributs de gabarit de tâche, divisés en :
1. attributs d’objet d’abonnement qu’un client peut fournir dans une demande de création d’abonnement, et
2. leurs attributs d’objet imprimante associés qui spécifient les valeurs prises en charge et par défaut pour les attributs de l’objet d’abonnement.
Le reste de la présente section spécifie les règles générales des attributs de gabarit d’abonnement et décrit chaque attribut d’un objet d’abonnement.
Les attributs de gabarit d’abonnement sont fondamentaux pour le modèle de Notification décrit dans la présente spécification. Le client fournit ces attributs dans les opérations de création d’abonnement et l’imprimante utilise ces attributs pour remplir un objet d’abonnement nouvellement créé.
Les attributs d’objets d’abonnement qui sont les attributs de gabarit d’abonnement se conforment aux règles suivantes :
1. Chaque nom d’attribut commence par la chaîne préfixe "notify-" et le présent document appelle de tels attributs "notify-xxx".
2. Pour chaque attribut d’objet d’abonnement "notify-xxx" défini dans la colonne 1 du Tableau 1 du paragraphe 5.3, le Tableau 1 spécifie les attributs d’imprimante correspondants : "notify-xxx-default", "notify-xxx-supported", "yyy-supported" et "notify-max-xxx-supported" définis dans la colonne 2 du Tableau 1. Noter que "xxx" est mis pour la même chaîne dans chaque cas et "yyy" est mis pour d’autres chaînes.
3. Si une imprimante prend en charge "notify-xxx" dans la colonne 1 du Tableau 1, l’imprimante DOIT alors prendre en charge tous les attributs associés spécifiés dans la colonne 2 du Tableau 1. Par exemple, le Tableau 1 montre que si l’imprimante prend en charge "notify-events", elle DOIT prendre en charge "notify-events-default", "notify-events-supported" et "notify-max-events-supported".
4. Si une imprimante ne prend pas en charge "notify-xxx" dans la colonne 1 du Tableau 1, l’imprimante NE DOIT PAS alors prendre en charge d’attribut "notify-yyy" associé spécifié dans la colonne 2 du Tableau 1. Par exemple, le Tableau 1 montre que si l’imprimante ne prend pas en charge "notify-events", elle NE DOIT PAS prendre en charge "notify-events-default", "notify-events-supported" et "notify-max-events-supported". Noter que cette règle ne s’applique pas aux attributs dont le nom ne commence pas par la chaîne "notify-" et sont donc définis dans un autre objet et utilisés par d’autres attributs.
5. La plupart des attributs "notify-xxx" ont un attribut "yyy-supported" correspondant qui spécifie les valeurs prises en charge pour "notify-xxx". La colonne 2 du Tableau 1 spécifie le nom de chaque attribut "yyy-supported". Les règles de dénomination de IPP/1.1 (voir la [RFC2911]) sont utilisées lorsque "yyy-supported" est "notify-xxx-supported".
6. Certains attributs "notify-xxx" ont un attribut "notify-xxx-default" correspondant qui spécifie la valeur de "notify-xxx" si le client ne la fournit pas. La colonne 2 du Tableau 1 spécifie le nom de chaque attribut "notify-xxx-default". On utilise les règles de dénomination de IPP/1.1 (voir la [RFC2911]).
Si un client souhaite présenter à un utilisateur final une liste des valeurs prises en charge pour y faire un choix, le client DEVRAIT questionner l’imprimante sur ses attributs de valeurs prises en charge. Le client DEVRAIT aussi interroger les attributs de valeur par défaut. Si le client limite alors les valeurs à choisir aux seules valeurs qui sont prises en charge, le client peut garantir que les valeurs qu’il a fournies dans la demande de création entrent toutes dans l’ensemble des valeurs prises en charge à l’imprimante. En interrogeant l’imprimante, le client PEUT énumérer chaque attribut par son nom dans la demande Get-Printer-Attributes (obtenir les attributs d’imprimante), ou le client PEUT simplement fournir le nom de groupe de 'gabarit d’abonnement' afin d’obtenir l’ensemble complet des attributs pris en charge (attributs pris en charge et attributs par défaut - voir au paragraphe 11.2.3).
Ce paragraphe définit un ensemble détaillé des règles que suit une imprimante lorsqu’elle traite les attributs de gabarit d’abonnement dans une demande de création d’abonnement. Ces règles sont semblables aux règles de traitement des attributs d’opération dans la [RFC2911]. A savoir que l’imprimante peut ou non prendre en charge un attribut et un client peut ou non fournir l’attribut. Certaines combinaisons de ces cas sont convenables. D’autres retournent des avertissements ou des erreurs , et peut-être une liste d’attributs non pris en charge.
Une imprimante DOIT mettre en œuvre le comportement suivant pour traiter les attributs de gabarit d’abonnement dans une Demande de création d’abonnement:
1. Si un client fournit un attribut "notify-xxx" de la colonne 1 du Tableau 1 et si l’imprimante le prend en charge ainsi que sa valeur, l’imprimante DOIT remplir l’attribut sur l’objet d’abonnement créé.
2. Si un client fournit un attribut "notify-xxx" de la colonne 1 du Tableau 1 et si l’imprimante ne le prend pas en charge, lui ou sa valeur, l’imprimante NE DOIT PAS remplir l’attribut avec lui sur l’objet d’abonnement créé. L’imprimante DOIT faire une des choses suivantes :
a) Si la valeur de l’attribut "notify-xxx" n’est pas prise en charge, l’imprimante DOIT retourner l’attribut avec sa valeur dans le groupe d’attributs d’abonnement de la réponse.
b) Si "notify-xxx" est un attribut non pris en charge, l’imprimante DOIT retourner l’attribut dans le groupe d’attributs d’abonnement de la réponse avec la valeur "non pris en charge" hors bande.
Note : Les règles de cette étape sont les mêmes que pour les attributs non pris en charge du paragraphe 3.1.7 de la [RFC2911] sauf que les attributs non pris en charge sont retournés dans le groupe d’attributs d’abonnement plutôt que dans le groupe des attributs non pris en charge parce que les opérations de création d’abonnement peuvent créer plus d’un objet d’abonnement).
3. S’il est EXIGÉ d’un client qu’il fournisse un attribut "notify-xxx" de la colonne 1 du Tableau 1 et si l’imprimante ne prend pas en charge la valeur fournie, l’imprimante NE DOIT PAS créer un objet d’abonnement. Les règles pour les attributs non pris en charge dans l’étape n° 2 s’appliquent.
4. Si un client ne fournit pas un attribut "notify-xxx" de la colonne 1 du Tableau 1 et si la fourniture de l’attribut est EXIGÉE pour le client, l’imprimante DOIT rejeter l’opération de création d’abonnement (y compris l’opération de création de tâches) sans créer d’objet d’abonnement, et DOIT retourner dans la réponse :
a) le code d’état "client-error-bad-request" (erreur client, mauvaise demande) ET
b) pas de groupes d’attributs d’abonnement.
5. Si un client ne fournit pas un attribut "notify-xxx" de la colonne 1 du Tableau 1 qu’il soit FACULTATIF de fournir au client, et si la colonne 2 du Tableau 1, soit :
a) spécifie un attribut "notify-xxx-default", l’imprimante DOIT se comporter comme si le client avait fourni l’attribut "notify-xxx-default" (voit l’étape n°1) et remplir l’objet d’abonnement avec la valeur de l’attribut "notify-xxx-default" en tant que partie de l’opération de création d’abonnement (à la différence des attributs de gabarit de tâche où l’imprimante ne remplit pas l’objet tâche avec des valeurs par défaut – voir la [RFC2911]) OU
b) ne spécifie pas un attribut "notify-xxx-default", l’imprimante DOIT remplir l’attribut "notify-xxx" sur l’objet d’abonnement conformément à la définition de l’attribut "notify-xxx" au paragraphe 5.3. Pour certains attributs, le "notify-xxx" est rempli avec la valeur d’un autre attribut, et pour d’autres, le "notify-xxx" N’EST PAS rempli du tout sur l’objet d’abonnement.
6. Une imprimante DOIT créer un objet d’abonnement pour chacun des groupes d’attributs de gabarit d’abonnement dans une demande, à moins que l’imprimante :
a) ne rencontre des attributs dans un groupe d’attributs de gabarit d’abonnement qui requièrent que l’imprimante ne crée pas l’objet d’abonnement OU
b) ne crée un objet d’abonnement par tâche lorsqu’elle n’a pas la place pour un autre objet d’abonnement par tâche OU
c) ne crée un objet d’abonnement par imprimante lorsqu’elle n’a pas de place pour un autre objet d’abonnement par imprimante.
7. Une réponse DOIT contenir un groupe d’attributs d’abonnement pour chaque groupe d’attributs de gabarit d’abonnement de la demande (et dans le même ordre) que l’imprimante crée un objet d’abonnement à partir du groupe d’attributs de gabarit d’abonnement ou non. Cependant, les attributs de chaque groupe d’attributs d’abonnement peuvent être dans n’importe quel ordre.
8. L’imprimante DOIT remplir chaque groupe d’attributs d’abonnement de la réponse de sorte que chacun contienne :
a) l’attribut "notify-subscription-id" (notifier l’identifiant d’abonnement) (voir au paragraphe 5.4.1), si et seulement si l’imprimante crée un objet d’abonnement.
b) l’attribut "notify-lease-duration" (notifier la durée de location) (voir au paragraphe 5.3.8), si et seulement si l’imprimante crée un objet d’abonnement par imprimante. La valeur de cet attribut est la valeur de l’attribut "notify-lease-duration" de l’objet d’abonnement. Cette valeur PEUT être différente de la valeur fournie par le client (voir au paragraphe 5.3.8). Si un client fournit cet attribut dans la création d’un objet d’abonnement par tâche, il DOIT apparaître dans ce groupe avec la valeur "non pris en charge" hors bande pour indiquer que l’imprimante ne le prend pas en charge dans ce contexte.
c) tous les attributs de gabarit d’abonnement de l’étape n° 2 non pris en charge. Noter qu’ils ne sont pas retournés dans le groupe des attributs non pris en charge afin de séparer les attributs non pris en charge pour chaque objet d’abonnement.
d) l’attribut "notify-status-code" (notifier le code d’état) si l’imprimante ne crée pas l’objet d’abonnement ou si il y a des attributs de l’étape n° 2 non pris en charge. Les valeurs possibles de l’attribut "notify-status-code" sont indiquées ci-dessous (voir la section 13 pour les détails). L’imprimante retourne la première valeur dans la liste ci-dessous qui décrit les états.
"client-error-uri-scheme-not-supported" (Erreur client, schéma d’URI non accepté) : l’objet d’abonnement n’a pas été créé parce que le schéma de l’attribut "notify-recipient-uri" (notifier l’URI de réception) n’est pas accepté. Voir au paragraphe 13.1 des précisions sur ce code d’état. Voir à l’étape n° 3 du présent paragraphe le cas qui cause cette erreur, et l’étape résultante n° 6a) qui est cause que l’imprimante ne crée pas l’objet d’abonnement.
"client-error-attributes-or-values-not-supported" (Erreur client, attributs ou valeurs non acceptées) : l’objet d’abonnement n’a pas été créé parce que la méthode de l’attribut "notify-pull-method" (notifier la méthode tirée) n’est pas acceptée. Voir au paragraphe 13.1 des précisions sur ce code d’état. Voir à l’étape n° 3 du présent paragraphe le cas qui cause cette erreur, et l’étape résultante n° 6a) qui est cause que l’imprimante ne crée pas l’objet d’abonnement.
"client-error-too-many-subscriptions" (Erreur client, trop d’abonnements) : l’objet d’abonnement n’a pas été créé parce que l’imprimante n’a pas de place pour des objets d’abonnement supplémentaires. Le client PEUT réessayer plus tard. Voir au paragraphe 13.3 des précisions sur de code d’état. Voir aux étapes n° 6b) et 6c) du présent paragraphe les cas qui causent cette erreur.
"successful-ok-too-many-events" (réussite mais trop d’événements) : l’objet d’abonnement a été créé sans que les valeurs de "notify-events" soient incluses dans ce groupe d’attributs d’abonnement parce que l’attribut "notify-events" contient trop de valeurs. Voir au paragraphe 13.4 des précisions sur ce code d’état. Voir à l’étape n° 2 du présent paragraphe et au paragraphe 5.3.3 les cas qui causent ce code d’état.
"successful-ok-ignored-or-substituted-attributes" (réussite mais attributs ignorés ou substitués) : l’objet d’abonnement a été créé mais certains des attributs de gabarit d’abonnement fournis ne sont pas pris en charge. Ces attributs non pris en charge sont aussi dans le groupe d’attributs d’abonnement. Voir au paragraphe 13.5 des précisions sur ce code d’état. Voir à l’étape n° 2 du présent paragraphe les cas qui causent ce code d’état.
9. L’imprimante DOIT valider tous les attributs de gabarit d’abonnement et DOIT retourner tous les attributs et valeurs non pris en charge dans le groupe d’attributs d’abonnement correspondant de la réponse (voir l’étape n° 2) à moins qu’elle ne détermine qu’elle ne peut créer d’objets d’abonnement supplémentaires à cause de la condition 6b) ou de la condition 6c). L’imprimante PEUT NE PAS valider ces attributs de gabarit d’abonnement supplémentaires et le client NE DOIT PAS s’attendre à trouver des attributs non pris en charge de l’étape n° 2 dans de tels groupes d’attributs d’abonnement supplémentaires.
Ce paragraphe contient les attributs de gabarit d’abonnement définis pour les objets abonnement et imprimante.
Le Tableau 1 ci-dessous montre les attributs de gabarit d’abonnement et a deux colonnes :
- Attribut dans l’objet d’abonnement : le nom et la syntaxe d’attribut de chaque attribut d’objet d’abonnement qui est un attribut de gabarit d’abonnement
- attributs d’imprimante par défaut et pris en charge : les attributs d’imprimante par défaut et les attributs pris en charge qui sont associés à l’attribut dans la colonne 1.
L’attribut "notify-recipient-uri" est utilisé avec les méthodes de livraison poussées. L’attribut "notify-pull-method" est utilisé avec les méthodes de livraison tirées.
Pour les méthodes de livraison poussées, une imprimante DOIT prendre en charge tous les attributs du Tableau 1 ci-dessous excepté "notify-pull-method" et "notify-attributes" (et "notify-pull-method-supported" et "notify-attributes-supported"). Pour les méthodes de livraison tirées, une imprimante DOIT prendre en charge tous les attributs du Tableau 1 ci-dessous excepté "notify-recipient-uri" et "notify-attributes" (et "notify-schemes-supported" et "notify-attributes-supported"). Si une imprimante prend en charge aussi bien les méthodes de livraison poussées que tirées, elle DOIT alors prendre en charge les attributs "notify-recipient-uri" et "notify-pull-method".
Pour les méthodes de livraison tirées, un client DOIT fournir "notify-recipient-uri" et PEUT omettre tout le reste des attributs de la colonne 1 du Tableau 1 dans une demande de création d’abonnement. Pour les méthodes de livraison poussées, un client DOIT fournir "notify-pull-method" et PEUT omettre tout le reste des attributs de la colonne 1 du Tableau 1 dans une demande de création d’abonnement. Un client NE DOIT PAS fournir les deux attributs "notify-recipient-uri" et "notify-pull-method" dans la même demande de création d’abonnement.
Note : Les attributs d’imprimante par défaut et pris en charge dont la liste figure dans la colonne 2 du Tableau 1 n’ont pas de paragraphes séparés pour définir leur sémantique dans la présente spécification. A la place, le paragraphe de l’attribut d’objet d’abonnement correspondant (la colonne 1 du Tableau 1) contient la sémantique de ces attributs d’imprimante. Cette approche suit la préséance des attributs de gabarit de tâche du paragraphe 4.2 de la [RFC2911] où les attributs d’imprimante "xxx-default" et "xxx-supported" correspondants sont définis dans la même section que les attributs de tâche"xxx".
Tableau 1 - Les attributs de gabarit d’abonnement
|
Attribut dans l’objet
d’abonnement |
Attributs
d’imprimante par défaut et pris en charge |
|
notify-recipient-uri
(uri) * |
notify-schemes-supported
(1setOf uriScheme) |
|
notify-pull-method
(mot clé de type2) ** |
notify-pull-method-supported
(1setOf type2 keyword) |
|
notify-events
(1setOf mot clé de type2) |
notify-events-default
(1setOf type2 keyword) |
|
|
notify-events-supported
(1setOf type2 keyword) |
|
|
notify-max-events-supported
(entier(2:MAX)) |
|
notify-attributes
(1setOf mot clé de type2) |
notify-attributes-supported
(1setOf type2 keyword) |
|
notify-user-data (octetString(63)) |
|
|
notify-charset
(charset) |
charset-supported
(1setOf charset) |
|
notify-natural-language
(naturalLanguage) |
generated-natural-language-supported
(1setOf naturalLanguage) |
|
notify-lease-duration
(entier(0:MAX)) |
notify-lease-duration-default
(entier(0:67108863)) |
|
|
notify-lease-duration-supported |
|
|
(1setOf (entier(0:
67108863) | rangeOfInteger(0:67108863))) |
|
notify-time-interval
(entier(0:MAX)) |
|
* "notify-recipient-uri" est seulement pour les méthodes de livraison poussées.
** "notify-pull-method" est seulement pour les méthodes de livraison tirées.
La valeur de cet attribut est un URL, qui est un cas particulier d’URI. Sa valeur consiste en un schéma et une adresse. L’adresse spécifie le récepteur de notification et le schéma spécifie la méthode de livraison poussée pour chaque notification d’événement associée à cet objet d’abonnement.
Si une imprimante prend en charge des méthodes de livraison poussées, elle DOIT prendre en charge cet attribut et retourner la valeur comme fournie par le client (pas de conversion de casse ou autre canonisation) dans toute réponse d’opération qui inclut cet attribut.
Pour une méthode de livraison poussée, un client DOIT fournir cet attribut dans une opération de création d’abonnement. Et donc il n’y a aucun besion d’attribut d’imprimante par défaut.
Le schéma d’URI de la valeur de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "notify-schemes-supported (1setOf uriScheme)" (voir au paragraphe 5.3.1.1). Note : Conformément à la [RFC2396] le ":" termine le schéma et ne fait donc pas partie du schéma. Donc, les valeurs de l’attribut d’imprimante "notify-schemes-supported" n’incluent pas le caractère ":".
Si le client fournit un schéma non pris en charge dans la valeur de cet attribut, l’imprimante NE DOIT PAS alors créer l’objet d’abonnement et DOIT retourner l’attribut "notify-status-code" avec la valeur "client-error-uri-scheme-not-supported" (Erreur client, schéma d’URI non accepté) dans le groupe d’attributs d’abonnement de la réponse.
5.3.1.1 notify-schemes-supported
(1setOf uriScheme)
Cet attribut contient les schémas d’URI pris en charge dans l’attribut de gabarit d’abonnement "notify-recipient-uri". Voir aux paragraphes 5.1 et 5.2 le comportement des attributs de gabarit d’abonnement d’imprimante "xxx-supported".
La valeur de cet attribut est un mot clé de type2 qui indique quelle méthode de livraison tirée est à utiliser.
Comme une imprimante DOIT prendre en charge la méthode de livraison tirée 'ippget' [RFC3996] (voir la section 15), une imprimante DOIT prendre en charge cet attribut et retourner la valeur fournie par le client dans toute réponse d’opération qui comporte cet attribut.
Pour une méthode de livraison titée, un client DOIT fournir cet attribut dans une opération de création d’abonnement. ET donc il n’est pas besoin d’un attribut d’imprimante par défaut.
La valeur du mot clé de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "notify-pull-method-supported (1setOf type2 keyword)".
Si le client fournit une méthode non prise en charge dans la valeur de cet attribut, l’imprimante NE DOIT PAS créer alors l’objet d’abonnement et DOIT retourner l’attribut "notify-status-code" avec la valeur 'client-error-attributes-or-values-not-supported' (Erreur client, attribut ou valeurs non acceptées) dans le groupe d’attributs d’abonnement de la réponse.
5.3.2.1 notify-pull-method-supported
(1setOf type2 keyword)
Voir aux paragraphes 5.1 et 5.2 le comportement des attributs d’imprimante de gabarit d’abonnement "xxx-supported".
Cet attribut contient un ensemble d’événements abonnés. Lorsqu’un événement survient et qu’il "satisfait" une valeur de cet attribut, l’imprimante délivre une notification d’événement en utilisant les informations contenues dans le SubscriptionObject. Les détails de "satisfait" sont décrits au paragraphe 5.3.3.5.
Une imprimante DOIT prendre en charge cet attribut.
Un client PEUT fournir cet attribut dans une opération de création d’abonnement. Si le client ne fournit pas cet attribut dans une opération de création d’abonnement, l’imprimante DOIT remplir cet attribut sur l’objet d’abonnement avec sa valeur d’attribut "notify-events-default" (notifier les événements par défaut).
Chaque valeur de mot clé de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "notify-events-supported (1setOf type2 keyword)" (notifier les événements pris en charge).
Le nombre des valeurs de cet attribut NE DOIT PAS excéder la valeur de l’attribut "notify-max-events-supported" (notifier le maximum d’événements pris en charge). Une imprimante DOIT prendre en charge au moins deux valeurs par objet d’abonnement. Si le nombre de valeurs fournies par un client dans une opération de création d’abonnement excède la valeur de cet attribut, l’imprimante DOIT traiter les valeurs excédentaires comme des valeurs non prises en charge et DOIT utiliser la valeur de 'successful-ok-too-many-events' (réussite mais trop d’événements) pour l’attribut "notify-status-code" (notifier le code d’état) dans le groupe d’attributs d’abonnement de la réponse.
5.3.3.1 notify-events-default
(1setOf type2 keyword)
Voir aux paragraphes 5.1 et 5.2 le comportement des attributs d’imprimante de gabarit d’abonnement "xxx-default".
5.3.3.2 notify-events-supported (1setOf type2 keyword)
Voir aux paragraphes 5.1 et 5.2 le comportement des attributs d’imprimante de gabarit d’abonnement "xxx-supported".
5.3.3.3 notify-max-events-supported (integer(2:MAX))
Cet attribut spécifie le nombre maximum d’événements que l’imprimante prend en charge pour l’attribut de gabarit d’abonnemet "notify-events". Voir aux paragraphes 5.1 et 5.2 le comportement des attributs d’imprimante de gabarit d’abonnement "xxx-supported".
5.3.3.4 Valeurs standard pour événements abonnés
Chaque valeur de cet attribut est un mot clé et elle spécifie un événement abonné qui représente certain changements. Certains mots clé représentent un sous-ensemble de changements d’un autre mot clé, par exemple, 'job-completed' (fin de tâche)est une valeur d’événement qui est une sous-valeur de 'job-state-change' (changement d’état de tâche). Voir au paragraphe 5.3.3.5 le cas où cet attribut contient à la fois une valeur et une sous-valeur.
Les valeurs du présent paragraphe sont réparties en trois catégories : pas d’événement, événements de tâche et événements d’imprimante.
Une imprimante DOIT prendre en charge les événements indiqués comme "EXIGÉ" et PEUT prendre en charge les événements indiqués comme "FACULTATIF".
5.3.3.4.1 Pas dévénement
La valeur de mot clé standard unique pour pas d’événement est :
'aucune' : EXIGÉ – pas de notification d’événement pour tout événement. Etant la seule valeur pour "notify-events-supported" (notifier les événements pris en charge), cette valeur signifie que l’imprimante ne prend pas en charge la délivrance des notifications d’événement. Comme seule valeur de "notify-events-default" (notifier les événements par défaut), cette valeur signifie qu’un client DOIT spécifier l’attribut "notify-events" afin de réussir une opération de création d’abonnement. Si l’imprimante reçoit cette valeur comme seule valeur d’une opération de création d’abonnement, elle ne crée pas un objet d’abonnement. Si une imprimante reçoit cette valeur avec d’autres valeurs d’une opération de création d’abonnement, l’imprimante DOIT traiter cette valeur comme valeur non prise en charge.
5.3.3.4.2 Evénements d’imprimante abonnés
Les mots clé standard pour les événements d’impimante abonnés sont :
'printer-state-changed' (changement d’état de l’imprimante) : EXIGÉ - l’imprimante a changé d’état depuis n’importe quel état vers tout autre état. Précisément, la valeur des attributs "printer-state" (état de l’imprimante), "printer-state-reasons" (causes de l’état de l’imprimante) ou "printer-is-accepting-jobs" (l’imprimante accepte les tâches) a changé.
Cette valeur d’événement abonné a les sous-valeurs suivantes :
'printer-restarted' (rédémarrage d’imprimante) et 'printer-shutdown' (fermeture de l’imprimante). Un client peut surveiller une de ces sous-valeurs s’il ne veut pas surveiller tous les changements d’état de l’imprimante :
'printer-restarted' : FACULTATIF – lorsque l’imprimante est mise sous tension.
'printer-shutdown' : FACULTATIF – lorsque l’appareil est éteint.
'printer-stopped : EXIGÉ - lorsque l’imprimante arrête l’impression, c’est-à-dire, la valeur de l’attribut d’imprimante "printer-state" devient 'stopped' (arrêté).
'printer-config-changed' : FACULTATIF - lorsque la configuration d’une imprimante a changé, c’est-à-dire, la valeur de l’attribut d’imprimante "printer-message-from-operator" (message de l’imprimante pour l’opérateur) ou toute "configuration" a changé. Un attribut d’imprimante "configuration" est un attribut qui peut changer de valeur à cause d’une interaction humaine directe ou indirecte, et qui n’est pas couvert par un des autres événements de ce paragraphe. A titre d’exemples d’attributs d’imprimante "configuration"on trouve tous les attributs de gabarit de tâche, tels que "xxx-supported", "xxx-ready" et "xxx-default". Le client doit effectuer un Get-Printer-Attributes (obtenir les attributs d’imprimante) pour trouver les nouvelles valeurs de ces attributs modifiés. Cet événement est utile pour les clients et pilotes GUI pour mettre à jour auprès de l’utilisateur les capacités de l’imprimante disponible.
Cette valeur d’événement a les sous-valeurs suivantes : 'printer-media-changed' (changement du support d’imprimante) et 'printer-finishings-changed' (changements des finitions de l’imprimante). Un client peut surveiller une de ces sous-valeurs s’il ne veut pas surveiller tous les changements de configuration d’imprimante.
'printer-media-changed' : FACULTATIF – lorsque le média chargé sur une imprimante a été changé, c’est-à-dire que l’attribut "media-ready" a été changé. Cet événement inclut deux cas : une corbeille d’entrée qui se vide et une corbeille d’entrée qui reçoit des supports supplémentaires du même type ou d’un type différent. Le client doit vérifier séparément les attributs d’imprimante "media-ready" (voir au paragraphe 4.2.11 de la [RFC2911]) pour découvrir ce qui a changé.
'printer-finishings-changed' : FACULTATIF – lorsque le module de finition d’une imprimante a été changé, c’est-à-dire que les attributs "finishings-ready" ont changé. Cet événement comporte deux cas : un module de finition qui devient vide, et un module de finition qui est rechargé (même s’il n’est pas plein). Le client doit vérifier séparément les attributs d’imprimante "finishings-ready" pour découvritr ce qui a changé.
'printer-queue-order-changed' (changement de l’ordre de la file d’attente de l’imprimante) : FACULTATIF – l’ordre des tâches de la file d’attente de l’imprimante a changé, de sorte qu’une application de surveillance de la file d’attente peut effectuer une opération Get-Jobs (obtenir les tâches) pour déterminer le nouvel ordre. Cet événement n’inclut pas l’entrée d’une tâche dans la file d’attente (c’est couvert par l’événement 'job-created') et n’inclut pas la sortie d’une tâche de la file d’attente (c’est couvert par l’événement 'job-completed').
5.3.3.4.3 Evénements de tâche abonnée
Les valeurs de mot clé standard pour les événements de tâche abonnée sont :
'job-state-changed' (changement d’état de tâche) : EXIGÉ – la tâche a changé à partir de n’importe quel état vers tout autre état. Précisément, l’imprimante délivre cet événement chaque fois que la valeur de l’attribut "job-state" ou "job-state-reasons" change. Lorsqu’une tâche est retirée des phases Rétention de tâche ou Historique des tâches (voir au paragrapohe 4.3.7.1 de la [RFC2911]), aucun événement n’est généré.
Cette valeur d’événement a les sous-valeurs suivantes : 'job-created' (création de tâche), 'job-completed' (fin de tâche) et 'job-stopped' (tâche arrêtée). Un client peut surveiller une de ces sous-valeurs s’il ne veut pas surveiller tous les 'changements d’état de tâche'.
'job-created' : EXIGÉ - l’imprimante a accepté une opération de création de tâche, une opération Restart-Job [RFC2911], ou toute opération de tâche qui crée un objet tâche à partie d’un objet tâche existant. L’imprimante remplit la valeur d’attribut de tâche "time-at-creation" (heure de création) [RFC2911] paragraphe 4.3.14.1). L’imprimante met la tâche dans l’état 'pending' (en suspens), 'pending-held' (gardée en suspens) ou 'processing' (en cours).
'job-completed' : EXIGÉ – la tâche a atteint un des états achevés, c’est-à-dire que la valeur de l’attribut "job-state" (état de tâche) de la tâche est passé à : 'completed' (achevé), 'aborted' (échec), ou 'canceled' (annulé). Les attributs "time-at-completed" (heure d’achèvement) et "date-time-at-completed" (date et heure d’achèvement) (si ce dernier est pris en charge) de la tâche sont établis (voir au paragraphe 4.3.14 de la [RFC2911]). Lorsqu’une tâche se termine, un récepteur de notification PEUT interroger la tâche en utilisant l’opération Get-Job-Attributes (obtenir les attributs de la tâche). Pour permettre une telle interrogation, l’imprimante retient la tâche dans les phases Job Retention et/ou Job History (voir au paragraphe 4.3.7.1 de la [RFC 2911]) pendant une durée convenable qui dépend de la mise en œuvre et des méthodes de livraison prises en charge. L’imprimante délivre aussi cet événement lorsqu’une tâche est supprimée par l’opération Purge-Job (purger les tâches) (voir au paragraphe 3.2.9 de la [RFC2911]). Dans ce cas, la notification d’événement DOIT rapporter l’état de tâche comme 'annulé' et l’objet tâche n’est plus présent pour l’interrogation.
'job-stopped : FACULTATIF – lorsque la tâche arrête l’impression, c’est-à-dire que la valeur de l’attribut "état de tâche" devient 'processing-stopped' (traitement arrêté).
'job-config-changed' (configuration de tâche modifiée) : FACULTATIF – lorsque la configuration d’une tâche a changé, c’est-à-dire que la valeur de l’attribut de tâche "job-message-from-operator" ou d’un des attributs "configuration" a changé. Un attribut de tâche "configuration" est un attribut qui peut changer de valeur à cause d’une interaction humaine directe ou indirecte. Des exemples d’attributs de tâche "configuration" figurent dans tout attribut de gabarit de tâche et dans l’attribut "job-name". Le client effectue un Get-Job-Attributes pour découvrir les nouvelles valeurs des attributs modifiés. Cet événement est utile pour les clients et pilotes GUI pour mettre à jour les informations de tâches destinées à l’utilisateur.
'job-progress' (avancement de tâche) : FACULTATIF - lorsque l’imprimante a fini d’imprimer une page. Voir dans la spécification distincte [RFC3381] les attributs supplémentaires qu’une imprimante PEUT dlivrer dans une notification d’événement causée par cet événement. L’attribut "notify-time-interval" (notifier les intervalles de temps) affecte cet événement en faisant que l’imprimante NE délivre PAS de notification d’événement lorsque que survient un événement 'job-progress'. Voir tous les détails au paragraphe 5.3.9.
5.3.3.5 Règles pour la correspondance des événements abonnés
Lorsqu’un événement survient, l’imprimante DOIT trouver chaque objet abonné dont l’attribut "notify-events" "correspond" à l’événement. Les règles de "correspondance" des événements abonnés sont décrites séparément pour les événements d’imprimante et les événements de tâche. Ce paragraphe décrit aussi quelques cas particulers.
5.3.3.5.1 Règles pour la correspondance des événements d’imprimante
Etant donné que l’imprimante cause la survenance de l’événement d’imprimante E, pour chaque abonnement par tâche ou par imprimante S dans l’imprimante, si E est égal à une valeur de cet attribut dans S ou si E est une sous-valeur d’une valeur de cet attribut dans S, l’imprimante DOIT générer une notification d’événement.
Considérons un exemple. Il y a trois objets d’abonnement dont chacun a l’événement d’imprimante abonné 'printer-state-changed' (changement d’état d’imprimante). L’objet d’abonnement A est un objet d’abonnement par imprimante. L’objet d’abonnement B est un objet d’abonnement par tâche pour la tâche 1, et l’objet d’abonnement C est un objet d’abonnement par tâche pour la tâche 2. Lorsque l’imprimante entre dans l’état 'stopped' (arrêté), l’imprimante délivre une notification d’événement aux récepteurs de notification des objets d’abonnement A, B, et C parce que c’est un événement d’imprimante. Noter que si la tâche 1 est déjà terminée, l’imprimante ne délivrera pas de notification d’événement pour son objet d’abonnement, même si la tâche 1 est conservée dans les phases Job Retention et/ou Job History (voir au paragraphe 4.3.7.1 de la [RFC2911]).
5.3.3.5.2 Règles pour la correspondance des événements de tâche
Étant donné que la tâche J cause la survenance de l’événement de tâche E :
1. Pour chaque abonnement par imprimante S à l’imprimante, si E est égal à une valeur de cet attribut dans S ou si E est une sous-valeur d’une valeur de cet attribut dans S, l’imprimante DOIT générer une notification d’événement.
2. Pour chaque abonnement par tâche S associé à la tâche J, si E est égal à une valeur de cet attribut dans S ou si E est une sous-valeur d’une valeur de cet attribut dans S, l’imprimante DOIT générer une notification d’événement.
3. Pour chaque abonnement par tâche S NON associé à la tâche J, si E est égal à une valeur de cet attribut dans S ou si E est une sous-valeur d’une valeur de cet attribut, l’imprimante NE DOIT PAS générer de notification d’événement à partir de S.
Considérons un exemple : Il y a trois objets d’abonnement qui surveillent l’événement de tâche 'fin de tâche'. L’objet d’abonnement A est un objet d’abonnement par imprimante. L’objet d’abonnement B est un objet d’abonnement par tâche pour la tâche 1, et l’objet d’abonnement C est un objet d’abonnement par tâche pour la tâche 2. De plus, l’objet d’abonnement par imprimante D surveille l’événement de tâche 'changement d’état de tâche'. Lorsque la tâche 1 se termine, l’imprimante délivre une notification d’événement au récepteur de notification de l’objet d’abonnement A (parce que d’est par imprimante) et à l’objet d’abonnement B parce que c’est un objet d’abonnement par tâche associé à la tâche qui génère l’événement. L’imprimante délivre aussi une notification d’événement au récepteur de notification de l’objet d’abonnement D parce que 'fin de tâche' est une sous-valeur de 'changement d’état de tâche' - la valeur que cet objet d’abonnement D surveille. L’imprimante ne délivre pas de notification d’événement aux récepteurs de notification de l’objet d’abonnement C parce qu’il est un objet d’abonnement par tâche associé à une tâche autre que celle qui génère l’événement.
5.3.3.5.3 Cas particuliers de règles de correspondance
Le présent paragraphe contient deux règles pour le cas particulier où un seul événement produit plusieurs notifications d’événement destinées au même récepteur de notification. Ces deux règles précisent si une imprimante doit envoyer plusieurs notifications d’événement ou regrouper en une seule notification d’événement.
Si un événement correspond à des événements abonnés dans deux objets d’abonnement différents et que l’imprimante voudrait délivrer deux notifications d’événement identiques (sauf pour l’attribut "notify-subscription-id") au même récepteur de notification en utilisant la même méthode de livraison, l’imprimante DOIT délivrer les deux notifications d’événement. C’est-à-dire, l’imprimante NE DOIT PAS essayer de regrouper des notifications d’événement apparemment semblables qui surviennent dans des objets d’abonnement séparés. De façon incidente, l’imprimante NE DOIT PAS rejeter des opérations de création d’abonnement qui créeraient ce scénario.
Considérons un exemple : Au moment où une tâche s’achève, il y a deux objets d’abonnement par imprimante A et B avec le même récepteur de notification R. L’objet d’abonnement A a l’événement de tâche abonnée 'changement d’état de tâche'. L’objet d’abonnement B a l’événement de tâche abonnée 'fin de tâche'. Les deux objets d’abonnement satisfont à l’événement 'fin de tâche'. L’imprimante délivre deux notifications d’événement au récepteur de notification R. Une avec la valeur de 'changement d’état de tâche' pour l’attribut "notifier l’événement abonné" et l’autre avec la valeur de 'fin de tâche' pour l’attribut "notifier l’événement abonné".
Si un événement correspond à deux événements abonnés dans un seul objet d’abonnement (par exemple, une valeur et sa sous-valeur), une imprimante PEUT délivrer une notification d’événement pour chaque valeur satisfaite dans l’objet d’abonnement ou elle PEUT ne délivrer qu’une notification d’événement. Les règles des paragraphes 5.3.3.5.1 et 5.3.3.5.2 sont souples à dessein quant au nombre de notifications d’événement envoyées lorsque l’événement E correspond à deux valeurs ou plus dans un objet d’abonnement.
Considérons un exemple : Au moment où une tâche se termine, un objet d’abonnement A a deux événements de tâche abonnés 'changement d’état de tâche' et 'fin de tâche'.Les deux événements de tâche abonnés satisfont à l’événement 'fin de tâche'. L’imprimante délivre une ou deux notifications d’événement au récepteur de notification de l’objet d’abonnement A, selon la mise en œuvre. Si elle délivre deux notifications d’événement, une a la valeur de 'changement d’état de tâche' pour l’attribut "notifier l’événement abonné",et l’autre a la valeur de 'fin de tâche' pour l’attribut "notifier l’événement abonné". Si elle délivre une notification d’événement, elle a la valeur de 'changement d’état de tâche' ou de 'fin de tâche' pour l’attribut "notifier l’événement abonné", selon la mise en œuvre. L’algorithme de choix d’une telle valeur dépend de la mise en œuvre.
Cet attribut contient un ensemble de noms d’attribut. Lorsqu’une imprimante délivre une notification d’événement à destination machine, elle inclut un ensemble d’attributs fixé (voir au paragraphe 9.1). Si cet attribut est présent et si la notification d’événement est à destination machine, l’imprimante inclut aussi les attributs spécifiés par cet attribut.
Une imprimante PEUT prendre en charge cet attribut.
Un client PEUT fournir cet attribut dans une opération de création d’abonnement. Si le client ne fournit pas cet attribut dans l’opération de création d’abonnement ou si l’imprimante ne prend pas en charge cet attribut, l’objet d’abonnement soit (1) PEUT contenir l’attribut "notifier les attributs" avc une valeur 'aucune' soit (2) PEUT NE PAS contenir l’attribut du tout. Il n’y a pas d’attribut d’imprimante "notifier les attributs par défaut".
Chaque valeur de mot clé de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "notify-attributes-supported (1setOf type2 keyword)" (voir au paragraphe 5.3.4.1). "notifier les attributs pris en charge" PEUT contenir tout attribut d’imprimante, attribut de tâche ou attribut d’objet d’abonnement que l’imprimante prend en charge dans une notification d’événement. Il NE DOIT PAS contenir d’attributs du paragraphe 9.1 qu’une imprimante met automatiquement dans une notification d’événement; qui seraient redondants. Si un client fournit un attribut du paragraphe 9.1, l’imprimante DOIT le traiter comme une valeur d’attribut non acceptée de l’attribut "notifier les attributs".
Les règles suivantes s’appliquent à chaque valeur N de mot clé d’attribut "notifier les attributs" : Si la valeur N désigne :
a) un attribut d’abonnement, l’imprimante DOIT utiliser l’attribut N dans l’objet d’abonnement qui est utilisé pour générer la notification d’événement.
b) un attribut de tâche et si l’imprimante génère une notification d’événement à partir d’un objet d’abonnement par tâche S, l’imprimante DOIT utiliser l’attribut N dans l’objet de tâche associé à S.
c) un attribut de tâche et si l’imprimante génère une notification d’événement à partir d’un objet d’abonnement par imprimante et si l’événement est :
- un événement de tâche, l’imprimante DOIT utiliser l’attribut N dans l’objet de tâche qui a causé l’événement.
- un événement d’imprimante, l’imprimante DOIT utiliser l’attribut N dans la tâche en cours.
Si une imprimante prend en charge cet attribut et si un objet d’abonnement contient cet attribut et que la méthode de livraison génère une notification d’événement à destination machine, l’imprimante DOIT inclure dans chaque notification d’événement :
a) les attributs spécifiés au paragraphe 9.1 et
b) chaque attribut désigné par cet attribut.
L’imprimante NE DOIT PAS utiliser cet attribut pour générer de notification d’événement à destination humaine.
5.3.4.1 notify-attributes-supported (1setOf type2 keyword)
Voir aux paragraphes 5.1 et 5.2 le comportement des attributs de gabarit d’abonnement "xxx-supported".
Cet attribut contient des données opaques que certaines méthodes de livraison incluent dans chaque notification d’événement à destination machine. Les données opaques peuvent contenir, par exemple :
- l’identité de l’abonné
- un chemin ou index vers des informations d’abonné
- une clé qui identifie auprès du récepteur de notification le destinataire ultime de la notification d’événement
- l’identifiant pour un récepteur de notification qui s’était précédemment enregistré sur un Service d’échange de messages instantané.
Une imprimante DOIT prendre en charge cet attribut.
Un client PEUT fournir cet attribut dans une opération de création d’abonnement. Si le client ne fournit pas cet attribut dans l’opération de création d’abonnement, l’objet d’abonnement soit (1) PEUT contenir l’attribut "notifier les données d’utilisateur" avec une valeur de longueur de zéro, soit (2) PEUT NE PAS contenir l’attribut du tout. Il n’y a pas d’attribut d’imprimante "notifier les données d’utilisateur par défaut".
Il n’y a pas d’attribut d’imprimante "notifier les données d’utilisateur prises en charge". Au lieu de cela, toute chaîne d’octet dont la longueur ne dépasse pas 63 octets est une valeur prise en charge. Si la longueur dépasse 63 octets, l’imprimante DOIT la traiter comme valeur non prise en charge.
Cet attribut spécifie le charset (ensemble de caractères) qui doit être utilisé dans le contenu de la notification d’événement envoyée au récepteur de notification, que le contenu de la notification d’événement soit à destination machine ou humaine.
Une imprimante DOIT prendre en charge cet attribut.
Un client PEUT fournir cet attribut dans une opération de création d’abonnement. Si le client ne fournit pas cet attribut dans l’opération de création d’abonnement ou fournit une valeur non prise en charge, l’imprimante DOIT remplir cet attribut dans l’objet d’abonnement avec la valeur de l’attribut d’opération "attributes-charset", qui est un attribut EXIGÉ dans toutes les demandes IPP (voir la [RFC2911]). Si la valeur de l’attribut "attributes-charset" n’est pas acceptée, l’imprimante DOIT remplir cet attribut dans l’objet d’abonnement avec la valeur de l’attribut "charset-configured" (charset de configuration) de l’imprimante. Il n’y a pas d’attribut d’imprimante "notify-charset-default" (notifier le charset par défaut).
La valeur de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "charset-supported (1setOf charset)".
Cet attribut spécifie le langage naturel à utiliser dans tout texte à destination humaine dans le contenu de notification d’événement envoyé au récepteur de notification, que le contenu de notification d’événement soit à destination machine ou à destination humaine.
Une imprimante DOIT prendre en charge cet attribut.
Un client PEUT fournir cet attribut dans une opération de création d’abonnement. Si le client ne fournit pas cet attribut dans l’opération de création d’abonnement ou fournit une valeur non prise en charge, l’imprimante DOIT remplir cet attribut dans l’objet d’abonnement avec la valeur de l’attribut d’opération "attributes-natural-language", qui est un attribut EXIGÉ dans toutes les demandes IPP (voir au paragraphe 3.1.4 de la [RFC2911]). Si la valeur de l’attribut "attributes-natural-language" n’est pas acceptée, l’imprimante DOIT remplir cet attribut dans l’objet d’abonnement avec la valeur de l’attribut "natural-language-configured" de l’imprimante (voir au paragraphe 4.4.19 de la [RFC2911]). Il n’y a pas d’attribut d’imprimante "notify-natural-language-default".
La valeur de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "generated-natural-language-supported (1setOf type2 naturalLanguage)" (voir le paragraphe 4.4.20 de la [RFC2911]).
Cet attribute spécifie la durée de la location (en secondes) associée à l’objet d’abonnement par imprimante au moment où l’objet d’abonnement a été créé ou où la location a été renouvelée. La durée de la location est infinie si la valeur est 0, c’est-à-dire, la location n’arrive jamais à expiration. Voir des précisions au paragraphe 5.4.3 sur "notify-lease-expiration-time (entier(0:MAX))" (notifier l’heure d’expiration de la location).
Cet attribut n’est pas présent sur un objet d’abonnement par tâche parce que l’objet d’abonnement dure exactement autant que l’objet de tâche associé. Voir l’exposé sur l’événement 'fin de tâche' au paragraphe 5.3.3.4.3 à propos de la rétention de l’objet de tâche après achèvement.
Une imprimante DOIT prendre en charge cet attribut.
Pour une opération de création d’objet d’abonnement d’un objet d’abonnement par tâche, le client NE DOIT PAS fournir cet attribut. Si le client fournit cet attribut, l’imprimante DOIT le traiter comme un attribut non pris en charge.
Pour une opération de création d’abonnement d’un objet d’abonnement par imprimante ou une opération de renouvellement d’abonnement, un client PEUT fournir cet attribut. Si le client ne fournit pas cet attribut, l’imprimante DOIT remplir cet attribut avec sa valeur d’attribut "notify-lease-duration-default" (notifier la durée de location par défaut) (de 0 à 67108863). Si le client fournit cet attribut avec une valeur non prise en charge, l’imprimante DOIT remplir cet attribut avec une valeur acceptable, et cette valeur DEVRAIT être aussi proche que possible de la valeur demandée par le client. Note : cette règle implique qu’une imprimante n'alloue pas la valeur 0 (infini) sauf si le client le demande.
Après que l’imprimante a rempli cet attribut avec une valeur acceptée, cette valeur représente la "durée accordée" de la location en secondes et l’imprimante met à jour la valeur de l’attribut "notify-lease-expiration-time" (notifier l’heure d’expiration) de l’objet d’abonnement comme spécifié au paragraphe 5.4.3.
La valeur de cet attribut sur un objet d’abonnement DOIT être une valeur de l’attribut d’imprimante "notify-lease-duration-supported" (1setOf (integer(0:67108863) | rangeOfInteger(0:67108863))).
Une imprimante PEUT demander l’authentification afin de retourner la valeur 0 (la location n’arrive jamais à expiration) comme une des valeurs de "notify-lease-duration-supported", et pour permettre 0 comme valeur de l’attribut "notify-lease-duration".
Note : La valeur maximum 67 108 863 est 2 à la puissance 26 moins 1 et est d’environ 2 ans en secondes. La valeur est considérablement inférieure à MAX de sorte qu’il n’y a virtuellement aucune chance de débordement quand l’imprimante l’ajoute à la valeur d’attribut "printer-up-time" de l’imprimante (voir le paragraphe 4.4.29 de la [RFC2911]) pour produire la valeur d’attribut de description d’abonnement "notify-lease-expiration-time" (notifier l’heure d’expiration de la location) (voir au paragraphe 5.4.3).
5.3.8.1 notify-lease-duration-default (entier de 0 à 67108863))
Voir aux paragraphes 5.1 et 5.2 le comportement des attributs d’imprimante de gabarit d’abonnement "xxx-default".
5.3.8.2 notify-lease-duration-supported (1setOf (integer(0: 67108863) | rangeOfInteger(0:67108863))
Voir aux paragraphes 5.1 et 5.2 le comportement des attributs d’imprimante de gabarit d’abonnement "xxx-supported".
L’événement 'avancement de tâche' survient à chaque fois qu’une imprimante termine une page. Certains récepteurs de notification ne veulent pas recevoir une notification d’événement à chaque fois que se produit cet événement. Cet attribut permet à un Client abonné de demander la fréquence à laquelle il veut recevoir la notification d’événements pour les événements 'avancement de tâche'. La valeur de cet attribut PEUT peut être tout entier non négatif (0,MAX) indiquant le nombre minimum de secondes entre les notifications d’événement 'avancement de tâche'.
L’imprimante DOIT prendre en charge cet attribut si et seulement si l’imprimante prend en charge l’événement 'avancement de tâche'.
Un client PEUT fournir cet attribut dans une opération de création d’abonnement. Si le client ne fournit pas cet attribut dans l’opération de création d’abonnement, l’objet d’abonnement soit (1) PEUT contenir l’attribut "notify-time-interval" (notifier l’intervalle de temps) avec une valeur '0' soit (2) PEUT NE PAS contenir cet attribut du tout. Il n’y a pas d’attribut d’imprimante "notify-time-interval-default" (notifier l’intervalle de temps par défaut).
Il n’y a pas d’attribut d’imprimante "notify-time-interval-supported" (notifier l’intervalle de temps pris en charge).
Si l’événement 'avancement de tâche' survient et qu’un objet d’abonnement contient l’événement 'avancement de tâche' comme valeur de l’attribut 'notifier les événements', il faut distinguer deux cas :
1. Cet attribut n’est pas présent sur l’objet d’abonnement ou a la valeur 0. L’imprimante DOIT générer et délivrer une notification d’événement (comme c’est le cas avec les autres événements).
2. Cet attribut est présent avec une valeur N différente de zéro :
a) Si l’imprimante n’a pas envoyé de notification d’événement pour l’événement pour l’objet d’abonnement associé dans les N secondes passées, l’imprimante DOIT délivrer une notification d’événement pour l’événement qui vient de survenir. Noter que lorsque l’imprimante achève la première page d’une tâche, cette règle implique que l’imprimante délivre une notification d’événement pour un objet d’abonnement par tâche.
b) Autrement, l’imprimante NE DOIT PAS générer ou délivrer de notification d’événement pour l’objet d’abonnement associé. L’imprimante NE DOIT PAS augmenter la valeur de l’attribut d’objet d’abonnement "notifier le numéro de séquence" (c’est-à-dire, la séquence des valeurs de l’attribut "notifier le numéro de séquence" compte les notifications d’événement que l’imprimante envoie et non les événements qui ne causent pas l’envoi d’une notification d’événement).
Il est RECOMMENDÉ qu’un client abonné utilise cet attribut lorsqu’il s’abonne à l’événement 'avancement de tâche', et que la valeur soit suffisement grande pour limiter la fréquence à laquelle l’imprimante délivre les demandes de notification d’événement.
Cet attribut NE DOIT PAS affecter d’autre événement que 'avancement de tâche'.
Les attributs de description d’abonnement sont les attributs qu’une imprimante ajoute à un objet d’abonnement au moment de sa création.
Une imprimante DOIT prendre en charge tous les attributs du Tableau 2.
Un client NE DOIT PAS fournir les attributs du Tableau 2 dans un groupe d’attributs de gabarit d’abonnement d’une opération de création d’abonnement. Il n’y a pas d’attributs par défaut ou pris en charge correspondants.
Tableau 2 - Attributs de description d’abonnement
Attributs d’objet d’abonnement :
notify-subscription-id (integer(1:MAX)) (notifier l’identifiant d’abonnement (entier de 1 à Max)
notify-sequence-number (integer(0:MAX)) (notifier le numéro de séquence (entier de 0 à Max)
notify-lease-expiration-time (integer(0:MAX)) (notifier l’heure d’expiation de location (entier de 0 à Max)
notify-printer-up-time (integer(1:MAX)) (notifier l’heure d’activation de l’imprimante (entier de 1 à Max)
notify-printer-uri (uri) (notifier l’uri de l’imprimante (uri)
notify-job-id (integer(1:MAX)) (notifier l’identifiant de tâche (entier de 1 à Max)
notify-subscriber-user-name (name(MAX)) (notifier le nom de l’utilisateur abonné (nom(Max)
Cet attribut identifie une instance d’objet d’abonnement avec un numéro qui est unique dans le contexte de l’imprimante. L’imprimante génère cette valeur au moment où elle crée l’objet d’abonnement.
Une imprimante DOIT prendre en charge cet attribut.
L’imprimante PEUT allouer la valeur de cet attribut de façon séquentielle lorsqu’elle crée les objets d’abonnement. Cependant, il n’y a pas de sécurité sur les objets d’abonnement, et l’allocation séquentielle expose le système à des menaces d’espionnage passif du trafic.
L’imprimante DEVRAIT éviter de réutiliser des valeurs récentes de cet attribut pendant un fonctionnement continu de l’imprimante ainsi que sur un cycle d’alimentation. Un client d’abonnement aura alors peu de chances qu’une référence périmée donne accès à un nouvel objet d’abonnement.
La valeur 0 n’est pas autorisée afin de permettre la compatibilité avec "job-id" et avec les valeurs d’indice de tableau MIB, qu’il est recommandé d’avoir différentes de 0.
La valeur de cet attribut indique le nombre de fois où l’imprimante a généré et tenté de délivrer une notification d’événement pour cet objet d’abonnement. Lorsqu’une notification d’événement contient cet attribut, le récepteur de notification peut déterminer si il manque des notifications d’événement (c’est-à-dire, des numéros sautés) ou si des doubles sont reçus (c’est-à-dire, deux fois le même numéro).
Une imprimante DOIT prendre en charge cet attribut.
Lorsque l’imprimante crée un objet d’abonnement, elle DOIT remplir cet attribut avec une valeur de 0. Cette valeur indique que l’imprimante n’a pas envoyé de notification d’événement pour cet objet d’abonnement.
Chaque fois que l’imprimante délivre une notification d’événement qui vient d’être générée, elle DOIT augmenter la valeur de cet attribut de 1. Pour certaines méthodes de livraison, l’imprimante DOIT inclure cet attribut dans chaque notification d’événement, et la valeur DOIT être la valeur après l’augmentation de 1. C’est-à-dire que la valeur de cet attribut dans la première notification d’événement après la création de l’objet d’abonnement DOIT être 1, la seconde DOIT être 2, etc. Si une méthode de livraison est définie de telle sorte que le récepteur de notification retourne une réponse, l’imprimante peut réessayer de délivrer une notification d’événement un certain nombre de fois avec le même numéro de séquence lorsque le récepteur de notification échoue à retourner une réponse.
Si un objet d’abonnement dure assez longtemps pour atteindre la valeur de MAX, sa prochaine valeur DOIT être 0, c’est-à-dire qu’il fait un tour complet.
Cet attribut spécifie l’heure à venir à laquelle expirera la location de l’objet d’abonnement par imprimante, c’est-à-dire la valeur de "printer-up-time" (durée d’activation de l’imprimante) à laquelle va expirer la location. Si la valeur est 0, la location n’arrive jamais à expiration.
Une imprimante DOIT prendre en charge cet attribut.
Lorsque l’imprimante crée un objet d’abonnement par tâche, cet attribut NE DOIT PAS être présent – l’objet d’abonnement dure exactement aussi longtemps que l’objet de tâche associé. Voir aussi l’exposé de l’événement 'fin de tâche' au paragraphe 5.3.3.4.3 sur la rétention de l’objet tâche après achèvement de sorte qu’un récepteur de notification puisse interroger l’objet de tâche après réception de la notification d’événement 'fin de tâche'.
Lorsque l’imprimante crée un objet d’abonnement par imprimante, elle remplit cet attribut avec une valeur qui est la somme des valeurs de l’attribut "printer-up-time" de l’imprimante et de l’attribut "notify-lease-duration" de l’objet d’abonnement avec l’exception suivante. Si la valeur de l’attribut "notify-lease-duration" d’objet d’abonnement est 0 (c’est-à-dire, pas d’heure d’expiration), la valeur de cet attribut DOIT alors être mise à 0 (c’est-à-dire, pas d’heure d’expiration).
Lorsque l’imprimante est mise sous tension, elle DOIT remplir cet attribut dans chaque objet d’abonnement persistant avec une valeur qui utilise l’algorithme du paragraphe précédent.
Lorsque le "printer-up-time" est égal à la valeur de cet attribut, l’imprimante DOIT supprimer l’objet d’abonnement. Un client peut étendre une location d’un objet d’abonnement par imprimante avec l’opération de renouvellement d’abonnement (voir au paragraphe 11.2.6).
Note : Pour calculer le nombre de secondes restant dans une location pour un objet d’abonnement par imprimante, un client peut soustraire l’attribut "notify-printer-up-time" de l’abonnement (voir au paragraphe 5.4.4) de l’attribut "notify-lease-expiration-time" de l’abonnement.
Cet attribut est un autre nom pour l’attribut "printer-up-time" de l’imprimante (voir le paragraphe 4.4.29 de la [RFC2911]). En d’autres termes, lorsque cet attribut est interrogé par les opérations Get-Subscriptions ou Get-Subscription-Attributes (voir aux paragraphes 11.2.4 et 11.2.5), la valeur retournée est la valeur en cours de l’attribut "printer-up-time" de l’imprimante, plutôt que l’heure à laquelle l’objet d’abonnement a été créé.
Une imprimante DOIT prendre en charge cet attribut.
Lorsque l’imprimante crée un objet d’abonnement par tâche, cet attribut NE DOIT PAS être présent. Lorsque l’imprimante crée un objet d’abonnement par imprimante, cet attribut DOIT être présent.
Note : cet attribut existe dans un objet d’abonnement par imprimante de sorte qu’un client qui utilise les opérations Get-Subscription-Attributes ou Get-Subscription peut convertir l’attribut "notify-lease-expiration-time" de l’abonnement par imprimante en heure d’horloge avec une demande. Si la valeur de l’attribut "notify-lease-expiration-time" n’est pas 0 (c’est-à-dire, pas d’heure d’expiration), la différence entre les attributs "notify-lease-expiration-time" et "notify-printer-up-time" est alors le nombre de secondes restantes sur la location par rapport à l’heure courante.
Cet attribut identifie l’objet imprimante qui a créé cet objet d’abonnement.
Une imprimante DOIT prendre en charge cet attribut.
Durant une opération de création d’abonnement, l’imprimante DOIT remplir cet attribut avec la valeur de l’attribut d’opération "printer-uri" dans la demande. A partir de l’URI de l’imprimante, le client peut, par exemple, déterminer quel schéma de sécurité a été utilisé.
Cet attribut spécifie si l’objet d’abonnement contenant est un objet d’abonnement par tâche ou par imprimante,et pour les objets d’abonnement par tâche, il spécifie la tâche associée.
Une imprimante DOIT prendre en charge cet attribut.
Si cet attribut n’est pas présent, l’objet d’abonnement DOIT être un abonnement par imprimante. Si cet attribut est présent, l’objet d’abonnement DOIT être un objet d’abonnement par tâche et cet attribut DOIT identifier la tâche à laquelle l’objet d’abonnement est associé.
Note : Cet attribut pourrait être utile au récepteur de notification qui reçoit une notification d’événement générée à partir d’un objet d’abonnement par tâche et causée par un événement d’imprimante. La notification d’événement donne accès à l’imprimante et à l’objet d’abonnement. La notification d’événement ne donne accès à la tâche associée que via cet attribut. Voir au paragraphe 5.3.3.4.3 l’exposé sur l’événement 'fin de tâche' à propos de la rétention de l’objet tâche après achèvement de sorte qu’un récepteur de notification puisse interroger l’objet tâche après réception de la notification d’événement 'fin de tâche'.
Cet attribut contient le nom de l’utilisateur qui a effectué l’opération de création d’abonnement.
Une imprimante DOIT prendre en charge cet attribut.
L’imprimante DOIT remplir cet attribut avec le nom imprimable le plus authentifié qu’il puisse obbtenir du service d’authentification sur lequel l’opération de création d’abonnement a été reçue. L’imprimante utilise le même mécanisme pour déterminer la valeur de cet attribut comme elle le fait pour un "job-originating-user-name" (nom d’utilisateur d’origine de tâche) de tâche (voir le paragraphe 4.3.6 de la [RFC2911]).
Note : Pour aider à l’authentification, un objet d’abonnement peut avoir des attributs privés supplémentaires sur l’utilisateur, par exemple, un accréditif d’un principal. De tels attributs privés dépendent de la mise en œuvre et ne sont pas définis dans le présent document.
La présente section définit les attributs de description de l’imprimante qui se rapportent à la Notification. Le Tableau 3 fait la liste des attributs de description de l’imprimante, indique le support d’imprimante exigé pour la conformité, et si l’attribut est ou non en LECTURE SEULE (READ-ONLY) (voir au paragraphe 3.1) :
Tableau 3 - Attributs de description d’imprimante associés à Notification
|
Attributs d’objet
imprimante : |
EXIGÉ |
READ-ONLY |
|
printer-state-change-time
(entier de 1 à MAX) |
Non |
oui |
|
printer-state-change-date-time
(date et heure) |
Non |
oui |
Cet attribut FACULTATIF note l’heure la plus récente à laquelle l’événement d’imprimante 'printer-state-changed' (changement d’état de l’imprimante) est survenu, que des objets d’abonnement surveillent ou non cet événement. Cet attribut aide un client ou opérateur à déterminer depuis combien de temps l’imprimante se trouve dans l’état en cours.
Une imprimante PEUT prendre en charge cet attribut et si c’est le cas, l’attribut DOIT être LECTURE SEULE.
A la mise sous tension, l’imprimante DOIT remplir cet attribut avec la valeur de son attribut "printer-up-time", de sorte qu’il ait toujours une valeur. Chaque fois que survient l’événement d’imprimante 'printer-state-changed', l’imprimante DOIT mettre à jour cet attribut avec la valeur de l’attribut "printer-up-time" de l’imprimante.
Cet attribut FACULTATIF note l’heure la plus récente à laquelle est survenu l’événement d’imprimante 'printer-state-changed' que des objets d’abonnement surveillent ou non cet événement. Cet attribut aide un client ou opérateur à déterminer depuis combien de temps l’imprimante est dans l’état en cours.
Une imprimante PEUT prendre en charge cet attribut et si c’est le cas, l’attribut DOIT être LECTURE SEULE.
A la mise sous tension, l’imprimante DOIT remplir cet attribut avec la valeur de son attribut "printer-current-time", de sorte qu’il ait toujours une valeur (voir le paragraphe 4.4.30 de la [RFC2911] sur "printer-current-time").
Chaque fois que survient l’événement d’imprimante 'printer-state-changed', l’imprimante DOIT mettre à jour cet attribut avec la valeur de l’attribut "printer-current-time" de l’imprimante.
La présente section contient les attributs pour lesquels des valeurs supplémentaires ont été ajoutées.
Les valeurs suivantes de "id d’opération" sont ajoutées afin de prendre en charge les nouvelles opérations définies dans le présent document:
Tableau 4 – Allocations d’id d’opération
|
Valeur |
Nom de l’opération |
|
0x0016 |
Create-Printer-Subscriptions
(créer des abonnements d’imprimante) |
|
0x0017 |
Create-Job-Subscriptions
(créer des abonnements de tâche) |
|
0x0018 |
Get-Subscription-Attributes
(obtenir des attributs d’abonnement) |
|
0x0019 |
Get-Subscriptions (obtenir
des abonnements) |
|
0x001A |
Renew-Subscription (renouveller
l’abonnement) |
|
0x001B |
Cancel-Subscription
(annuler l’abonnement) |
La présente section contient ceux des attributs qui n’existent que dans les notifications d’événement et n’existent dans aucun objet.
Cet attribut indique l’événement abonné qui a amené l’imprimante à délivrer cette notification d’événement. Cet attribut n’existe que dans les notifications d’événement.
Cet attribut DOIT contenir une des valeurs de l’attribut "notify-events" dans l’objet d’abonnement, c’est-à-dire, une des valeurs d’événement abonné. Sa valeur est l’événement abonné qui "correspond" à l’événement qui a amené l’imprimante à délivrer cette notification d’événement. Cette valeur d’événement abonné peut être identique à l’événement ou l’événement peut être une sous-valeur de l’événement abonné. Par exemple, l’événement 'fin de tâche' (qui est un sous-événement de l’événement 'changement d’état de tâche') amènerait l’imprimante à délivrer une notification d’événement pour les événements abonnés 'fin de tâche' ou 'changement d’état de tâche' et à délivrer respectivement la valeur 'fin de tâche' ou 'changement d’état de tâche' pour cet attribut. Voir au paragraphe 5.3.3.5 les règles de "correspondance" des événements abonnés et pour d’autres exemples.
Le document de méthode de livraison spécifie si l’imprimante inclut la valeur de cet attribut dans une notification d’événement.
Cet attribut contient un message textuel à destination humaine (voir au paragraphe 9.2). Ce message décrit l’événement et est codé comme texte pur, c’est-à-dire, 'text/plain' avec le charset spécifié par l’attribut "notify-charset" de l’objet d’abonnement.
Note : cet attribut contient seulement un message textuel et ne doit contenir aucune information de codage, telle que 'text/plain'. Le codage 'text/plain' est implicite et donc le charset doit être spécifié par un mécanisme de remplacement, à savoir l’attribut "notify-charset".
Le document méthode de livraison spécifie si l’imprimante inclut cet attribut dans une notification d’événement.
La présente section définit le contenu de la notification d’événement que délivre l’imprimante lorsque survient un événement.
Lorsque survient un événement, l’imprimante DOIT trouver chaque objet d’abonnement dont l’attribut "notify-events" "correspond" à l’événement. Voir au paragraphe 5.3.3.5 les détails sur "correspond". Pour chaque objet d’abonnement correspondant, l’imprimante DOIT créer une notification d’événement avec le contenu et le format spécifié par le document de méthode de livraison. Le contenu contient la valeur des attributs spécifiés par le document de méthode de livraison. L’imprimante obtient les valeurs immédiatement après la survenance de l’événement. Par exemple, si l’attribut "état d’imprimante" change de 'repos' à 'traitement', l’événement 'changement d’état de l’imprimante' survient et l’imprimante met divers attributs dans la notification d’événement, y compris "printer-up-time" et "état d’imprimante" avec les valeurs qu’ils ont immédiatement après la survenance de l’événement, c’est-à-dire, la valeur de "état d’imprimante" est 'traitement'.
Ordre des notifications d’événement :
Lorsqu’une imprimante délivre des notifications d’événement, les notifications d’événement provenant de tout objet d’abonnement donné DOIVENT être dans l’ordre de l’horodatage, c’est-à-dire, en ordre croissant de valeur d’attribut "printer-up-time" dans la notification d’événement (voir au Tableau 5). Ces notifications d’événement PEUVENT être entrelacées avec celle provenant d’autres objets d’abonnement, pourvu que ces autres notifications soient aussi dans l’ordre de l’horodatage. L’imprimante DOIT observer ces exigences d’ordonnancement qu’elle délivre plusieurs événements en cours sous forme de multiples notifications d’événement séparées ou rassemblées dans une seule notification d’événement composée.
Si un Client abonné veut que l’imprimante délivre certaines notifications d’événement dans l’ordre de l’horodatage, il utilise un seul objet d’abonnement. Même ainsi, selon le transport sous jacent, l’ordre réel dans lequel un récepteur de notification reçoit des notifications d’événement séparées diffère de l’ordre d’envoi par l’imprimante (par exemple, messagerie électronique).
Exemple : Considérons deux objets d’abonnement par imprimante : SO1 et SO2. SO1 demande les événements 'changement d’état de tâche' et SO2 demande les événements 'changement d’état d’imprimante'. Le nombre entre parenthèses est l’horodatage. Les séquences de notification d’événement suivantes sont les seules qui se conforment aux exigences d’ordonnancement pour la délivrance des notifications d’événement par l’imprimante :
(a) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO1: 'job-completed' (1009), SO2: 'printer-stopped' (1005)
(b) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO2: 'printer-stopped' (1005), SO1: 'job-completed' (1009)
(c) SO1: 'job-created' (1000), SO2: 'printer-stopped' (1005), SO1: 'job-stopped' (1005), SO1: 'job-completed' (1009)
(d) SO2: 'printer-stopped (1005), SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO1: 'job-completed' (1009)
Les exemples (b) et (c) sont entrelacés ; les exemples (a) et (d) ne sont pas entrelacés et ne sont pas appropriés pour certaines méthodes de livraison.
Si deux événements différents surviennent simultanément, ou presque (par exemple, "printer-up-time" a la même valeur pour les deux), l’imprimante DOIT créer une notification d’événement séparée pour chaque événement, même si l’objet d’abonnement associé est le même pour les deux événements. Cependant, l’imprimante PEUT combiner ces notifications d’événement distinctes en une seule notification d’événement composée si la méthode de livraison accepte les notifications d’événement composées. Par exemple, supposons que deux événements presque simultanés représentent deux événements 'changement d’état d’imprimante' successifs, un de 'repos' à 'traitement' et l’autre de 'traitement' à 'arrêté'. Ces deux événements ont le même nom mais sont des instances différentes de l’événement. L’imprimante DOIT alors créer une notification d’événement séparée pour chaque événement et DEVRAIT rapporter précisément l’état d’imprimante du premier événement comme 'traitement' et le second événement comme 'arrêté'.
Si un objet d’abonnement contient plus d’un événement abonné, et que plusieurs événements surviennent en succession rapide, chacun correspondant à un événement abonné différent dans l’objet d’abonnement, l’imprimante NE DOIT PAS générer une notification d’événement unique à partir de plusieurs de ces événements, mais PEUT combiner des notifications d’événement distinctes en une seule notification d’événement composée si la méthode de livraison accepte les notifications d’événement composées.
Après la création de la notification d’événement par l’imprimante, celle-ci la délivre via :
une méthode de livraison poussée : l’imprimante délivre la notification d’événement peu après qu’un événement survienne. Pour certaines méthodes de livraison poussées, le récepteur de notification DOIT délivrer une réponse ; pour d’autres il NE DOIT PAS délivrer une réponse.
une méthode de livraison tirée : l’imprimante sauvegarde les notifications d’événement pour une certaine durée de vie de l’événement et attend que le récepteur de notification demande des notifications d’événement. L’imprimante retourne les notifications d’événement dans une réponse à de telles demandes.
Si une erreur satisfaisant aux conditions ci-après survient, l’imprimante DOIT annuler l’objet d’abonnement.
a) l’erreur survient durant la délivrance d’une notification d’événement générée à partir d’un objet d’abonnement S ET
b) l’erreur continuerait de se produire chaque fois que l’imprimante délivre une notification d’événement générée à partir de l’objet d’abonnement S à l’avenir.
Par exemple, l’adresse du "notify-recipient-uri" de l’objet d’abonnement A se réfère à une cible non existante et l’imprimante détermine ce fait, elle DOIT supprimer l’objet d’abonnement A.
Les deux paragraphes suivants décrivent respectivement les valeurs que délivre une imprimante dans le contenu des notifications d’événement à destination machine et à destination humaine.
Les tableaux de ces paragraphes contiennent les colonnes suivantes :
a) Valeur de source : nom de l’attribut qui fournit la valeur pour la notification d’événement. Les astérisques dans ce champ se réfèrent à une note au bas du tableau.
b) Délivre : si l’imprimante accepte la valeur (colonne 1) sur l’objet de source (colonne 3) la méthode de livraison DOIT spécifier :
DOIT : que l’imprimante DOIT délivrer la valeur.
DEVRAIT : soit que l’imprimante DOIT délivrer la valeur soit que la valeur est incompatible avec la méthode de livraison.
PEUT : que l’imprimante DOIT, DEVRAIT, PEUT, NE DOIT PAS, NE DEVRAIT PAS, ou PEUT NE PAS délivrer la valeur. La méthode de livraison spécifie le niveau de conformité pour l’imprimante.
c) Objet de source : objet duquel vient la valeur de source. Si l’objet est "notification d’événement", l’imprimante fabrique la valeur quand elle délivre la notification d’événement. Voir la section 8.
Ce paragraphe définit les attributs qu’une méthode de livraison DOIT mentionner dans un document de méthode de livraison lors de la spécification du contenu d’une notification d’événement à destination machine.
Le présent document ne définit pas l’ordre des attributs dans les notifications d’événement. Cependant, les documents de méthode de livraison PEUVENT définir l’ordre de certains ou de tous les attributs.
Un document de méthode de livraison DOIT spécifier les attributs supplémentaires (s’il en est) qu’une mise en œuvre d’imprimante délivre dans une notification d’événement à destination machine.
Les récepteurs de notification DOIVENT être capables d’accepter des notifications d’événement contenant des attributs qu’ils ne reconnaissent pas. Ce qu’un récepteur de notification fait d’un attribut non reconnu dépend de la mise en œuvre. Les récepteurs de notification PEUVENT essayer d’afficher de toutes façons les attributs non reconnus ou PEUVENT les ignorer.
Les trois paragraphes suivants définissent les attributs dans les contenus de notification d’événement qui sont :
1. pour tous les événements
2. seulement pour les événements de tâche
3. seulement pour les événements d’imprimante.
Ce paragraphe fait la liste des attributs qu’un document de méthode de livraison DOIT spécifier pour tous les événements.
Le Tableau 5 fait la liste des valeurs potentielles dans chaque notification d’événement.
Tableau 5 - Attributs dans le contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
notify-subscription-id
(entier(1:MAX)) |
DOIT |
Abonnement |
|
notify-printer-uri
(uri) |
DOIT |
Abonnement |
|
notify-subscribed-event
(mot clé type2) |
DOIT |
notification
d’événement |
|
printer-up-time
(integer(MIN:MAX)) |
DOIT |
Imprimante |
|
printer-current-time
(date et heure) * |
DOIT |
Imprimante |
|
notify-sequence-number
(entier (0:MAX)) |
DEVRAIT |
Abonnement |
|
notify-charset
(charset) |
DEVRAIT |
Abonnement |
|
notify-natural-language
(Langage naturel) |
DEVRAIT |
Abonnement |
|
notify-user-data
(chaîne d’octets(63)) ** |
DEVRAIT |
Abonnement |
|
notify-text (texte) |
DEVRAIT |
notification d’événement |
|
attributs de
"notify-attributes" |
PEUT |
Attribut
d’imprimante *** |
|
attributs de
"notify-attributes" |
PEUT |
Attribut de tâche
*** |
|
attributs de
"notify-attributes" |
PEUT |
Attribut d’abonnement
*** |
* Une imprimante ne DOIT délivrer cette valeur que si et seulement si elle prend en charge l’attribut de l’imprimante "printer-current-time" (heure en cours de l’imprimante).
** Si l’objet d’abonnement ne contient pas un attribut "notify-user-data" (notifier les données d’utilisateur) et que le document de méthode de livraison EXIGE que l’imprimante délivre la valeur de source "notify-user-data" dans la notification d’événement, l’imprimante DOIT délivrer une chaîne d’octets de longueur 0.
*** Les trois dernières rangées représentent des attributs supplémentaires qu’un client PEUT demander via l’attribut "notify-attributes". Une imprimante PEUT prendre en charge l’attribut "notify-attributes". La méthode de livraison DOIT dire que l’imprimante DOIT, DEVRAIT, PEUT, NE DOIT PAS, NE DEVRAIT PAS, ou PEUT NE PAS prendre en charge l’attribut "notify-attributes" et des valeurs spécifiques de cet attribut. La méthode de livraison PEUT dire que la prise en charge de "notify-attributes" est conditionnée par la prise en charge de l’attribut par l’imprimante ou elle PEUT dire que l’imprimante DOIT prendre en charge l’attribut "notify- attributes" si l’imprimante accepte la méthode de livraison.
Ce paragraphe fait la liste des attributs supplémentaires qu’un document de méthode de livraison DOIT spécifier pour les événements de tâche. Voir le Tableau 6.
Tableau 6 – Contenu supplémentaire de notification
d’événement
pour les événements de tâche
|
Valeur de source |
Livraison |
Objet de source |
|
job-id
(integer(1:MAX)) |
DOIT |
Tâche |
|
job-state (énumération
de type1) |
DOIT |
Tâche |
|
job-state-reasons
(1setOf mot clé de type2) |
DOIT |
Tâche |
|
job-impressions-completed
(entier(0:MAX)) * |
DOIT |
Tâche |
* L’imprimante ne DOIT délivrer l’attribut "job-impressions-completed" (fin de tâches d’impression) dans une notification d’événement que pour les combinaisons d’événements et d’événements abonnés indiquées au Tableau 7.
Tableau 7 - Combinaisons d’événements et d’événements abonnés pour "job-impressions-completed"
|
Événement de tâche |
Événement de tâche abonnét |
|
'job-progress' |
'job-progress' |
|
'job-completed' |
'job-completed' |
|
'job-completed' |
'job-state-changed' |
Ce paragraphe fait la liste des attributs supplémentaires qu’un document de méthode de livraison DOIT spécifier pour les événements d’imprimante. Voir le Tableau 8.
Tableau 8 – Contenu supplémentaire de notification d’événement pour les événements d’imprimante
|
Valeur de source |
Livraison |
Objet de source |
|
printer-state (énumération
de type1) |
DOIT |
Imprimante |
|
printer-state-reasons
(1setOf mot clé de type2) |
DOIT |
Imprimante |
|
printer-is-accepting-jobs
(booléen) |
DOIT |
Imprimante |
Ce paragraphe définit les informations qu’une méthode de livraison DOIT mentionner dans un document de méthode de livraison lors de la spécification de contenus de notifications d’événements à destination humaine ou de la valeur de l’attribut "notify-text".
Une telle méthode de livraison DOIT spécifier les informations suivantes et une imprimante DEVRAIT les délivrer :
a) nom de l’imprimante (voir le Tableau 9)
b) heure de l’événement (voir le Tableau 11)
c) seulement pour les événements d’imprimante :
i) les informations d’état de l’événement (voir le Tableau 10) et/ou de l’imprimante (voir le Tableau 14)
d) seulement pour les événements de tâche :
i) l’identité de la tâche (voir le Tableau 12)
ii) les informations d’état de l’événement (voir le Tableau 10) et/ou de tâche (voir le Tableau 13).
Les sous-paragraphes de cette section spécifient les attributs qu’une imprimante DOIT utiliser pour obtenir cette information.
Un document de méthode de livraison DOIT spécifier les informations supplémentaires(s’il en est) qu’une mise en œuvre d’imprimante délivre dans une notification d’événement à destination humaine ou dans l’attribut "notify-text".
Un client NE DOIT PAS demander des attributs supplémentaires via l’attribut "notify-attributes" parce que cet attribut ne fonctionne que pour les notifications d’événement à destination machine.
Les récepteurs de notification NE DOIVENT PAS s’attendre à être capables d’analyser le contenu des notifications d’événement à destination humaine ou les valeur de l’attribut "notify-text".
Les trois paragraphes suivants définissent les attributs dans les contenus de notification d’événement qui sont :
a) pour tous les événements
b) seulement pour les événements de tâche
c) seulement pour les événements d’imprimante.
Ce paragraphe fait la liste des sources d’informations qu’une méthode de livraison DOIT spécifier pour tous les événements.
Il y a un tableau séparé pour chaque élément d’information. Chaque rangée du tableau représente une valeur de source pour les informations et les valeurs sont listées dans l’ordre de préférence, la première étant la préférée. Une mise en œuvre DEVRAIT utiliser la valeur de source de la plus proche rangée de chaque tableau. Elle PEUT à la place utiliser la valeur de source d’une autre rangée, ou elle PEUT combiner les valeurs de source de plusieurs rangées. Une mise en œuvre a toute liberté pour déterminer la meilleure façon de présenter cette information.
Dans tous les tableeaux de la présente section, toutes les rangées contiennent un "PEUT" afin d’établir que la méthode de livraison spécifie la conformité.
Le Tableau 9 fait la liste des sources d’information pour le nom de l’imprimante. Le "printer-name" est d’utilisation plus facile à moins que le récepteur de notification soit dans un endroit où le nom de l’imprimante n’est pas significatif. Par exemple, une mise en œuvre pourrait avoir l’intelligence de délivrer la valeur de l’attribut "printer-name" à un récepteur de notification qui peut accéder à l’imprimante via la valeur de l’attribut "printer-name" et autrement de délivrer la valeur de l’attribut "notify-printer-uri".
Tableau 9 – Nom de l’imprimante dans un contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
printer-name (nom(127)) |
PEUT |
Imprimante |
|
notify-printer-uri
(uri) |
PEUT |
Abonnement |
Le Tableau 10 fait la liste des sources d’information pour le nom d’événement. Une imprimante PEUT combiner ces informations avec les informations d’état décrites pour les tâches dans le Tableau 13 ou pour les imprimantes au Tableau 14.
Tableau 10 – Nom d’événement dans le contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
notify-subscribed-event
(mot clé de type2) |
PEUT |
Abonnement |
Le Tableau 11 fait la liste des sources d’information pour l’heure d’arrivée de l’événement. Une imprimante ne peut délivrer cette valeur que si elle prend en charge l’attribut de l’imprimante "printer-current-time". Si une imprimante ne prend pas en charge l’attribut "printer-current-time", elle NE DOIT PAS délivrer à la place la valeur "printer-up-time", car ce n’est pas une option admise pour les informations à destination humaine.
Tableau 11 – Heure d’événement dans un contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
printer-current-time
(date et heure) |
PEUT |
Imprimante |
Ce paragraphe fait la liste des sources d’informations supplémentaires qu’une méthode de livraison DOIT spécifier pour les événements de tâche.
Le Tableau 12 fait la liste des sources d’information pour le nom de tâche. Le "job-name" est vraisemblablement plus significatif pour un utilisateur qu’un "job-id".
Tableau 12 – Nom de tâche dans le contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
job-name (nom(MAX)) |
PEUT |
Tâche |
|
job-id (entier(1:MAX)) |
PEUT |
Tâche |
Le Tableau 13 fait la liste des sources d’information pour l’état de tâche. Si une imprimante prend en charge les attributs "job-state-message" et "job-detailed-state- message", elle DEVRAIT utiliser ces attributs pour les informations d’état de tâche, et autrement, elle devrait fabriquer de telles informations à partir de "job-state" et "job-state-reasons". Pour certains événements, une imprimante PEUT combiner ces informations avec les informations d’événement.
Tableau 13 – Etat de tâche dans le contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
job-state-message
(texte(MAX)) |
PEUT |
Tâche |
|
job-detailed-status-messages
(1setOf texte(MAX)) |
PEUT |
Tâche |
|
job-state (énumération
de type1) |
PEUT |
Tâche |
|
job-state-reasons
(1setOf mot clé de type2) |
PEUT |
Tâche |
Ce paragraphe fait la liste des sources des informations supplémentaires qu’une méthode de livraison DOIT spécifier pour les événements d’imprimante.
Le Tableau 14 fait la liste des sources d’information pour l’état d’imprimante. Si une imprimante prend en charge le "printer-state-message", elle DEVRAIT utiliser cet attribut pour les informations d’état de tâche, et autrement, elle DEVRAIT fabriquer de telles informations à partir de "printer-state" et "printer-state-reasons". Pour certains événements, une imprimante PEUT combiner ces informations avec des informations d’événement.
Tableau 14 – Etat d’imprimante dans le contenu de notification d’événement
|
Valeur de source |
Livraison |
Objet de source |
|
printer-state-message
(texte(MAX)) |
PEUT |
Imprimante |
|
printer-state (énumération
de type1) |
PEUT |
Imprimante |
|
printer-state-reasons
(1setOf mot clé de type2) |
PEUT |
Imprimante |
|
printer-is-accepting-jobs
(booléen) |
PEUT |
Imprimante |
Une méthode de livraison est le mécanisme, c’est-à-dire, le protocole, par lequel l’imprimante délivre une notification d’événement à un récepteur de notification. Il y a plusieurs méthodes de livraison possibles pour les notifications d’événement, normalisées, aussi bien que du domaine privé. La présente spécification EXIGE que la méthode de livraison tirée 'ippget' de [RFC3996] soit prise en charge. Les mises en œuvre conformes PEUVENT aussi prendre en charge des méthodes de livraisons tirées ou poussées. Le présent document ne définit aucun de ces mécanismes de livraison. Chaque méthode de livraison DOIT être définie dans un document de méthode de livraison distinct du présent document. De nouvelles méthodes de livraison seront créées en tant que de besoin en utilisant une extension aux procédures d’enregistrement définies dans [RFC2911]. De tels documents sont enregistrés auprès de l’IANA (voir au § 23.7.3).
Les méthodes de livraison suivantes sont possibles :
- Le récepteur de notification consulte les notifications d’événements à des intervalles définis par l’imprimante.
- L’imprimante délivre les notifications d’événement au récepteur de notification en utilisant http comme moyen de transport.
- L’imprimante délivre un message électronique.
Le présent paragrahe spécifie comment définir un document de méthode de livraison et ce qu’il convient de mettre dans un tel document.
Un document de méthode de livraison DOIT contenir une copie exacte du paragraphe, du tableau et de la légende suivants. De plus, la colonne 2 du tableau du document de méthode de livraison DOIT contenir les réponses aux questions de la colonne 1 sur la méthode de livraison. Le document de méthode de livraison DOIT aussi contenir une référence au présent document et appeler cette référence [RFC3995] parce que le tableau contient une référence à [RFC3995].
Si une imprimante prend en charge cette méthode de livraison, ses caractéristiques sont les suivantes :
Tableau 15 – Informations sur la méthode de livraison
|
|
Exigences de
conformité pour le document de méthode |
Réalisation de la
méthode de livraison |
|
1 |
Quel est le nom du
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 ? |
|
|
2 |
Pour une imprimante
IPP, la prise en charge de la méthode de livraison est-elle EXIGÉE, RECOMMANDÉE,
ou FACULTATIVE ? |
|
|
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 réseau complète
? |
|
|
4 |
Plusieurs
notifications d’événement peuvent-elles être combinée dans une notification
d’événement composée ? |
|
|
5 |
La méthode de
livraison est elle initiée par le récepteur de notification (tirée), ou par
l’imprimante (poussée) ? |
|
|
6 |
Le contenu de la
notification d’événement est-il à destination machine ou à destination humaine
? |
|
|
7 |
Quel paragraphe du
présent document répond à la question suivante : Pour une notification
d’événement à destination machine, quelle est la représentation et quel est
le codage des valeurs définies au paragraphe 9.1 de [RFC3995] et des
exigences de conformité qu’elle contient ? Pour une notification d’événement
à destination humaine, quelle est la représentation et quel est le codage des
éléments d’information définis au paragraphe 9.2 de [RFC3995] et des
exigences de conformité qu’elle contient ? |
|
|
8 |
Quels sont le délai
de latence et la fiabilité du protocole de transport et de livraison ? |
|
|
9 |
Quels sont les
problèmes de sécurité du protocole de transport et de livraison ; par
exemple, comment est-il traité dans les pare-feu ? |
|
|
10 |
Quelles sont les restrictions
sur la longueur du contenu ? |
|
|
11 |
Quelles sont les
valeurs ou éléments d’information supplémentaires qu’une imprimante délivre
dans un contenu de notification d’événement et les exigences de conformité
qu’elle contient ? |
|
|
12 |
Quels sont les
attributs de gabarit d’abonnement et/ou description d’abonnement
supplémentaires et des exigences de conformité qu’ils contiennent ? |
|
|
13 |
Quels sont les
attributs supplémentaires de description d’imprimante et des exigences de
conformité qu’elle contient ? |
|
La présente section définit toutes les opérations pour Notification. Le paragraphe 7.1 alloue l’"id d’opération" pour chaque opération. Les deux paragraphes suivants définissent les opérations de création d’abonnement, et les autres opérations.
Cette section définit les opérations de création d’abonnement. Le premier paragraphe sur l’opération Créer des abonnements de tâche donne l’essentiel de l’information. Les autres opérations de création d’abonnement se réfèrent au paragraphe sur Créer des abonnements de tâche au moyen de l’opération Créer des abonnements de tâche qui est la seule opération FACULTATIVE dans le présent document (voir au paragraphe 12).
Une imprimante DOIT prendre en charge Créer des abonnements d’imprimante et le groupe d’attributs de gabarit d’abonnement dans les opérations de création de tâche. Elle PEUT prendre en charge les opérations Créer des abonnements de tâche.
L’opération crée un ou plusieurs objets d’abonnement par tâche. Le client fournit un ou plusieurs groupes d’attributs de gabarit d’abonnement dont chacun contient un ou plusieurs attributs de gabarit d’abonnement (définis au paragraphe 5.3).
Sauf pour les erreurs, l’imprimante DOIT créer exactement un objet d’abonnement par tâche provenant de chaque groupe d’attributs de gabarit d’abonnement de la demande, même si l’objet d’abonnement nouvellement créé aurait un comportement identique à celui d’un objet d’abonnement existant. L’imprimante DOIT associer chaque objet d’abonnement par tâche nouvellement créé avec la tâche cible, qui est spécifiée par l’attribut d’opération "notify-job-id" (notifier l’identifiant de tâche).
L’imprimante DOIT accepter la demande dans tous les états 'non terminé' de la tâche cible, c’est-à-dire, 'en suspens', 'gardé en suspens', 'traitement en cours, ou 'traitement arrêté'. L’imprimante NE DOIT PAS changer l’attribut "état de tâche " de la tâche à cause de cette opération. Si la tâche cible est dans l’un des états 'achevé', c’est-à-dire, 'terminé', 'annulé', ou 'avorté, l’imprimante DOIT alors rejeter la demande et retourner le code d’état 'erreur client, impossible' ; la réponse NE DOIT PAS contenir de groupe d’attributs d’abonnement.
Droits d’accès : Pour créer des objets d’abonnement par tâche, l’usager authentifié (voir la [RFC2911] paragraphe 8.3) effectuant cette opération DOIT (1) être le propriétaire de la tâche, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante pour créer des objets d’abonnement par tâche pour la tâche cible. Autrement, l’imprimante 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.
11.1.1.1 Demande Créer des abonnements de tâche
Les groupes d’attributs suivants font partie de la demande Créer des abonnements de tâche :
Groupe 1 : Attributs d’opération
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont décrits au paragraphe 3.1.4.1 de la [RFC2911].
Cible : L’attribut "printer-uri" (URI de l’imprimante) qui définit la cible de cette opération comme décrit au paragraphe 3.1.5 de la [RFC2911].
Nom de l’usager demandeur :
L’attribut "requesting-user-name" DEVRAIT être fourni par le client comme décrit au paragraphe 8.3 de la [RFC2911].
11.1.1.1.1 notify-job-id (entier de 1 à MAX)
Le client DOIT fournir cet attribut et il DOIT spécifier l’objet de tâche associé à l’abonnement de tâche. La valeur de "notify-job-id" DOIT être la valeur du "job-id" de l’objet de tâche associé. Si le client ne fournit pas cet attribut, l’imprimante DOIT rejeter cette demande avec un code d’état 'erreur client, mauvaise demande'.
Groupe 2-N : Attributs de gabarit d’abonnement
Pour chaque occurrence de ce groupe :
Le client DOIT fournir un ou plusieurs attributs de gabarit d’abonnement dans n’importe quel ordre. Voir au paragraphe 5.3 la description ce ces attributs. Voir au paragraphe 5.2 les détails du traitement de ces attributs.
11.1.1.2 Réponse à Créer des abonnements de tâche
L’imprimante DOIT retourner au client les ensembles suivants d’attributs au titre de la réponse à Créer des abonnements de tâche :
Groupe 1 : Attributs d’opération
Message d’état :
En plus du code d’état EXIGÉ retourné dans toute 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 [RFC2911].
Dans ce groupe, l’imprimante peut retourner tous les codes d’état définis dans la [RFC2911] et à la section 12. Les codes d’état les plus importants sont décrits ci-après :
successful-ok : l’imprimante a créé tous les objets d’abonnement demandés (voir la [RFC2911]).
successful-ok-ignored-subscriptions : l’imprimante a créé certains objets d’abonnement demandés mais certains ont échoué. Les groupes d’attributs d’abonnement avec un attribut "notifier le code d’état" sont ceux qui ont échoué (voir au paragraphe 12.1).
client-error-ignored-all-subscriptions : l’imprimante n’a pas créé les objets d’abonnement demandés et tous ont échoué. Les groupes d’attributs d’abonnement avec un attribut "notifier le code d’état" sont ceux qui ont échoué (voir au paragraphe 12.2).
client-error-not-possible : pour cettte opération et les autres opérations d’abonnement par tâche, cette erreur peut survenir parce que la tâche spécifiée a déjà été accomplie (voir la [RFC2911], que la tâche soit retenue ou non dans les phases de rétention de tâche et/ou d’historique des tâches (voir le paragraphe 4.3.7.1 de la [RFC2911]).
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont décrits au paragraphe 3.1.4.2 de la [RFC2911].
Groupe 2 : Attributs non pris en charge
Voir au paragraphe 3.1.7 de la [RFC2911] les détails sur le retour des attributs non pris en charge. Ce groupe ne contient aucun attribut de gabarit d’abonnement non pris en charge ; ils sont retournés dans le groupe d’attributs d’abonnement (voir ci-dessous).
Groupe 3-N : Attributs d’abonnement
Ces groupes DOIVENT être retournés à moins que l’imprimante ne soit incapable d’interpréter la demande toute entière, par exemple, le paramètre "code d’état" retourné dans le groupe 1 a la valeur : 'erreur client, mauvaise demande'.
"notifier le code d’état" (énumération de type2) :
Elle indique l’état de cet abonnement (voir à la section 13 les définitions de code d’état). Le paragraphe 5.2 définit quand cet attribut DOIT être présent dans ce groupe.
Voir au paragraphe 5.2 les détails sur le contenu de chaque occurrence de ce groupe
L’opération est identique à Create-Job-Subscriptions (créer des abonnements de tâches) avec les exceptions mentionnées dans ce paragraphe.
L’opération crée des objets d’abonnement par imprimante au lieu d’objets d’abonnement par tâche, et associe chaque objet d’abonnement par imprimante nouvellement créé à l’imprimante spécifiée par la cible de l’opération plutôt qu’à une tâche spécifique.
L’imprimante DOIT accepter la demande dans tous ses états, c’est-à-dire, 'repos', 'en traitement', ou 'arrêtée'. L’imprimante NE DOIT PAS changer son attribut "état d’imprimante" à cause de cette opération.
Droits d’accès : Pour créer des objets d’abonnement par imprimante, l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT avoir (1) des droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (2) être autorisé d’une autre façon par la politique de sécurité configurée par l’administrateur de l’imprimante à créer des objets d’abonnement par imprimante pour cette imprimante. Autrement, l’imprimante 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é.
11.1.2.1 Demande Create-Printer-Subscriptions
Les groupes sont identiques à Create-Job-Subscriptions (voir au paragraphe 11.1.1.1) excepté que le groupe d’attributs d’opération NE DOIT PAS contenir l’attribut "notify-job-id". Si le client fournit l’atribut "notify-job-id", l’imprimante DOIT alors le traiter comme tout autre attribut d’opération non pris en charge et DOIT le retourner dans le groupe des attributs non pris en charge.
11.1.2.2 Réponse à Create-Printer-Subscriptions
Les groupes sont identiques à ceux de Create-Job-Subscriptions (voir au paragraphe 11.1.1.2).
Le présent document étend les opérations de création de tâche (voir au paragraphe 3.2) pour créer des objets d’abonnement au titre de l’opération.
Les opérations de création de tâche sont identiques aux opérations de Create-Job-Subscriptions avec les exceptions notées dans ce paragraphe.
A la différence de l’opération Create-Job-Subscriptions, une opération de création de tâche associe les objets d’abonnement nouvellement créés aux objets de tâche créés par cette opération. L’opération ne réussit que si et seulement si la création de tâche réussit. Si l’imprimante ne crée pas tout ou partie des objets d’abonnement demandés, l’imprimante DOIT retourner un code d’état 'successful-ok-ignored-subscriptions' (réussite mais abonnement ignorés) au lieu d’un code d’état 'successful-ok' (réussite), mais l’imprimante NE DOIT PAS rejeter l’opération à cause d’un échec à créer les objets d’abonnement.
Si l’opération de création de tâche inclut un groupe de gabarit de tâche, le client DOIT le fournir après le groupe d’attribut d’opération et avant le premier groupe d’attributs de gabarit d’abonnement.
Si une imprimante ne prend pas en charge cette spécification de Notification, elle DOIT alors traiter le groupe d’attributs d’abonnement comme un groupe inconnu et l’ignorer (voir le paragraphe 5.2.2 de la [RFC2911]). Comme l’imprimante ignore le groupe d’attributs d’abonnement, elle ne les retourne pas non plus dans la réponse, indiquant par là au client que l’imprimante ne prend pas en charge Notification.
Après achèvement d’une opération de création de tâche réussie, l’imprimante génère un événement 'tâche créée' (voir au paragraphe 5.3.3.4.3).
Droits d’accès : Pour créer des objets d’abonnement par tâche, l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT avoir la permission de créer des tâches sur l’imprimante ou avoir les droits d’accès de l’opérateur ou de l’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]). Autrement, l’imprimante 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é.
11.1.3.1 Demande de création de tâche
Les groupes pour cette opération sont suffisamment différents de l’opération Créer des abonnements de tâche pour qu’ils soient tous présentés ici. Les groupes d’attributs suivants sont fournis au titre d’une Demande de création de tâche :
Groupe 1 : Attributs d’opération
Les mêmes que ceux définis dans la [RFC2911] pour les demandes Print-Job ( tâche d’impression), Print-URI (URI d’impression), et Create-Job (création de tâche).
Groupe 2 : Attributs de gabarit de tâche
Le client fournit FACULTATIVEMENT un ensemble d’attributs de gabarit de tâche comme défini au paragraphe 4.2 de la [RFC2911].
Groupes 3 à N : Attributs de gabarit d’abonnement
Les mêmes que ceux du Groupe 2-N dans Create-Job-Subscriptions. Voir au paragraphe 11.1.1.1.
Groupe N+1: Contenu du Document (seulement pour Tâche d’impression)
Le client DOIT fournir les données du document à traiter.
11.1.3.2 Réponse de création de tâche
L’imprimante DOIT retourner au client les ensembles d’attributs suivants au titre d’une réponse Print-Job, Print-URI, et Create-Job :
Groupe 1 : Attributs d’opération
Message d’état :
Comme défini dans la [RFC2911] pour les demandes Print-Job, Print-URI, et Create-Job.
Dans ce groupe, l’imprimante peut retourner tous les codes d’état définis dans la [RFC2911] et à la section 12. Ce qui suit est une description des codes d’état les plus importants :
successful-ok (réussite) : l’imprimante a créé la tâche et tous les objets d’abonnement demandés (voir la [RFC2911].
successful-ok-ignored-subscriptions (réussite, mais abonnements ignorés) : l’imprimante a créé la tâche mais pas tous les objets d’abonnement demandés (voir au paragraphe 12.1). Ce code d’état recouvre des codes d’état 'successful-ok-xxx' qui pourraient révéler des problèmes dans la création de tâche. L’imprimante NE DOIT PAS retourner le code d’état 'client-error-ignored-all-subscriptions' (erreur client, tous les abonnements sont ignorés) pour les opérations de création de tâche parce que l’imprimante ne retourne un code d’état d’erreur que quand elle échoue à créer une tâche.
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont décrits au paragraphe 3.1.4.2 de la [RFC2911].
Groupe 2 : Attributs non pris en charge
Voir au paragraphe 3.1.7 de la [RFC2911] les déails sur le retour des attributs non pris en charge. Ce groupe ne contient aucun des attributs de gabarit d’abonnement non pris en charge ; ils sont retournés dans le groupe d’attributs d’abonnement (voir ci-dessous).
Groupe 3 : Attributs d’objet tâche
Le "job-id" (identifiant de tâche) de l’objet de tâche qui vient d’être créé, etc., comme défini dans la [RFC2911] pour les demandes Print-Job, Print-URI, et Create-Job.
Groupes 4 à N : Attributs d’abonnement
Ces groupes ne DOIVENT être retournés que si et seulement si le client a fourni les attributs de gabarit d’abonnement et que l’opération a été acceptée.
Voir au paragraphe 5.2 des précisions sur le contenu de chaque occurrence de ces groupes.
La présente section définit d’autres opérations sur les objets d’abonnement.
L’opération Restart-Job (recommencer la tâche) de la [RFC2911] n’est ni une opération de création de tâche ni une opération de création d’abonnement (voir au paragraphe 3.2).
Pour l’opération Restart-Job, le client NE DOIT PAS fournir de groupes d’attributs d’abonnement de tâche. L’imprimante DOIT traiter tout attribut d’abonnement de tâche comme attribut non pris en charge.
Pour cette opération, l’imprimante ne retourne pas d’id de tâche ou de groupes d’attributs d’abonnement parce que l’imprimante réutilise l’objet de tâche existant avec le même id de tâche et les objets d’abonnement par tâche existants avec les mêmes identifiants d’abonnement. Cependant, après achèvement réussi de cette opération, l’imprimante génère un événement 'job-created' (tâche créée) (voir au paragraphe 5.3.3.4.3).
Un client peut vérifier si un ou plusieurs objets d’abonnement pourraient être créés en utilisant l’opération Validate-Job (valider la tâche). Le client fournit un ou plusieurs groupes d’attributs de gabarit d’abonnement (définis au paragraphe 5.3), tout comme dans une demande de création de tâche.
Une imprimante DOIT prendre en charge cette extension d’opération.
L’imprimante DOIT accepter les demandes qui sont identiques à la demande de création de tâche définie au paragraphe 11.1.3.1, sauf que la demande NE DOIT PAS contenir de données de document.
L’imprimante DOIT retourner les mêmes groupes et attributs que l’opération Print-Job (tâche d’impression) (paragraphe 11.1.3.1) avec les exceptions suivantes. L’imprimante NE DOIT PAS retourner un groupe d’attributs d’objet de tâche parce qu’aucune tâche n’est créée. L’imprimante NE DOIT PAS retourner l’attribut "notify-subscription-id" (notifier l’identifiant d’abonnement) d’aucun groupe d’attributs d’abonnement parce qu’aucun objet d’abonnement n’est créé.
Si l’imprimante réussit à créer un objet d’abonnement, le groupe d’attributs d’abonnement correspondant n’a pas d’attribut 'code d’état' ou un attribut 'code d’état' d’une valeur de 'successful-ok-too-many-events' (réussite mais trop d’événements) ou 'successful-ok-ignored-or- substituted-attributes' (réussite mais attributs ignorés ou substitués) (voir aux paragraphes 5.2 et 13). Les codes d’état ont la même signification que dans la création de tâche excepté que le résultat indique ce qui "arriverait".
L’imprimante DOIT valider les groupes d’attributs de gabarit d’abonnement de la même façon que dans les opérations de création de tâche.
Cette opération est étendue de sorte qu’elle retourne les attributs d’imprimante définis dans le présent document.
Une imprimante DOIT prendre en charge l’extension à cette opération.
En plus des exigences du paragraphe 3.2.5 de la [RFC2911], une imprimante DOIT prendre en charge les valeurs supplémentaires suivantes pour l’attribut d’opération "requested- attributes" (attributs demandés) dans cette opération et retourner de tels attributs dans le groupe d’attributs d’objet imprimante de sa réponse.
1. Attributs de gabarit d’abonnement : chaque attribut pris en charge dans la colonne 2 du Tableau 1.
2. Attributs de description de nouvelle imprimante : chaque attribut pris en charge dans la section 6.
3. Nom du nouveau groupe : nom du groupe de 'subscription-template' (gabarit d’abonnement), dont les noms prennent tous en charge l’attribut de gabarit d’abonnement dans la colonne 2 du Tableau 1. Ce nom de groupe est aussi utilisé dans les opérations Get-Subscription-Attributes (obtenir les attributs d’abonnement) et Get-Subscriptions (obtenir des abonnements) avec une signification identique.
4. Nom de groupe étendu : nom du groupe 'tout entier', qui désigne tous les attributs de l’imprimante, conformément au paragraphe 3.2.5 de la [RFC2911]. Dans cette extension 'all' (tous) désigne tous les attributs spécifiés dans la [RFC2911] plus ceux désignés aux points 1 et 2 de la présente liste
Cette opération permet à un client de demander les valeurs des attributs d’un objet d’abonnement.
Une imprimante DOIT prendre en charge cette opération.
Cette opération est presque identique à l’opération Get-Job-Attributes (obtenir les attributs de tâche) (voir au paragraphe 3.3.4 de la [RFC2911]). La seule différence est que l’opération est dirigée vers un objet d’abonnement plutôt que vers un objet tâche, et le groupe d’attributs retourné contient des attributs d’objet d’abonnement plutôt que des attributs d’objet tâche.
Droits d’accès : l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement, (2) avoir les droits d’accès d’opérateur ou d’administrateur sur cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à interroger l’objet d’abonnement sur la tâche cible. Autrement, l’imprimante 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, d’une façon similaire à celle de l’opération Get-Job-Attributes (voir à la fin du paragraphe 3.3.4.2 de la [RFC2911]).
11.2.4.1 Demande Get-Subscription-Attributes
Les groupes d’attributs suivants font partie de la demande Get-Subscription-Attributes :
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 "printer-uri" (uri de l’imprimante) qui définit la cible pour cette opération comme décrit au paragraphe 3.1.5 de la [RFC2911].
Nom de l’utilisateur demandeur : l’attribut "requesting-user-name" DEVRAIT être fourni par le client comme décrit au paragraphe 8.3 de la [RFC2911].
11.2.4.1.1 "notify-subscription-id" (entier de 1 à MAX)
Le client DOIT fournir cet attribut. L’imprimante DOIT prendre en charge cet attribut. Cet attribut spécifie l’objet d’abonnement à partir duquel le client demande les attributs. Si le client omet cet attribut, l’imprimante DOIT rejeter cette demande avec le code d’état 'erreur client, mauvaise demande'.
11.2.4.1.2 "requested-attributes" (1setOf keyword)
Le client fournit FACULTATIVEMENT cet attribut. L’imprimante DOIT prendre en charge cet attribut. Cet attribut spécifie les attributs de l’objet d’abonnement spécifié que l’imprimante DOIT retourner dans la réponse. Chaque valeur de cet attribut est un nom d’attribut (défini aux paragraphes 5.3 et 5.4) ou un nom de groupe d’attributs. Les noms de groupe d’attribut sont :
- 'subscription-template' (gabarit d’abonnement) : tous les attributs qui sont à la fois définis au paragraphe 5.3 et présents dans l’objet d’abonnement spécifié (colonne 1 du Tableau 1).
- 'subscription-description' (description d’abonnement) : tous les attributs qui sont à la fois définis au paragraphe 5.4 et présents dans l’objet d’abonnement spécifié (Tableau 2).
- 'all' (tous) : tous les attributs qui sont présents dans l’objet d’abonnement spécifié.
Une imprimante DOIT prendre en charge tous ces noms de groupe.
Si le client omet cet attribut, l’imprimante DOIT répondre comme si cet attribut avait été fourni avec une valeur de 'all'.
11.2.4.2 Réponse à Get-Subscription-Attributes
L’imprimante retourne les ensembles d’attributs suivants au titre de la réponse à Get-Subscription-Attributes :
Groupe 1: Attributs d’opération
Message d’état : le même que celui de la [RFC2911].
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit au paragraphe 3.1.4.2 de la [RFC2911]. Le "attributes-natural-language" PEUT être le langage naturel de l’objet d’abonnement, plutôt que celui demandé.
Groupe 2 : Attributs non pris en charge
Voir les paragraphes 3.1.7 et 3.2.5.2 de la [RFC2911] pour des précisions sur le retour des attributs non pris en charge.
La réponse PEUT NE PAS contenir l’attribut d’opération "requested-attributes" (attributs demandés) avec des valeurs de mot clé fournies qui ont été demandées par le client mais qui ne sont pas prises en charge par l’objet IPP. Si l’objet imprimante ne retourne pas les attributs non pris en charge référencés dans l’attribut d’opération "requested-attributes", les valeurs de l’attribut "requested-attributes" returnées ne DOIVENT inclure que les mots clé non pris en charge qui étaient demandés par le client. Si le client avait demandé un nom de groupe, tel que 'all', les attributs non pris en charge retournés ensuite NE DOIVENT PAS inclure les noms de mots clé d’attribut décrits dans la norme mais non pris en charge par la mise en œuvre.
Groupe 3 : Attributs d’abonnement
Ce groupe contient un ensemble d’attributs avec leurs valeurs courantes. Chaque attribut retourné dans ce groupe :
a) DOIT être spécifié par l’attribut "requested-attributes" dans la demande, ET
b) DOIT être présent sur l’objet d’abonnement spécifié ET
c) NE DOIT PAS être restreint par la politique de sécurité en vigueur. Par exemple, une imprimante PEUT interdire à un client qui n’est pas le créateur d’un objet d’abonnement de voir tout ou partie de ses attributs. Voir la fin du paragraphe 3.3.4.2 de la [RFC2911] et la section 8.
L’imprimante peut retourner les attributs de l’objet d’abonnement dans tout ordre. Le client DOIT accepter les attributs dans tout ordre.
Cette opération permet à un client de restaurer les valeurs des attributs de tous objets d’abonnement appartenant à une tâche ou à une imprimante.
Une imprimante DOIT prendre en charge cette opération.
Cette opération est similaire à l’opération Get-Subscription-Attributes (obtenir les attributs d’abonnement), excepté que cette opération Get-Subscriptions (obtenir les abonnements) retourne les attributs à partir de plus d’un objet le cas échéant.
Cette opération est similaire à l’opération Get-Jobs (obtenir les tâches) (voir le paragraphe 3.2.6 de la [RFC2911]), excepté que l’opération retourne les objets d’abonnement plutôt que les objets de tâche.
Droits d’accès : Pour interroger les objets d’abonnement par tâche de la tâche spécifiée (le client a fourni l’attribut d’opération "notify-job-id" - voir au paragraphe 11.2.5.1.1), l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) effectuant cette opération DOIT (1) être le propriétaire de l’objet d’abonnement, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autorisé par ailleurs par la politique de sécurité configurée par l’administrateur de l’imprimante à interroger l’objet d’abonnement sur la tâche cible. Pour interroger les objets d’abonnement par imprimante de l’imprimante (le client omet l’attribut d’opération "notify-job-id" - voir au paragraphe 11.2.5.1.1), l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) effectuant cette opération DOIT (1) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (2) être autorisé par ailleurs par la politique de sécurité configurée par l’administrateur de l’imprimante pour interroger les objets d’abonnement par imprimante sur l’imprimante cible. Autrement, l’imprimante 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 qui sont retournés, de la même manière que pour les opérations Get-Jobs et Get-Printer-Attributes (voir à la fin des paragraphes 3.2.6.2 et 3.2.5.2 de la [RFC2911]).
11.2.5.1 Demande Get-Subscriptions
Les groupes d’attributs suivants font partie de la demande Get-Subscriptions :
Groupe 1 : Attributs d’opération
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit au paragraphe 3.1.4.1 de la [RFC2911].
Cible : Attribut "printer-uri" qui définit 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" DEVRAIT être fourni par the client comme décrit au paragraphe 8.3 de la [RFC2911].
11.2.5.1.1 "notify-job-id" (entier de 1 à MAX)
Si le client spécifie cet attribut, l’imprimante retourne les attributs spécifiés de tous les objets d’abonnement par tâche associés à la tâche dont la valeur d’attribut de "job-id" est égale à la valeur de cet attribut. Si le client ne spécifie pas cet attribut, l’imprimante retourne les attributs spécifiés de tous les objets d’abonnement par imprimante. Note : Il n’y a aucun moyen d’obtenir tous les abonnements par tâche connus à l’imprimante en une seule opération. Une opération Obtenir les tâches suivie d’une opération Obtenir les abonnements pour chaque tâche aura pour retour tous les abonnements par tâche.
11.2.5.1.2 "limit" (entier de 1 à MAX)
Le client fournit FACULTATIVEMENT cet attribut. L’imprimante DOIT prendre en charge cet attribut. C’est une valeur d’entier qui détermine le nombre maximum d’objets d’abonnement qu’un client recevra de l’imprimante même si l’attribut "my-subscriptions" constitue une contrainte sur les objets d’abonnement qui sont retournés. La limite est une "limite sans état" en ce que si la valeur fournie par le client est 'N', seuls les 'N' premiers objets d’abonnement sont retournés dans la réponse à Obtenir les abonnements. Il n’y a pas de mécanisme qui permette les 'M' prochains objets d’abonnement après les 'N' premiers objets d’abonnement. Si le client ne fournit pas cet attribut, l’imprimante répond avec tous les objets d’abonnement applicables.
11.2.5.1.3 "requested-attributes" (1setOf mot clé de type2)
Le client fournit FACULTATIVEMENT cet attribut. L’imprimante DOIT prendre en charge cet attribut. Cet attribut spécifie les attributs des objets d’abonnement spécifiés que l’imprimante DOIT retourner dans la réponse. Chaque valeur de cet attribut est un nom d’attribut (défini aux paragraphes 5.3 et 5.4) ou un nom de groupe d’attributs (défini au paragraphe 11.2.4.1). Si le client omet cet attribut, l’imprimante DOIT répondre comme si le client avait fourni cet attribut avec la valeur un : 'notifier l’identifiant d’abonnement'.
11.2.5.1.4 "my-subscriptions" (booléen)
Le client fournit FACULTATIVEMENT cet attribut. L’imprimante DOIT prendre en charge cet attribut. Si la valeur est 'faux', l’imprimante DOIT considérer les objets d’abonnement provenant de tous les utilisateurs comme candidats. Si la valeur est 'vrai', l’imprimante DOIT retourner les objets d’abonnement créés par l’usager demandeur de cette requête. Si le client ne fournit pas cet attribut, l’imprimante DOIT répondre comme si le client avait fourni l’attribut avec la valeur 'faux'. Les moyens d’authentification de l’usager demandeur et de faire correspondre les objets d’abonnement sont similaires à ceux pour les tâches qui sont décrits à la section 8 de [RFC2911].
11.2.5.2 Réponse à Get-Subscriptions
L’imprimante retourne les ensembles d’attributs suivants au titre de la réponse à Get-Subscriptions (Obtenir les abonnements) :
Groupe 1 : Attributs d’opération
Message d’état : le même que celui de la [RFC2911].
Langage naturel et ensemble de caractères : Les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit auparagraphe 3.1.4.2 de la [RFC2911].
Groupe 2 : Attributs non pris en charge
Les mêmes que pour Get-Subscription-Attributes.
Groupes 3 à N : Attributs d’abonnement
L’imprimante répond avec un groupe d’attributs d’abonnement pour chaque objet d’abonnement demandé (voir l’attribut "notify-job-id" dans le groupe d’attributs d’opération de cette opération).
L’imprimante retourne les objets d’abonnements dans n’importe quel ordre.
Si l’attribut "limit" est présent dans le groupe d’attributs d’opération de la demande, le nombre de groupes d’attributs d’abonnement dans la réponse NE DOIT PAS excéder la valeur de l’attribut "limit".
Si aucun objet d’abonnement n’est associé à la tâche ou imprimante spécifiée, l’imprimante DOIT retourner zéro groupe d’attributs d’abonnement et NE DOIT PAS traiter ce cas comme une erreur, c’est-à-dire que le code d’état DOIT être 'réussi-ok' à moins que quelque chose d’autre ne cause une autre valeur du code d’état.
Voir à la réponse de Groupe 3 (Groupe d’attributs d’abonnement) de l’opération Get-Subscription-Attributes (paragraphe 11.2.4.2) les attributs qu’une imprimante retourne dans ce groupe.
Cette opération permet à un client de demander à l’imprimante d’étendre la location sur un objet d’abonnement par imprimante.
L’imprimante DOIT prendre en charge cette opération.
L’imprimante DOIT accepter cette demande pour un objet d’abonnement par imprimante dans tous les états de l’imprimante cible, c’est-à-dire, 'repos', 'traitement', ou 'arrêté', mais NE DOIT PAS changer l’attribut "printer-state" (état de l’imprimante) de l’imprimante.
L’imprimante DOIT rejeter cette demande pour un objet d’abonnement par tâche parce qu’elle n’a pas de location (voir au paragraphe 5.4.3). Le code d’état retourné DOIT être 'erreur client, impossible'.
Droits d’accès : l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement par imprimante, (2) avoir les droits d’accès d’opérateur ou d’administrateur sur cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à renouveler l’objet d’abonnement par imprimante pour l’imprimante cible. Autrement, l’imprimante 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é.
11.2.6.1 Renew-Subscription
Request
Les groupes d’attributs suivants font partie de la demande Renew-Subscription :
Groupe 1 : Attributs d’opération
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit au paragraphe 3.1.4.1 de la [RFC2911].
Cible : L’attribut "printer-uri" qui définit la cible pour cette opération comme décrit au paragraphe 3.1.5 de la [RFC2911].
Nom de l’usager demandeur :
L’attribut "requesting-user-name" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3 de la [RFC2911].
11.2.6.1.1 "notify-subscription-id" (entier de 1 à MAX)
Le client DOIT fournir cet attribut. L’imprimante DOIT prendre en charge cet attribut. Cet attribut spécifie l’objet d’abonnement par imprimante dont la location DOIT être renouvelée. Si le client omet cet attribut, l’imprimante DOIT rejeter cette demande avec le code d’état 'erreur client, mauvaise demande'.
Groupe 2 : Attributs de gabarit d’abonnement.
11.2.6.1.2 "notify-lease-duration" (entier de 0 à MAX)
Le client PEUT fournir cet attribut. Il indique le nombre de secondes de renouvellement de la location pour l’objet d’abonnement spécifié. Une valeur de 0 demande une location infinie (qui PEUT exiger des droits d’accès d’opérateur). Si le client omet cet attribut, l’imprimante DOIT utiliser la valeur de l’attribut "notify-lease-duration-default" (notifier la durée de location par défaut) de l’imprimante'. Voir des précisions au paragraphe 5.3.8.
11.2.6.2 Réponse à Renew-Subscription
L’imprimante retourne les ensembles d’attributs suivants au titre de la réponse à Renew-Subscription :
Groupe 1 : Attributs d’opération
Message d’état : le même que celui de la [RFC2911].
Les codes qui suivent sont une partie de ceux qui sont retournés (voir la [RFC2911] :
successful-ok (réussite) : l’opération a réussi à renouveler la location de l’objet d’abonnement pour la durée demandée.
successful-ok-ignored-or-substituted-attributes (réussite mais attributs ignorés ou substitués) : l’opération a réussi à renouveler la location de l’objet d’abonnement pour une durée autre que celle demandée.
client-error-not-possible (erreur client, impossible) : l’opération a échoué parce que l’attribut d’opération "notify-subscription-id" (notifier l’identifiant d’abonnement) a identifié un objet d’abonnement par tâche.
client-error-not-found (erreur client, introuvable) : l’opération a échoué parce que l’attribut d’opération "notify-subscription-id" identifie un objet d’abonnement non existant.
Langage naturel et ensemble de caractères :
Les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit au paragraphe 3.1.4.2 de la [RFC2911]. Le "attributes-natural-language" PEUT être le langage naturel de l’objet d’abonnement, plutôt que celui demandé.
Groupe 2 : Attributs non pris en charge
Voir au paragraphe 3.1.7 de la [RFC2911] des précisions sur le retour des attributs non pris en charge.
Groupe 3 : Attributs d’abonnement
L’imprimante DOIT retourner les attributs d’abonnement suivants :
11.2.6.2.1 "notify-lease-duration" (entier de 0 à MAX)
La valeur de cet attribut DOIT être le nombre de secondes que l’imprimante a attribué pour la location de l’objet d’abonnement (voir des précisions au paragraphe 5.3.8, comme la valeur de cet attribut lorsque l’imprimante ne prend pas en charge la valeur demandée).
Cette opération permet à un client de supprimer un objet d’abonnement et d’arrêter la délivrance d’autres notifications d’événement par l’imprimante. Une fois effectuée, il n’y a plus de moyen de faire référence à l’objet d’abonnement.
Une imprimante DOIT prendre en charge cette opération.
L’imprimante DOIT accepter cette demande dans tous les états de l’imprimante cible, c’est-à-dire, 'repos', 'traitement', ou 'arrêté', mais NE DOIT PAS changer l’attribut "printer-state" de l’imprimante.
Si l’objet d’abonnement spécifié est un objet d’abonnement par tâche, l’imprimante DOIT accepter cette demande dans tous les états de la tâche cible, mais NE DOIT PAS changer l’attribut "job-state" de la tâche ou affecter la tâche.
Note : Il n’y a aucun moyen de changer un attribut sur un objet d’abonnement, excepté l’attribut "notify-lease-duration" (notifier la durée de location) (en utilisant l’opération Renouveler l’abonnement). Pour changer les autres attributs, un client effectue une opération Création d’abonnement et une opération Annulation d’abonnement sur le vieil objet d’abonnement. Si le client veut éviter de manquer des notifications d’événement, il effectue d’abord l’opération de création d’abonnement. Si cet ordre créerait trop d’objets d’abonnement sur l’imprimante, le client inverse l’ordre.
Droits d’accès : l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement, (2) avoir les droits d’accès d’opérateur ou d’administrateur sur cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à annuler l’objet d’abonnement cible. Autrement, l’imprimante 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é.
11.2.7.1 Demande Cancel-Subscription
Les groupes d’attributs suivants font partie de la demande Cancel-Subscription :
Groupe 1 : Attributs d’opération
Langage naturel et ensemble de caractères :
les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit au paragraphe 3.1.4.1 de la [RFC2911].
Cible : l’attribut "printer-uri" qui définit la cible de cette opération comme décrit au paragraphe 3.1.5 de la [RFC2911].
Nom de l’usager demandeur :
l’attribut "requesting-user-name" DEVRAIT être fourni par le client comme décrit au paragraphe 8.3 de la [RFC2911].
11.2.7.1.1 "notify-subscription-id" (entier de 1 à MAX)
Le client DOIT fournir cet attribut. L’imprimante DOIT prendre en charge cet attribut. Cet attribut spécifie l’objet d’abonnement que l’imprimante DOIT annuler. Si le client omet cet attribut, l’imprimante DOIT rejeter cette demande avec le code d’état 'erreur client, mauvaise demande'.
11.2.7.2 Réponse à Cancel-Subscription
L’imprimante retourne les ensembles d’attributs suivants au titre de la réponse à Cancel-Subscription :
Groupe 1 : Attributs d’opération
Message d’état : le même que celui de la [RFC2911].
Les codes d’état suivants sont quelques uns de ceux retournés (voir la [RFC2911] :
successful-ok : l’opération a réussi à annuler (supprimer) l’objet d’abonnement.
client-error-not-found : l’opération a échoué parce que l’attribut d’opération "notify-subscription-id" a identifié un objet d’abonnement non existant.
Langage naturel et ensemble de caractères : les attributs "attributes-charset" et "attributes-natural-language" sont comme décrit au paragraphe 3.1.4.2 de la [RFC2911]. Le "attributes-natural-language" PEUT être le langage naturel de l’objet d’abonnement, plutôt que celui demandé.
Groupe 2 : Attributs non pris en charge
Voir au paragraphe 3.1.7 de la [RFC2911] des précisions sur le retour des attributs non pris en charge.
Les codes d’état suivants sont définis comme des extensions à Notification et sont retournés comme valeurs du paramètre "code d’état" dans le groupe d’attributs d’opération d’une réponse (voir le paragraphe 3.1.6.1 de la [RFC2911]). Les opérations du présent document peuvent aussi retourner les codes d’état définis à la section 13 de la [RFC2911]. Le code d’état 'successful-ok' (réussite) est un exemple d’un tel code d’état.
L’opération de création d’abonnement a été incapable de créer tous les objets d’abonnement demandés.
Pour une opération Create-Job-Subscriptions (créer des abonnements de tâche) ou Create-Printer-Subscriptions (créer des abonnements d’imprimante), ce code d’état signifie que l’imprimante a créé un ou plusieurs objets d’abonnement, mais pas tous les objets d’abonnement demandés.
Pour une opération de création de tâche, ce code d’état signifie que l’imprimante a créé la tâche en même temps que zéro ou plusieurs objets d’abonnement. L’imprimante retourne ce code d’état même si d’autres attributs de tâche ne sont pas pris en charge ou sont en conflit. C’est-à-dire que si une imprimante IPP trouve un avertissement qui lui permettrait de retourner 'successful-ok-ignored- subscriptions' et 'successful-ok-ignored-or-substituted-attributes' et/ou 'successful-ok-conflicting-attributes', elle DOIT retourner 'successful-ok-ignored-subscriptions'.
Ce code d’état est le même que 'successful-ok-ignored-subscriptions' excepté que seules les opérations Create-Job-Subscriptions et Create-Printer-Subscriptions le retournent. Elles retournent ce code d’état seulement quand l’imprimante crée zéro objet d’abonnement.
La présente section contient les valeurs de l’attribut "notifier le code d’état" (énumération de type2) que l’imprimante retourne dans un groupe d’attributs d’abonnement dans une réponse lorsque l’objet d’abonnement correspondant :
1. n’est pas créé, ou
2. est créé et que certains des attributs fournis par le client ne sont pas pris en charge.
Les paragraphes qui suivent sont ordonnés selon l’importance décroissante des codes d’état.
Ce code d’état est défini dans la [RFC2911]. Le présent document étend sa signification et lui permet d’être dans un groupe d’attributs d’abonnement d’une réponse.
Le schéma de l’URI fourni par le client dans un attribut de gabarit d’abonnement "notifier l’uri du récepteur" dans une opération de création d’abonnement n’est pas accepté. Voir au § 5.3.1.
Ce code d’état est défini dans la [RFC2911]. Le présent document étend sa signification et lui permet d’être dans un groupe d’attributs d’abonnement d’une réponse.
La méthode du mot clé fourni par le client dans un attribut de gabarit d’abonnement "notifier la méthode tirée" dans une opération de création d’abonnement n’est pas acceptée. Voir au paragraphe 5.3.2.
Le nombre d’objets d’abonnements pris en charge par l’imprimante serait dépassé si cet objet d’abonnement était créé (voir au paragraphe 5.2).
Le client a fourni plus d’événements dans l’attribut d’opération "notifier les événements" d’une opération de création d’abonnement que l’imprimante n’en accepte, comme indiqué dans son attribut d’imprimante "notifier le maximum d’événements acceptés" (voir au paragraphe 5.3.3).
Ce code d’état est défini dans la [RFC2911]. Le présent document étend sa signifcation pour inclure les attributs de gabarit d’abonnement non pris en charge et il peut apparaître dans un groupe d’attributs d’abonnement.
La présente section alloue des valeurs aux deux étiquettes d’attributs comme extensions aux codages définis dans la [RFC2910]).
L’étiquette "subscription-attributes-tag" délimite les groupes d’attributs de gabarit d’abonnement dans les demandes et les groupes d’attributs d’abonnement dans les réponses.
L’étiquette "event-notification-attributes-tag" délimite les notifications d’événements dans les méthodes de livraison qui utilisent un codage de type IPP.
Le tableau suivant spécifie les valeurs pour les étiquettes de délimitation :
|
Valeur d’étiquette
(Hex) |
Signification |
|
0x06 |
"subscription-attributes-tag"
(étiquette d’attribut d’abonnement) |
|
0x07 |
"event-notification-attributes-tag"
(étiquette d’attribut de notification d’événement) |
Il est FACULTATIF pour les clients et imprimantes IPP de mettre en œuvre la spécification de notification d’événement.
Si la présente spécification de notification d’événement est mise en œuvre par un client, ce client DOIT prendre en charge la méthode de livraison tirée 'ippget' et satisfaire aux exigences de conformité définies dans la [RFC3996] pour les clients. Un client PEUT prendre en charge des méthodes de livraison supplémentaires.
Si la présente spécification de notification d’événement est mise en œuvre par une imprimante, l’imprimante DOIT :
- satisfaire aux exigences de conformité détaillées à la section 5 de la [RFC2911].
- prendre en charge le groupe d’attributs de gabarit d’abonnement dans les demandes et le groupe d’attributs d’abonnement dans les réponses.
- prendre en charge tous les attributs suivants :
a. les attributs d’objet d’abonnement marqués EXIGÉ à la section 5.
b. les attributs d’objet de description d’imprimante marqués EXIGÉ à la section 6.
c. les attributs marqués EXIGÉ dans le contenu de notification d’événement à la section 8.
- prendre en charge la méthode de livraison tirée 'ippget' et satisfaire aux exigences de conformité définies pour les imprimantes dans la [RFC3996]. L’imprimante PEUT prendre en charge des méthodes de livraison tirées et poussées supplémentaires.
- délivrer des notifications d’événement qui se conforment aux exigences de la section 9 et aux exigences du document de méthode de livraison pour chaque méthode de livraison prise en charge (les exigences de conformité pour les documents de méthode de livraison sont spécifiées à la section 10).
- pour toutes les opérations de création de tâche que l’imprimante accepte, prendre en charge les extensions marquées EXIGÉ pour la notification définie au paragraphe 11.1.3.
- satisfaire aux exigences de conformité pour les opérations comme décrit au Tableau 16 et satisfaire aux exigences pour les imprimantes comme spécifié aux paragraphes indiqués à la section 11 :
Tableau 16 – Exigences de conformité d’imprimante pour les opérations
|
Opération |
Exigences de conformité
d’imprimante |
|
Create-Printer-Subscriptions
(§ 11.1.2) |
EXIGÉ |
|
Create-Job-Subscriptions
(§ 11.1.1) |
FACULTATIF |
|
Get-Subscription-Attributes
(§ 11.2.3) |
EXIGÉ |
|
Get-Subscriptions (§
11.2.5) |
EXIGÉ |
|
Renew-Subscription
(§ 11.2.6) |
EXIGÉ |
|
Cancel-Subscription
(§ 11.2.7) |
EXIGÉ |
Avec ce modèle (voir la Figure 2 ci-dessous),il y a un serveur d’impression qui intervient entre l’utilisateur humain et l’appareil de sortie. Ainsi, le système a effectivement deux objets imprimante. Deux cas sont à prendre en compte :
1. Lorsque l’imprimante 1 (dans le serveur) génère des événements, le système se comporte comme le client et l’imprimante de la Figure 1. Dans ce cas, l’imprimante 1 délivre les notifications d’événement qui sont montrées comme notifications d’événement (A) à la Figure 2.
2. Lorsque l’imprimante 2 (dans l’appareil de sortie) génère des événements, il y a deux configurations de système possibles :
a) L’imprimante 1 transmet les opérations de création d’abonnement fournies par le client à l’imprimante aval 2 et laisse l’imprimante 2 délivrer les notifications d’événement directement aux récepteurs de notification fournis par le client (notifications d’événement (C) dans le diagramme).
b) L’imprimante 1 effectue les opérations de création d’abonnement fournies par le client et transmet aussi les opérations de création d’abonnement à l’imprimante 2 avec le récepteur de notification modifié pour être l’imprimante 1. Lorsque survient un événement dans l’imprimante 2, l’imprimante 2 délivre la notification d’événement (B) au récepteur de notification de l’imprimante 1, qui relaie les notifications d’événement (B) reçues au récepteur de notification fourni par le client (comme les notifications d’événement (A) dans le diagramme). Noter que lorsqu’un client effectue une opération de création d’abonnement, l’imprimante 1 n’a pas besoin de transmettre l’opération de création d’abonnement à l’imprimante 2 si cela créerait une duplication d’objet d’abonnement sur l’imprimante 2.
Note : lorsque l’imprimante 1 transmet des opérations de création d’abonnement à l’imprimante 2, elle peut demander à l’imprimante 2 de créer des objets d’abonnement supplémentaires (appelé du "portage" (piggy-backing)). Le portage est utile lorsque :
- L’appareil A est configuré pour accepter des demandes (IPP ou non-IPP) venant d’autres serveurs.
- Le serveur S veut recevoir des événements de tâche que le client n’a pas demandé et le serveur S veut ces événements pour des tâches qu’il soumet et non pour d’autres tâches.
serveur S appareil A
+------------+ +------------+
| | | |
+--------+ Opération de | ###########| | ###########|
| client |--Création ----># Objet #| Opération de | # Objet #|
+--------+ d’abonnement | # Imprim.1#|---Création------|># Imprim.2#|
| ###|#######| d’abonnement | ####|#|####|
+----|---^---+ +-----|-|----+
+---------+ Notifications | | | |
|Récepteur|<-d’événements (A)-+ +- notif.ons d’événement(B)-+ |
|de notifi|<-------notifications d’événement(C)-----------------+
|cations |
+---------+
Figure 2 - Modèle pour Notification avec imprimantes en cascade
Une mise en œuvre d’imprimante pourrait utiliser un serveur de notification distant pour fournir tout ou partie du service. Par exemple, le serveur de notification distant pourrait délivrer des notifications d’événement en utilisant des méthodes de livraison qui ne sont pas acceptées directement par l’appareil de sortie ou l’objet imprimant. Ou bien, le serveur de notification distant pourrait emmagasiner les objets d’abonnement (qui lui sont passés de l’appareil de sortie en réponse aux demandes de création d’abonnement), accepter les événements, formater la notification d’événement dans le langage naturel du récepteur de notification, et délivrer les notifications d’événement au ou aux récepteurs de notification.
La Figure 3 montre cette répartition. L’interface entre l’appareil de sortie (ou objet imprimante) et le serveur de notification distant est en dehors du domaine d’application du présent document et il est prévu qu’il soit transparent pour le client et le présent document.
***********************
* Imprimante combinée au
* serveur de notification
* distribué)
*
* appareil de sortie ou serveur
* +---------------+
PDA, desktop, ou serveur * + ########### +
+--------+ * | # # |
| client |---Opération de -----------># Objet # |
+--------+ Création d’abonnement* | #Imprimant# |
IPP * | #####|##### |
* +-------|-------+
* | Abonnements
* | OU Notifications
+------------+ * | d’événements
|Récepteur de| notif. d’événements* +------v--------+
|notification|<-----définies par IPP* | Serveur de |
+------------+ * | Notification |
* +---------------+
*
*************************
*** = Limite opaque de configuration de la mise en oeuvre
Figure 3 – Utilisation opaque d’un serveur de notification transparent pour le client
Le modèle permet un récepteur de notification étendu qui est lui-même un serveur de notification qui transmet chaque notification d’événement à un autre récepteur (appelé le récepteur ultime de notification dans la présente section). La méthode de livraison au Récepteur ultime est probablement différente de la méthode de livraison au récepteur de notification étendu utilisée par l’imprimante.
Ce récepteur de notification étendu est transparent pour l’imprimante mais pas pour le client.
Lorsqu’un client effectue une opération de création d’abonnement, il spécifie le récepteur de notification étendu comme il le ferait de n’importe quel récepteur de notification. De plus, le client spécifie le récepteur ultime de notification dans l’opération de création d’abonnement d’une façon qui est spécifiée par le récepteur de notification étendu. Normalement, ce sont des octets dans la valeur de "notify-user-data" ou des paramètres supplémentaires dans la valeur de "notify-recipient-uri". Le client s’abonne aussi directement au récepteur de notification étendu (par des moyens qui sont en dehors du domaine d’application du présent document), dans la mesure où il est un serveur de notification de plein droit.
L’imprimante IPP traite le récepteur de notification étendu comme n’importe quel autre récepteur de notification et l’imprimante IPP n’est pas au courant de la transmission. La méthode de livraison qu’utilise le récepteur de notification étendu pour délivrer la notification d’événement au récepteur ultime de notification sort du domaine d’application du présent document et elle est transparente pour l’imprimante IPP.
Des exemples de ce récepteur de notification étendu sont les services de localisation, l’échange de messages immédiats, les services de notification générale, et l’infrastructure NOS des fabricants. La Figure 4 illustre cette approche.
PDA, desktop, ou serveur serveur ou appareil de sortie
+---------------+
+--------+ | ########### |
| client |---Opération de création -----------># Objet # |
+--------+ d’abonnement | #Imprimant# |
| #####|##### |
+------------+ +------------+ +-------|-------+
|Récepteur de| qcq |Récepteur de|<--notification d’événements----+
|Notification|<----|notification| définis IPP
|Ultime | +------------+
+------------+ (Serveur de notification)
Figure 4 – Utilisation d’un récepteur de notification étendu transparent pour l’imprimante
La présent section décrit le modèle d’objet Notification qui ajoute un objet d’abonnement qui conjointement à l’objet tâche et l’objet imprimante donne la sémantique complète de Notification.
Les relations d’objet peuvent être visualisées comme :
Objet d’abonnements (abonnements par imprimante) Objet Imprimante
+----+ +------------+
| s1 |<--------------------------------------------->| |
+----++ | |
| s2 |<-------------------------------------------->| p1 |
+----++ | |
| s3 |<------------------------------------------->| |
+----+ +------------+
Objets Tâche
+---------+
| |
+----+ | j1 |
| s4 |<------->| |
+----+ | |
| | s4 est un objet d’abonnement par tâche
++--------++
| |
+----+ | j2 |
| s5 |<------>| |
+----++ | |
| s6 |<----->| | s5 et s6 sont des objets d’abonnement
+----+ ++--------++ par tâche
| |
| j3 |
| |
| | <----> indique l’association
+---------+
Figure 5 – Modèle d’objets pour Notification
s1, s2, et s3 sont les objets d’abonnement par imprimante et peuvent identifier les événements imprimante et/ou tâche.
s4, s5, et s6 sont les objets d’abonnement par tâche et peuvent identifier les événements imprimante et/ou tâche.
Ce paragraphe définit les relations d’objet entre par exemple, l’imprimante, la tâche, et les objets d’abonnement. Que les objets d’abonnement par imprimante soient réellement contenus dans un objet imprimante ou lui soient simplement associés de façon bi-directionnelle DÉPEND DE LA MISE EN ŒUVRE et est transparent pour le client. De même, que les objets d’abonnement par tâche soient réelement contenus dans un objet tâche ou lui soient simplement associés de façon bi-directionnelle de quelque façon DÉPEND DE LA MISE EN ŒUVRE et est transparent pour le client. Les relations d’objet sont définies comme suit :
1. L’objet imprimante contient (est associé à) zéro ou plusieurs objets d’abonnement par imprimante (p1 contient s1-s3 objets d’abonnement par imprimante).
2. Chaque objet d’abonnement par imprimante (s1, s2, et s3) est contenu dans (ou est associé à) exactement un objet imprimante (p1).
1. Un objet tâche (j1, j2, j3) est associé à zéro ou plusieurs objets d’abonnement par tâche (s4-s6). La tâche j1 est associée à l’objet d’abonnement par tâche s4, la tâche j2 est associée aux objets d’abonnement par tâche s5 et s6, et la tâche j3 n’est associée à aucun objet d’abonnement par tâche.
2. Chaque objet d’abonnement par tâche est associé à exactement un objet tâche.
Les objets d’abonnement par imprimante et par tâche sont assez semblables. L’un et l’autre type d’objet d’abonnement peuvent s’abonner aux événements de tâche, aux événements d’imprimante, ou aux deux. Les deux types d’objets d’abonnement epuventêtre interrogés en utilisant les opérations Get-Subscriptions et Get-Subscription-Attributes et annulées en utilisant l’opération Cancel-Subscription. Les deux types d’objets d’abonnement créent des objets d’abonnement qui ont des définitions d’attribut d’objet d’abonnement identiques. Cependant, il y a quelques différences sémantiques entre objets d’abonnement par tâche et objets d’abonnement par imprimante. Un objet d’abonnement par tâche est établi par le client lorsqu’il soumet une tâche et après avoir créé la tâche en utilisant l’opération Create-Job-Subscriptions en spécifiant l’"identifiant de tâche" de la tâche avec l’attribut "notifier l’identifiant de tâche". Un objet d’abonnement par tâche est établi entre un client et une imprimante en utilisant l’opération Créer des abonnements d’imprimante. Quelques différences spécifiques sont :
1. Un client crée normalement un ou plusieurs objets d’abonnement par tâche au titre des opérations de création de tâches (Create-Job, Print-Job, et Print-URI), plutôt que d’utiliser l’opération FACULTATIVE Créer des abonnements de tâche, en particulier dans la mesure où les mises en œuvre d’imprimantes PEUVENT NE PAS prendre en charge l’opération Créer des abonnements de tâche, FACULTATIVE.
2. Pour les objets d’abonnement par tâche, l’objet d’abonnement n’est valide que tant que la tâche est "non terminée" (voir au paragraphe 5.4.3) alors que pour les objets d’abonnement par imprimante, l’objet d’abonnement est valide jusqu’au moment (en seconde) où l’imprimante revient à l’attribut d’opération "notifier le temps d’expiration de location".
3. Les événements de tâche dans un objet d’abonnement par tâche ne s’appliquent qu’à "une tâche" (la tâche créée par l’opération de création de tâche ou référencée par l’opération Créer des abonnements de tâche) alors que les événements de tâche dans un objet d’abonnement par imprimante s’appliquent à TOUTES les tâches contenues dans l’imprimante IPP.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119 (Mots clé à utiliser dans les RFC pour indiquer les niveaux d’exigence), mars 1997.
[RFC2396] Berners-Lee, T., Fielding, R., et L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax" (Identifiants de ressource uniformes (URI) : Syntaxe générique), RFC 2396, août 1998.
[RFC2717] Petke, R. et I. King, "Registration Procedures for URL Scheme Names" (Procédures d’enregistrement pour les noms de schéma d’URL), RFC 2717, novembre 1999.
[RFC2910] Herriot, R., Butler, S., Moore, P., et R. Turner, "Internet Printing Protocol/1.1: Encoding and Transport" (Protocole /1.1 d’impression sur Internet : Codage et transport), RFC 2910, septembre 2000.
[RFC2911] deBry, R., Hastings, T., Herriot, 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.
[RFC3381] Hastings, T., Lewis, H., et R. Bergman, "IPP: Job Progress Attributes" (Protocole d’impression sur Internet : Attributs de progrès de tâche), RFC 3381, septembre 2002.
[RFC3996] Herriot, R., Hastings, T., et H. Lewis, "Internet Printing Protocol (IPP): The 'ippget' delivery method for event notifications" (Protocole d’impression sur Internet (IPP) : méthode de livraison 'ippget' pour les notifications d’événement), RFC 3996, mars 2005.
[IANA-CON] Narten, T. et H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs" (Lignes directrices pour introduire une section sur les considérations relatives à l’IANA dans les RFC), BCP 26, RFC 2434, octobre 1998.
[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, April 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, D., "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 and 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., et 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., et T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, juin 1999.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., et H. Holst, "Internet Printing Protocol/1.1: Implementer's Guide" (Protocole /1.1 d’impression sur Internet : Guide de mise en oeuvre), RFC 3196, novembre 2001.
[RFC3997] Hastings, T., Editor, deBry, R., et 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 d’enregistrement ajoutées par l’IANA au registre IPP conformément aux procédures définies à la section 6 de la RFC 2911 [RFC2911] pour couvrir les définitions du présent document. De plus, la présente section définit comment les événements et les méthodes de livraison seront enregistrées lorsqu’elles sont définies dans d’autres documents. Les inscriptions résultantes ont été publiées dans le registre http://www.iana.org/assignments/ipp-registrations.
Le tableau suivant fait la liste de tous les attributs définis dans le présent document. Ils ont été enregistrés conformément aux procédures du paragaphe 6.2 de la RFC 2911 [RFC2911].
|
Attributs de gabarit d’abonnement : |
Référence |
Paragraphe |
|
notify-attributes (1setOf type2 keyword) |
[RFC3995] |
5.3.4 |
|
notify-attributes-supported (1setOf type2 keyword) |
[RFC3995] |
5.3.4.1 |
|
notify-charset (charset) |
[RFC3995] |
5.3.6 |
|
notify-events (1setOf type2 keyword) |
[RFC3995] |
5.3.3 |
|
notify-events-default (1setOf type2 keyword) |
[RFC3995] |
5.3.3.1 |
|
notify-events-supported (1setOf type2 keyword) |
[RFC3995] |
5.3.3.2 |
|
notify-lease-duration (integer(0:67108863)) |
[RFC3995] |
5.3.8 |
|
notify-lease-duration-default (integer(0:67108863)) |
[RFC3995] |
5.3.8.1 |
|
notify-lease-duration-supported (1setOf (integer(0:
67108863) | rangeOfInteger(0:67108863))) |
[RFC3995] |
5.3.8.2 |
|
notify-max-events-supported (integer(2:MAX)) |
[RFC3995] |
5.3.3.3 |
|
notify-natural-language (naturalLanguage) |
[RFC3995] |
5.3.7 |
|
notify-pull-method (type2 keyword) |
[RFC3995] |
5.3.2 |
|
notify-pull-method-supported (1setOf type2 keyword) |
[RFC3995] |
5.3.2.1 |
|
notify-recipient-uri (uri) |
[RFC3995] |
5.3.1 |
|
notify-schemes-supported
(1setOf uriScheme) |
[RFC3995] |
5.3.1.1 |
|
notify-time-interval (integer(0:MAX)) |
[RFC3995] |
5.3.9 |
|
notify-user-data (octetString(63)) |
[RFC3995] |
5.3.5 |
|
Subscription Description Attributes: |
|
|
|
notify-job-id (integer(1:MAX)) |
[RFC3995] |
5.4.6 |
|
notify-lease-expiration-time (integer(0:MAX)) |
[RFC3995] |
5.4.3 |
|
notify-printer-up-time (integer(1:MAX)) |
[RFC3995] |
5.4.4 |
|
notify-printer-uri (uri) |
[RFC3995] |
5.4.5 |
|
notify-sequence-number (integer (0:MAX)) |
[RFC3995] |
5.4.2 |
|
notify-subscriber-user-name (name(MAX)) |
[RFC3995] |
5.4.7 |
|
notify-subscription-id
(integer (1:MAX)) |
[RFC3995] |
5.4.1 |
|
Printer Description Attributes: |
|
|
|
printer-state-change-date-time (dateTime) |
[RFC3995] |
6.2 |
|
printer-state-change-time (integer(1:MAX)) |
[RFC3995] |
6.1 |
|
Attributes Only in notification d’événements |
|
|
|
notify-subscribed-event (type2 keyword) |
[RFC3995] |
8.1 |
|
notify-text (text(MAX)) |
[RFC3995] |
8.2 |
Le tableau suivant fait la liste de toutes les nouvelles valeurs d’attribut d’énumération définies dans le présent document. Elles ont été enregistrées au sein du registre IPP conformément aux procédures du paragraphe 6.1 de la RFC 2911 [RFC2911].
|
Valeur d’attribut |
Nom |
Référence |
Paragraphe |
|
opérations-supported |
(1setOf type2 enum) |
[RFC2911] |
4.4.15 |
|
0x0016 |
Create-Printer-Subscriptions |
[RFC3995] |
7.1 |
|
0x0017 |
Create-Job-Subscriptions |
[RFC3995] |
7.1 |
|
0x0018 |
Get-Subscription-Attributes |
[RFC3995] |
7.1 |
|
0x0019 |
Get-Subscriptions |
[RFC3995] |
7.1 |
|
0x001A |
Renew-Subscription |
[RFC3995] |
7.1 |
|
0x001B |
Cancel-Subscription |
[RFC3995] |
7.1 |
Le Tableau suivant fait la liste de toutes les opérations définis dans le présent document. Elles ont été enregistrées conformément aux procédures du paragraphe 6.4 de la RFC 2911.
|
Nom d’opération |
Référence |
Paragraphe |
|
Cancel-Subscription |
[RFC3995] |
11.2.7 |
|
Create-Job – Extensions |
[RFC3995] |
11.1.3 |
|
Create-Job-Subscriptions |
[RFC3995] |
11.1.1 |
|
Create-Printer-Subscriptions |
[RFC3995] |
11.1.2 |
|
Get-Printer-Attributes – Extensions |
[RFC3995] |
11.2.3 |
|
Get-Subscription-Attributes |
[RFC3995] |
11.2.4 |
|
Get-Subscriptions |
[RFC3995] |
11.2.5 |
|
Print-Job – Extensions |
[RFC3995] |
11.1.3 |
|
Print-URI – Extensions |
[RFC3995] |
11.1.3 |
|
Renew-Subscription |
[RFC3995] |
11.2.6 |
|
Validate-Job Opération – Extensions |
[RFC3995] |
11.2.2 |
Le Tableau suivant fait la liste de tous les codes d’état définis dans le présent document. Ils ont été enregistrés conformément aux procédures du paragraphe 6.6 de la RFC 2911 [RFC2911].
|
Valeur |
Nom du code d’état |
Référence |
Paragraphe |
|
0x0000:0x00FF |
Réussite: |
|
|
|
0x0003 |
Réussite mais
abonnements ignorés |
[RFC3995] |
12.1 |
|
0x0005 |
Réussite mais trop
d’événements |
[RFC3995] |
13.4 |
|
0x0400:0x04FF - |
Erreur client : |
|
|
|
0x0414 |
Erreur client, ignorer
tous les abonnements |
[RFC3995] |
12.2 |
|
0x0415 |
Erreur client, trop
d’abonnements |
[RFC3995] |
13.3 |
Le Tableau suivant fait la liste de toutes les étiquettes de groupe d’attributs définis dans le présent document. Telles ont été enregistrées conformément aux procédures du paragraphe 6.5 de la RFC 2911 [RFC2911].
|
Valeur |
Nom de l’étiquette
du groupe d’attribut |
Référence |
Paragraphe |
|
0x06 |
Etiquette d’attribut
d’abonnement |
[RFC3995] |
14 |
|
0x07 |
Etiquette
d’attribut de notification d’événement |
[RFC3995] |
14 |
Le tableau suivant fait la liste de tous les événements définis dans le présent document comme mots clé de type2 à utiliser avec les attributs de gabarit d’abonnement "notifier les événements", "notifier les événements par défaut", et "notifier les événements pris en charge" (voir au paragraphe 5.3.3). Plutôt que de créer un paragraphe distincr dans le Registre IPP pour les événements, ces mots clé d’événement ont été enregistrés conformément aux procédures du paragraphe 7.1 de la [RFC2911] comme valeurs supplémentaires d’attribut de mot clé à utiliser avec l’attribut de gabarit d’abonnement "notifier les événements" (voir au paragraphe 5.3.3), c’est-à-dire, enregistrées comme valeurs de mot clé pour les attributs "notifier les événements", "notifier les événements par défaut", et "notifier les événements pris en charge" :
|
Valeur d’attribut
(syntaxe d’attribut) |
Référence |
Paragraphe |
|
notifier les
événements (1setOf mot clé de type 2) |
[RFC3995] |
5.3.3 |
|
notifier les
événements par défaut (1setOf mot clé de type 2) |
[RFC3995] |
5.3.3.1 |
|
notifier les
événements par défaut (1setOf mot clé de type 2) |
[RFC3995] |
5.3.3.2 |
|
notifier les
événements abonnés (mot clé de type 2) |
[RFC3995] |
8.1 |
|
Pas d’événement : Aucun |
[RFC3995] |
5.3.3.4.1 |
|
Evénements
d’imprimante |
|
|
|
printer-state-changed
(changement d’état d’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-restarted (redémarrage
d’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-shutdown (fermeture
de l’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-stopped (arrêt
de l’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-config-changed
(changement de configuration de l’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-media-changed
(changement desupport de l’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-finishings-changed
(changement des finitions de l’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
printer-queue-order-changed
(changement de l’ordre de file d’attente de l’imprimante) |
[RFC3995] |
5.3.3.4.2 |
|
Evénements de tâche |
|
|
|
job-state-changed (changement
d’état de tâche) |
[RFC3995] |
5.3.3.4.3 |
|
job-created (création
de tâche) |
[RFC3995] |
5.3.3.4.3 |
|
job-completed (fin de tâche) |
[RFC3995] |
5.3.3.4.3 |
|
job-stopped (tâche
interrompue) |
[RFC3995] |
5.3.3.4.3 |
|
job-config-changed (changement
de congiguration de tâche) |
[RFC3995] |
5.3.3.4.3 |
|
job-progress (avancement de tâche) |
[RFC3995] |
5.3.3.4.3 |
Ce paragraphe décrit les exigences et les procédures d’enregistrement et de publication des méthodes de livraison de notification d’événement et de soumission de telles propositions.
Les méthodes de livraison de notification d’événement enregistrées comme IPP sont supposées suivre les exigences décrites ci-après.
23.7.1.1 Caractéristiques requises
Un document de méthode de livraison DOIT soit (1) contenir toute la sémantique de la méthode de livraison soit (2) contenir les exigences d’enregistrement de la méthode de livraison IPP et un profil d’un autre protocole qui combiné est la méthode de livraison (par exemple, mailto). Le document de méthode de livraison (et tous documents requis) DOIT définir soit (1) un URL pour une méthode de livraison poussée qui satisfait aux exigences de [RFC2717] soit (2) un mot clé pour une méthode de livraison poussée.
Les documents de méthode de livraison de notification d’événement DOIVENT satisfaire aux exigences du présent document (voir aux paragraphes 9 et 10).
De plus, un document de méthode de livraison DOIT contenir les informations suivantes :
Type d’enregistrement : méthode de livraison de notification d’événement IPP
Nom de cette méthode de livraison :
Nom du schéma d’URL proposé de cette méthode de livraison poussée ou nom du mot clé de cette méthode de livraison tirée :
Nom du proposant :
Adresse du proposant :
Adresse email du proposant :
La méthode de livraison est elle EXIGÉE ou FACULTATIVE pour la conformité au document de notification d’événement eet d’abonnement IPP :
La méthode de livraison définit elle un contenu à destination machine et/ou à destination humaine :
23.7.1.2 Exigences de dénomination
Exactement un nom (schéma d’URL ou mot clé) DOIT être alloué à chaque méthode de livraison.
Chaque nom alloué DOIT identifier de façon univoque une seule méthode de livraison. Tous les noms de méthode de livraison poussée DOIVENT se conformer aux règles des noms de schéma d’URL, conformément à la [RFC2396] et à la [RFC2717] pour les schémas dans l’arborescence de l’IETF. Tous les noms de méthode de livraison tirée DOIVENT se conformer aux règles sur les mots clé conformément à la [RFC2911].
23.7.1.3 Exigences fonctionnelles
Les méthodes de livraison DOIVENT fonctionner comme un protocole capable de délivrer des notifications d’événement IPP(poussées ou tirées) aux récepteurs de notification.
23.7.1.4 Exigences d’utilisation et de mise en œuvre
L’utilisation d’un grand nombre de méthodes de livraison peut nuire à l’interopérabilité. Cependant, l’utilisation d’un grand nombre de méthodes de livraison non documentées et/ou non étiquetées nuit encore plus à l’interopérabilité.
Une méthode de livraison ne devrait donc être enregistrée QUE SI elle ajoute une fonctionnalité significative valable pour une large communauté, OU si elle documente des pratiques existantes dans une large communauté. Noter que les méthodes de livraison enregistrées pour la seconde raison devraient être explicitement marquées comme étant d’utilisation limitée ou spécialisée et ne devraient être utilisées qu’après accord bilatéral préalable.
23.7.1.5 Exigences de publication
Les documents de méthode de livraison DOIVENT être publiés dans des RFC de normalisation, d’information, ou expérimentales.
23.7.2 Procédure d’enregistrement
Le groupe de travail IPP développe un petit nombre de méthodes de livraison qui sont destinées à être publiées comme RFC de normalisation. Cependant, certaines parties peuvent souhaiter enregistrer des méthodes de livraison supplémentaires à l’avenir. Ce paragraphe décrit les procédures pour ces méthodes de livraison supplémentaires.
23.7.2.1 Présentation de la proposition à la Communauté
Tout d’abord, le document de méthode de livraison DOIT être un projet Internet visant la catégorie de document normatif, informationnel, ou expérimental. Il DOIT en être de même pour tout document de référence.
Fournir la proposition de document de méthode de livraison proposée à la liste de diffusion "ipp@pwg.org". Cette liste de diffusion a été établie par la [RFC2911] pour passer en revue les enregistrements proposés et discuter les autres questions d’IPP. Les documents de méthode de livraison proposés ne sont pas formellement enregistrés et NE DOIVENT PAS être utilisés tant qu’ils ne sont pas approuvés.
L’objet de la diffusion publique est de provoquer des commentaires et des retours sur la définition et la praticabilité de la méthode de livraison et du nom choisi pour elle sur une période de quatre semaines.
23.7.2.2 Réviseur de méthode de livraison
Le réviseur de méthode de livraison est la personne qui a été désignée par le ou les directeurs de domaine d’application de l’IETF comme expert désigné sur IPP conformément à la [RFC2911] et [IANA-CON]. Lorsque la période de quatre semaine est écoulée et que l’expert désigné sur IPP est convaincu que le consensus est réalisé, l’expert désigné sur IPP approuve la demande d’enregistrement ou la rejette. Le rejet peut survenir à cause d’objections significatives soulevées sur la liste de diffusion ou à l’extérieur.
Les décisions prises par le réviseur doivent être envoyées à la liste de diffusion ipp@pwg.org dans les 14 jours. Il peut être fait appel des décisions du réviseur auprès de l’IESG.
23.7.2.3 Enregistrement IANA
Si la proposition d’enregistrement de méthode de livraison est acceptée au niveau de la révision ou au niveau de l’appel auprès de l’IESG, le réviseur notifiera à l’IANA la méthode de livraison et lui demandera d’enregistrer la méthode de livraison pour la mettre à la disposition de la communauté.
Chaque document de méthode de livraison poussée définit un schéma d’URI. Un tel schéma d’URI sert dans une valeur d’URI de l’attribut de gabarit d’abonnement "notification-recipient" (uri) (voir au paragraphe 5.3.1) et la valeur uriScheme de l’attribut d’imprimante "notify-schemes-supported" (1setOf uriScheme) (voir au paragraphe 5.3.1.1). Plutôt que de créer un paragraphe distinct dans le registre IPP pour les méthodes de livraison, les méthodes de livraison poussées seront enregistrées comme une valeur supplémentaire de l’attribut d’imprimante "notify-schemes-supported". Ces valeurs de uriScheme seront enregistrées conformément aux procédures du paragraphe 7.1 de la [RFC2911] pour les valeurs d’attribut supplémentaires. Donc, l’entrée de registre IPP pour une méthode de livraison poussée sera de la forme :
|
Valeur d’attribut |
Réf. |
Paragraphe |
|
notify-schemes-supported
(1setOf uriScheme) |
[RFC3995] |
5.3.1.1 |
|
<scheme name> |
RFC xxxx |
m.n |
Chaque document de méthode de livraison tirée définit une méthode de mot clé qui est enregistrée comme une valeur supplémentaire des attributs d’impprimante "notify-pull-method" et "notify-pull-method-supported". Ces valeurs de mot clé seront enregistrées conformément aux procédures du paragraphe 7.1 de la [RFC2911] pour les valeurs d’attribut supplémentaires. Donc, l’entrée du registre IPP pour une méthode de livraison tirée sera de la forme :
|
Valeur d’attribut |
Réf. |
Paragraphe |
|
notify-pull-method
(type2 keyword) |
[RFC3995] |
5.3.2 |
|
notify-pull-method-supported
(1setOf type2 keyword) |
[RFC3995] |
5.3.2.1 |
|
<method keyword name> |
RFC xxxx |
m.n |
A : ipp@pwg.org
Objet : Enregistrement d’une nouvelle méthode de livraison
Nom de la méthode de livraison : (Tous les noms de méthode de livraison poussée doivent pouvoir être utilisés comme valeur d’un schéma d’URL dans l’arborescence de l’IETF et tous les noms de méthode de livraison tirée doivent être des mots clé IPP convenables, conformément à la [RFC2911])
Spécification(s) publiées : (Une spécification pour la méthode de livraison qui décrit convenablement ce qui est enregistré doit être disponible au public.)
Adresse personnelle & email à contacter pour plus d’informations : ?
La présente spécification de Notification IPP prolonge la prise en charge de l’internationalisation de la [RFC2911] des attributs contenant des chaînes de texte et des noms. Permettre au Client abonné de spécifier un langage naturel et un ensemble de caractères différents pour chaque objet d’abonnement augmente l’internationalisation de la prise en charge.
L’imprimante DOIT être capable de localiser le contenu des notifications d’événement à destination humaine et de localiser la valeur de l’attribut "notify-text" dans les notifications d’événement à destination machine qu’elle délivre aux récepteurs de notification. Pour la localisation, l’imprimante DOIT utiliser la valeur de l’attribut "notify-charset" et l’attribut "notify-natural-language" dans l’objet d’abonnement fourni par le client abonné.
Les clients qui soumettent des demandes de notification à l’imprimante IPP connaissent les mêmes problèmes de sécurité qu’en soumettant une demande de tâched’impression IPP/1.1 (voir le paragraphe 3.2.1 et la section 8 de la [RFC2911]). Les mêmes mécanismes utilisés par IPP/1.1 peuvent donc être utilisés par la sousmission de notification client. Les opérations qui exigent l’authentification peuvent utiliser l’authentification HTTP. Les opérations qui exigent la confidentialité peuvent utiliser la confidentialité de HTTP/TLS. Comme avec les objets de tâche d’impression de IPP/1.1, s’il n’y a pas de sécurité sur les objets d’abonnement, l’allocation en séquence des identifiants d’abonnement expose le système à une menace de surveillance passive du trafic.
Le modèle de contrôle d’accès de l’objet d’abonnement est le même que le modèle de contrôle d’accès pour les objets tâche. Le client DOIT avoir les droits d’accès suivants pour les opérations d’abonnement indiquées :
1. Créer des abonnements de tâche (voir au paragraphe 11.1.1) : un objet d’abonnement par tâche est associé à une tâche. Pour créer des objets d’abonnement par tâche, l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de la tâche, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à créer des objets d’abonnement par tâche pour la tâche cible.
2. Créer des abonnements d’imprimante (voir au paragraphe 11.1.2) : un objet d’abonnement par imprimante est –associé à l’imprimante. Pour créer des objets d’abonnement par imprimante, l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (2) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à créer des objets d’abonnement par imprimante pour cette imprimante.
3. Obtenir les attributs d’abonnement (voir au paragraphe 11.2.4) : le modèle de contrôle d’accès pour cette opération est le même que celui de l’opération Obtenir les attributs de tâche (voir le paragraphe 3.3.4 de la [RFC2911]). La principale différence est que l’opération Obtenir les attributs d’abonnement est dirigée vers un objet d’abonnement plutôt que vers un objet tâche, et un groupe d’attributs retourné contient des attributs d’objet d’abonnement plutôt que des attributs d’objet tâche. Pour interroger l’objet d’abonnement spécifié, l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à interroger l’objet d’abonnement sur la tâche cible. De plus, la politique de sécurité de l’imprimante PEUT limiter les attributs qui sont retournés, de la même manière que pour l’opération Obtenir les attributs de tâche (voir la fin du paragraphe 3.3.4.2 de la [RFC2911]).
4. Obtenir les abonnements (voir au paragraphe 11.2.5) : le modèle de contrôle d’accès pour cette opération est le même que celui de l’opération Obtenir les tâches (voir le paragraphe 3.2.6 de la [RFC2911]). La principale différence est que l’opération est dirigée vers les objets d’abonnement plutôt que vers les objets tâche, et que les groupes d’attribut retournés contiennent des attributs d’objet d’abonnement plutôt que des attributs d’objet tâche. Pour interroger les objets d’abonnement par tâche sur la tâche spécifiée (le client a fourni l’attribut d’opération "notifier l’identifiant de tâche" - voir au paragraphe 11.2.5.1.1), l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à interroger l’objet d’abonnement sur la tâche cible. Pour interroger les objets d’abonnement par imprimante de l’imprimante (le client a omis l’attribut d’opération "notifier l’identifiant de tâche" - voir au paragraphe 11.2.5.1.1), l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (2) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à interroger les objets d’abonnement par imprimante sur l’imprimante cible. De plus, la politique de sécurité de l’imprimante PEUT limiter les attributs qui sont retournés, de la même manière que pour l’opération Obtenir les attributs de tâche (voir la fin du paragraphe 3.3.4.2 de la [RFC2911]).
5. Renouveler les abonnements (voir au paragraphe 11.2.6) : l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement par imprimante, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à renouveler les objets d’abonnement par imprimante pour l’imprimante cible.
6. Annuler l’abonnement (voir au paragraphe 11.2.7) : l’utilisateur authentifié (voir le paragraphe 8.3 de la [RFC2911]) qui effectue cette opération DOIT (1) être le propriétaire de l’objet d’abonnement, (2) avoir les droits d’accès d’opérateur ou d’administrateur pour cette imprimante (voir la section 1 et le paragraphe 8.5 de la [RFC2911]), ou (3) être autrement autorisé par la politique de sécurité configurée par l’administrateur de l’imprimante à annuler l’objet d’abonnement cible.
Le souci de la sécurité standard (livraison au bon utilisateur, confidentialité du contenu, contenu protégé contre les altérations) s’applique à chaque méthode de livraison. Certaines méthodes de livraison sont plus sûres que d’autres. Chaque document de méthode de livraison DOIT discuter de ses Considérations de sécurité.
Piège à notifications : si une imprimante prend en charge l’attribut de gabarit d’abonnement FACULTATIF "notifier les attributs" (voir au paragraphe 5.3.4) alors que le client peut demander que l’imprimante retourne tout attribut d’objet de tâche, d’imprimante et d’abonnement spécifié, l’imprimante DOIT appliquer la même politique de sécurité à ces attributs demandés dans la demande Obtenir les notifications qu’elle applique pour les demandes Obtenir les tâches, Obtenir les attributs de tâche, Obtenir les attributs d’imprimante, et Obtenir les attributs d’abonnement.
Notifications d’événements non désirés (spam) : pour toute méthode de livraison poussée, le plus gros problème de sécurité est de loin l’abus de notifications : la délivrance de notifications d’événement non désirées à des tiers (c’est-à-dire, le spam). Le problème empire lorsqu’il y a des adresses de notification qui peuvent être redistribuées de nombreuses fois. Il existe des scénarios où la notification à un tiers est utilisée (voir les scénario n° 2 et n° 3 dans la [RFC3997]). Toute solution pleinement sécurisée passe par l’accord actif de tous les récepteurs avant une quelconque livraison.
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 protocvoles 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).
Les personnes suivantes ont apporté des contributions significatives à la conception et à la révision de la présente spécification :
|
Scott A. Isaacson |
Roger deBry |
Jay Martin |
|
Novell, Inc. |
Utah Valley State
College |
Underscore Inc. |
|
122 E 1700 S |
Orem, UT 84058 |
9 Jacqueline St. |
|
Provo, UT 84606 |
Phone: 801-863-8848 |
Hudson, NH
03051-5308 |
|
Phone: 801-861-7366 |
|
Phone: 603-889-7000 |
|
Fax: 801-861-2517 |
mél:
debryro@uvsc.edu |
Fax: 775-414-0245 |
|
mél:
sisaacson@novell.com |
|
mél:
jkm@underscore.com |
|
Michael Shepherd |
Ron Bergman |
|
Xerox Corporation |
Ricoh Printing
Systems America |
|
800 Phillips
Road MS 128-51E |
1757 Tapo Canyon
Road |
|
Webster, NY 14450 |
Simi Valley, CA
93063-3394 |
|
Phone: 716-422-2338 |
Phone: 805-578-4421 |
|
Fax: 716-265-8871 |
Fax: 805-578-4001 |
|
mél:
ron.bergman@rpsa.ricoh.com |
Adresse des auteurs
|
Robert Herriot |
Tom Hastings |
|
Global Workflow
Solutions |
Xerox Corporation |
|
706 Colorado Ave. |
701 S Aviation
Blvd, ESAE 242 |
|
Palo Alto, CA 94303 |
El Segundo, CA 90245 |
|
Phone: 650-324-4000 |
Phone: 310-333-6413 |
|
mél: bob@herriot.com |
mél:
hastings@cp10.es.xerox.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.