RFC 2911

Groupe de travail Réseau T. Hastings, éditeur ; R. Herriot : Xerox Corporation

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.

Le présent document fait partie d’un ensemble de documents, qui tous ensemble décrivent les divers aspects d’un nouveau protocole d’impression sur Internet (IPP). IPP est un protocole de niveau application qui peut être utilisé pour l’impression distribuée à l’aide des outils et technologies de l’Internet. Le présent document décrit un modèle simplifié qui comporte des objets abstraits, leurs attributs, et leurs opérations qui sont indépendantes du codage et du transport. Le modèle comporte un objet Imprimante et un objet Tâche. Une tâche prend facultativement en charge plusieurs documents. La sémantique de IPP 1.1 permet aux utilisateurs finaux et aux opérateurs d’interroger les capacités d’une imprimante, de soumettre des tâches d’impression, d’enquêter sur l’état des tâches d’impression et des imprimantes, d’annuler, de mettre en garde, de libérer et de redémarrer des tâches d’impression. La sémantique d’IPP 1.1 permet aux opérateurs de suspendre, de restaurer, et de purger (de leurs tâches) les objets Imprimante. Le présent document traite aussi des questions de sécurité, d’internationalisation et d’annuaire.

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 (le présent document)

Le document "Objectifs de conception pour un protocole d’impression sur Internet" porte un large 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.1. Quelques opérations d’opérateur FACULTATIVES ont été ajoutées à IPP/1.1.

Le document "Fondements de la structure, modèle et protocole du protocole d’impression sur Internet" décrit IPP d’un point de vue plus élevé et définit la mission des divers documents qui forment la série des documents de spécification d’IPP. Il donne les fondements des décisions majeures du groupe de travail IPP de l’IETF.

Le document "Protocole/1.1 d’impression sur Internet : Modèle et sémantique" décrit un modèle simplifié avec des objets abstraits, leurs attributs, et leurs opérations qui sont indépendantes du codage et du transport. Le modèle introduit un objet Imprimante et un objet Tâche. L’objet tâche prend facultativement en charge plusieurs documents par tâche. Il traite aussi des questions de sécurité, d’internationalisation, et d’annuaire.

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 les règles de codage pour un nouveau type de support MIME sur 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 un nouveau schéma nommé 'ipp' pour l’identification des imprimantes et tâches IPP.

Le document "Protocole/1.1 d’impression sur Internet : Guide de mise en œuvre" donne des perspectives et des conseils pour les mises en œuvre de clients et objets IPP. Il est destiné à aider à comprendre IPP/1.1 et certaines de ses considérations peuvent faciliter la conception des mises en œuvre client et/ou objet IPP. Par exemple, il donne l’ordre normal de traitement des demandes, y compris la recherche d’erreurs. Il inclut aussi les motivations de certaines des décisions de la spécification.

Le document "Transposition entre protocoles LPD et IPP" donne quelques conseils à ceux qui mettent en œuvre des passerelles entre des mises en œuvre IPP et LPD (Line Printer Daemon).

Table des matières

1. Introduction 2

1.1 Modèle d’impression simplifié 3

2. Objets IPP 4

2.1 Objet Imprimantes 5

2.2. Objet tâche 6

2.3. Relations d’objet 6

2.4. Identité d’objet 7

3. Opérations IPP 9

3.1. Sémantique commune 9

3.2. Opérations d’imprimante 19

3.3. Opérations de tâche 30

4. Attributs d’objet 38

4.1. Syntaxes d’attribut 38

4.2. Attributs de gabarit de tâche 45

4.3. Attributs de description de tâche 53

4.4. Attributs de description d’imprimante 63

5. Conformité 74

5.1. Exigences de conformité pour le client 74

5.2. Exigences de conformité des objets IPP 74

5.3. Exigences de charset et de langage naturel 77

6. Considérations relatives à l’IANA 77

6.1. Extensions des types 'mot-clé' et 'enum' 77

6.2. Extensibilité d’attribut 78

6.3. Extensibilité de syntaxe d’attribut 79

6.4. Extensibilité d’opération 79

6.5. Extensibilité de groupe d’attributs 79

6.6. Extensibilité de code d’état 79

7. Considérations relatives à l’internationalisation 80

8. Considérations sur la sécurité 82

8.1. Scénarios de sécurité 83

8.2. URI dans les attributs d’opération, de tâche, et d’imprimante 83

8.3. URI pour chaque mécanisme d’authentification 84

8.4. Interrogations interdites 84

8.5. Opérations effectuées par des opérateurs et administrateurs de système 84

8.6. Interrogations sur des tâches soumises en utilisant des protocoles non-IPP 84

9. Références 85

10. Adresse des auteurs 87

11. Formats des propositions d’enregistrement IPP 88

12. APPENDICE A : Terminologie 91

13. APPENDICE B : Codes d’état et messages de code d’état suggérés 94

13.1. Codes d’état 94

13.2 Codes d’état pour les opérations IPP 99

14. APPENDICE C : valeurs de mot-clé "support" 101

14.1. Exemples 108

15. APPENDICE D : Traitement des attributs IPP 110

15.1. Fidélité 110

15.2. Outrepasser le langage de description de page (PDL) 111

15.3. Utilisation des attributs de gabarit de tâche durant le traitement de document 112

16. APPENDICE E : Schéma d’annuaire générique 113

17. APPENDICE F : Différences entre les documents "Modèle et sémantique" IPP/1.0 et IPP/1.1 114

18. Déclaration de Copyright 118

1 Introduction

Le Protocole d’impression sur Internet (IPP) est un protocole de niveau application qui peut être utilisé pour l’impression distribuée en utilisant les outils et techniques de l’Internet. IPP version 1.1 (IPP/1.1) se concentre principalement sur les fonctions d’utilisateur terminal mais quelques opérations administratives sont incluses. Le présent document est inclus dans une suite de documents qui définissent entièrement IPP. L’ensemble complet des documents IPP comporte :

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 (le présent document)

Ceux qui lisent ces documents pour la première fois sont vivement encouragés à lire les documents IPP dans l’ordre ci-dessus.

- Le reste de la Section 1 est une introduction au modèle IPP simplifié pour l’impression distribuée.

- La Section 2 introduit les types d’objet couverts dans le modèle avec leurs comportements, attributs et interactions de base.

- La Section 3 définit les opérations comprises dans IPP/1.1. Les opérations d’IPP sont synchrones, et donc, pour chaque opération, il y a à la fois une demande et une réponse.

- La Section 4 définit les attributs (et leur syntaxe) qui sont utilisés dans le modèle.

- Les sections 5 - 6 présentent respectivement les exigences de conformité des mises en œuvre pour les objets qui prennent en charge le protocole et les considérations liées à l’IANA.

- Les sections 7 à 11 couvrent les considérations sur l’internationalisation, sur la sécurité ainsi que les références, les informations de contact des auteurs, et les formats des propositions d’enregistrement.

- Les sections 12 à 14 sont des appendices qui traitent de la terminologie, des codes d’état et des messages, et des valeurs de mot-clé de "support".

Note : Le présent document utilise des termes comme "attributs", "mot-clé", et "prise en charge". Ces termes ont une signification particulière et sont définis au paragraphe 12.2 de la terminologie modèle. Les termes mis en majuscules, tels que DOIT, NE DOIT PAS, EXIGE, DEVRAIT, NE DEVRAIT PAS, PEUT, PEUT NE PAS, et FACULTATIF, ont une signification particulière en rapport avec la conformité. Ces termes sont définis au paragraphe 12.1 sur la terminologie de conformité, et la plupart sont tirés de la RFC 2119 [RFC2119].

- La Section 15 est un appendice qui aide à préciser les effets des interactions entre les attributs et leurs valeurs.

- La Section 16 est un appendice qui décrit le sous-ensemble des attributs d’imprimante qui forme un schéma d’annuaire générique. Ces attributs sont utiles lors de l’enregistrement d’une imprimante pour qu’un client puisse trouver l’imprimante non seulement par son nom, mais aussi par des recherches filtrantes.

- La Section 17 est un appendice qui résume les ajouts et modifications par rapport au document IPP/1.0 "Modèle et sémantique" [RFC2566] pour arriver au présent document IPP/1.1.

1.1 Modèle d’impression simplifié

Pour mener à bien son objectif de constitution d’un protocole d’impression utilisable sur l’Internet, le protocole d’impression sur Internet (IPP) se fonde sur un modèle d’impression simplifié qui idéalise les nombreux composants du monde réel de l’impression. L’Internet est un environnement de calcul distribué, où les demandeurs de services d’impression (clients, applications, pilotes d’impression, etc.) coopèrent et interagissent avec les fournisseurs de services d’impression. Le présent document de modélisation et de sémantique décrit un modèle simple et abstrait pour IPP, même si les configurations sous-jacentes peuvent être des systèmes complexes de client/serveur à "n dimensions". Une importante étape simplificatrice dans le modèle IPP est de n’exposer que les objets et les interfaces clés nécessaires pour l’impression. Le modèle décrit dans le présent document de modélisation n’inclut pas les caractéristiques, interfaces, et relations qui sont au-delà du domaine d’application de la première version d’IPP (IPP/1.1). IPP/1.1 incorpore nombre des idées pertinentes et des leçons tirées d’autres spécifications et efforts de développement [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. IPP est fortement influencé par le modèle d’impression introduit par la norme d’application d’impression de document (DPA, Document Printing Application) [ISO10175]. Bien que DPA spécifie à la fois les caractéristiques d’utilisateur terminal et administratives, IPP version 1.1 (IPP/1.1) se concentre principalement sur les fonctions d’utilisateur terminal avec quelques opérations d’opérateur supplémentaires FACULTATIVES.

Le modèle IPP/1.1 classe les composants importants de l’impression distribuée en deux types d’objet :

Chaque type d’objet a un ensemble d’opérations (voir la section 3) et d’attributs (voir la section 4) associé. Il est cependant important de comprendre que dans des mises en œuvre de systèmes réels (qui sont sous-jacents au modèle abstrait d’IPP/1.1), il y a d’autres composants de services d’impression qui ne sont pas explicitement définis dans le modèle IPP/1.1. La figure ci-après illustre comment IPP/1.1 s’accorde par rapport à ces autres composants.

Un objet imprimante IPP incorpore les fonctions normalement associées aux appareils de sortie physique ainsi qu’aux fonctions de dévidage, de programmation et de gestion des nombreux appareils souvent associés à un serveur d’impression. Les objets imprimante sont facultativement enregistrés comme entrées dans un répertoire où les utilisateurs finaux les trouvent et les sélectionnent sur la base d’une sorte de mécanisme de recherche et de filtrage fondé sur le contexte (voir la section 16). Le répertoire sert à emmagasiner des informations relativement statiques sur l’imprimante, ce qui permet aux utilisateurs finaux de chercher et trouver les imprimantes qui satisfont à leurs critères de recherche, par exemple : nom, contexte, capacités d’imprimante, etc. Les informations plus dynamiques, telles que l’état, le support actuellement chargé et prêt, le nombre de tâches à l’imprimante, les erreurs, les avertissements, et ainsi de suite, sont directement associées à l’objet imprimante lui-même plutôt qu’aux entrées dans le répertoire qui ne représentent que les objets Imprimante.

Les clients IPP mettent en œuvre le protocole IPP du côté client et donnent aux utilisateurs finaux (ou aux programmes tournant au nom des utilisateurs finaux) la capacité d’interroger les objets imprimante et de soumettre et gérer des tâches d’impression. Un serveur IPP est simplement la partie de l’objet imprimante qui met en œuvre le protocole côté serveur. Le reste de l’objet imprimante met en œuvre (ou sert de passerelle pour) la sémantique d’application des services d’impression eux-mêmes. Les objets imprimante peuvent être incorporés dans un appareil d’entrée ou peuvent être mis en œuvre sur un hôte du réseau, qui communique avec un appareil de sortie.

Lorsqu’une tâche est soumise à l’objet imprimante et que l’objet imprimante valide les attributs de la demande de soumission, l’objet imprimante crée un nouvel objet tâche. L’utilisateur final interagit alors avec ce nouvel objet tâche pour interroger son état et surveiller les progrès de la tâche. Un utilisateur final peut aussi annuler les tâches d’impression en utilisant l’opération Annuler-tâche de l’objet tâche. Un utilisateur final peut aussi mettre en garde, libérer, et redémarrer les tâches d’impression en utilisant les opérations FACULTATIVES Garder la tâche, Libérer la tâche et Redémarrer la tâche de l’objet tâche, si elles sont mises en œuvre.

Un opérateur ou administrateur privilégié d’un objet imprimante peut annuler, mettre en garde, libérer, et redémarrer toute tâche d’utilisateur en utilisant les opérations Annuler-tâche EXIGÉE, et Garder la tâche, Libérer la tâche et Redémarrer la tâche FACULTATIVES. De plus, un opérateur ou administrateur privilégié d’un objet imprimante peut mettre en pause, reprendre ou purger (les tâches d’un) un objet imprimante en utilisant les opérations FACULTATIVES Pause d’imprimante, Reprendre-l’imprimante, et Purger les tâches, si elles sont mises en œuvre.

Le service de notification sort du domaine d’application du présent document IPP/1.1, mais en utilisant un tel service de notification, l’utilisateur final est en mesure d’enregistrer et de recevoir des événements spécifiques d’imprimante et de tâche. Un utilisateur final peut interroger l’état des objets imprimante et peut suivre les progrès des objets tâche par consultation en utilisant les opérations Obtenir les attributs d’imprimante, Obtenir les tâches et Obtenir les attributs de tâche.

2 Objets IPP

Le modèle IPP/1.1 introduit des objets du type Imprimante et Tâche. Chaque type d’objet modélise les aspects pertinents d’entités réelles telles qu’une vraie imprimante ou une vraie tâche d’impression. Chaque type d’objet est défini comme un ensemble d’attributs possibles qui peuvent être pris en charge par des instances de ce type d’objet. Pour chaque objet (instance), l’ensemble réel d’attributs et valeurs pris en charge décrit une mise en œuvre spécifique. Les attributs et les valeurs de l’objet décrivent son état, ses capacités, les caractéristiques réalisables, les fonctions de traitement des tâches, et les comportements et caractéristiques par défaut. Par exemple, le type d’objet Imprimante se définit comme un ensemble d’attributs que chaque objet Imprimante peut prendre en charge. De la même façon le type d’objet Tâche se définit comme un ensemble d’attributs qui peuvent être pris en charge par chaque objet Tâche.

Chaque attribut inclus dans l’ensemble des attributs qui définissent un type d’objet est étiqueté comme :

Certaines définitions de valeurs d’attribut indiquent qu’un objet DOIT ou DEVRAIT prendre en charge la valeur ; autrement, prendre en charge la valeur est FACULTATIF.

Cependant, si une mise en œuvre prend en charge un attribut, elle DOIT prendre en charge au moins une des valeurs possibles pour cet attribut.

2.1 Objet Imprimante

Le composant majeur du modèle IPP/1.1 est l’objet Imprimante. Un objet Imprimante met en œuvre le côté serveur du protocole IPP/1.1. En utilisant ce protocole, les utilisateurs finaux peuvent interroger les attributs de l’objet imprimante et soumettre des tâches d’impression à l’objet imprimante. Les composants de mises en œuvre réelles derrière l’imprimante abstraite peuvent prendre des formes diverses et différentes configurations. Cependant, le modèle abstrait permet aux détails de configuration des composants réels de rester opaques à l’utilisateur final. La section 3 décrit chacune des opérations d’imprimante en détail.

Les capacités et l’état d’un objet Imprimante sont décrits par ses attributs. Les attributs d’imprimante se divisent en deux groupes :

- attributs de "gabarit de tâche" : ces attributs décrivent les capacités de traitement de tâche prises en charge et par défaut par l’objet imprimante. (Voir au paragraphe 4.2.)

- attributs de "description d’imprimante" : ces attributs décrivent l’identification, l’état, la localisation de l’objet imprimante et les références à d’autres sources d’information sur l’objet imprimante, etc. (Voir au paragraphe 4.4.)

Dans la mesure où un objet Imprimante est une abstraction d’un appareil générique de sortie de document et de fournisseur de services d’impression, un objet Imprimante pourrait être utilisé pour représenter tout appareil réel ou virtuel ayant une sémantique cohérente avec l’objet imprimante, tel qu’un télécopieur, un reproducteur d’images, ou même un graveur de CD.

3) Un serveur d’impression prenant en charge IPP avec un ou plusieurs appareils de sortie associés

3a) Les appareils de sortie associés peuvent être ou n’être pas capables de tâches de dévidage

3b) Les appareils de sortie associés peuvent ou ne peuvent pas prendre en charge IPP.

Les figures ci-après donnent quelques exemples de la façon dont les objets imprimante peuvent être réalisés au titre de diverses configurations d’impression distribuée. Le cas "incorporé" ci-dessous représente les configurations 1 et 2. Les figures "avec hôte" et "ventilée" ci-dessous représentent les configurations 3a et 3b.

Dans le présent document le terme "client" se réfère à une entité logicielle qui envoie des demandes d’opération IPP à un objet imprimante IPP et accepte les réponses d’opération IPP. Un client PEUT être :

1. contenu dans un logiciel contrôlé par un utilisateur final, par exemple, activé par l’élément "Imprimer" du menu dans une application ou

2. le composant de serveur d’impression qui envoie des demandes IPP à un appareil de sortie ou à un autre serveur d’impression "aval".

Le terme "imprimante IPP" se réfère à une entité réseau qui accepte des demandes d’opération IPP et retourne des réponses d’opération IPP. Comme tel, un objet IPP PEUT être :

1. un composant (incorporé) d’appareil qui accepte des demandes IPP et contrôle l’appareil ou

2. un composant d’un serveur d’impression qui accepte des demandes IPP (lorsque le serveur d’impression contrôle un ou plusieurs appareils en réseau qui utilisent IPP ou d’autres protocoles).

##### indique un objet Imprimante qui est incorporé dans un appareil de sortie ou hébergé dans un serveur. L’objet Imprimante peut être capable ou non de mettre en file d’attente/dévider.

2.2 Objet tâche

Un objet Tâche est utilisé pour modéliser une tâche d’impression. Un objet Tâche contient des documents. Les informations nécessaires pour créer un objet Tâche sont envoyées dans une demande de création de l’utilisateur final via un client IPP à l’objet imprimante. L’objet Imprimante valide la demande de création, et si l’objet imprimante accepte la demande, l’objet imprimante crée le nouvel objet Tâche. Chacune des opérations de tâche est décrite en détail à la section 3.

Les caractéristiques et l’état d’un objet Tâche sont décrits par ses attributs. Les attributs de tâche sont rassemblés en deux groupes comme suit :

- attributs de "gabarit de tâche" : ces attributs peuvent être fournis par le client ou l’utilisateur final et inclure les instructions de traitement de tâche qui sont destinées à se substituer à toutes les valeurs par défaut et/ou instructions de l’objet Imprimante incorporées au sein des données documentaires. (Voir au paragraphe 4.2.)

- attributs de "description de tâche" : ces attributs décrivent l’identification, l’état, la taille, etc., de l’objet Tâche. Le client fournit certains de ces attributs, et l’objet imprimante génère les autres. (Voir au paragraphe 4.3)

Une mise en œuvre DOIT prendre en charge au moins un document par objet Tâche. Une mise en œuvre PEUT prendre en charge plusieurs documents par objet Tâche. Un document est soit :

- un flux de données documentaires dans un format accepté par l’objet imprimante (normalement un langage de description de page (PDL, Page Description Language), ou

Dans IPP/1.1, un document n’est pas modélisé comme un objet IPP, et n’a donc pas d’identifiant d’objet ou d’attributs associés. Toutes les instructions de traitement de tâche sont modélisées comme attributs d’objet Tâche. Ces attributs sont appelés attributs de gabarit de tâche et ils s’appliquent également à tous les documents au sein d’un objet Tâche.

2.3 Relations d’objet

Les objets IPP ont des relations qui se conservent de façon persistante avec le stockage permanent des attributs d’objet.

Un objet Imprimante peut représenter un ou plusieurs appareils physiques de sortie ou un appareil logique qui "traite" les tâches mais n’utilise jamais réellement un appareil physique de sortie pour mettre des signes sur le papier. Parmi les exemples d’appareil logique on trouvera un éditeur de pages Web ou une passerelle avec une archive de document en ligne ou un répertoire. Un objet Imprimante contient zéro ou plusieurs objets Tâche.

Un objet Tâche est contenu dans exactement un objet Imprimante, cependant les données documentaires identiques associées à un objet Tâche pourraient être envoyées au même objet Imprimante ou à un objet différent. Dans ce cas, un second objet Tâche serait créé qui serait presque identique au premier objet Tâche, mais il aurait un nouvel identifiant (différent) d’objet Tâche (voir au paragraphe 2.4).

Un objet Tâche est soit vide (avant qu’aucun document n’y ait été ajouté) soit il contient un ou plusieurs documents. Si le document contenu est un flux de données documentaires, ce flux peut être contenu dans un seul document. Cependant, il peut y avoir des copies identiques du flux dans d’autres documents dans le même objet Tâche ou dans des objets différents. Si le document contenu est une simple référence à un flux de données documentaires, d’autres documents (dans le même objet Tâche ou dans des objets différents) peuvent contenir la même référence.

2.4 Identité d’objet

Tous les objets Imprimante ou Tâche sont identifiés par un Identifiant de ressource uniforme (URI, Uniform Resource Identifier) [RFC2396] de sorte qu’ils puissent être référencés de façon persistante et non ambiguë. Dans la mesure où chaque URL est une forme spécialisée d’URI, bien que le terme plus général d’URI soit utilisé tout au long du reste du présent document, son utilisation est destinée à recouvrir aussi la notion plus spécifique d’URL.

Un administrateur configure les objets Imprimante pour prendre en charge ou ne pas prendre en charge l’authentification et/ou la confidentialité de message en utilisant la sécurité de couche transport (TLS, Transport Layer Security) [RFC2246] (le mécanisme de configuration de la sécurité est en dehors du domaine d’application du présent document IPP/1.1). Dans certaines situations, les deux types de connexions (authentifiée et non authentifiée) peuvent être établies en utilisant un seul canal de communication qui a une sorte de mécanisme de négociation. Dans d’autres situations, plusieurs canaux de communication sont utilisés, un pour chaque type de configuration de sécurité. Une description complète de toutes les considérations et configurations de sécurité figure à la section 8.

Si un objet Imprimante prend en charge plus d’un canal de communication, certains de ces canaux, ou tous, peuvent prendre en charge et/ou exiger des mécanismes de sécurité différents. Dans de tels cas, un administrateur pourrait considérer la prise en charge simultanée de ces divers canaux de communication comme plusieurs URI pour un seul objet Imprimante où chaque URI représente un des canaux de communication avec l’objet imprimante. Pour prendre en charge cette souplesse, le type d’objet imprimante IPP définit un attribut d’identification à plusieurs valeurs appelé "uri-d’imprimante-acceptés". Il DOIT contenir au moins un URI. Il PEUT contenir plus d’un URI. C’est à dire que chaque objet Imprimante aura au moins un URI qui identifie au moins un canal de communication avec l’objet imprimante, mais il peut avoir plus d’un URI là où chaque URI identifie un canal de communication différent avec l’objet imprimante. L’attribut "uri-d’imprimante-acceptés" a deux attributs compagnons, "sécurité-d’uri-acceptée" et "authentification-d’uri-acceptée". Tous deux ont la même cardinalité que "uri-d’imprimante-acceptés". L’objet de l’attribut "sécurité-d’uri-acceptée" est d’indiquer les mécanismes de sécurité (s’il en est) utilisés pour chaque URI dont la liste figure dans "uri-d’imprimante-acceptés". L’objet de l’attribut "authentification-d’uri-acceptée" est d’indiquer les mécanismes d’authentification (s’il en est) utilisés pour chaque URI de la liste de "uri-d’imprimante-acceptés". Ces trois attributs font l’objet d’une description complète aux paragraphes 4.4.1, 4.4.2, et 4.4.3.

Lorsqu’une tâche est soumise à l’objet imprimante via une demande de création, le client ne fournit qu’un seul URI d’objet Imprimante. L’URI d’objet Imprimante fourni par le client DOIT être une des valeurs de l’attribut d’imprimante "uri-d’imprimante-acceptés".

IPP/1.1 ne spécifie pas comment le client obtient l’URI fourni par le client, mais il est RECOMMENDÉ qu’un objet Imprimante soit enregistré comme entrée dans un service d’annuaire. Les utilisateurs finaux et les programmes peuvent alors interroger l’annuaire pour chercher des imprimantes. La section 16 définit un schéma générique pour les entrées d’objet Imprimante dans les services d’annuaire et décrit comment l’entrée agit comme pont vers l’objet imprimante IPP réel. L’entrée dans l’annuaire que représente l’objet imprimante IPP inclut les nombreux URI possibles pour cet objet Imprimante comme valeurs dans un de ses attributs.

Lorsqu’un client soumet une demande de création à l’objet imprimante, l’objet imprimante valide la demande et crée un nouvel objet Tâche. L’objet Imprimante alloue au nouvel objet Tâche un URI qui est stocké dans l’attribut de tâche "uri-de-tâche". Cet URI est ensuite utilisé par les clients comme cible pour les opérations de tâche suivantes. L’objet Imprimante génère un URI de tâche sur la base de sa politique de sécurité configurée et de l’URI utilisé par le client dans la demande de création.

Par exemple, considérons un objet Imprimante qui prend en charge à la fois un canal de communication sécurisé par l’utilisation de SSL3 (utilisant HTTP sur SSL3 avec un URI de schéma "https") et un autre canal de communication ouvert qui n’est pas sécurisé avec SSL3 (utilisant un simple URI de schéma "http"). Si un client devait soumettre une tâche en utilisant l’URI sécurisé, l’objet imprimante allouerait aussi bien un URI sécurisé au nouvel objet Tâche. Si un client devait soumettre une tâche en utilisant l’URI du canal ouvert, l’imprimante allouerait un URI de canal ouvert au nouvel objet Tâche.

De plus, l’objet imprimante remplit aussi l’attribut "tâche-d’uri-d’imprimante" de l’objet Tâche. Ceci est une référence en retour à l’objet imprimante qui a créé l’objet Tâche. Si un client a seulement l’accès à un identifiant d’"uri-de-tâche" d’un objet Tâche, le client peut interroger l’attribut "tâche-d’uri-d’imprimante" de la tâche afin de déterminer quel objet Imprimante a créé l’objet Tâche. Si l’objet imprimante prend en charge plus d’un URI, l’objet imprimante prend l’URI fourni par le client lors de la création de la tâche pour construire la valeur et remplir l’attribut "tâche-d’uri-d’imprimante" de la tâche.

Permettre aux objets Tâche d’avoir des URI donne de la souplesse et des éléments de comparaison. Par exemple, dans certaines mises en œuvre, l’objet imprimante peut créer des tâches qui sont traitées dans le même environnement local que l’objet imprimante lui-même. Dans ce cas, l’URI de tâche peut être simplement une composition de l’URI de l’imprimante et de quelque composant unique pour l’objet Tâche, tel que l’entier positif unique de 32 bits mentionné plus loin dans ce paragraphe. Dans d’autres mises en œuvre, l’objet imprimante peut être une chambre de compensation centrale pour la validation de toutes les demandes de création d’objet Tâche, mais l’objet Tâche lui-même peut être créé dans un environnement distant de l’objet imprimante.

Dans ce cas, l’URI de l’objet Tâche peut n’avoir pas du tout de relation de localisation physique avec l’URI de l’objet imprimante. Là encore, le fait que les objets Tâche aient des URI permet souplesse et mesurabilité. Cependant, de nombreux systèmes d’impression existants ont des contraintes de modèle ou d’interface locales qui forcent les tâches d’impression à être identifiées en utilisant seulement un entier positif de 32 bits plutôt qu’un URI indépendant. Cet identifiant de tâche numérique n’est unique que dans le contexte de l’objet imprimante auquel la demande de création a été soumise à l’origine. Donc, afin de permettre aux deux types de client d’accéder aux objets Tâche IPP (par URI de tâche ou par ID numérique de tâche), lorsque l’objet imprimante réussit à traiter une demande de création et crée un nouvel objet Tâche, l’objet imprimante DOIT générer un URI de tâche et un ID de tâche. L’ID de tâche (conservé dans l’attribut "id-de-tâche") n’a de signification que dans le contexte de l’objet imprimante auquel la demande de création a été soumise à l’origine. Cette exigence de prendre en charge à la fois les URI de tâche et les ID de tâche permet à tous les types de clients d’accéder aux objets Imprimante et objets Tâches sans se soucier des contraintes locales imposées à la mise en œuvre du client.

En plus des identifiants, les objets Imprimante et Tâche ont des noms ("nom-d’imprimante" et "nom-de-tâche"). Un nom d’objet PEUT NE PAS être unique à travers toutes les instances de tous les objets. Un nom d’objet Imprimante est choisi et fixé par un administrateur par un mécanisme qui sort du domaine d’application du présent document IPP/1.1. Un nom d’objet Tâche est facultativement choisi et fourni par le client IPP qui soumet la tâche. Si le client ne fournit pas de nom d’objet Tâche, l’objet imprimante génère un nom pour le nouvel objet Tâche. Dans tous les cas, le nom n’a qu’une signification locale.

- Chaque objet Imprimante est identifié par un ou plusieurs URI. L’attribut "uri-d’imprimante-acceptés" de l’imprimante contient le ou les URI.

- L’attribut "sécurité-d'uri-acceptée" d’objet Imprimante identifie les protocoles de sécurité du canal de communication qui peuvent avoir ou n’avoir pas été configurés pour les divers URI d’objet Imprimante (par exemple, 'tls' ou 'aucun').

- L’attribut "authentification-d'uri-acceptée" d’objet Imprimante identifie les mécanismes d’authentification qui peuvent avoir ou n’avoir pas été configurés pour les divers URI d’objet Imprimante (par exemple, 'abrégé' ou 'aucun').

- Chaque objet Tâche est identifié par un URI de tâche. L’attribut "uri-de-tâche" d’une tâche contient l’URI.

- Chaque objet Tâche est aussi identifié par l’ID de tâche qui est un entier positif de 32 bits. L’attribut "id-de-tâche" de la tâche contient l’ID de tâche. L’ID de tâche n’est unique que dans le contexte de l’objet imprimante qui a créé l’objet Tâche.

- Chaque objet Tâche a un attribut "tâche-d’uri-d’imprimante" qui contient l’URI de l’objet imprimante utilisé pour créer l’objet Tâche. Cet attribut est utilisé pour déterminer l’objet imprimante qui a créé un objet Tâche lorsque seul l’URI pour l’objet Tâche est donné. Ce lien est nécessaire pour déterminer les langages, les ensembles de caractères (charset), et les opérations qui sont prises en charge sur cette tâche (les bases d’une telle prise en charge viennent de l’objet Imprimante créateur).

- Chaque objet Imprimante a un nom (qui n’est pas nécessairement unique). L’administrateur choisit et fixe ce nom par un mécanisme qui sort du domaine d’application du présent document IPP/1.1. L’attribut "nom-d’imprimante" de l’objet Imprimante contient le nom.

- Chaque objet Tâche a un nom (qui n’est pas nécessairement unique). Le client fournit facultativement ce nom dans la demande de création. Si le client ne fournit pas ce nom, l’objet imprimante génère un nom pour l’objet Tâche. L’attribut "nom-de-tâche" de l’objet Tâche contient le nom.

3 Opérations IPP

Les objets IPP prennent en charge des opérations. Une opération consiste en une demande et une réponse. Lorsqu’un client communique avec un objet IPP, le client produit une demande d’opération à l’URI de cet objet. Les demandes et réponses d’opération possèdent des paramètres qui identifient l’opération. Les opérations ont aussi des attributs qui affectent les caractéristiques d’heure de déroulement de l’opération (la cible visée, les informations de localisation, etc.). Ces attributs spécifiques d’opération sont appelés attributs d’opération (par opposition aux attributs d’objet tels que les attributs d’objet Imprimante ou d’objet Tâche). Chaque demande emporte avec elle tous les attributs d’opération, attribut d’objets, et/ou données documentaires nécessaires pour effectuer l’opération. Chaque demande exige une réponse de la part de l’objet. Chaque réponse indique la réussite ou l’échec de l’opération avec un code d’état comme paramètre de réponse. La réponse contient tous les attributs d’opération, attribut d’objets, et/ou messages d’état générés durant l’exécution de la demande d’opération.

La présente section décrit la sémantique des opérations d’IPP, demandes et réponses, en termes de paramètres, attributs, et autres données associées à chaque opération.

Obtenir-les-attributs-d’imprimante (Get-printer-attributes) (paragraphe 3.2.5)

Les opérations de tâche Document-d’envoi et URI-d’envoi servent à ajouter un nouveau document à un objet Tâche multi-document existant créé en utilisant l’opération Créer-une-tâche.

3.1 Sémantique commune

Toutes les opérations d’IPP requièrent des paramètres et attributs d’opération communs. Ces éléments communs et leurs caractéristiques sémantiques sont définies et décrites plus en détail dans les paragraphes suivants.

Le document "Codage et Transport" [RFC2910] définit des règles particulières pour le codage de ces paramètres. Tous les autres éléments d’opération sont représentés à l’aide de règles de codage plus générales pour les attributs et groupes d’attributs.

Chaque demande d’opération IPP inclut une valeur "id-d’opération" qui l’identifie. Les valeurs valides sont définies au paragraphe sur l’attribut d‘imprimante "opérations-acceptées" (voir au paragraphe 4.4.15). Le client spécifie quelle opération est demandée en fournissant la valeur correcte de "id-d’opération".

De plus, chaque invocation d’une opération est identifiée par une valeur de "id-de-demande". Pour chaque demande, le client choisit l’"id-de-demande" qui DOIT être un entier (qui peut être unique selon les exigences du client) dans la gamme de 1 à 2**31 - 1 (inclus). Cet "id-de-demande" permet aux clients de gérer plusieurs demandes en même temps. L’objet IPP récepteur copie tous les 32 bits de l’attribut "id-de-demande" fourni par le client dans la réponse, de sorte que le client puisse faire correspondre la réponse avec la demande en instance adéquate, même si l’"id-de-demande" est hors gamme. Si la demande est achevée avant la réception de l’"id-de-demande" complet, l’objet IPP rejette la demande et retourne une réponse avec un "id-de-demande" de 0.

Note : Dans certains cas, le protocole de transport sous-jacent à IPP pourrait être un protocole orienté connexion qui rendrait impossible que le client reçoive des réponses dans tout autre ordre que celui dans lequel les demandes correspondantes ont été envoyées. Dans de tels cas, l’attribut "id-de-demande" ne serait pas essentiel pour un fonctionnement correct du protocole. Cependant, dans d’autres transpositions, les réponses d’opération peuvent revenir dans n’importe quel ordre. Dans ces cas, l’"id-de-demande" serait essentiel.

Les demandes et réponses d’opération sont toutes deux composées de groupes d’attributs et/ou de données documentaires. Les groupes d’attributs sont :

- attributs d’opération : Ces attributs sont passés dans l’opération et affectent le comportement de l’objet IPP tandis qu’il traite la demande d’opération et peuvent affecter d’autres attributs ou groupes d’attributs. Certains attributs d’opération décrivent les données documentaires associées à la tâche d’impression et sont associés à de nouveaux objets Tâche, cependant la plupart des attributs d’opération ne persistent pas au-delà de la durée de vie de l’opération. La description de chaque attribut d’opération inclut des déclarations de conformité indiquant quels attributs d’opération il est EXIGÉ et FACULTATIF de prendre en charge pour un objet IPP et quels attributs un client DOIT fournir dans une demande et qu’un objet IPP DOIT fournir dans une réponse.

- attributs de gabarit de tâche : Ces attributs affectent le traitement d’une tâche. Un client fournit FACULTATIVEMENT les attributs de gabarit de tâche dans une demande de création, et l’objet récepteur DOIT être préparé à recevoir tous les attributs pris en charge. L’objet Tâche peut être interrogé plus tard pour trouver quels attributs de gabarit de tâche étaient demandés à l’origine dans la demande de création, et ces attributs sont retournés dans la réponse comme attributs d’objet de tâche. L’objet Imprimante peut être interrogé sur ses attributs de gabarit de tâche pour trouver quel type de capacités de traitement de tâche ont les comportements de traitement de tâche par défaut, bien que de tels attributs soient retournés dans la réponse comme attributs d’objet Imprimante. L’attribut d’opération "fidélité-d’attribut-ipp" affecte le traitement de tous les attributs de gabarit de tâche fournis par le client (voir aux paragraphes 3.2.1.2 et 15 une description complète de "fidélité-d’attribut-ipp" et de ses relation avec d’autres attributs).

- attributs d’objet de tâche : Ces attributs sont retournés dans une réponse à une opération d’interrogation dirigée vers un objet Tâche.

- attributs d’objet Imprimante : Ces attributs sont retournés en réponse à une opération d’interrogation dirigée vers un objet Imprimante.

- attributs non acceptés : Dans une demande de création, le client fournit un ensemble d’attributs d’opération et de gabarit de tâche. Si l’un de ces attributs ou de leurs valeurs n’est pas accepté par l’objet imprimante, l’objet imprimante retourne l’ensemble des attributs non acceptés dans la réponse. Les paragraphes 3.1.7, 3.2.1.2, et 15 donnent une description complète de la façon dont les attributs de gabarit de tâche fournis par le client dans une demande de création sont traités par l’objet imprimante et comment les attributs non acceptés sont retournés au client. A cause de l’extensibilité, tout objet IPP peut recevoir une demande qui contient des attributs ou valeurs nouveaux ou inconnus pour lesquels il n’y a pas de prise en charge. Dans de tels cas, l’objet IPP traite ce qu’il peut et retourne les attributs non pris en charge dans la réponse. Le groupe des attributs non acceptés est défini pour toutes les réponses d’opération pour le retour des attributs non acceptés que le client a fourni dans la demande.

Plus loin dans la présente section, chaque opération est définie formellement en identifiant les groupes d’attributs permis et attendus pour chaque demande et réponse. Le modèle identifie un ordre spécifique pour chaque groupe dans chaque demande et réponse, mais les attributs au sein de chaque groupe peuvent être dans n’importe quel ordre, sauf spécification contraire.

Les attributs au sein d’un groupe DOIVENT être uniques ; si un attribut survient avec le même nom plus d’une fois, le groupe est mal formé. Les clients NE DOIVENT PAS soumettre de telles demandes mal formées et les imprimantes NE DOIVENT PAS retourner de telles réponses mal formées. Si une demande mal formée est soumise à une imprimante, elle DOIT soit (1) rejeter la demande avec le code d’état 'erreur-client-mauvaise-demande' (voir au paragraphe 13.1.4.1) soit (2) traiter la demande normalement après avoir choisi une seule des instances de l’attribut, selon la mise en œuvre. Le choix de l’attribut lorsqu’il y a duplication dépend de la mise en œuvre. L’imprimante IPP NE DOIT PAS utiliser les valeurs de plus d’une instance d’attribut ainsi dupliqué.

Chaque définition d’attribut inclut le nom de l’attribut suivi par le nom de sa ou ses syntaxes d’attribut entre parenthèses. De plus, chaque attribut 'entier' est suivi par la gamme permise entre parenthèses, (m:n), pour les valeurs de cet attribut. Chaque attribut 'texte' ou 'nom' est suivi par la taille maximum en octets entre parenthèses, (taille), pour les valeurs de cet attribut. Pour des détails complémentaires sur la notation syntaxique des attributs, voir la description de ces syntaxes d'attribut au paragraphe 4.1.

Note : Les données documentaires incluses dans l’opération ne sont pas strictement un attribut, mais elles sont traitées comme un groupe particulier d’attributs pour les besoins de l’organisation. Les seules opérations qui prennent en charge la fourniture des données documentaires au sein d’une demande d’opération sont Impression-de-tâche et Document-d’envoi. Il n’y a pas de réponse d’opération qui inclut de données documentaires.

Certaines opérations sont EXIGÉES pour la prise en charge des objets IPP ; les autres sont FACULTATIVES (voir au paragraphe 5.2.2). Donc, avant d’utiliser une opération FACULTATIVE, un client DEVRAIT d’abord utiliser l’opération EXIGÉE Obtenir-les-attributs-d’imprimante pour interroger l’attribut "opérations-acceptées" de l’imprimante afin de déterminer quelles opérations FACULTATIVES d’imprimante et de tâche sont réellement prises en charge. Le client NE DEVRAIT PAS utiliser une opération FACULTATIVE qui n’est pas prise en charge. Lorsqu’un objet IPP reçoit une demande d’effectuer une opération qu’il ne prend pas en charge, il retourne le code d’état 'erreur-serveur-opération-non-acceptée' (voir au paragraphe 13.1.5.2). Un objet IPP est non-conforme s’il ne prend pas en charge une opération EXIGÉE.

Certains attributs d’imprimante et de tâche ont des valeurs qui sont des chaînes de texte et de noms destinés à être compris par l’homme plutôt que par la machine (voir les descriptions syntaxiques des attributs 'texte' et 'nom' au paragraphe 4.1). Les paragraphes qui suivent décrivent deux attributs d’opération particuliers appelés "charset-des-attributs" et "langage-naturel-des-attributs". Ces attributs font toujours partie du groupe d’attributs d’opération. Pour la plupart des groupes d’attributs, l’ordre des attributs au sein du groupe n’est pas important. Cependant, pour ces deux attributs au sein du groupe d’attributs d’opération, l’ordre est crucial. L’attribut "charset-des-attributs" DOIT être le premier attribut dans le groupe et l’attribut "langage-naturel-des-attributs" DOIT être le second attribut dans le groupe. En d’autres termes, ces attributs DOIVENT être fournis dans chaque demande et réponse IPP, ils DOIVENT venir en premier dans le groupe, et DOIVENT venir dans l’ordre spécifié. Pour les opérations de création de tâche, une mise en œuvre d’imprimante IPP sauvegarde ces deux attributs avec le nouvel objet Tâche comme attributs de description de tâche. Pour abréger ce document, ces descriptions d’attribut d’opération ne seront pas répétées avec chaque demande et réponse d’opération mais auront une référence au présent paragraphe.

Le client DOIT fournir et l’objet imprimante DOIT prendre en charge les attributs d’opération EXIGÉS suivants dans chaque demande d’opération IPP/1.1 :

Cet attribut d’opération identifie le charset (ensemble des caractères codés et méthode de codage) utilisé par tout attribut 'texte' et 'nom' que le client fournit dans sa demande. Il identifie aussi le charset que l’objet imprimante DOIT utiliser (s’il le prend en charge) pour tous les attributs 'texte' et 'nom' et les messages d’état que l’objet imprimante retourne dans la réponse à cette demande. Voir aux paragraphes 4.1.1 et 4.1.2 la définition de la syntaxe des attributs 'texte' et 'nom'.

Tous les clients et objets IPP DOIVENT prendre en charge le charset 'utf-8' [RFC2279] et PEUVENT prendre en charge des charsets supplémentaires pourvu qu’ils soient enregistrés auprès de l’IANA [IANA-CS]. Si l’objet imprimante ne prend pas en charge la valeur de charset fournie par le client, l’objet imprimante DOIT rejeter la demande, régler le "charset-des-attributs" à 'utf-8' dans la réponse, et retourner le code d’état 'erreur-client-charset-non-accepté' et tous attributs 'texte' ou 'nom' en utilisant le charset 'utf-8'. L’imprimante PEUT NE PAS retourner d’attribut dans le groupe attributs non acceptés (voir aux paragraphes 3.1.7 et 3.2.1.2). L’objet Imprimante DOIT indiquer le ou les charsets pris en charge comme les valeurs de l’attribut d’imprimante "charset-accepté" (voir au paragraphe 4.4.18), de sorte que le client puisse déterminer par interrogation quel ou quels charsets sont pris en charge.

Note aux concepteurs de mises en œuvre de client : Dans la mesure où il est seulement demandé aux objets IPP de prendre en charge le charset 'utf-8', afin de maximiser l’interopérabilité avec les mises en œuvre multiples d’objet IPP, un client peut vouloir fournir 'utf-8' dans l’attribut d’opération "charset-des-attributs", même si le client ne fait que passer et est capable de présenter un charset plus simple, tel qu’US-ASCII [ASCII] ou ISO-8859-1 [ISO8859-1]. Le client devra alors filtrer (ou convertir le charset) les caractères retournés dans la réponse qu’il ne peut pas présenter à son utilisateur. D’un autre côté, si le client et les objets IPP prennent aussi tous deux en charge un même charset différent de utf-8, le client peut vouloir utiliser ce charset afin d’éviter une conversion de charset ou une perte de données.

Voir la description de la syntaxe d’attribut 'charset' au paragraphe 4.1.7 pour la syntaxe et l’interprétation sémantique des valeurs de cet attribut et des exemples de valeurs.

Cet attribut d’opération identifie le langage naturel utilisé par tous les attributs 'texte' et 'nom' que le client fournit dans cette demande. Cet attribut identifie aussi le langage naturel que l’objet imprimante DEVRAIT utiliser pour tous les attributs 'texte' et 'nom' et messages d’état que l’objet imprimante retourne dans la réponse à cette demande. Voir la description de la syntaxe de l’attribut 'langageNaturel' au paragraphe 4.1.8 pour la syntaxe et l’interprétation sémantique des valeurs de cet attribut et des exemples de valeurs.

Il n’y a pas de langage naturel EXIGÉ dont la prise en charge soit obligatoire pour l’objet imprimante. Cependant, l’attribut "langage-naturel-généré-pris-en-charge" de l’objet imprimante identifie les langages naturels pris en charge par l’objet imprimante et tous objets Tâche qu’il contient pour toutes les chaînes de texte générées par l’objet IPP. Un client PEUT interroger cet attribut pour déterminer quel ou quels langage naturels sont pris en charge pour les messages générés.

Pour tout attribut pour lequel l’objet imprimante génère du texte, c’est-à-dire, pour "message-d’état-de-tâche", "message-d’état-d’imprimante", et les messages d’état (voir au paragraphe 3.1.6), l’objet imprimante DOIT être capable de générer ces chaînes de texte dans tous les langages naturels pris en charge. Si le client demande un langage naturel non accepté, l’objet imprimante DOIT retourner les messages générés dans le langage naturel de configuration de l’imprimante comme spécifié par l’attribut "langage-naturel-configuré" de l’imprimante" (voir au paragraphe 4.4.19).

Pour les autres attributs 'texte' et 'nom' fournis par le client, le système d’authentification, l’opérateur, l’administrateur de système, ou le fabricant (c’est-à-dire, pour "nom-d’utilisateur-d’origine-de-tâche", "nom-d’imprimante" (nom), "localisation-d’imprimante" (texte), "info-d’imprimante" (texte), et "modèle-d’imprimante" (texte)), il est seulement demandé à l’objet imprimante de prendre en charge le langage naturel configuré de l’imprimante identifié par l’attribut "langage-naturel-configuré" de l’objet imprimante, bien que la prise en charge de langages naturels supplémentaires soit permise pour ces attributs.

Pour tout attribut 'texte' ou 'nom' de la demande, qui est dans un langage naturel différent de la valeur fournie dans l’attribut d’opération "langage-naturel-des-attributs", le client DOIT utiliser le mécanisme Outrepasser le langage naturel (voir aux paragraphes 4.1.1.2 et 4.1.2.2) pour chacune des valeurs d’attribut fournies. Le client PEUT utiliser de façon redondante le mécanisme Outrepasser le langage naturel, c’est-à-dire, l’utiliser même lorsque la valeur est dans le même langage naturel que la valeur fournie dans l’attribut d’opération "langage-naturel-des-attributs" de la demande.

L’objet IPP DOIT accepter tout langage naturel et tout Outrepasser le langage naturel, que l’objet IPP prenne en charge ce langage naturel ou non (et indépendamment de la valeur de l’attribut d’opération "fidélité-d’attribut-ipp"). Cela signifie que l’objet IPP accepte toutes les valeurs fournies par le client sans considérer ce que sont les valeurs dans l’attribut "langage-naturel-généré-pris-en-charge" de l’objet imprimante. Cet attribut "langage-naturel-généré-pris-en-charge" ne s’applique qu’aux messages générés, et non aux messages fournis par le client. L’objet IPP DOIT se souvenir du langage naturel pour tous les attributs fournis par le client, et lorsqu’il retourne ces attributs en réponse à une interrogation, l’objet IPP DOIT indiquer ce langage naturel.

Chaque valeur dont le type de syntaxe d’attribut est 'texte' ou 'nom' (voir aux paragraphes 4.1.1 et 4.1.2) a un langage-naturel associé.

Le présent document ne spécifie pas comment cette association est emmagasinée dans un objet Imprimante ou Tâche. Lorsqu’une telle valeur est codée dans une demande ou réponse, le langage naturel est implicite ou explicite :

- Dans le cas implicite, la valeur contient seulement la valeur texte/nom, et le langage est spécifié par l’attribut d’opération "langage-naturel-des-attributs" dans la demande ou réponse (voir aux paragraphes 4.1.1.1 texteSansLangage et 4.1.2.1 nomSansLangage).

- Dans le cas explicite (connu aussi sous le nom de cas Outrepasser le langage-naturel), la valeur contient à la fois le langage et la valeur texte/nom (voir aux paragraphes 4.1.1.2 texteAvecLangage et 4.1.2.2 nomAvecLangage).

Par exemple, l’attribut "nom-de-tâche" PEUT être fourni par le client dans une demande de création. La valeur texte pour cet attribut sera dans le langage naturel identifié par l’attribut "langage-naturel-d’attribut", ou s’il est différent, tel qu’identifié par le mécanisme Outrepasser le langage naturel. Si elle est fournie, l’objet IPP utilisera la valeur de l’attribut "nom-de-tâche" pour remplir l’attribut "nom-de-tâche" de l’objet Tâche. Chaque fois qu’un client interroge l’attribut "nom-de-tâche" d’un objet Tâche , l’objet IPP retourne l’attribut tel que mémorisé et utilise le mécanisme Outrepasser le langage naturel pour spécifier le langage naturel, s’il est différent de celui rapporté dans l’attribut d’opération "langage-naturel-des-attributs" de la réponse. L’objet IPP PEUT utiliser le mécanisme Outrepasser le langage naturel de façon redondante, c’est-à-dire, l’utiliser même lorsque la valeur est dans le même langage naturel que la valeur fournie dans l’attribut d’opération "langage-naturel-des-attributs" de la réponse.

Un objet IPP NE DOIT PAS rejeter une demande sur la base d’un langage naturel fourni dans un attribut d’opération "langage-naturel-des-attributs" ou dans tout attribut qui utilise Outrepasser le langage naturel.

Les clients NE DEVRAIENT PAS fournir des attributs 'texte' ou 'nom' qui utilisent une combinaison illégale de langage naturel et de charset. Par exemple, supposons un objet Imprimante qui prend en charge les charsets 'utf-8', 'iso-8859-1', et 'iso-8859-7'. Supposons aussi qu’il prenne en charge les langages naturels 'en' (anglais), 'fr' (français), et 'el' (grec). Bien que l’objet imprimante prenne en charge le charset 'iso-8859-1' et le langage naturel 'el', il ne prend probablement pas en charge la combinaison des chaînes de texte grecques utilisant le charset 'iso-8859-1'. L’objet Imprimante traite cette incompatibilité apparente différemment selon le contexte dans lequel il survient :

- Dans une demande de création : si le client fournit un attribut texte ou nom (par exemple, l’attribut d’opération "nom-de-tâche") qui utilise une combinaison apparemment incompatible, c’est un choix du client qui n’affecte pas l’objet imprimante ou son fonctionnement correct. Donc, l’objet imprimante accepte simplement la valeur fournie par le client, la mémorise avec l’objet Tâche, et répond avec la même combinaison chaque fois que le client (ou tout client) interroge pour cet attribut.

- Dans une opération de type interrogation, telle que Obtenir-les-attributs-d’imprimante : si le client demande une combinaison apparemment incompatible, l’objet imprimante répond (comme décrit au paragraphe 3.1.4.2) en utilisant le langage naturel configuré dans l’imprimante plutôt que le langage naturel demandé par le client.

Dans les deux cas, l’objet imprimante ne rejette pas la demande à cause de l’incompatibilité apparente. La combinaison potentiellement incompatible de charset et de langage naturel peut survenir soit au niveau de fonctionnement global soit au niveau de Outrepasser le langage naturel attribut par attribut. De plus, dans la mesure ou la réponse inclut toujours des informations explicites de charset et de langage naturel, il n’y a jamais de question ou d’ambiguïté sur la façon dont le client interprète la réponse.

L’objet Imprimante DOIT fournir et le client DOIT prendre en charge les attributs d’opération EXIGÉS suivants dans chaque réponse d’opération IPP/1.1 :

Cet attribut d’opération identifie le charset utilisé par tout attribut 'texte' et 'nom' que l’objet imprimante retourne dans cette réponse. La valeur dans cette réponse DOIT être la même valeur que dans l’attribut d’opération "charset-des-attributs" fourni par le client dans la demande. Si ce n’est pas possible (c’est-à-dire, si le charset demandé n’est pas pris en charge), la demande devrait être rejetée. Voir ci-dessus le "charset-des-attributs" décrit au paragraphe 3.1.4.1.

Si l’objet imprimante prend en charge plus que le simple charset 'utf-8', l’objet imprimante DOIT être capable de convertir le code entre chacun des charsets pris en charge sur la base la plus fidèle possible afin de retourner les attributs 'texte' et 'nom' dans le charset demandé par le client. Cependant, certaines pertes d’information PEUVENT survenir durant la conversion de charset selon les charsets impliqués. Par exemple, l’objet imprimante peut convertir d’UTF-8 'a' en US-ASCII 'a' (sans perte d’information), de LETTRE MAJUSCULE ISO Latin 1 A ACCENT AIGU à l’US-ASCII 'A' (en perdant l’accent), ou d’un caractère japonais Kanji en UTF-8 à une indication de caractère d’erreur en ISO Latin 1 tel que '?', en équivalent de code décimal, ou à l’absence d’un caractère, selon la mise en œuvre.

La question de savoir si une mise en œuvre qui prend en charge plus d’un charset mémorise les données dans le charset fourni par le client ou convertit le code en un des autres charsets pris en charge dépend de la mise en œuvre. La stratégie devrait essayer de minimiser les pertes d’information durant la conversion de code. Sur chaque réponse, une telle mise en œuvre convertit de son charset interne à celui demandé.

Cet attribut d’opération identifie le langage naturel utilisé par tout attribut 'texte' et 'nom' que l’objet IPP retourne dans cette réponse. A la différence de l’attribut d’opération "charset-des-attributs", l’objet IPP PEUT NE PAS retourner la même valeur que celle fournie par le client dans la demande. L’objet IPP PEUT retourner le langage naturel de l’objet Tâche ou le langage naturel configuré de l’imprimante tel qu’identifié par l’attribut "langage-naturel-configuré" de l’objet imprimante, plutôt que le langage naturel fourni par le client. Pour tout attribut 'texte' ou 'nom' ou message d’état dans la réponse qui est dans un langage naturel différent de la valeur retournée dans l’attribut d’opération "langage-naturel-des-attributs", l’objet IPP DOIT utiliser le mécanisme Outrepasser le langage naturel (voir aux paragraphes 4.1.1.2 et 4.1.2.2) sur chaque valeur d’attribut retourné. L’objet IPP PEUT utiliser le mécanisme Outrepasser le langage naturel de façon redondante, c’est-à-dire, l’utiliser même lorsque la valeur est dans le même langage naturel que la valeur fournie dans l’attribut d’opération "langage-naturel-des-attributs" de la réponse.

Toutes les opérations d’IPP sont dirigées vers des objets IPP. Pour les opérations d’imprimante, l’opération est toujours dirigée vers un objet Imprimante en utilisant un de ses URI (c’est-à-dire, une des valeurs dans l’attribut "uri-d’imprimante-acceptés" de l’objet imprimante). Même si l’objet imprimante prend en charge plus d’un URI, le client ne fournit qu’un URI comme cible de l’opération. Le client identifie l’objet cible en fournissant l’URI correct dans l’attribut d’opération "uri-d’imprimante (uri)".

- L’objet Tâche lui-même en utilisant l’URI d’objet Tâche. Dans ce cas, le client identifie l’objet cible en fournissant l’URI correct dans l’attribut d’opération "uri-de-tâche (uri)".

- L’objet Imprimante qui a créé l’objet Tâche en utilisant à la fois l’URI d’objets imprimante et l’ID de tâche des objets Tâche. Dans la mesure où l’objet imprimante qui a créé l’objet Tâche a généré l’ID de tâche, il DOIT être capable d’associer correctement l’ID de tâche fourni par le client avec l’objet Tâche correct. Le client fournit l’URI de l’objet imprimante dans l’attribut d’opération "uri-d’imprimante (uri)" et l’ID de tâche de l’objet Tâche dans l’attribut d’opération "id-de-tâche (entier(1:MAX))".

Si l’opération est dirigée directement vers l’objet Tâche en utilisant l’URI de l’objet Tâche, le client NE DOIT PAS inclure l’attribut d’opération "id-de-tâche" redondant.

Les attributs de cible d’opération sont des attributs d’opération EXIGÉS qui DOIVENT être inclus dans chaque demande d’opération. Comme les attributs charset et langage naturel (voir au paragraphe 3.1.4), les attributs de cible d’opération sont des attributs d’opération spécialement ordonnés. Dans tous les cas, les attributs de cible d’opération suivent immédiatement les attributs "charset-des-attributs" et "langage-naturel-des-attributs" au sein du groupe des attributs d’opération, cependant les règles d’ordre spécifiques sont :

- Dans le cas où il n’y a qu’un seul attribut cible d’opération (c’est-à-dire, soit seulement l’attribut "uri-d’imprimante" soit seulement l’attribut "uri-de-tâche"), cet attribut DOIT être le troisième attribut dans le groupe des attributs d’opération.

- Dans le cas où les opérations de tâche utilisent deux attributs cible d’opération (c’est-à-dire, les attributs "uri-d’imprimante" et "id-de-tâche"), l’attribut "uri-d’imprimante" DOIT être le troisième attribut et l’attribut "id-de-tâche" DOIT être le quatrième attribut.

Dans tous les cas, les URI cibles contenus dans le corps des demandes et réponses d’opération IPP doivent être en format absolu plutôt qu’en format relatif (un URL relatif identifie une ressource dans la perspective d’un serveur HTTP, mais n’inclut pas de schéma, hôte ou port).

Les règles suivantes s’appliquent aux utilisateurs de numéros de port dans les URI qui identifient les objets IPP :

1. Si le schéma d’URI permet que le numéro de port soit explicitement inclus dans la chaîne d’URI, et qu’un numéro de port est spécifié dans l’URI, ce numéro de port DOIT alors être utilisé par le client pour contacter l’objet IPP.

2. Si le schéma d’URI permet que le numéro de port soit explicitement inclus dans la chaîne d’URI, et qu’aucun numéro de port n’est spécifié dans l’URI, le numéro de port par défaut impliqué par ce schéma d’URI DOIT être alors utilisé par le client pour contacter l’objet IPP.

3. Si le schéma d’URI ne permet pas que le numéro de port soit inclus dans la chaîne d’URI, le numéro de port par défaut impliqué par cet URI DOIT être utilisé par le client pour contacter l’objet IPP.

Note : Le document IPP "Codage et Transport" [RFC2910] donne une transposition de IPP sur HTTP/1.1 [RFC2616] et définit un nouveau numéro de port par défaut pour utiliser IPP sur HTTP/1.1.

Toute réponse d’opération inclut un paramètre "code-d’état" EXIGÉ et un attribut d’opération FACULTATIF "message-d’état", et un attribut d’opération FACULTATIF "message-d’état-détaillé". La réponse URI-d’impression et URI-d’envoi PEUT inclure un attribut d’opération FACULTATIF "erreur-d’accès-au-document".

Le paramètre EXIGÉ "code-d’état" donne des informations sur le traitement d’une demande.

Le code d’état est destiné à une utilisation par un automate. Une mise en œuvre de client d’IPP DEVRAIT convertir les valeurs de code d’état en tout message localisé qui a une signification sémantique pour l’utilisateur final.

La valeur "code-d’état" est une valeur numérique qui a une signification sémantique. La syntaxe de "code-d’état" est similaire à "énumération de type2" (voir au paragraphe 4.1 sur la "Syntaxe des attributs") excepté que la gamme de valeurs va de 0x0000 à 0x7FFF. La section 13 décrit les codes d’état, alloue les valeurs numériques, et suggère un message d’état correspondant pour chaque code d’état à utiliser par le client lorsque le langage naturel de l’utilisateur est l’anglais.

Si l’imprimante effectue une opération sans erreur et ne rencontrant pas de problème, elle DOIT retourner le code d’état 'réussite-ok' dans la réponse. Voir la section 13.

Si le client fournit des valeurs non acceptées pour les paramètres ou attributs d’opération suivants, l’objet imprimante DOIT rejeter l’opération, PEUT NE PAS retourner la valeur d’attributs non acceptés dans le groupe des attributs non acceptés, et DOIT retourner le code d’état indiqué :

Si le client fournit des valeurs non acceptées pour d’autres attributs, ou des attributs non acceptés, l’imprimante retourne le code d’état défini au paragraphe 3.1.7 sur les attributs non acceptés.

L’attribut d’opération FACULTATIF "message-d’état" fournit une courte description textuelle de l’état de l’opération. La syntaxe de l’attribut "message-d’état" est "texte(255)", et donc la longueur maximum est de 255 octets (voir au paragraphe 4.1.1). Le message d’état est destiné à l’utilisateur final humain. Si une réponse inclut un attribut "message-d’état", un client IPP PEUT NE PAS examiner ou afficher les messages, cependant il DEVRAIT le faire d’une façon spécifique de la mise en œuvre. Le "message-d’état" est particulièrement utile dans la dernière version d’un objet Imprimante à retourner comme informations supplémentaires destinées à l’utilisateur humain qui accompagnent un code d’état alors qu’une version de client plus ancienne pourrait ne pas comprendre.

Si l’objet imprimante prend en charge l’attribut d’opération message-d’état", l’objet imprimante DOIT être capable de générer ce message dans tous les langages naturels identifiés par l’attribut "langage-naturel-généré-pris-en-charge" de l’objet imprimante (voir l’attribut d’opération "langage-naturel-des-attributs" spécifié au paragraphe 3.1.4.1. La section 13 suggère le texte du message d’état retourné par l’imprimante à utiliser avec le langage naturel anglais.

Comme décrit au paragraphe 3.1.4.1 pour tout attribut 'texte' retourné, s’il y a le choix pour générer ce message, l’objet imprimante utilise le langage naturel indiqué par la valeur de "langage-naturel-des-attributs" dans la demande du client si elle est prise en charge, autrement l’objet imprimante utilise la valeur dans le propre attribut "langage-naturel-configuré" de l’objet imprimante.

Si l’objet imprimante prend en charge l’attribut d’opération "message-d’état", il DEVRAIT utiliser le charset EXIGÉ 'utf-8' pour retourner un message d’état pour les codes d’état d’erreur suivants (voir au paragraphe 13) :

'erreur-client-mauvaise-demande', 'erreur-client-charset-non-accepté', 'erreur-serveur-erreur-interne', 'erreur-serveur-opération-non-acceptée', et 'erreur-serveur-version-non-acceptée'. Dans ce cas, il DOIT régler la valeur de l’attribut d’opération "charset-des-attributs" à 'utf-8' dans la réponse d’erreur.

L’attribut d’opération FACULTATIF "message-d’état-détaillé" donne des informations supplémentaires plus détaillées techniques et spécifiques de la mise en œuvre sur l’opération. La syntaxe de l’attribut "message-d’état-détaillé" est "texte(MAX)", et sa longueur maximum est donc 1023 octets (voir au paragraphe 4.1.1). Si les objets Imprimante prennent en charge l’attribut d’opération "message-d’état-détaillé", l’imprimante PEUT NE PAS localiser le message, dans la mesure où il est destiné à être utilisé par l’administrateur de système ou d’autres personnes expérimentées techniquement. La localisation peut brouiller la signification technique de tels messages. Les clients NE DOIVENT PAS tenter d’analyser la valeur de cet attribut. Voir l’attribut d’opération "erreur-d’accès-au-document" (paragraphe 3.1.6.4) pour les erreurs supplémentaires qu’un programme peut traiter.

Cet attribut d’opération FACULTATIF fournit des informations supplémentaires sur toutes erreurs d’accès documentaires rencontrées par l’imprimante avant qu’elle retourne une réponse à l’opération URI-d’impression (paragraphe 3.3.2) ou URI-d’envoi (paragraphe 3.3.1). Pour les erreurs dans le protocole identifiées par le schéma d’URI dans l’attribut d’opération "uri-de-document", tels que 'http:' ou 'ftp:', le code d’erreur est retourné entre parenthèses, suivi par l’URI. Par exemple :

La plupart des protocoles Internet utilisent les codes d’erreur décimaux (à la différence d’IPP), de sorte que la représentation du code d’erreur ASCII est en décimal.

Le groupe des attributs non acceptés contient les attributs qui ne sont pas pris en charge par l’opération. Ce groupe est principalement pour les opérations de création de tâche, mais toutes les opérations peuvent retourner ce groupe.

Un objet Imprimante DOIT inclure un groupe attributs non acceptés dans une réponse si le code d’état est un des suivants : 'réussite-ok-mais-attributs-substitués-ou-ignorés', 'réussite-ok-mais-conflit-d’attributs', 'erreur-client-attributs-ou-valeurs-non-acceptés' ou 'erreur-client-conflit-d’attributs'.

Si le code d’état est un des quatre spécifiés au paragraphe précédent, le groupe des attributs non acceptés DOIT contenir tous ces attributs et seulement ces attributs qui sont :

a. un attribut de gabarit d’opération ou de tâche fourni dans la demande, et

b. non acceptés par l’imprimante. Voir ci-dessous des précisions sur les trois catégories d’attributs "non-acceptés".

Si le code d’état est un de ceux du tableau du paragraphe 3.1.6.1, le groupe des attributs non acceptés PEUT NE PAS contenir le paramètre ou attribut non accepté indiqué dans ce tableau.

Si l’objet imprimante ne retourne aucun attribut non accepté dans la réponse, l’objet imprimante DEVRAIT omettre le groupe 2 plutôt que d’envoyer un groupe vide. Cependant, un client DOIT être capable d’accepter un groupe vide.

1. L’objet Imprimante ne prend pas en charge l’attribut fourni (quelle que soit la syntaxe ou la valeur de l’attribut).

2. L’objet Imprimante prend en charge l’attribut, mais ne prend pas en charge certaines ou toutes les syntaxes ou valeurs particulières de l’attribut fourni par le client (c’est-à-dire, l’objet imprimante n’a pas ces syntaxes ou valeurs d’attribut dans son attribut "xxx-pris-en-charge" correspondant).

3. L’objet Imprimante prend en charge les attributs et valeurs fournis, mais les valeurs particulières sont en conflit avec une autre, parce qu’elles violent une contrainte, telle que n’être pas capable d’agrafer les transparents.

Dans le cas d’un nom d’attribut non accepté, l’objet imprimante retourne l’attribut fourni par le client avec une valeur substituée de 'non-acceptée'. Le type de syntaxe de cette valeur est "hors-bande" et son codage est défini par les règles spéciales pour les valeurs "hors-bande" dans le document "Codage et Transport" [RFC2910]. Sa valeur indique la non prise en charge de l’attribut lui-même (voir le début du paragraphe 4.1).

Dans le cas d’un attribut pris en charge avec une ou plusieurs syntaxes ou valeurs d’attribut non acceptées, l’objet imprimante retourne simplement l’attribut fourni par le client avec les syntaxes ou valeurs d’attribut non acceptées telles que fournies par le client. Ceci indique la prise en charge de l’attribut, mais la non prise en charge de cette syntaxe ou valeur d’attribut particulière. Si le client fournit un attribut multi-valeurs avec plus d’une valeur et si l’objet imprimante prend en charge l’attribut mais ne prend en charge qu’un sous-ensemble des syntaxes ou valeurs de l’attribut fourni par le client, l’objet imprimante DOIT retourner seulement les syntaxes ou valeurs d’attribut qu’il n’accepte pas.

Dans le cas de deux (ou plus) valeurs d’attribut prises en charge qui sont en conflit avec une autre (bien que chacune d’entre elles soit prise en charge indépendamment, les valeurs entrent en conflit lorsqu’elles sont demandées ensemble dans la même tâche), l’objet imprimante DOIT retourner toutes les valeurs qu’il ignore ou qu’il substitue pour résoudre le conflit, mais aucune des valeurs qu’il utilise encore. Le choix de la manière exacte de résoudre les conflits dépend de la mise en œuvre. Voir aux paragraphes 3.2.1.2 et 15. Un exemple figure dans le Guide de mise en œuvre [IPP-IIG].

Chaque demande et réponse d’opération porte avec elle un paramètre "numéro-de-version". Chaque valeur du "numéro-de-version" est de la forme "X.Y" où X est le numéro de version majeure et Y est le numéro de version mineure. En incluant un numéro de version dans la demande du client, cela permet au client d’identifier la version d’IPP qui l’intéresse, c’est-à-dire, la version dont les exigences de conformité du client peuvent être satisfaites selon l’imprimante.

Si l’objet IPP ne prend pas en charge ce numéro de version majeure fourni par le client, c’est-à-dire, si le champ de version majeure du paramètre "numéro-de-version" ne correspond à aucune des valeurs du "versions-ipp-prises-en-charge" de l’imprimante (voir au paragraphe 4.4.14), l’objet DOIT répondre par un code d’état de 'erreur-serveur-version-non-acceptée' avec le plus proche numéro de version pris en charge (voir au paragraphe 13.1.5.4). Si le numéro de version majeure est pris en charge, mais que le numéro de version mineure ne l’est pas, l’objet IPP DEVRAIT accepter et tenter d’effectuer la demande (ou rejeter la demande si l’opération n’est pas prise en charge), ou alors rejeter la demande et retourner le code d’état 'erreur-serveur-version-non-acceptée'. Dans tous les cas, l’objet IPP DOIT retourner le "numéro-de-version" qu’il prend en charge le plus proche du numéro de version fourni par le client dans la demande.

Il n’y a pas de négociation de version en soi. Cependant, si après réception d’un code d’état 'erreur-serveur-version-non-acceptée' d’un objet IPP, un client DEVRAIT ressayer avec un numéro de version différent. Un client PEUT aussi déterminer les versions prises en charge à partir d’un répertoire conforme à l’Appendice E (voir à la section 16) ou en interrogeant l'attribut "versions-ipp-prises-en-charge" de l’objet imprimante (voir au paragraphe 4.4.14) pour déterminer quelles versions sont prises en charge.

Une mise en œuvre d’objet IPP DOIT prendre en charge la version '1.1', c’est-à-dire, satisfaire aux exigences de conformité d’IPP/1.1 telles que spécifiées dans le présent document et dans la [RFC2910]. Il est recommandé que les mises en œuvre d’objet IPP acceptent toute demande ayant la version majeure '1' (ou rejettent la demande si l’opération n’est pas prise en charge).

Il n’y a qu’une seule notion de "numéro de version" qui recouvre à la fois le modèle IPP et les changements de protocole IPP. Et donc le numéro de version DOIT changer lors de l’introduction d’une nouvelle version du document Modèle et Sémantique (le présent document) ou une nouvelle version du document "Codage et Transport" [RFC2910].

Les changements du numéro de version majeure du document Modèle et Sémantique indiquent les modifications structurales ou syntaxiques qui rendraient impossible aux plus anciennes versions de clients IPP et d’objets imprimante d’analyser correctement et de traiter correctement les attributs, opérations et réponses nouveaux ou modifiés. Si le numéro de version majeure change, les numéros de version mineure sont mis à zéro. Par exemple, l’ajout de l’attribut EXIGÉ "fidélité-d’attribut-ipp" à la version '1.1' (s’il n’avait déjà fait partie de la version '1.0'), aurait exigé un changement du numéro de version majeure, car une imprimante IPP/1.0 n’aurait pas pu traiter une demande avec la sémantique correcte contenue dans l’attribut "fidélité-d’attribut-ipp" dont elle ne saurait rien. Les éléments qui peuvent affecter le changement du numéro de version majeure incluent tout changement du document Modèle et Sémantique (le présent document) ou du document "Codage et Transport" [RFC2910], tels que :

- ajout de groupes d’attributs d’opération EXIGÉS (de prise en charge pour un objet IPP),

Les changements de numéro de version mineure indiquent l’ajout de nouvelles caractéristiques, attributs et valeurs d’attribut qui peuvent n’être pas comprises par tous les objets IPP, mais qui peuvent être ignorés s’ils ne sont pas compris. Les éléments qui pourraient être affectés par le changement de numéro de version mineure incluent tout changement des objets et attributs modélisés hors codage et règles de transport [RFC2910] (excepté l’ajout de syntaxes d’attribut). Des exemples de tels changements sont :

- le groupage de toutes les extensions non incluses dans une version précédente en une nouvelle version,

- l’ajout d’attributs d’opération FACULTATIFS (de prise en charge pour un objet IPP) (c’est-à-dire, ces attributs qu’un objet IPP peut ignorer sans embrouiller les clients),

- l’ajout de groupes d’attributs d’opération FACULTATIFS (de prise en charge pour un objet IPP) (c’est-à-dire, ces attributs qu’un objet IPP peut ignorer sans embrouiller les clients),

- le changement des attributs de description de tâche ou des attributs de description d’imprimante de FACULTATIF à EXIGÉ ou vice versa,

Le codage du "numéro-de-version" NE DOIT PAS changer sur tout numéro de version (majeur ou mineur). Cette règle garantit que toutes les futures versions seront compatibles en amont avec toutes les versions précédentes (au moins pour vérifier le "numéro-de-version"). De plus, tout élément de protocole (attribut, code d’erreur, étiquette, etc.) qui n’est pas repris d’une version à la suivante est déconseillé de sorte qu’il ne puisse jamais être réutilisé avec la nouvelle sémantique.

Les mises en œuvre qui prennent en charge une certaine version PEUVENT NE PAS prendre en charge TOUTES les versions précédentes. Comme chaque nouvelle version est définie (au moyen de la publication d’un nouveau document de spécification IPP), cette version spécifiera quelles versions précédents DOIVENT et quelles versions DEVRAIENT être prises en charge dans les mises en œuvre conformes.

Pour "soumettre une tâche d’impression" et créer un nouvel objet Tâche, un client produit une demande de création. Une demande de création est l’une des trois demandes d’opération suivantes :

- La demande de Tâche-d’impression : Un client qui veut soumettre une tâche d’impression avec un seul document utilise l’opération Tâche-d’impression. L’opération permet au client de "pousser" les données documentaires à l’objet imprimante en incluant les données documentaires dans la demande elle-même.

- La demande d’URI-d’impression : Un client qui veut soumettre une tâche d’impression avec un seul document (où l’objet imprimante "tire" les données documentaires au lieu que le client "pousse" les données à l’objet imprimante) utilise l’opération URI-d’impression. Dans ce cas, le client inclut dans la demande seulement une référence d’URI avec les données documentaires (et non les données documentaires elles-mêmes).

- La demande Création-de-tâche : un client qui veut soumettre une tâche d’impression avec plusieurs documents utilise l’opération Création-de-tâche. Cette opération est suivie par un nombre arbitraire (un ou plus) d’opérations Document-d’envoi et/ou URI-d’envoi (chacune créant un autre document pour l’objet Tâche nouvellement créé). L’opération Document-d’envoi inclut les données documentaires dans la demande (le client "pousse" les données documentaires à l’imprimante), et l’opération URI-d’envoi joint seulement une référence d’URI aux données documentaires dans la demande (l’imprimante "tire" les données documentaires de la localisation référencée). La dernière demande Document-d’envoi ou URI-d’envoi pour un objet Tâche donné inclut un attribut d’opération "dernier-document" mis à 'vrai' qui indique que c’est la dernière demande.

Tout au long du présent document de modélisation, le terme "demande de création" est utilisé pour se référer à l’une de ces trois demandes d’opération.

Une opération Création-de-tâche suivie d’une seule opération Document-d’envoi est sémantiquement équivalente à une opération Tâche-d’impression, cependant, pour des raisons de performances, le client DEVRAIT utiliser l’opération Tâche-d’impression pour toutes les tâches d’un seul document. Ainsi, Tâche-d’impression est une opération EXIGÉE (toutes les mises en œuvre DOIVENT la prendre en charge) bien que Création-de-tâche soit une opération FACULTATIVE, et donc certaines mises en œuvre peuvent ne pas la prendre en charge.

L’heure de soumission de tâche est le moment dans le temps où un client produit une demande de création. L’état initial de chaque objet Tâche est l’état 'en instance', 'gardé-en-instance', ou 'traitement-en-cours' (voir au paragraphe 4.3.7). Lorsque l’objet imprimante commence à traiter la tâche d’impression, l’état de l’objet Tâche passe à 'traitement-en-cours'. Ceci est connu sous le nom d’heure de traitement de tâche. Il y a des vérifications de validation qui doivent être faites à l'heure de soumission de tâche et d’autres qui doivent être effectuées à l’heure du traitement de tâche.

A l’heure de soumission de tâche et à l’heure où une opération Tâche-de-validation est reçue, l’imprimante DOIT faire ce qui suit :

1. Traiter les attributs fournis par le client et accepter ou rejeter la demande,

2. Valider et prendre en charge la syntaxe du schéma de tout URI fourni par le client.

A l’heure de soumission de tâche, l’objet imprimante DOIT valider si les attributs, syntaxes d’attribut, et valeurs fournis sont pris en charge en les comparant aux attributs "xxx-pris-en-charge" de l’objet imprimante correspondants. Voir les détails au paragraphe 3.1.7. [IPP-IIG] présente les étapes suggérées pour qu’un objet IPP accepte ou rejette toute demande et des étapes supplémentaires pour les demandes de création de traitement.

A l'heure de soumission de tâche l’objet imprimante PEUT NE PAS effectuer la vérification de validation réservée à l'heure du traitement de tâche telle que :

2. Valider le contenu réel de tout URI fourni par le client (résoudre la référence et suivre le lien vers les données documentaires)

A l’heure de soumission de tâche, ces vérifications de validation d’heure de tâche supplémentaire de traitement sont assez inutiles, car elles nécessitent une réelle analyse grammaticale et l’interprétation des données documentaires, et il n’est pas garanti qu’elles soient pertinentes à 100 %, et elles DOIVENT être faites à nouveau à l’heure du traitement de la tâche. Ainsi, dans le cas d’un URI, vérifier la disponibilité à l’heure de soumission de tâche ne garantit pas la disponibilité à l’heure du traitement de la tâche. De plus, à l’heure du traitement de la tâche, l’objet imprimante peut découvrir une des conditions suivantes qui n’était pas détectable à l’heure de la soumission de tâche :

- référence d’URI plus valide (c’est-à-dire, le serveur hébergeant le document peut être éteint), ou

A l’heure de soumission de tâche, un objet Imprimante, particulièrement une imprimante sans dévidement, PEUT accepter des tâches pour lesquelles elle n’a pas assez d’espace. Dans une telle situation, un objet Imprimante PEUT arrêter de lire des données provenant d’un client pour une durée indéfinie. Un client DOIT être préparé à ce qu’une opération d’écriture le bloque pour une durée indéfinie (voir le paragraphe 5.1 sur la conformité du client).

Lorsqu’un objet Imprimante a trop peu d’espace pour commencer une nouvelle tâche, il PEUT rejeter une nouvelle demande de création. Dans ce cas, un objet Imprimante DOIT retourner une réponse (en réplique à la demande rejetée) avec un code d’état de 'erreur-serveur-occupé' (voir au paragraphe 14.1.5.8) et il PEUT clore la connexion avant de recevoir tous les octets de l’opération. Une imprimante DEVRAIT indiquer qu’elle est temporairement incapable d’accepter des tâches en mettant la valeur 'espace-de-dévidage-plein' dans son attribut "cause-d’état-d’imprimante" et en retirant la valeur lorsqu’elle peut accepter une autre tâche (voir au paragraphe 4.4.12).

En recevant un code d’état 'erreur-serveur-occupé' dans une réponse d’opération, un client DOIT être préparé à ce que l’objet imprimante close la connexion avant que le client ait envoyé toutes les données (spécialement pour l’opération Tâche-d’impression). Un client DOIT être préparé à continuer à soumettre une demande de création jusqu’à ce que l’objet imprimante IPP accepte la demande de création.

A l’heure du traitement de tâche, comme l’objet imprimante a déjà répondu par un code d’état de réussite dans la réponse à la demande de création, si l’objet imprimante détecte une erreur, l’objet imprimante est incapable d’informer l’utilisateur final de l’erreur par un code d’état d’opération. Dans ce cas, l’imprimante, selon l’erreur, peut régler l’attribut "état-de-tâche", "causes-d’état-de-tâche", ou "message-d’état-de-tâche" de l’objet tâche à la ou aux valeurs appropriées de sorte que des interrogations ultérieures puissent rapporter l’état de tâche correct.

Note : La notification asynchrone d’événements sort du domaine d’application du présent document IPP/1.1.

Toutes les opérations d’imprimante sont dirigées vers les objets imprimante. Un client DOIT toujours fournir l’attribut d’opération "uri-d’imprimante" afin d’identifier la cible correcte de l’opération.

Cette opération EXIGÉE permet à un client de soumettre une tâche d’impression avec un seul document et de fournir les données documentaires (plutôt que juste une référence aux données). Voir à la section 15 les étapes suggérées pour traiter les opérations de création et leurs attributs d’opération et de gabarit de tâche.

Les groupes d’attributs suivants sont fournis au titre de Demande de Tâche-d’impression :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" sont décrits au paragraphe 3.1.4.1. L’objet Imprimante DOIT copier ces valeurs dans les attributs de description de tâche correspondants, décrits dans les paragraphes 4.3.19 et 4.3.20.

Cible : l’attribut d’opération "uri-d’imprimante" (uri) qui est la cible de cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-de-l’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

"nom-de-tâche" (nom(MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. Il contient le nom de tâche fourni par le client. Si cet attribut est fourni par le client, sa valeur est utilisée pour l’attribut "nom-de-tâche" de l’objet Tâche nouvellement créé. Le client PEUT automatiquement inclure toute information qui aidera l’utilisateur final à distinguer ses tâches, telles que le nom du programme d’application avec les informations provenant du document, telles que le nom du document, le sujet du document, ou le nom du fichier source. Si cet attribut n’est pas fourni par le client, l’imprimante génère un nom à utiliser dans l’attribut "nom-de-tâche" de l’objet Tâche nouvellement créé (voir au paragraphe 4.3.5).

"fidélité-d’attribut-ipp" (booléen) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. La valeur 'vrai' indique qu’une totale fidélité aux attributs et valeurs de gabarit de tâche fournis par le client est nécessaire, autrement, l’objet imprimante DOIT rejeter la demande Tâche-d’impression. La valeur 'faux' indique qu’une tentative raisonnable d’impression de l’objet Tâche est acceptable et l’objet imprimante DOIT accepter la demande Tâche-d’impression. Si elle n’est pas fournie, l’objet imprimante suppose que la valeur est 'faux'. Tous les objets imprimante DOIVENT prendre en charge les deux types de traitement de tâche. Voir à la Section 15 une description complète de "fidélité-d’attribut-ipp" et ses relations avec les autres attributs, particulièrement l’attribut"outrepassement-pdl-pris-en-charge" de l’objet imprimante.

"nom-du-document" (nom(MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. Il contient le nom du document fournit par le client. Le nom du document PEUT être différent du nom de tâche. Normalement, le logiciel du client fournit automatiquement le nom du document au nom de l’utilisateur final en utilisant un nom de fichier ou un nom généré par l’application. Si cet attribut est fourni, sa valeur peut être utilisée d’une manière définie par chaque mise en œuvre. Par exemple, imprimé avec la tâche (feuille de début de tâche, ornements de page, etc.), utilisé par des outils de comptabilité ou de suivi de ressources, ou même mémorisé avec le document comme attribut de niveau document. IPP/1.1 ne prend pas en charge le concept d’attribut de niveau document.

"compression" (mot-clé type3) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut et l’attribut "compression-prise-en-charge" (voir au paragraphe 4.4.32). L’attribut d’opération "compression" fourni par le client identifie l’algorithme de compression utilisé sur les données documentaires. Il existe les cas suivants :

a) Si le client omet cet attribut, l’objet imprimante DOIT supposer que les données ne sont pas compressées (c’est-à-dire l’imprimante suit les règles ci-dessous comme si le client fournissait l’attribut "compression" avec une valeur de 'aucun').

b) Si le client fournit cet attribut, mais la valeur n’est pas prise en charge par l’objet imprimante, c’est-à-dire, la valeur n’est pas une des valeurs de l’attribut "compression-prise-en-charge" de l’objet Imprimante, celui-ci DOIT rejeter la demande, et retourner le code d’état 'erreur-client-compression-non-acceptée'. Voir au paragraphe 3.1.7 le retour des attributs et valeurs non acceptés.

c) Si le client fournit l’attribut et que l’objet imprimante prend en charge la valeur de l’attribut, l’objet imprimante utilise l’algorithme de décompression correspondant sur les données documentaires.

d) Si l’algorithme de décompression échoue avant que l’imprimante ne retourne une réponse d’opération, l’objet imprimante DOIT rejeter la demande et retourner le code d’état 'erreur-client-erreur-de-compression'.

e) Si l’algorithme de décompression échoue après que l’imprimante ait retourné une réponse d’opération, l’objet imprimante DOIT avorter la tâche et ajouter la valeur 'erreur-de-compression' à l’attribut "causes-d’état-de-tâche" de la tâche.

f) Si l’algorithme de décompression réussit, les données documentaires DOIVENT alors avoir le format spécifié par l’attribut "format-de-document" de la tâche, s’il est fourni (voir la définition de l’attribut d’opération "format-de-document" ci-dessous).

"format-de-document" (typeSupportMime) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. La valeur de cet attribut identifie le format des données documentaires fournies. Il existe les cas suivants :

a) Si le client ne fournit pas cet attribut, l’objet imprimante suppose que les données documentaires sont dans le format défini par l’attribut "format-de-document-par-défaut" de l’objet imprimante. (C’est-à-dire que l’imprimante suit les règles ci-dessous comme si l’attribut "format-de-document" fourni par le client avait une valeur égale à la valeur par défaut de l’imprimante).

b) Si le client fournit cet attribut, mais la valeur n’est pas prise en charge par l’objet imprimante, c’est-à-dire, la valeur n’est pas une des valeurs de l’attribut "format-de-document-pris-en-charge" de l’objet imprimante, celui-ci DOIT rejeter la demande et retourner le code d’état 'erreur-client-format-de-document-non-accepté'.

c) Si le client fournit cet attribut et que sa valeur est 'application/flux-d’octets' (c’est-à-dire qu’il est auto-détecté, voir au paragraphe 4.1.9.1), et si le format n’est pas un des formats-de-document que l’imprimante peut auto-détecter, et cette vérification survient avant que l’imprimante retourne une réponse d’opération, l’imprimante DOIT alors rejeter la demande et retourner le code d’état 'erreur-client-format-de-document-non-accepté'.

d) Si le client fournit cet attribut, et que la valeur est prise en charge par l’objet imprimante, l’imprimante est capable d’interpréter les données documentaires.

e) Si l’interprétation des données documentaires échoue avant que l’imprimante ne retourne une réponse d’opération, l’objet imprimante DOIT rejeter la demande et retourner le code d’état 'erreur-client-erreur-de-format-de-document'.

f) Si l’interprétation des données documentaires échoue après que l’imprimante ait retourné une réponse d’opération, l’objet imprimante DOIT avorter la tâche et ajouter la valeur 'erreur-de-format-de-document' à l’attribut "causes-d’état-de-tâche" de la tâche.

"langage-naturel-du-document" (langageNaturel) : Le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante prend FACULTATIVEMENT en charge cet attribut. Cet attribut spécifie le langage naturel du document pour les formats de document qui requièrent une spécification du langage naturel afin de donner une image non ambiguë du document. Il n’y a pas de valeurs particulières que l’objet imprimante doive prendre en charge.

Le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante prend FACULTATIVEMENT en charge cet attribut et l’attribut "k-octets-de-tâche-pris-en-charge" (voir au paragraphe 4.4.33). L’attribut d’opération "k-octets-de-tâche" fourni par le client identifie la taille totale du ou des documents en K octets soumis (voir au paragraphe 4.3.17.1 la sémantique complète). Si le client fournit l’attribut et que l’objet imprimante prend en charge cet attribut, la valeur de l’attribut est utilisée pour remplir l’attribut de description de tâche "k-octets-de-tâche" de l’objet Tâche. Pour cet attribut et les deux attributs suivants ("tâches-d’impression", et "feuilles-de-support-de-tâche"), si le client fournit l’attribut, mais que l’objet imprimante ne prend pas en charge l’attribut, l’objet imprimante ignore la valeur fournie par le client. Si le client fournit l’attribut et que l’imprimante le prend en charge, et si la valeur est dans la gamme de l’attribut "xxx-pris-en-charge" de l’objet Imprimante correspondant, l’objet imprimante DOIT utiliser la valeur pour remplir l’attribut "xxx" de l’objet Tâche . Si le client fournit l’attribut et que l’imprimante le prend en charge, mais que la valeur est en-dehors de la gamme de l’attribut "xxx-pris-en-charge" de l’objet Imprimante correspondant, l’objet imprimante DOIT copier l’attribut et sa valeur dans le groupe de réponse des attributs non acceptés, rejeter la demande, et retourner le code d’état 'erreur-client-attributs-ou-valeurs-non-pris-en-charge'. Si le client ne fournit pas l’attribut, l’objet imprimante PEUT choisir de remplir l’attribut de l’objet Tâche correspondant selon que l’objet imprimante prend en charge ou non l’attribut et est capable de calculer ou discerner la valeur correcte.

"tâches-d’impression" (entier(0:MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante prend FACULTATIVEMENT en charge cet attribut et l’attribut "tâches-d’impression-prises-en-charge" (voir au paragraphe 4.4.34). L’attribut d’opération "tâches-d’impression" fourni par le client identifie la taille totale en nombre d’impressions du ou des documents soumis (voir au paragraphe 4.3.17.2 la sémantique complète). Voir le dernier paragraphe sous "k-octets-de-tâche".

"feuilles-de-support-de-tâche" (entier(0:MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante prend FACULTATIVEMENT en charge cet attribut et l’attribut "feuilles-de-support-de-tâche-prises-en-charge" (voir au paragraphe 4.4.35). L’attribut d’opération "feuilles-de-support-de-tâche" identifie le nombre total de feuilles de support à produire pour cette tâche (voir au paragraphe 4.3.17.3 la sémantique complète). Voir le dernier paragraphe sous "k-octets-de-tâche".

Le client fournit FACULTATIVEMENT un ensemble d’attributs de gabarit de tâches comme défini au paragraphe 4.2. Si le client ne fournit aucun attribut de gabarit de tâche dans la demande, il DEVRAIT omettre le groupe 2 plutôt que d’envoyer un groupe vide. Cependant, un objet Imprimante DOIT être capable d’accepter un groupe vide.

En plus des paramètres OBLIGATOIRES exigés pour chaque demande d’opération, la plus simple demande de Tâche-d’impression comporte les attributs d’opération "charset-des-attributs" et "langage-naturel-des-attributs", l’attributs d’opération cible "uri-d’imprimante", le contenu du document et rien d’autre. Dans ce cas le plus simple, l’objet imprimante :

- mémorise un nom de tâche généré dans l’attribut "nom-de-tâche" dans le langage naturel et charset demandés (voir au paragraphe 3.1.4.1) (s’ils sont pris en charge, autrement en utilisant le langage naturel et charset par défaut de l’objet imprimante), et

- à l’heure du traitement de la tâche, utilise ses attributs de valeur par défaut correspondants pour les attributs de gabarit de tâche pris en charge qui n’étaient pas fournis par le client comme attributs IPP ou comme instructions incorporées dans les données documentaires.

L’objet Imprimante DOIT retourner au client les ensembles d’attributs suivants au titre de la réponse de Tâche-d’impression :

Message d’état : en plus du code d’état EXIGÉ retourné dans chaque réponse, la réponse inclut FACULTATIVEMENT un attribut d’opération "message-d’état" (texte(255)) et/ou "message-d’état-détaillé" (texte(MAX)) comme décrit aux paragraphes 13 et 3.1.6. Si le client fournit des attributs ou valeurs de gabarit de tâche non pris en charge ou contradictoires, l’objet imprimante DOIT rejeter ou accepter la demande de Tâche-d’impression selon que le client a fourni une valeur 'vrai' ou 'faux' pour l’attribut d’opération "fidélité-d’attribut-ipp". Voir dans le Guide de mise en œuvre [IPP-IIG] une description complète des étapes suggérées pour le traitement d’une demande de création.

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2.

Voir au paragraphe 3.1.7 les détails sur le retour des attributs non acceptés.

La valeur du "fidélité-d’attribut-ipp" fourni par le client n’affecte pas les attributs que l’objet imprimante retourne dans ce groupe. La valeur de "fidélité-d’attribut-ipp" n’affecte que l’acceptation ou le rejet de l’opération Tâche-d’impression. Si la tâche est acceptée, le client peut interroger la tâche en utilisant l’opération Obtenir-les-attributs-de-tâche en demandant les attributs non acceptés qui ont été retournés dans la réponse à création pour voir quels attributs ont été ignorés (non mémorisés sur l’objet Tâche) et quels attributs ont été mémorisés avec d’autres valeurs (substitués).

"uri-de-tâche" (uri) : l’objet Imprimante DOIT retourner l’URI d’objet Tâche en retournant le contenu de l’attribut d’objet Tâche EXIGÉ "uri-de-tâche". Le client utilise l’URI d’objet Tâche lorsqu’il dirige des opérations vers l’objet Tâche. L’objet Imprimante utilise toujours sa politique de sécurité configurée lorsqu’il crée le nouvel URI. Cependant, si l’objet imprimante prend en charge plus d’un URI, l’objet imprimante utilise aussi les informations sur l’URI qui a été utilisé dans la demande Tâche-d’impression pour générer de nouvel URI de sorte que les nouvelles références d’URI aient le canal d’accès correct. En d’autres termes, si la demande Tâche-d’impression vient par un canal sécurisé, l’objet imprimante DOIT générer un URI de tâche qui utilise lui aussi le canal sécurisé.

"id-de-tâche" (entier(1:MAX)) : l’objet Imprimante DOIT retourner l’ID de tâche de l’objet Tâche en retournant l’attribut EXIGÉ "id-de-tâche" d’objet Tâche. Le client utilise cet attribut "id-de-tâche" en conjonction avec l’attribut "uri-d’imprimante" utilisé dans la demande de Tâche-d’impression lorsqu’il dirige les opérations de tâche vers l’objet imprimante.

"état-de-tâche" (type1 enum) : l’objet Imprimante DOIT retourner l’attribut EXIGÉ "état-de-tâche" de l’objet Tâche. La valeur de cet attribut (avec la valeur de l’attribut suivant : "causes-d’état-de-tâche") est tirée d’un "cliché" du nouvel objet Tâche à un instant significatif (défini par la mise en œuvre) entre le moment où l’objet imprimante reçoit la demande Tâche-d’impression et celui où l’objet imprimante retourne la réponse.

"causes-d’état-de-tâche" (1setOf type2 keyword) : l’objet Imprimante DOIT retourner l’attribut EXIGÉ "causes-d’état-de-tâche" de l’objet Tâche.

"message-d’état-de-tâche" (texte(MAX)) : l’objet Imprimante retourne FACULTATIVEMENT l’attribut FACULTATIF "message-d’état-de-tâche" de l’objet Tâche. Si l’objet Imprimante prend en charge cet attribut, il DOIT alors être retourné dans la réponse. Si cet attribut n’est pas retourné dans la réponse, le client peut supposer que l’attribut "message-d’état-de-tâche" n’est pas pris en charge et il ne sera pas retourné dans une interrogation d’objet Tâche ultérieure.

"nombre-de-tâches-prévues" (entier(0:MAX)) : l’attribut FACULTATIF "nombre-de-tâches-prévues" de l’objet Tâche est retourné FACULTATIVEMENT par l’objet Imprimante. Si l’objet imprimante prend en charge cet attribut, il DOIT alors être retourné dans la réponse. Si cet attribut n’est pas retourné dans la réponse, le client peut supposer que l’attribut "nombre-de-tâches-prévues" n’est pas pris en charge et ne sera pas retourné dans une interrogation d’objet Tâche ultérieure.

Note : Dans la mesure où toute information d’état d’imprimante qui affecte un état de tâche est reflétée dans les attributs "état-de-tâche" et "causes-d’état-de-tâche", il est suffisant de retourner seulement ces attributs et pas d’attributs d’état spécifiques de l’imprimante.

Note : En plus des paramètres OBLIGATOIRES requis pour chaque réponse d’opération, la plus simple réponse comporte simplement les attributs d’opération "charset-des-attributs" et "langage-naturel-des-attributs" et les attributs d’objet de tâche "uri-de-tâche", "id-de-tâche", et "état-de-tâche". Dans ce cas le plus simple, le code d’état est 'réussite-ok' et il n’y a pas d’attribut d’opération "message-d’état" ou "message-d’état-détaillé".

Cette opération FACULTATIVE est identique à l’opération Tâche-d’impression (paragraphe 3.2.1) excepté qu’un client fournit une référence d’URI aux données documentaires en utilisant l’attribut d’opération "uri-de-document" (uri) (dans le Groupe 1) plutôt que d’inclure les données documentaires elles-mêmes. Avant de retourner la réponse, l’imprimante DOIT valider que l’imprimante prend en charge la méthode de restitution (par exemple, http, ftp, etc.) impliquée par l’URI, et DOIT vérifier la validité de la syntaxe d’URI. Si le schéma d’URI fourni par le client n’est pas pris en charge, c’est-à-dire si la valeur n’est pas dans l’attribut "schéma-d’uri-référencé-pris-en-charge" de l’objet imprimante, l’objet imprimante DOIT rejeter la demande et retourner le code d’état 'erreur-client-schéma-d’uri-non-pris-en-charge'.

L’imprimante IPP PEUT valider l’accessibilité du document au titre de l’opération ou ultérieurement. Si l’imprimante détermine un problème d’accessibilité avant de retourner une réponse d’opération, elle rejette la demande et retourne le code d’état 'erreur-client-erreur-d’accès-au-document'. L’imprimante PEUT aussi retourner un code d’erreur d’accès au document spécifique en utilisant l’attribut d’opération "erreur-d’accès-au-document" (voir au paragraphe 3.1.6.4).

Si l’imprimante détermine ce problème d’accessibilité au document après voir accepté la demande et retourné la réponse d’opération avec un des codes d’état de succès, l’imprimante ajoute la valeur 'erreur-d’accès-au-document' à l’attribut "causes-d’état-de-tâche" de la tâche et PEUT remplir l’attribut de description de tâche "erreurs-d’accès-au-document-de-tâche" de la tâche (voir au paragraphe 4.3.11). Voir le Guide de mise en œuvre [IPP-IIG] pour des suggestions de vérification supplémentaires.

Si l’objet imprimante prend en charge cette opération, il DOIT prendre en charge l’attribut d’imprimante "schémas-d’uri-référencés-pris-en-charge" (voir au paragraphe 4.4.27).

Il appartient à l’objet IPP d’interpréter l’URI et ensuite de "tirer" le document de la source référencée par la chaîne d’URI.

3.2.3 Opération Valider-la-tâche

Cette opération EXIGÉE est similaire à l’opération Tâche-d’impression (paragraphe 3.2.1) excepté qu’un client ne fournit pas de données documentaires et que l’imprimante n’alloue pas de ressources (c’est-à-dire, elle ne crée pas un nouvel objet Tâche). Cette opération n’est utilisée que pour vérifier les capacités d’un objet imprimante par rapport aux attributs fournis par le client dans la demande Valider-la-tâche. En utilisant l’opération Valider-la-tâche un client peut valider qu’une opération Tâche-d’impression identique (avec les données documentaires) serait acceptée. L’opération Valider-la-tâche effectue aussi la même négociation de sécurité que l’opération Tâche-d’impression (voir à la section 8), de sorte qu’un client peut vérifier que les exigences de sécurité du client et de l’objet Imprimante peuvent être satisfaites avant d’effectuer une opération Tâche-d’impression.

L’opération Valider-la-tâche n’accepte pas un attribut "uri-de-document" dans le but de permettre à un client de vérifier que la même opération URI-d’impression sera acceptée, dans la mesure où le client n’envoie pas les données avec l’opération URI-d’impression. Le client DEVRAIT simplement produire la demande URI-d’impression.

L’objet Imprimante retourne les mêmes codes d’état, attributs d’opération (Groupe 1) et attributs non acceptés (Groupe 2) que l’opération Tâche-d’impression. Cependant, aucun attribut d’objet de tâche (Groupe 3) n’est retourné, car aucun objet Tâche n’est créé.

Cette opération FACULTATIVE est similaire à l’opération Tâche-d’impression (paragraphe 3.2.1) excepté que dans la demande Création-de-tâche, un client ne fournit pas de données documentaires ou de référence aux données documentaires. Et aussi, le client ne fournit aucun attribut d’opération "nom-du-document", "format-de-document", "compression", ou "langage-naturel-du-document". Cette opération est suivie par une ou plusieurs opérations Document-d’envoi ou URI-d’envoi. Dans chacune de ces demandes d’opération, le client fournit FACULTATIVEMENT les attributs "nom-du-document", "format-de-document", et "langage-naturel-du-document" pour chaque document dans l’objet Tâche multi-document.

Si un objet Imprimante prend en charge l’opération Création-de-tâche, il DOIT aussi prendre en charge l’opération Document-d’envoi et PEUT aussi prendre en charge l’opération URI-d’envoi.

Si l’objet imprimante prend en charge cette opération, il DOIT prendre en charge l’attribut d’imprimante "temporisation-d’opération-multiple" (voir au paragraphe 4.4.31).

Si l’objet imprimante prend en charge cette opération, il DOIT alors prendre en charge l’attribut de description d’opération "tâches-multi-document-prises-en-charge" (voir au paragraphe 4.4.16) et indiquer si il prend ou non en charge des tâches multi-document.

Si l’objet imprimante prend en charge cette opération et prend en charge les documents multiples dans une tâche, il DOIT alors prendre en charge l’attribut de tâche de gabarit de tâche "traitement-de-document-multiple" avec au moins une valeur (voir au paragraphe 4.2.4) et les attributs d’imprimante de gabarit de tâche associés "traitement-par-défaut-de-document-multiple" et "traitement-de-document-multiple-pris-en-charge" (voir au paragraphe 4.2).

Après l’achèvement de l’opération Création-de-tâche, la valeur de l’attribut "état-de-tâche" est similaire à celle de "état-de-tâche" après une tâche-d’impression, même si aucune donnée documentaire n’est arrivée. Une imprimante PEUT régler la valeur de 'données-de-tâche-insuffisantes' de l’attribut "causes-d’état-de-tâche" de la tâche pour indiquer que le traitement ne peut pas commencer tant que des données suffisantes ne sont arrivées et régler l’"état-de-tâche" à 'en-instance' ou 'gardé-en-instance'. Une imprimante sans dévidage qui ne met pas en œuvre l’état de tâche 'en-instance' peut même régler l’"état-de-tâche" à 'traitement-en-cours', bien qu’il n’y ait pas encore de données à traiter. Voir aux paragraphes 4.3.7 et 4.3.8.

Cette opération EXIGÉE permet à un client de demander les valeurs des attributs d’un objet Imprimante. Dans la demande, le client fournit l’ensemble des noms d’attribut d’imprimante et/ou des noms de groupe d’attributs auxquels le demandeur s’intéresse. Dans la réponse, l’objet imprimante retourne un ensemble d’attributs correspondant remplis avec les valeurs d’attribut appropriées.

- 'gabarit-d’imprimante' : le sous-ensemble des attributs de gabarit d’imprimante qui s’applique à un objet Imprimante (les deux dernières colonnes du tableau du paragraphe 4.2) que la mise en œuvre prend en charge pour les objets imprimante.

- 'description-d’imprimante' : le sous-ensemble des attributs spécifiés au paragraphe 4.4 que la mise en œuvre prend en charge pour les objets imprimante.

- 'tout': le groupe spécial 'tout' qui inclut tout attribut que la mise en œuvre prend en charge pour les objets imprimante.

Comme un client PEUT demander des attributs ou groupes nommés spécifiques, il y a des possibilités de recouvrement. Par exemple, si un client demande 'nom-d’imprimante' et 'tout', il demande en réalité deux fois l’attribut "nom-d’imprimante" : une fois en le nommant explicitement, et une fois par inclusion dans le groupe 'tout'. Dans de tels cas, l’objet imprimante PEUT NE retourner chaque attribut qu’une seule fois dans la réponse même s’il est demandé plusieurs fois. Le client NE DEVRAIT PAS demander le même attribut de plusieurs façons.

Il n’est PAS EXIGÉ qu’un objet Imprimante prenne en charge tout attribut appartenant à un groupe (dans la mesure où certains attributs sont FACULTATIFS). Cependant, il est EXIGÉ que chaque objet Imprimante prenne en charge tous les noms de groupes.

Les ensemble d’attributs suivants font partie de la demande Obtenir-les-attributs-d’imprimante :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.1.

Cible : l’attribut d’opération "uri-d’imprimante" (uri) qui est la cible de cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-de-l’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

"attributs-demandés" (1setOf mot-clé) : le client fournit FACULTATIVEMENT un ensemble de noms d’attribut et/ou groupe de noms d’attribut dont les valeurs intéressent le demandeur. L’objet Imprimante DOIT prendre en charge cet attribut. Si le client omet cet attribut, l’imprimante DOIT répondre comme si cet attribut avait été fourni avec une valeur de 'tout'.

"format-de-document" (typeDeSupportMime) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. Cet attribut sert à un objet Imprimante pour déterminer l’ensemble des valeurs d’attribut pris en charge qui se rapportent au format de document demandé. L’objet Imprimante DOIT retourner les attributs et valeurs qu’il utilise pour valider une tâche sur une opération Créer ou Valider-la-tâche dans laquelle ce format de document est fourni. L’objet Imprimante DEVRAIT ne retourner que (1) les attributs qui sont pris en charge pour le format spécifié et (2) les valeurs d’attribut qui sont prises en charge pour le format de document spécifié . En spécifiant le format du document, le client peut obtenir de l’objet imprimante qu’il élimine les attributs et valeurs qui ne sont pas pris en charge pour un format de document spécifique. Par exemple, un objet Imprimante pourrait avoir plusieurs interprétations pour prendre à la fois en charge les documents 'application/postscript' (pour PostScript) et 'texte/clair' (pour le texte). Cependant, pour une seule de ces interprétations l’objet imprimante pourrait être capable de prendre en charge "jusqu'à" avec les valeurs de '1', '2', et '4'. Pour les autres interprétations elle pourrait être seulement capable de prendre en charge "jusqu'à" avec une valeur de '1'. Et donc un client peut utiliser l’opération Obtenir-les-attributs-d’imprimante pour obtenir les attributs et valeurs qui seront utilisés pour accepter/rejeter une opération de création de tâche.

Si l’objet imprimante ne fait pas de différence entre deux ensembles différents de valeurs prises en charge pour chaque format de document différent lors de la validation des tâches pour les opérations Créer et Valider-la-tâche , il NE DOIT PAS distinguer entre les différents formats de document dans les opérations Obtenir-les-attributs-d’imprimante. Si l’objet imprimante fait une distinction entre les différents ensembles de valeurs prises en charge pour chaque format de document différent spécifié par le client, cette spécialisation ne s’applique que pour les attributs d’objet Imprimante suivants :

- attributs d’imprimante qui sont des attributs de gabarit d’imprimante ("xxx-par-défaut" "xxx-pri-en-charge", et "xxx-prêt" dans le tableau du paragraphe 4.2),

Les valeurs de tout autre attribut d’objet Imprimante (y compris "format-de-document-pris-en-charge") restent invariantes par rapport au format de document fourni par le client (exception faite du nouvel attribut de description d’imprimante tel qu’enregistré conformément au paragraphe 6.2).

Si le client omet cet attribut d’opération "format-de-document", l’objet imprimante DOIT répondre comme si l’attribut avait été fourni avec la valeur de l’attribut "format-de-document-par-défaut" de l’objet imprimante. Il est RECOMMENDÉ que le client fournisse toujours une valeur pour "format-de-document", car le "format-de-document-par-défaut" de l’objet imprimante peut être 'application/flux-d’octets', auquel cas les attributs et valeurs retournés sont pour l’union des formats de document que l’imprimante peut détecter automatiquement. Pour des précisions, voir la description de la syntaxe de l’attribut 'typeDeSupportMime' au paragraphe 4.1.9.

Si le client fournit une valeur pour l’attribut d’opération "format-de-document" qui n’est pas prise en charge par l’imprimante, c’est-à-dire qu’elle n’est pas parmi les valeurs de l’attribut "format-de-document-pris-en-charge" de l’objet imprimante, celui-ci DOIT rejeter l’opération et retourner le code d’état 'erreur-client-format-de-document-non-accepté'.

L’objet Imprimante retourne les ensembles d’attributs suivants au titre de la réponse à Obtenir-les-attributs-d’imprimante :

Langage naturel et ensemble de caractères : Les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2.

Voir au paragraphe 3.1.7 des précisions sur le retour des attributs non acceptés.

La réponse PEUT NE PAS contenir l’attribut d’opération "attributs-demandés" avec des valeurs fournies (mots-clés d’attribut) demandées par le client mais non prises en charge par l’objet IPP. Si l’objet imprimante retourne des attributs non acceptés référencés dans l’attribut d’opération "attributs-demandés" et que cet attribut incluait des noms de groupes, tels que 'tout', les attributs non acceptés NE DOIVENT PAS comporter d’attribut décrit dans la norme mais non pris en charge par la mise en œuvre.

C’est l’ensemble des attributs demandés et de leurs valeurs actuelles. L’objet Imprimante ignore (ne leur répond pas) tout attribut demandé qui n’est pas pris en charge. L’objet Imprimante PEUT répondre avec un sous-ensemble des attributs et valeurs pris en charge, selon la politique de sécurité en vigueur. Cependant, l’objet imprimante DOIT répondre par la valeur 'inconnu' pour tout attribut pris en charge (y compris tout attribut EXIGÉ) dont l’objet imprimante ne connaît pas la valeur. L’objet imprimante DOIT aussi répondre par 'pas-de-valeur' pour tout attribut pris en charge (y compris tout attribut EXIGÉ) pour lequel l’administrateur du système n’a pas configuré de valeur. Voir la description des valeurs "hors-bande" au débit du paragraphe 4.1.

Cette opération EXIGÉE permet à un client de restituer la liste des objets Tâche appartenant à l’objet Imprimante cible. Le client peut aussi fournir une liste des noms d’attribut de tâche et/ou groupes d’attribut. Un groupe d’attributs d’objet Tâche sera retourné pour chaque objet Tâche qui est retourné.

Cette opération est semblable à l’opération Obtenir-les-attributs-de-tâches, sauf que cette opération Obtenir-les-tâches retourne des attributs qui peuvent provenir de plus d’un objet.

Les groupes d’attributs suivants font partie de la demande Obtenir-les-tâches :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.1.

Cible : L’attribut d’opération "uri-d’imprimante" (uri) qui est la cible pour cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-de-l’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

"limite" (entier(1:MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. C’est une valeur d’entier qui détermine le nombre maximum de tâches qu’un client va recevoir de l’imprimante même si "quelles-tâches" ou "mes-tâches" fait peser une contrainte sur les tâches qui sont retournées. La limite est une "limite sans état" en ce que si la valeur fournie par le client est 'N', seules les ‘N’ premières tâches seront alors retournées dans la réponse à Obtenir-les-tâches. Aucun mécanisme ne permet d’avoir les M’ tâches suivantes après les ‘N’ premières tâches. Si le client ne fournit pas cet attribut, l’objet imprimante répond avec toute tâche applicable.

"attributs-demandés" (1setOf type2 mot-clé) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. C’est un ensemble de noms d’attribut de tâche et/ou groupes d’attribut aux valeurs desquels s’intéresse le demandeur. Cet ensemble d’attributs est retourné pour chaque objet Tâche retourné. Les noms de groupe d’attributs permis sont les mêmes que ceux définis dans l’opération Obtenir-les-tâches du paragraphe 3.3.4. Si le client ne fournit pas cet attribut, l’imprimante DOIT répondre comme si le client avait fourni cet attribut avec deux valeurs: 'uri-de-tâche' et 'id-de-tâche'.

"quelles-tâches" (type2 mot-clé) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. Il indique quels objets Tâche DOIVENT être retournés par l’objet imprimante. Les valeurs pour cet attribut sont :

'terminé' : Ceci inclut tout objet Tâche dont l’état est 'terminé', 'annulé', ou 'avorté'.

'non-terminé' : Ceci inclut tout objet Tâche dont l’état est 'en-instance', 'traitement-en-cours', 'traitement-arrêté', ou 'gardé-en-instance'.

Un objet Imprimante DOIT prendre en charge les deux valeurs. Cependant, si la mise en œuvre ne conserve pas les tâches dans les états 'terminé', 'annulé', et 'avorté', elle ne retourne alors aucune tâche lorsque la valeur 'terminé' est fournie.

Si un client fournit un autre valeur, l’objet imprimante DOIT copier l’attribut et la valeur non acceptée dans le groupe de réponse des attributs non acceptés, rejeter la demande, et retourner le code d’état 'erreur-client-attributs-ou-valeurs-non-pris-en-charge'.

Si le client ne fournit pas cet attribut, l’objet imprimante DOIT répondre comme si le client avait fourni l’attribut avec une valeur de 'non-terminé'.

"mes-tâches" (booléen) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. Il indique si les tâches provenant de tout usager ou seulement les tâches soumises par l’usager demandeur de cette demande DOIVENT être considérées comme tâches candidates pour être retournées par l’objet imprimante. Si le client ne fournit pas cet attribut, l’objet imprimante DOIT répondre comme si le client avait fourni l’attribut avec une valeur de 'faux', c’est-à-dire, les tâches de tous les usagers. Le moyen d’authentifier l’usager demandeur et la correspondance des tâches est décrit à la section 8.

L’objet Imprimante retourne tous les objets Tâche jusqu’au nombre spécifié par l’attribut "limite" qui satisfait au critère défini par les valeurs d’attribut fournies par le client dans la demande. Il est possible qu’aucun objet Tâche ne soit retourné dans la mesure où il n’y a effectivement aucun objet Tâche à l’imprimante, ou il peut n’y avoir aucun objet Tâche qui satisfasse le critère fourni par le client. Si le client demande tous les attributs de tâche, il y a un ensemble d’attributs d’objet de tâche retourné pour chaque objet Tâche.

Ce n’est pas une erreur pour l’imprimante de retourner 0 tâche. Si la réponse retourne 0 tâche parce qu’il n’y a aucune tâche qui satisfasse le critère, et que la demande aurait retourné une ou plusieurs tâches avec un code d’état de 'réussite-ok' si des tâches avaient satisfait au critère, le code d’état pour 0 tâche DOIT être 'réussite-ok'.

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2.

Voir au paragraphe 3.1.7 des précisions sur le retour des attributs non acceptés.

La réponse PEUT NE PAS contenir l’attribut d’opération "attributs-demandés" avec une des valeurs fournies (mots-clé d’attribut) qui étaient demandées par le client mais ne sont pas prises en charge par l’objet IPP. Si l’objet imprimante retourne des attribut non pris en charge référencés dans l’attribut d’opération "attributs-demandés" et que cet attribut inclut des noms de groupe, tels que 'tout', les attributs non pris en charge NE DOIVENT PAS inclure d’attributs décrits dans la norme mais non pris en charge par la mise en œuvre.

L’objet Imprimante répond avec un ensemble d’attributs d’objet de tâche pour chaque objet Tâche retourné. L’objet Imprimante ignore (ne répond pas à) tout attribut ou valeur demandé qui n’est pas pris en charge ou est interdit par la politique de sécurité en vigueur, y compris si l’usager demandeur est celui qui a soumis la tâche (utilisateur d’origine de la tâche) (voir la section 8). Cependant, l’objet imprimante DOIT répondre par la valeur 'inconnu' pour tout attribut pris en charge (y compris tout attribut EXIGÉ ) pour lequel l’objet imprimante ne connaît pas la valeur, à moins que cela ne viole la politique de sécurité. Voir la description des valeurs "hors-bande" au début du paragraphe 4.1.

- Si le client demande toutes les tâches 'terminé' (tâches dans les états 'terminé', 'avorté', ou 'annulé'), les tâches sont alors retournées de la plus récente à la plus ancienne (par rapport à l’heure réelle d’achèvement) ;

- Si le client demande toutes les tâches 'non-terminé' (tâches dans les états 'en-instance', 'traitement-en-cours', 'gardé-en-instance', et 'traitement-arrêté'), les tâches sont alors retournées dans l’ordre chronologique relatif de l’heure d’achèvement attendue (fondée sur tout algorithme de programmation configuré pour l’objet imprimante).

Cette opération FACULTATIVE permet à un client d’arrêter la programmation de tâches sur tous les appareils de l’objet imprimante. Selon la mise en œuvre, l’opération Pause-d’imprimante PEUT aussi arrêter sur l’imprimante le traitement de la ou des tâches en cours. Toute tâche en cours d’impression est soit arrêtée aussitôt que la mise en œuvre le permet, soit terminée, selon la mise en œuvre. L’objet Imprimante DOIT toujours accepter que les opérations de création créent de nouvelles tâches, mais DOIT empêcher toute tâche d’entrer dans l’état 'traitement-en-cours'.

Si l’opération Pause-d’imprimante est prise en charge, l’opération Reprise-d’imprimante DOIT être prise en charge, et vice-versa.

L’imprimante IPP arrête la ou les tâches en cours sur son ou ses appareils qui étaient dans les états 'traitement-en-cours' ou 'traitement-arrêté' aussitôt que la mise en œuvre le permet. Si la mise en œuvre va prendre un temps appréciable pour s’arrêter, l’imprimante IPP ajoute la valeur 'passage-en-pause' à l’attribut "causes-d’état-d’imprimante" de l’objet imprimante (voir au paragraphe 4.4.12). Lorsque le ou les appareils ont tout arrêté, l’imprimante IPP passe l’objet imprimante à l’état 'arrêté', retire la valeur 'passage-en-pause', si elle est présente, et ajoute la valeur 'pause' à l’attribut "causes-d’état-d’imprimante" de l’objet imprimante.

Lorsque la ou les tâches en cours qui étaient dans l’état 'traitement-en-cours' s’achèvent, l’imprimante IPP les passe dans l’état 'terminé'. Lorsque la ou les tâches en cours qui étaient dans l’état 'traitement-en-cours' s’arrêtent à mi-traitement, l’imprimante IPP les passe à l’état 'traitement-arrêté' et ajoute la valeur 'imprimante-arrêtée' à l’attribut "causes-d’état-de-tâche" de la tâche.

Pour toute tâche 'en-instance' ou 'gardé-en-instance', la valeur 'imprimante-arrêtée' de l’attribut "causes-d’état-de-tâche" de la tâches s'applique aussi. Cependant, l’imprimante IPP PEUT NE PAS mettre à jour ces attributs "causes-d’état-de-tâche" de tâche et a seulement besoin de retourner la valeur 'imprimante-arrêtée' lorsque ces tâches sont interrogées (c’est ce qu’on appelle "évaluation paresseuse").

Savoir si l’opération Pause-d’imprimante affecte les tâches qui ont été soumises à l’appareil à partir d’autres sources que l’objet imprimante IPP de la même façon que l’opération Pause-d’imprimante affecte les tâches qui ont été soumises à l’objet imprimante IPP en utilisant IPP, dépend de la mise en œuvre, c’est-à-dire respectivement, si le protocole IPP est utilisé comme protocole de gestion universel ou seulement pour gérer les tâches IPP.

L’imprimante IPP DOIT accepter la demande dans tout état et passer l’imprimante au nouvel "état-d’imprimante" indiqué avant de retourner comme suit :

Droits d’accès : L’utilisateur authentifié (voir au paragraphe 8.3) effectuant cette opération doit être un opérateur ou administrateur de l’objet imprimante (voir aux paragraphes 1 et 8.5). Autrement, l’imprimante IPP DOIT rejeter l’opération et retourner : 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas.

Les groupes d’attributs suivants font partie de la demande de Pause-d’imprimante :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.1.

Cible : l’attribut d’opération "uri-d’imprimante" (uri) qui est la cible de cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-de-l’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

Les groupes d’attributs suivants font partie de la réponse à Pause-d’imprimante :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2.

Voir au paragraphe 3.1.7 des précisions sur le retour des attributs non acceptés.

Cette opération permet à un client de faire reprendre la programmation de tâche à l’objet imprimante sur tous ses appareils. L’objet Imprimante DOIT retirer les valeurs 'pause' et 'passage-en-pause' de l’attribut "causes-d’état-d’imprimante" de l’objet imprimante, s’il est présent. S’il n’y a pas d’autres raisons de garder un appareil en pause (telle qu’un encombrement du support), l’imprimante IPP est libre de passer elle-même à l’état 'traitement-en-cours' ou 'repos', selon que des tâches sont à traiter ou non, et le ou les appareils reprennent le traitement des tâches.

Si l’opération Pause-d’imprimante est prise en charge, l’opération Reprise-d’imprimante DOIT alors être prise en charge, et vice-versa.

L’imprimante IPP retire la valeur 'imprimante-arrêtée' de tous les attributs "causes-d’état-de-tâche" des tâches contenues dans cette imprimante.

L’imprimante IPP DOIT accepter la demande dans tout état, passer l’objet imprimante au nouvel état indiqué comme suit :

Droits d’accès : l’utilisateur authentifié (voir au paragraphe 8.3) effectuant cette opération doit être un opérateur ou administrateur de l’objet imprimante (voir aux paragraphes 1 et 8.5). Autrement, l’imprimante IPP DOIT rejeter l’opération et retourner : 'erreur-client-interdit', 'erreur-client-non-authentifié', ou'erreur-client-non-autorisé' selon le cas.

La demande Reprise-d’imprimante et la réponse à Reprise-d’imprimante ont les mêmes attributs et groupes d’attributs que l’opération Pause-d’imprimante (voir aux paragraphes 3.2.7.1 et 3.2.7.2).

Cette opération FACULTATIVE permet à un client de retirer toutes les tâches d’un objet imprimante IPP, sans considération de l’état des tâches, y compris des tâches de l’historique des tâches de l’objet imprimante (voir au paragraphe 4.3.7.2). Après avoir effectué une opération Purger-les-tâches, un objet Imprimante DOIT ne retourner aucune tâche dans les Obtenir-les-tâches et réponses à Obtenir-les-tâches suivantes (jusqu’à ce que de nouvelles tâches soient soumises).

Savoir si l’opération Purger-les-tâches (et Obtenir-les-tâches) affecte les tâches qui ont été soumises à l’appareil à partir d’autres sources que l’objet imprimante IPP de la même façon que l’opération Purger-les-tâches affecte les tâches qui ont été soumises à l’objet imprimante IPP en utilisant IPP, dépend de la mise en œuvre, c’est-à-dire respectivement de si le protocole IPP est utilisé comme protocole de gestion universel ou simplement pour gérer les tâches IPP.

Note : si un opérateur veut annuler toutes les tâches sans vider l’historique des tâches, il utilise l’opération Annuler-la-tâche sur chaque tâche au lieu d’utiliser l’opération Purger-les-tâches.

L’objet Imprimante DOIT accepter cette opération dans tout état et passer l’objet imprimante à l’état 'repos'.

La demande Purger-les-tâches et la réponse à Purger-les-tâches ont les mêmes groupes d’attributs et attributs que l’opération Pause-d’imprimante (voir aux paragraphes 3.2.7.1 et 3.2.7.2).

3.3 Opérations de tâche

Toutes les opérations de tâche sont dirigées vers des objets Tâche. Un client DOIT toujours fournir des moyens d’identifier l’objet Tâche afin d’identifier la cible correcte de l’opération. Cette identification de tâche PEUT être un seul URI de tâche ou une combinaison d’un URI d’imprimante avec un ID de tâche. La mise en œuvre d’objet IPP DOIT prendre en charge les deux formes d’identification pour chaque tâche.

Cette opération FACULTATIVE permet à un client de créer un objet Tâche multi-document qui est initialement "vide" (ne contient aucun document). Dans la réponse à Création-de-tâche, l’objet imprimante retourne l’URI de l’objet Tâche (l’attribut "uri-de-tâche") et l’identifiant de 32 bits de l’objet Tâche (l’attribut "id-de-tâche"). Pour chaque nouveau document que le client désire ajouter, le client utilise une opération Document-d’envoi. Chaque demande Document-d’envoi contient le flux entier de données documentaires pour un document.

Si l’imprimante prend en charge cette opération mais ne prend pas en charge plusieurs documents par tâche, l’imprimante DOIT rejeter les opérations Document-d’envoi suivantes fournies avec des données et retourner 'erreur-serveur-documents-multiples-non-accepté'. Cependant, l’imprimante DOIT accepter le premier document avec une valeur 'vrai' ou 'faux' pour l’attribut d’opération "dernier-document" (voir ci-dessous) de sorte que les clients PEUVENT toujours soumettre une tâche de document avec une valeur 'faux' pour "dernier-document" dans le premier Document-d’envoi et 'vrai' pour "dernier-document" dans le second Document-d’envoi (sans données).

Dans la mesure où les opérations Création-de-tâche et d’envoi (opérations Document-d’envoi ou URI-d’envoi) qui suivent pourraient survenir sur une période de temps arbitrairement longue pour une tâche particulière, un client DOIT envoyer une autre opération d’envoi dans un intervalle de temps minimum défini dans une imprimante IPP après la réception de la demande précédente pour la tâche. Si un objet Imprimante prend en charge les opérations Création-de-tâche et Document-d’envoi, l’objet imprimante DOIT prendre en charge l’attribut "temporisation-d’opération-multiple" (voir au paragraphe 4.4.31). Cet attribut indique le nombre minimum de secondes pendant lequel l’objet imprimante va attendre la prochaine opération d’envoi avant d’entreprendre une action de récupération.

Un objet IPP DOIT récupérer d’un client erratique qui ne fournit pas une opération d’envoi, parfois après l’intervalle de temps minimum spécifié par l’attribut "temporisation-d’opération-multiple" de l’objet imprimante. Une telle récupération PEUT inclure tout ou partie des actions de récupération suivantes ou d’autres :

1. Supposer que la tâche est invalide, commencer le processus de passage de l’état de la tâche à 'avorté', ajouter la valeur 'avorté-par-le-système' à l’attribut "causes-d’état-de-tâche" de la tâche (voir au paragraphe 4.3.8), et vider toutes les ressources associées à la tâche. Dans ce cas, si une autre opération d’envoi est finalement reçue, l’imprimante répond par un "erreur-client-impossible" ou "erreur-client-introuvable" selon que l’objet Tâche est toujours ou non autour lorsque l’opération d’envoi arrive finalement.

2. Supposer que la dernière opération d’envoi reçue était en fait le dernier document (comme si le fanion "dernier-document" avait été mis à 'vrai'), fermer l’objet Tâche, et procéder à son traitement (c’est-à-dire, passer l’état de tâche à 'en-instance').

3. Supposer que la dernière opération d’envoi reçue état en fait le dernier document, fermer la tâche, mais la passer à 'gardé-en-instance' et ajouter la valeur 'soumission-interrompue' à l’attribut "causes-d’état-de-tâche" de la tâche (voir au paragraphe 4.3.8). Cette action permet à l’utilisateur ou à un opérateur de déterminer si il continue le traitement de la tâche en la ramenant à l’état 'en-instance' en utilisant l’opération Libération-de-tâche (voir au paragraphe 3.3.6) ou d’annuler la tâche en utilisant l’opération Annuler-la-tâche (voir au paragraphe 3.3.3).

Chaque mise en œuvre est libre de décider la "meilleure" action à prendre selon la politique locale, si des documents ont été ajoutés, si la mise en œuvre dévide les tâches ou non, et/ou si d’autres informations sont disponibles pour elle. Si le choix est d’avorter l’objet Tâche, il est possible que l’objet Tâche ait déjà été traité au point que certaines feuilles de support soient déjà imprimées.

Droits d’accès : l’utilisateur authentifié (voir au paragraphe 8.3) effectuant cette opération doit être le propriétaire de la tâche (comme déterminé dans l’opération Création-de-tâche) ou un opérateur ou administrateur de l’objet imprimante (voir aux paragraphes 1 et 8.5). Autrement, l’objet IPP DOIT rejeter l’opération et retourner : 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas approprié.

Les ensembles d’attribut suivants font partie de la demande de Document-d’envoi :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.1.

Cible : soit (1) l’"uri-d’imprimante" (uri) plus l’"id-de-tâche" (entier(1:MAX)), soit (2) le ou les attributs d’opération "uri-de-tâche" (uri) qui définissent la cible de cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-d’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

"nom-du-document" (nom(MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. Il contient le nom du document fourni par le client. Le nom du document PEUT être différent du nom de tâche. Il peut être utile, mais PEUT NE PAS être unique sur plusieurs documents dans la même tâche. Normalement, le logiciel du client fournit automatiquement le nom du document au nom de l’utilisateur final en utilisant un nom de fichier ou un nom généré par l’application. Voir la description de l’attribut d’opération "nom-du-document" dans la Demande de Tâche-d’impression (paragraphe 3.2.1.1) pour des informations complémentaires sur cet attribut.

"compression" (type3 mot-clé) : voir la description de "compression" pour l’opération Tâche-d’impression au paragraphe 3.2.1.1.

"format-de-document" (typeDeSupportMime) : voir la description de "format-de-document" pour l’opération Tâche-d’impression au paragraphe 3.2.1.1.

"langage-naturel-du-document" (langageNaturel) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante prend FACULTATIVEMENT en charge cet attribut. Cet attribut spécifie le langage naturel du document pour les formats de document qui requièrent la spécification du langage naturel afin de reproduire le document de façon non ambiguë. Il n’y a pas de valeur particulière dont la prise en charge soit exigée de l’objet imprimante.

"dernier-document" (booléen) : le client DOIT fournir cet attribut. L’objet Imprimante DOIT prendre en charge cet attribut. C’est un fanion booléen qui est mis à 'vrai' si c’est le dernier document pour la tâche, 'faux' autrement.

Le client DOIT fournir les données documentaires si le fanion "dernier-document" est mis à 'faux'. Cependant, comme un client pourrait ignorer que le précédent document envoyé avec une opération Document-d’envoi (ou URI-d’envoi) était le dernier document (c’est-à-dire que l’attribut "dernier-document" était mis à 'faux'), il est permis d’envoyer une demande de Document-d’envoi sans données documentaires alors que le fanion "dernier-document" est mis à 'vrai'. Une telle demande NE DOIT PAS incrémenter la valeur de l’attribut "nombre-de-documents" de l’objet Tâche, car aucun document réel n’a été ajouté à la tâche. Ce n’est pas une erreur pour un client de soumettre une tâche sans réelles données documentaires, c’est-à-dire, seulement une demande de Création-de-tâche et de Document-d’envoi avec un attribut d’opération "dernier-document" mis à 'vrai' sans données documentaires.

Les ensembles d’attributs suivants font partie de la réponse à Document-d’envoi :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2.

Voir au paragraphe 3.1.7 les détails sur le retour des attributs non acceptés.

C’est le même ensemble d’attributs que décrit dans la réponse à Tâche-d’impression (voir au paragraphe 3.2.1.2).

Cette opération FACULTATIVE est identique à l’opération Document-d’envoi (voir au paragraphe 3.3.1) sauf qu’un client DOIT fournir une référence d’URI (attribut d’opération "uri-de-document") plutôt que les données documentaires elles-mêmes. Si un objet Imprimante prend en charge cette opération, les clients peuvent utiliser à la fois les opérations URI-d’envoi ou Document-d’envoi pour ajouter de nouveaux documents à un objet Tâche multi-document existant. Cependant, si un client a besoin d’indiquer que le précédent URI-d’envoi ou Document-d’envoi était le dernier document, le client DOIT utiliser l’opération Document-d’envoi sans données documentaires et le fanion "dernier-document" mis à 'vrai' (plutôt que d’utiliser une opération URI-d’envoi sans attribut d’opération "uri-de-document").

Si un objet Imprimante prend en charge cette opération, il DOIT aussi prendre en charge l’opération URI-d’impression (voir au paragraphe 3.2.2).

L’objet Imprimante DOIT valider la syntaxe et le schéma d’URI de l’URI fourni avant de retourner une réponse, tout comme dans l’opération URI-d’impression. L’imprimante IPP PEUT valider l’accessibilité du document au titre de l’opération ou plus tard (voir au paragraphe 3.2.2).

Cette opération EXIGÉE permet à un client d’annuler une tâche d’impression entre le moment où la tâche est créée jusqu’au moment où elle est terminée, annulée, ou avortée. Dans la mesure où une tâche peut être déjà en train d’imprimer au moment où Annuler-la-tâche est reçu, certaines pages peuvent être imprimées avant que la tâche ne soit réellement terminée.

L’objet IPP DOIT accepter ou rejeter la demande sur la base de l’état en cours de la tâche et passer la tâche au nouvel état indiqué comme suit :

Règle 1 : Si la mise en œuvre a besoin d’un délai mesurable pour annuler la tâche dans les états de tâche 'traitement-en-cours' ou 'traitement-arrêté', l’objet IPP DOIT ajouter la valeur 'traitement-en-cours-au-point-d’arrêt' à l’attribut "causes-d’état-de-tâche" de la tâche et passer ensuite la tâche à l’état 'annulé' lorsque cesse le traitement (voir au paragraphe 4.3.8).

Règle 2 : Si l’objet Tâche a déjà la valeur 'traitement-en-cours-au-point-d’arrêt' dans son attribut "causes-d’état-de-tâche", l’objet imprimante DOIT alors rejeter une opération Annuler-la-tâche.

Droits d’accès : L’utilisateur authentifié (voir au paragraphe 8.3) qui effectue cette opération doit être le propriétaire de la tâche ou un opérateur ou administrateur de l’objet imprimante (voir aux paragraphes 1 et 8.5). Autrement, l’objet IPP DOIT rejeter l’opération et retourner : 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas approprié.

Les groupes d’attributs suivants font partie de la demande Annuler-la-tâche :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.1.

Cible : soit (1) le ou les attributs d’opération "uri-d’imprimante" (uri) plus "id-de-tâche" (entier(1:MAX)) soit (2) l’attribut d’opération "uri-de-tâche" (uri) qui définissent la cible de cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-de-l’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

"message" (texte(127)) : le client fournit FACULTATIVEMENT cet attribut. L’objet Imprimante prend FACULTATIVEMENT en charge cet attribut. C’est un message à l’opérateur. Cet attribut "message" n’est pas le même que l’attribut "message-de-tâche-de-l’opérateur". Cet attribut est utilisé pour rapporter un message de l’opérateur à l’utilisateur final qui interroge sur cet attribut. Cet attribut d’opération "message" est utilisé pour envoyer un message du client à l’opérateur avec une demande d’opération. C’est une décision de la mise en œuvre de dire comment et où afficher ce message à l’opérateur (s’il en est).

Les ensembles d’attributs suivants font partie de la réponse à Annuler-la-tâche :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2.

Voir au paragraphe 3.1.7 les détails sur le retour des attributs non acceptés.

Une fois l’envoi d’une réponse de succès, la mise en œuvre garantit que la tâche se terminera finalement dans l’état 'annulé'. Entre le moment où l’opération Annuler-la-tâche est acceptée et le moment où la tâche entrer dans l’état-de-tâche 'annulé' (voir au paragraphe 4.3.7), l’attribut "causes-d’état-de-tâche" DEVRAIT contenir la valeur 'traitement-en-cours-au-point-d’arrêt' qui indique pour des interrogations ultérieures que bien que la tâche puisse toujours être à 'traitement-en-cours', elle se terminera finalement dans l’état 'annulé' et non dans l’état 'terminé'.

Cette opération EXIGÉE permet à un client de demander les valeurs des attributs d’un objet Tâche et elle est presque identique à l’opération Obtenir-les-attributs-d’imprimante (voir au paragraphe 3.2.5). Les seules différences sont que l’opération est dirigée vers un objet Tâche plutôt qu’un objet Imprimante, qu’il n’y a pas d’attribut d’opération "format-de-document" utilisé lors de l’interrogation d’un objet Tâche, et le groupe d’attributs retournés est un ensemble d’attributs d’objet Tâche plutôt qu’un ensemble d’attributs d’objet Imprimante.

- 'gabarit-d’imprimante' : sous-ensemble des attributs de gabarit d’imprimante qui s’applique à un objet Tâche (première colonne du tableau du paragraphe 4.2) que la mise en œuvre prend en charge pour les objets Tâche.

- 'description-de-tâche' : sous-ensemble des attributs de description de tâche spécifiés au paragraphe 4.3 que la mise en œuvre prend en charge pour les objets Tâche.

- 'tout' : le groupe spécial 'tout' inclut tout attribut que la mise en œuvre prend en charge pour les objets Tâche.

Comme un client PEUT demander des attributs spécifiques ou des groupes nommés, il y a une possibilité de recouvrement. Par exemple, si un client demande 'nom-de-tâche' et 'description-de-tâche', il demande en réalité l’attribut "nom-de-tâche" une fois en le nommant explicitement, et une fois par inclusion dans le groupe 'description-de-tâche'. Dans de tels cas, l’objet imprimante PEUT NE retourner l’attribut qu’une seule fois dans la réponse même s’il est demandé plusieurs fois. Le client NE DEVRAIT PAS demander le même attribut de plusieurs façons.

Il n’est PAS EXIGÉ qu’un objet Tâche prenne en charge tout attribut appartenant à un groupe (car certains attributs sont FACULTATIFS). Cependant il est EXIGÉ que chaque objet Tâche prenne en charge tous ces noms de groupes.

Les groupes d’attributs suivants font partie de la demande Obtenir-les-tâches lorsque la demande est dirigée vers un objet Tâche :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.1.

Cible : soit (1) l’"uri-d’imprimante" (uri) plus l’"id-de-tâche" (entier(1:MAX)) soit (2) le ou les attributs d’opération "uri-de-tâche" (uri) qui définissent la cible de cette opération comme décrit au paragraphe 3.1.5.

Nom de l’utilisateur demandeur : l’attribut "nom-de-l’utilisateur-demandeur" (nom(MAX)) DEVRAIT être fourni par le client comme décrit au paragraphe 8.3.

"attributs-demandés" (1setOf mot-clé) : le client fournit FACULTATIVEMENT cet attribut. L’objet IPP DOIT prendre en charge cet attribut. C’est un ensemble de noms d’attribut et/ou groupe de noms d’attributs dont les valeurs intéressent le demandeur. Si le client omet cet attribut, l’objet IPP DOIT répondre comme si cet attribut n’avait pas été fourni avec une valeur de 'tout'.

L’objet Imprimante retourne les ensembles d’attributs suivants au titre de la réponse à Obtenir-les-tâches :

Langage naturel et ensemble de caractères : les attributs "charset-des-attributs" et "langage-naturel-des-attributs" comme décrit au paragraphe 3.1.4.2. Le "langage-naturel-des-attributs" PEUT être le langage naturel de l’objet Tâche, plutôt que celui demandé.

Voir au paragraphe 3.1.7 les détails sur le retour des attributs non acceptés.

La réponse PEUT NE PAS contenir l’attribut d’opération "attributs-demandés" avec aucune des valeurs fournies (mots-clé d’attribut) qui étaient demandées par le client mais ne sont pas prises en charge par l’objet IPP. Si l’objet imprimante retourne les attributs non pris en charge référencés dans l’attribut d’opération "attributs-demandés" et que cet attribut inclut des noms de groupes, tels que 'tout', les attributs non pris en charge NE DOIVENT PAS inclure les attributs décrits dans la norme mais non pris en charge par la mise en œuvre.

C’est l’ensemble des attributs demandés et leurs valeurs courantes. L’objet IPP ignore (ne répond pas à) tout attribut ou valeur demandé qui n’est pas pris en charge ou qui est interdit par la politique de sécurité en vigueur, y compris si l’usager demandeur est celui qui a ou non soumis la tâche (usager d’origine de tâche) (voir la Section 8). Cependant, l’objet IPP DOIT répondre par la valeur 'inconnu' à tout attribut pris en charge (y compris tout attribut EXIGÉ) dont l’objet IPP ignore la valeur, à moins que cela ne viole la politique de sécurité. Voir la description des valeurs "hors-bande" au début du paragraphe 4.1.

Cette opération FACULTATIVE permet à un client de mettre en garde une tâche en instance dans la file d’attente de sorte qu’elle n’est pas éligible pour la programmation. Si l’opération Mettre-la-tâche-en-garde est prise en charge, l’opération Libération-de-tâche DOIT alors être prise en charge, et vice-versa. L’attribut d’opération FACULTATIF "mettre-la-tâche-en-garde-jusqu’à" permet à un client de spécifier de garder la tâche indéfiniment ou jusqu’à un instant spécifié, s’il est pris en charge.

L’objet IPP DOIT accepter ou rejeter la demande sur la base de l’état en cours de la tâche et passer la tâche au nouvel état comme suit :

Règle 1 : Si la mise en œuvre prend en charge plusieurs causes pour qu’une tâche soit dans l’état 'gardé-en-instance', l’objet IPP DOIT ajouter la valeur 'mettre-la-tâche-en-garde-jusqu’à-spécifié' à l’attribut "causes-d’état-de-tâche" de la tâche.

Règle 2 : Si l’objet IPP prend en charge l’attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" , mais que la période de temps spécifiée a déjà commencé (ou a la valeur 'pas-de-mise-en-garde') et qu’il n’y a pas d’autres raisons de mettre la tâche en garde, l’objet IPP DOIT faire que la tâche soit candidate à un traitement immédiat (voir au paragraphe 4.2.2) en mettant la tâche dans l’état 'en-instance'.

Note : Dans le but de conserver une certaine simplicité à l’opération Mettre-la-tâche-en-garde, une telle demande est rejetée lorsque la tâche est dans les états 'traitement-en-cours' ou 'traitement-arrêté'. Si une opération est nécessaire pour mettre les tâches en garde alors quelles sont dans ces états, elle devra être ajoutée comme opération supplémentaire, plutôt que de chevaucher l’opération Mettre-la-tâche-en-garde. Les clients voient alors clairement quelles opérations sont possibles en interrogeant les attributs "opérations-prises-en-charge" de l’objet imprimante (voir au paragraphe 4.4.15) et "état-de-tâche" de l’objet Tâche (voir au paragraphe 4.3.7).

Droits d’accès : L’utilisateur authentifié (voir au paragraphe 8.3) effectuant cette opération doit être le propriétaire de la tâche ou un opérateur ou administrateur de l’objet imprimante (voir aux paragraphes 1 et 8.5). Autrement, l’objet IPP DOIT rejeter l’opération et retourner 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas approprié.

Les groupes et attributs d’opération sont les mêmes que pour une demande Annuler-la-tâche (voir au paragraphe 3.3.3.1), avec l’ajout de l’attribut d’opération de Groupe 1 suivant :

Le client fournit FACULTATIVEMENT cet attribut d’opération. L’objet IPP DOIT prendre en charge cet attribut d’opération dans une demande Mettre-la-tâche-en-garde, si il prend en charge l’attribut de gabarit de tâche "mettre-la-tâche-en-garde-jusqu’à" dans les opérations de création. Voir au paragraphe 4.2.2. L’objet IPP DEVRAIT prendre en charge l’attribut de gabarit de tâche "mettre-la-tâche-en-garde-jusqu’à" pour l’utiliser dans les opérations de création de tâche avec au moins la valeur 'indéfini', s’il prend en charge l’opération Mettre-la-tâche-en-garde. Autrement, un client ne peut pas créer une tâche et la mettre immédiatement en garde (sans trouver une période de prise en charge dans le futur).

S’il est fourni et pris en charge comme spécifié dans l’attribut "mettre-la-tâche-en-garde-jusqu’à-pris-en-charge" de l’imprimante, l’objet IPP copie l’attribut d’opération fourni à l’objet Tâche, replaçant l’attribut précédent "mettre-la-tâche-en-garde-jusqu’à" de la tâche, s’il est présent, et fait de la tâche un candidat à la programmation durant la période fournie désignée.

S’il est fourni, mais que l’attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" lui-même ou la valeur fournie, n’est pas pris en charge, l’objet IPP accepte la demande, retourne l’attribut ou la valeur non pris en charge dans le groupe des attributs non acceptés conformément au paragraphe 3.1.7, retourne 'réussite-ok-mais-attributs-substitués-ou-ignorés, et met la tâche en garde pour une durée indéfinie jusqu’à ce qu’un client effectue une opération Libération-de-tâche ultérieure.

Si le client (1) fournit une valeur qui spécifie une période de temps qui a déjà commencé ou la valeur 'pas-de-mise-en-garde' (signifiant ne pas mettre la tâche en garde) et si (2) l’objet IPP prend en charge l’attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" et qu’il n’y a pas d’autre raison de mettre la tâche en garde, l’objet IPP DOIT accepter l’opération et faire de la tâche un candidat au traitement immédiat (voir au paragraphe 4.2.2).

Si le client ne fournit pas un attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" dans la demande, l’objet IPP DOIT remplir l’objet Tâche avec un attribut "mettre-la-tâche-en-garde-jusqu’à" avec la valeur 'indéfini' (si l’objet IPP prend en charge l’attribut "mettre-la-tâche-en-garde-jusqu’à") et mettre la tâche en garde indéfiniment, jusqu’à ce qu’un client effectue une opération Libération-de-tâche.

Les groupes et attributs sont les mêmes que pour une réponse à Annuler-la-tâche (voir au paragraphe 3.3.3.2).

Cette opération FACULTATIVE permet à un client de libérer une tâche précédemment mise en garde de sorte qu’elle soit de nouveau éligible pour la programmation. Si l’opération Mettre-la-tâche-en-garde est prise en charge, l’opération Libération-de-tâche DOIT alors être prise en charge, et vice-versa.

Cette opération retire l’attribut de tâche "mettre-la-tâche-en-garde-jusqu’à", s’il est présent, de l’objet Tâche qui avait été fourni dans l’opération de création ou dans la plus récente opération Mettre-la-tâche-en-garde ou Redémarrage-de-tâche et efface ses effets sur la tâche. L’objet IPP DOIT retirer la valeur 'mettre-la-tâche-en-garde-jusqu’à-spécifié' de l’attribut "causes-d’état-de-tâche" de la tâche, s’il est présent. Voir au paragraphe 4.3.8.

L’objet IPP DOIT accepter ou rejeter la demande sur la base de l’état en cours de la tâche et passer la tâche au nouvel état indiqué comme suit :

Règle 1 : si il y a d’autres raisons pour garder la tâche dans l’état 'gardé-en-instance', telles que 'ressources-pas-prêtes', la tâche reste dans l’état 'gardé-en-instance'. Et donc, l’état 'gardé-en-instance' n’est pas seulement pour les tâches à qui s’applique 'mettre-la-tâche-en-garde-jusqu’à', mais aussi pour toute raison d’empêcher la tâche d’être candidate à la programmation et au traitement, telle que 'ressources-pas-prêtes'. Voir l’attribut "tâche-en-garde-jusqu’à" (section 4.2.2).

Droits d’accès : l’utilisateur authentifié (voir au paragraphe 8.3) qui effectue cette opération doit être le propriétaire de la tâche ou un opérateur ou administrateur de l’objet imprimante (voir aux paragraphes 1 et 8.5). Autrement, l’objet IPP DOIT rejeter l'opération et retourner 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas approprié.

La demande de Libération-de-tâche et la réponse à Libération-de-tâche ont les mêmes groupes d’attributs et attributs que l’opération Annuler-la-tâche (voir aux paragraphes 3.3.3.1 et 3.3.3.2).

Cette opération FACULTATIVE permet à un client de redémarrer une tâche qui est retenue dans la file d’attente après la fin du traitement (voir au paragraphe 4.3.7.2).

La tâche est passée à l’état de tâche 'en-instance' ou 'gardé-en-instance' et redémarre au début sur le même objet imprimante IPP avec les mêmes valeurs d’attribut. Si un des documents de la tâche a été passé en référence (URI-d’imprimante ou URI-d’envoi), l’imprimante DOIT retourner chercher les données, car la sémantique de Redémarrer-la -tâche est de répéter tout traitement de tâche. Les attributs de description de tâche qui cumulent l’avancement de la tâche, tels que "tâches-d’impression-terminées", "feuilles de support de tâche t", et "k octets de tâche traités", DOIVENT être remis à 0 de sorte qu’ils puissent donner une image appropriée de la tâche depuis son point de redémarrage. L’objet Tâche DOIT continuer à utiliser les mêmes valeurs d’attribut "uri-de-tâche" et "id-de-tâche".

Note : Si à l’avenir est nécessaire une opération qui ne remet pas à zéro les attributs d’avancement de la tâche, une nouvelle opération devra alors être définie pour faire une copie de la tâche, allouer un nouvel "uri-de-tâche" et "id-de-tâche" à la copie et remettre les attributs d’avancement de la tâche uniquement dans la nouvelle copie.

L’objet IPP DOIT accepter ou rejeter la demande sur la base de l’état en cours de la tâche, passer la tâche au nouvel état indiqué comme suit :

Règle 1 : si la période de rétention de tâche est arrivée à expiration pour la tâche dans cet état, l’objet IPP rejette alors l’opération. Voir au paragraphe 4.3.7.2.

Note : Afin d’empêcher qu’un usager ne redémarre par inadvertance une tâche en son milieu, la demande Redémarrer-la-tâche est rejetée lorsque la tâche est dans les états 'traitement-en-cours' ou 'traitement-arrêté'. Si dans le futur une opération est nécessaire pour mettre en garde ou redémarrer des tâches qui sont dans ces états, il faudra ajouter une opération supplémentaire, plutôt que de surcharge l’opération Redémarrer-la-tâche, de sorte qu’il soit clair que l’usager a bien l’intention que la tâche en cours ne soit pas terminée.

Droits d’accès : l’utilisateur authentifié (voir au paragraphe 8.3) qui effectue cette opération doit être le propriétaire de la tâche ou un opérateur ou administrateur de l’objet imprimante (voir au paragraphes 1 et 8.5). Autrement, l’objet IPP DOIT rejeter l’opération et retourner 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas approprié.

Les groupes et attributs sont les mêmes que pour une demande Annuler-la-tâche (voir au paragraphe 3.3.3.1), avec l’ajout de l’attribut d’opération de Groupe 1 suivant :

"mettre-la-tâche-en-garde-jusqu’à" (type3 mot-clé | nom(MAX)) : le client fournit FACULTATIVEMENT cet attribut. L’objet IPP DOIT prendre en charge cet attribut d’opération dans une demande Redémarrer-la-tâche, s’il prend en charge l’attribut de gabarit de tâche "mettre-la-tâche-en-garde-jusqu’à" dans les opérations de création. Voir au paragraphe 4.2.2. Autrement, l’objet IPP PEUT NE PAS prendre en charge l’attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" dans une demande Redémarrer-la-tâche.

S’il est fourni et pris en charge comme spécifié dans l’attribut "mettre-la-tâche-en-garde-jusqu’à-pris-en-charge" de l’imprimante, l’objet IPP copie l’attribut d’opération fourni à l’objet Tâche, en remplaçant l’attribut précédent "mettre-la-tâche-en-garde-jusqu’à" de la tâche, s’il est présent, et fait de la tâche un candidat à la programmation durant la période de temps désignée qui est fournie. Voir au paragraphe 4.2.2.

S’il est fourni, mais que la valeur n’est pas pris en charge, l’objet IPP accepte la demande, retourne l’attribut ou valeur non pris en charge dans le groupe des attributs non acceptés conformément au paragraphe 3.1.7, retourne le code d’état 'réussite-ok-mais-attributs-substitués-ou-ignorés', et met la tâche en garde indéfiniment jusqu’à ce qu’un client effectue une opération Libération-de-tâche ultérieure.

S’il est fourni, mais que l’attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" n’est pas lui-même pris en charge, l’objet IPP accepte la demande, retourne l’attribut non accepté avec la valeur hors-bande 'non-accepté' dans le groupe des attributs non acceptés conformément au paragraphe 3.1.7, retourne le code d’état 'réussite-ok-mais-attributs-substitués-ou-ignorés', et redémarre la tâche, c’est-à-dire, ignore l’attribut "mettre-la-tâche-en-garde-jusqu’à".

Si le client (1) fournit une valeur qui spécifie une période de temps qui a déjà débuté ou la valeur 'pas-de-mise-en-garde' (qui signifie de ne pas mettre la tâche en garde) et (2) l’objet IPP prend en charge l’attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" et s’il n’y a pas d’autre raison de mettre la tâche en garde, l’objet IPP fait de la tâche un candidat au traitement immédiat (voir au paragraphe 4.2.2).

Si le client ne fournit pas un attribut d’opération "mettre-la-tâche-en-garde-jusqu’à" dans la demande, l’objet IPP retire de la tâche l’attribut "mettre-la-tâche-en-garde-jusqu’à", s’il est présent. S’il n’y a pas d’autre raison de mettre la tâche en garde, l’opération Redémarrer-la-tâche fait de la tâche un candidat au traitement immédiat (voir au paragraphe 4.2.2).

Les groupes et attributs sont les mêmes que pour une réponse à Annuler-la-tâche (voir au paragraphe 3.3.3.2).

Note : Une opération FACULTATIVE Modifier-la-tâche ou Régler-les-attributs-de-tâche pourrait être spécifiée à l’avenir, permettant au client de modifier d’autres attributs avant de libérer la tâche redémarrée.

4. Attributs d’objet

La présente section décrit les attributs avec leurs syntaxes et valeurs d’attribut correspondantes qui font partie du modèle IPP. Les paragraphes qui suivent montrent les objets et leurs attributs associés qui sont inclus dans le domaine d’application du présent protocole. Nombre de ces attributs sont dérivés d’autres documents pertinents :

- Application d’impression de document (DPA, Document Printing Application) [ISO10175]

Chaque attribut est identifié de façon univoque dans ce document en utilisant un "mot-clé" (voir au paragraphe 12.2.1) qui est le nom de l’attribut. Le mot-clé est inclus dans l’en-tête du paragraphe qui décrit l’attribut.

Note : Les mots-clé ne sont pas seulement utilisés pour identifier les attributs, mais une des syntaxes d’attribut décrites ci-dessous est "mot-clé", de sorte que certains attributs ont des valeurs de mot-clé. Donc, ces attributs sont définis comme ayant une syntaxe d’attribut qui est un ensemble de mots-clé.

4.1 Syntaxes d’attribut

Ce paragraphe définit les types de base de syntaxe d’attribut que tous les clients et objets IPP DOIVENT respectivement être capables d’accepter dans les réponses et accepter dans les demandes. Chaque description d’attribut des sections 3 et 4 inclut le nom de la ou des syntaxes d’attribut dans l’en-tête (entre parenthèses). Une mise en œuvre conforme d’un attribut DOIT inclure la sémantique de la ou des syntaxes d’attribut ainsi identifiée. Le paragraphe 6.3 décrit comment le protocole peut être étendu avec de nouvelles syntaxes d’attribut.

Les syntaxes d’attribut sont spécifiées dans les paragraphes suivants, où l’en-tête de paragraphe est le nom de mot-clé de la syntaxe d’attribut entre les guillemets simple. Dans les demandes et réponses d’opération, chaque valeur d’attribut DOIT être représentée comme une des syntaxes d’attribut spécifiées dans l’en-tête du paragraphe pour l’attribut. De plus, la valeur d’un attribut dans une réponse (mais ne l’est pas dans une demande) PEUT être une des valeurs "hors-bande" dont les règles particulières de codage sont définies dans le document "Codage et Transport" [RFC2910].

'inconnu' : L’attribut est pris en charge par l’objet IPP, mais la valeur est inconnue de l’objet IPP pour une raison quelconque.

'non-accepté' : L’attribut n’est pas pris en charge par l’objet IPP. Cette valeur ne DOIT être retournée que comme valeur d’un attribut dans le groupe des attributs non acceptés.

'pas-de-valeur' : L’attribut est pris en charge par l’objet imprimante, mais l’administrateur n’a pas encore configuré une valeur.

Tous les attributs dans une demande DOIVENT avoir une ou plusieurs valeurs telles que défini dans les paragraphes 4.2 à 4.4. Et donc les clients NE DOIVENT PAS fournir des attributs avec des valeurs "hors-bande" pour les opérations définies dans ce document. Tous les attributs dans une réponse DOIVENT avoir une ou plusieurs valeurs telles que défini dans les paragraphes 4.2 à 4.4 ou une seule valeur "hors-bande".

La plupart des attributs sont définis comme ayant une seule syntaxe d’attribut. Cependant, quelques attributs (par exemple, "feuille-de-tâche", "support", "mettre-la-tâche-en-garde-jusqu’à") sont définis comme ayant plusieurs syntaxes d’attribut, selon la valeur. Ces syntaxes d’attribut multiples sont séparées par le caractère "|" dans l’en-tête de paragraphe pour indiquer le choix. Comme chaque valeur DOIT être étiquetée avec sa syntaxe d’attribut dans le protocole, une instance d’attribut à une seule valeur peut avoir n’importe laquelle de ses syntaxes d’attribut et une instance d’attribut multi-valeur peut avoir un mélange de ses syntaxes d’attribut définies.

Tout attribut texte est un attribut dont la valeur est une séquence de zéro ou plus caractères codés dans un maximum de 1023 ('MAX') octets. MAX est la longueur maximum pour chaque valeur de tout attribut texte. Cependant, si un attribut va toujours contenir des valeurs dont la longueur maximum est très inférieure à MAX, la définition de cet attribut va inclure un qualificatif qui définit la longueur maximum pour les valeurs de cet attribut. Par exemple, l’attribut "localisation-d’imprimante" est spécifié comme "localisation-d’imprimante (texte(127))". Dans ce cas, les valeurs de texte pour "localisation-d’imprimante" NE DOIVENT PAS excéder 127 octets ; s’il est fourni avec une plus longue chaîne de texte via quelque interface externe (autre que le protocole), les mises en œuvre ont toute liberté pour le raccourcir à cette limite de longueur.

Dans le présent document, tous les attributs texte sont définis en utilisant la syntaxe 'texte'. Cependant, 'texte' est utilisé seulement pour faire court ; l’interprétation formelle de 'texte' est : 'texteSansLangage | texteAvecLangage'. C’est-à-dire, pour tout attribut défini dans le présent document en utilisant la syntaxe d’attribut 'texte', tout objet et client IPP DOIT prendre en charge les deux syntaxes d’attribut 'texteSansLangage' et 'texteAvecLangage'. Cependant, dans l’utilisation réelle et l’exécution du protocole, les objets et clients acceptent et retournent une seule des deux syntaxes par attribut. La syntaxe 'texte' n’apparaît jamais dans le monde réel.

'texteSansLangage' et 'texteAvecLangage' sont tous deux nécessaires pour prendre en charge les besoins réels d’interopérabilité entre les sites et les systèmes qui utilisent différents langages naturels comme base de communication humaine. Généralement, un langage naturel s’applique à tout attribut texte dans une demande ou réponse donnée. Le langage est indiqué par l’attribut d’opération "langage-naturel-des-attributs" défini au paragraphe 3.1.4 ou l’attribut de tâche "langage-naturel-des-attributs" défini au paragraphe 4.3.20, et il n’y a pas de besoin d’identifier le langage naturel pour chaque chaîne de texte valeur par valeur. Dans ces cas, la syntaxe d’attribut 'texteSansLangage' est utilisée pour les attributs texte. Dans d’autres cas, le client a besoin de fournir, ou l’objet imprimante a besoin de retourner, une valeur texte dans un langage naturel différent du reste des valeurs texte dans la demande ou réponse. Dans ces cas, le client ou objet Imprimante utilise la syntaxe d’attribut 'texteAvecLangage' pour les attributs de texte (‘est le mécanisme Outrepasser le langage naturel décrit au paragraphe 3.1.4).

Les syntaxes d’attribut 'texteSansLangage' et 'texteAvecLangage' sont décrites plus en détail dans les paragraphes qui suivent.

La syntaxe 'texteSansLangage' indique une valeur qui est une séquence de zéro ou plus caractères codés dans un maximum de 1023 (MAX) octets. Les chaînes de texte sont codées en utilisant les règles d’un ensemble de caractères (charset) quelconque. L’objet Imprimante DOIT prendre en charge le charset UTF-8 [RFC2279] et PEUT prendre en charge des charsets supplémentaires pour représenter des valeurs 'texte', pourvu que les charsets soient enregistrés auprès de l’IANA [IANA-CS]. Voir au paragraphe 4.1.7 la définition de la syntaxe d’attribut "charset", y compris la sémantique interdite et des exemples de charsets.

La syntaxe d’attribut 'texteAvecLangage' est une syntaxe d’attribut composite consistant en deux parties : une partie 'texteSansLangage' codée sur un maximum de 1023 (MAX) octets plus une partie supplémentaire 'langageNaturel' (voir au paragraphe 4.1.8) qui outrepasse le langage naturel en vigueur. La partie 'langageNaturel' identifie explicitement le langage naturel qui s’applique à la partie texte de cette valeur et à cette seule valeur. Pour tout attribut texte donné, la partie 'texteSansLangage' est limitée à la longueur maximum définie pour cet attribut 'texte', et la partie 'langageNaturel' est toujours limitée à 63 octets (supplémentaires). Utiliser la syntaxe d’attribut 'texteAvecLangage' plutôt que la syntaxe normale 'texteSansLangage' est ce qu’on appelle le mécanisme Outrepasser le langage naturel et il DOIT être pris en charge par tout objet et client IPP.

Si l’attribut est multi-valeur (1setOf texte), la syntaxe d’attribut 'texteAvecLangage' DOIT alors être utilisée pour spécifier explicitement chaque valeur d’attribut dont le langage naturel a besoin d’être outrepassé. D’autres valeurs dans un attribut multi-valeur 'texte' dans une demande ou une réponse repassent au langage naturel de l’attribut d’opération.

Dans une demande de création, l’objet imprimante DOIT accepter et mémoriser avec l’objet Tâche tout langage naturel dans l’attribut d’opération "langage-naturel-des-attributs", que l’objet imprimante prenne en charge ce langage naturel ou non. De plus, l’objet imprimante DOIT accepter et mémoriser toute valeur d’attribut 'texteAvecLangage', que l’objet imprimante prenne en charge ce langage naturel ou non. Ces exigences sont indépendantes de la valeur de l’attribut d’opération "fidélité-d’attribut-ipp" que le client PEUT fournir.

Exemple : Si le client fournit l’attribut d’opération "langage-naturel-des-attributs" avec la valeur : 'en' indiquant l’anglais, mais que la valeur de l’attribut "nom-de-tâche" est en français, le client DOIT utiliser la syntaxe d’attribut 'texteAvecLangage' avec les deux valeurs suivantes :

Voir le document "codage et Transport" [RFC2910] au paragraphe 3.9, pour le codage des deux parties, et à l’Appendice A pour un exemple détaillé de la syntaxe d’attribut de 'texteAvecLangage'.

Ce type de syntaxe est utilisé pour les chaînes faciles à mémoriser, telles qu’un nom d’imprimante, qui pour des humains, est plus significatif que des identifiants. Les noms ne sont jamais traduits d’un langage naturel à un autre. La syntaxe d’attribut de 'nom' est essentiellement la même que celle de 'texte', y compris la prise en charge EXIGÉE d’UTF-8 sauf que la séquence de caractères est limitée car sa forme codée NE DOIT PAS dépasser 255 (MAX) octets.

Comme 'texte', 'nom' est en réalité une notation abrégée pour 'nomSansLangage' ou 'nomAvecLangage'. C’est-à-dire que tout objet et client IPP DOIT prendre en charge les deux syntaxes d’attribut 'nomSansLangage' et 'nomAvecLangage'. Cependant, dans l’utilisation réelle et l’exécution de protocole, les objets et clients acceptent et retournent seulement une des deux syntaxes par attribut. La syntaxe 'nom' n’apparaît jamais dans la vie réelle.

Seules les syntaxes d’attribut 'texte' et 'nom' permettent le mécanisme Outrepasser le langage naturel.

Certains attributs sont définis comme 'type3 mot-clé | nom'. Ces attributs prennent en charge des valeurs qui sont des mots-clé de type3 ou des noms. Ce mécanisme de syntaxe duale permet à un administrateur de site d’étendre ces attributs pour qu’ils puissent légalement inclure des valeurs qui sont définies localement par l’administrateur de site. De tels noms ne sont pas enregistrés auprès de l’IANA.

La syntaxe de 'nomSansLangage' indique une valeur qui est une séquence de zéro ou plusieurs caractères codés dans un maximum de 255 (MAX) octets.

La syntaxe d’attribut 'nomAvecLangage' est une syntaxe d’attribut composite qui consiste en deux parties : une partie 'nomSansLangage' codée sur un maximum de 1023 (MAX) octets plus une partie supplémentaire 'langageNaturel' (voir au paragraphe 4.1.8) qui outrepasse le langage naturel en vigueur. La partie 'langageNaturel' identifie explicitement le langage naturel qui s’applique à cette valeur de nom et seulement à cette valeur de nom. Pour tout attribut texte donné, la partie 'texteSansLangage' est limitée à la longueur maximum définie pour cet attribut 'texte', et la partie 'langageNaturel' est toujours limitée à 63 octets (supplémentaires). Utiliser la syntaxe d’attribut 'texteAvecLangage' plutôt que la syntaxe normale 'texteSansLangage' est ce qu’on appelle le mécanisme Outrepasser le langage naturel et DOIT être pris en charge par tout objet et client IPP.

La syntaxe d’attribut 'nomAvecLangage' se comporte de la même façon que la syntaxe de 'texteAvecLangage'. Utiliser la syntaxe d’attribut 'texteAvecLangage' plutôt que la syntaxe normale 'texteSansLangage' est ce qu’on appelle le mécanisme Outrepasser le langage naturel et DOIT être pris en charge par tout objet et client IPP. Si un nom est dans un langage qui est différent du reste de l’objet ou opération, cette syntaxe 'nomAvecLangage' est alors utilisée plutôt que la syntaxe générique 'nomSansLangage'.

Si l’attribut est multi-valeur (1setOf texte), la syntaxe d’attribut 'nomAvecLangage' DOIT être utilisée pour spécifier explicitement chaque valeur d’attribut dont le langage naturel doit être outrepassé.

Les autres valeurs dans un attribut multi-valeur 'nom' dans une demande ou une réponse repassent au langage naturel de l’attribut d’opération.

Dans une demande de création, l’objet imprimante DOIT accepter et mémoriser avec l’objet Tâche tout langage naturel dans l’attribut d’opération "langage-naturel-des-attributs", que l’objet imprimante prenne en charge ce langage naturel ou non. De plus, l’objet imprimante DOIT accepter et mémoriser toute valeur d’attribut 'nomAvecLangage', que l’objet imprimante prenne en charge ce langage naturel ou non. Ces exigences sont indépendantes de la valeur de l’attribut d’opération "fidélité-d’attribut-ipp" que le client PEUT fournir.

Exemple : Si le client fournit l’attribut d’opération "langage-naturel-des-attributs" avec la valeur : 'en' indiquant l’anglais, mais que l’attribut "nom-d’imprimante" est en allemand, le client DOIT utiliser la syntaxe d’attribut 'nomAvecLangage' comme suit :

Voir le document "Codage et Transport" [RFC2910] paragraphe 3.9 pour le codage des deux parties et l’Appendice A pour un exemple détaillé de la syntaxe d’attribut 'nomAvecLangage'.

Pour rechercher l’égalité des valeurs d’attribut de deux 'nom', comme dans la validation de tâche (où la valeur fournie par le client pour l’attribut "xxx" est vérifiée pour voir si la valeur est parmi les valeurs correspondantes de l’attribut "xxx-pris-en-charge" de l’objet imprimante), les règles de correspondance suivantes s’appliquent :

2. les valeurs de 'nom' (nomSansLangage et nomAvecLangage) correspondent si (1) la partie nom correspond et (2) les parties Langage-naturel associées (voir au paragraphe 3.1.4.1) correspondent. Les règles de correspondance sont :

a. les parties nom correspondent si les deux noms sont identiques caractère par caractère, excepté qu’il est RECOMMENDÉ d’ignorer la casse. Par exemple: 'Ajax-letter-head-white' DOIT correspondre à 'Ajax-letter-head-white' et DEVRAIT correspondre à 'ajax-letter-head-white' et à 'AJAX-LETTER-HEAD-WHITE'.

b. les parties Langage-naturel associées correspondent si la plus courte des deux satisfait aux exigences syntaxiques de la RFC 1766 [RFC1766] et correspond octet par octet avec la plus longue. Par exemple, 'en' correspond à 'en', 'en-us' et 'en-gb', mais ne correspond ni à 'fr' ni à 'e'.

La syntaxe d’attribut 'mot-clé' est une séquence de caractères, de longueur de 1 à 255, contenant uniquement les valeurs US-ASCII [ASCII] codées des lettres minuscules ("a" - "z"), des chiffres ("0" - "9"), trait d’union ("-"), point ("."), et souligné ("_"). Le premier caractère DOIT être une minuscule. De plus, les mots-clé DOIVENT être en U.S. English.

Ce type de syntaxe est utilisé pour énumérer les identifiants sémantiques des entités du protocole abstrait, c’est-à-dire, les entités identifiées dans le présent document. Les mots-clé sont utilisés comme noms d’attribut ou valeurs d’attributs. A la différence des valeurs d’attribut 'texte' et 'nom', les valeurs de 'mot-clé' NE DOIVENT PAS utiliser le mécanisme Outrepasser le langage naturel, car elles DOIVENT toujours être en US-ASCII et anglais U.S.

Les mots-clé sont à utiliser dans le protocole. Une interface d’utilisateur fournira vraisemblablement une transposition entre les mots-clé du protocole et les mots et phrases affichables de façon compréhensible qui sont localisés dans le langage naturel de l’utilisateur. Alors que les mots-clé spécifiés dans le présent document PEUVENT être affichés pour les utilisateurs dont le langage naturel est l’anglais U.S, ils PEUVENT être transposés dans d’autres mots d’anglais U.S pour les utilisateurs d’anglais U.S, car l’interface d’utilisateur sort du domaine d’application du présent document.

Dans la définition de chaque attribut de type syntaxique figure la liste de l’ensemble complet des valeurs de mot-clé définies pour cet attribut.

Lorsqu’un mot-clé est utilisé pour représenter un attribut (son nom), il DOIT être unique dans l’ensemble du domaine des objets et attributs IPP. Lorsqu’un mot-clé est utilisé pour représenter une valeur d’un attribut, il DOIT être unique simplement dans le domaine de cet attribut. C’est-à-dire que le même mot-clé NE DOIT PAS être utilisé pour deux valeurs différentes au sein du même attribut pour signifier deux idées sémantiques différentes. Cependant, le même mot-clé PEUT être utilisé à travers deux attributs ou plus, représentant des idées sémantiques différentes pour chaque attribut. Le paragraphe 6.1 décrit comment le protocole peut être étendu avec de nouvelles valeurs de mot-clé. Exemples de mots-clé de nom d’attribut :

Note : Le présent document utilise les préfixes "type1", "type2", et "type3" pour la syntaxe de base de "mot-clé" pour indiquer différents niveaux de révision d’extensions (voir au paragraphe 6.1).

La syntaxe d’attribut 'enum' est une valeur d’entier énumérée qui est dans la gamme de 1 à 2**31 - 1 (MAX). Chaque valeur a un nom de 'mot-clé' associé. Dans la définition de chaque attribut de ce type syntaxique figure la liste de l’ensemble complet des valeurs possibles pour cet attribut. Ce type syntaxique est utilisé pour les attributs pour lesquels il y a des valeurs enum allouées par d’autres normes, telles que les MIB SNMP. Un certain nombre de valeurs d’attribut enum du présent document sont aussi utilisées pour les attributs correspondants dans d’autres normes [RFC1759]. Ce type syntaxique n’est pas utilisé pour les attributs auxquels l’administrateur peut allouer des valeurs. Le paragraphe 6.1 décrit comment le protocole peut être étendu avec de nouvelles valeurs enum.

Les valeurs enum sont à utiliser dans le protocole. Une interface d’utilisateur fournira une transposition entre les valeurs enum du protocole et les mots et phrases faciles à mémoriser par l’utilisateur à l’affichage qui sont situées dans le langage naturel de l’utilisateur. Alors que les symboles enum spécifiés dans le présent document PEUVENT être affichés aux utilisateurs dont le langage naturel est l’anglais U.S, ils PEUVENT être transposés dans d’autres mots d’anglais U.S pour les utilisateurs d’anglais U.S, car l’interface d’utilisateur sort du domaine d’application du présent document.

Note : Les MIB SNMP utilisent '2' pour 'inconnu', ce qui correspond à la valeur 'inconnu' "hors-bande" d’IPP. Voir la description des valeurs "hors-bande" au début du paragraphe 4.1. Et donc, les attributs de type 'enum' commencent à '3'.

Note : Le présent document utilise les préfixes "type1", "type2", et "type3" pour la syntaxe de base "enum" pour indiquer différents niveaux de révision pour les extensions (voir au paragraphe 6.1).

La syntaxe d’attribut 'uri' est tout identifiant de ressource uniforme ou URI [RFC2396]. Le plus souvent, les URI sont simplement des localisateurs de ressource uniformes ou URL. La longueur maximum des URI utilisés comme valeurs d’attributs IPP est de 1023 octets. Bien que la plupart des autres types de syntaxe d’attribut IPP n’admettent que des valeurs de minuscules, ce type de syntaxe d’attribut se conforme aux règles de sensibilité et insensibilité à la casse spécifiées dans la [RFC2396]. Voir aussi [IPP-IIG] pour une discussion sur la casse dans les URI.

La syntaxe d’attribut 'uriScheme' est une séquence de caractères représentant un schéma d’URI conformément à la RFC 2396 [RFC2396]. Bien que la RFC 2396 exige que les valeurs soient insensibles à la casse, IPP exige que toutes les valeurs dans les attributs IPP soient en minuscules pour simplifier la comparaison par les clients IPP et les objets imprimante.

'https' : à utiliser avec les URI à schéma HTTPS (par exemple, "https:...") (pas normalisé par l’IETF)

Un objet Imprimante PEUT prendre en charge tout URI 'schéma' d’URI qui a été enregistré auprès de l’IANA [IANA-MT]. La longueur maximum des valeurs de 'schéma' d’URI utilisées pour représenter des valeurs d’attribut IPP est de 63 octets.

La syntaxe d’attribut 'charset' est un identifiant standard pour un charset. Un charset est un ensemble de caractères codé et de schéma de codage. Les charsets sont utilisés pour étiqueter le contenu de certains documents et valeurs d’attribut 'texte' et 'nom'. La syntaxe et la sémantique de cette syntaxe d’attribut sont spécifiées dans la RFC 2046 [RFC2046] et contenues dans le Registre des ensembles de caractères [IANA-CS] de l’IANA, conformément aux procédures de l’IANA [RFC2278]. Bien que la RFC 2046 exige que les valeurs soient de l’US-ASCII [ASCII] insensible à la casse, IPP exige que toutes les valeurs dans les attributs IPP soient en minuscules pour simplifier les comparaisons par les clients IPP et les objets imprimante. Lorsqu’un ensemble de caractères dans le registre de l’IANA a plus d’un nom (alias), le nom étiqueté comme "(nom MIME préféré)", s’il est présent, DOIT être utilisé.

La longueur maximum des valeurs de 'charset' utilisées pour représenter des valeurs d’attribut IPP est de 63 octets.

'utf-8' : Ensemble universel de caractères codés en multi-octet (UCS) de l’ISO 10646 représenté comme le schéma de codage de transfert UTF-8 [RFC2279] dans lequel l’US-ASCII est un sous-ensemble de charset.

'us-ascii' :Code américain standard à 7 bits pour les échanges d’informations (ASCII), de la norme ANSI X3.4-1986 [ASCII]. Cette norme définit l’US-ASCII, mais la RFC 2045 [RFC2045] élimine la plupart des caractères de contrôle pour une utilisation conforme dans MIME et IPP.

'iso-8859-1' : Ensemble de caractères codés à un octet/8 bits, Alphabet latin n° 1 [ISO8859-1]. Cette norme définit un ensemble de caractères codés qui est utilisé par les langues latines dans le monde occidental. L’US-ASCII est un sous-ensemble de ce charset.

Certaines descriptions d’attribut PEUVENT poser des exigences supplémentaires sur les valeurs de charset qui peuvent être utilisées, comme des valeurs EXIGÉES qui DOIVENT être prises en charge, ou des restrictions supplémentaires, comme d’exiger que les charset aient l’US- ASCII comme sous-ensemble de charset.

La syntaxe d’attribut 'langageNaturel' est un identifiant standard pour un langage naturel et facultativement pour un pays. Les valeurs pour ce type de syntaxe sont définies par la RFC 1766 [RFC1766]. Bien que la RFC 1766 exige que les valeurs soient de l’US-ASCII [ASCII] insensible à la casse, IPP exige que toutes les valeurs dans les attributs IPP soient en minuscules pour simplifier les comparaisons par les clients IPP et les objets imprimante.

La longueur maximum des valeurs de 'langageNaturel' utilisées pour représenter les valeurs d’attribut IPP est de 63 octets.

La syntaxe d’attribut 'typeDeSupportMime' est le type de support Internet (parfois appelé type MIME) comme défini par la RFC 2046 [RFC2046] et enregistré conformément aux procédures de la RFC 2048 [RFC2048] pour l’identification d’un format de document. La valeur PEUT inclure un paramètre charset, ou autre, selon la spécification du type de support dans le registre de l’IANA [IANA-MT]. Bien que la plupart des autres types de syntaxe IPP ne permettent que des valeurs en minuscules, ce type syntaxique permet des valeurs mixtes qui sont insensibles à la casse.

'texte/clair' : un document tout de texte en US-ASCII (la RFC 2046 indique que l’absence du paramètre charset DOIT signifier US-ASCII plutôt que simplement non spécifié) [RFC2046].

'texte/clair; charset=US-ASCII' : un document tout de texte en US-ASCII [52, 56].

'texte/clair; charset=ISO-8859-1' : un document tout de texte en ISO 8859-1 (Latin 1) [ISO8859-1].

'texte/clair; charset=utf-8': un document tout de texte en ISO 10646 représenté comme UTF-8 [RFC2279].

'application/vnd.hp-PCL' : un document PCL [IANA-MT] (la séquence d’échappement de charset est incorporée dans les données documentaires)

'application/pdf' : format de document portable (pdf)– voir le registre de type de support MIME de l’IANA.

La longueur maximum d’une valeur de 'typeDeSupportMime' pour représenter les valeurs d’attribut IPP est de 255 octets.

4.1.9.1 Application/flux-d’octets -- Auto-détection du format de document

'application/flux-d’octets' est d’un type particulier. Si l’objet imprimante prend en charge cette valeur, l’objet imprimante DOIT être capable d’auto-détecter le format des données documentaires en utilisant une méthode dépendant de la mise en œuvre qui examine un certain nombre d’octets des données documentaires, au titre de l’opération de création et/ou durant le traitement du document. Durant l’auto-détection, une imprimante peut déterminer que les données documentaires ont un format que l’imprimante ne reconnaît pas. Si l’imprimante détermine ce problème avant de retourner une réponse d’opération, elle rejette la demande et retourne le code d’état 'erreur-client-format-de-document-non-accepté'. Si l’imprimante détermine ce problème après avoir accepté la demande et retourné une réponse d’opération avec un des codes d’état de succès, l’imprimante ajoute la valeur 'format-de-document-non-accepté' à l’attribut "causes-d’état-de-tâche" de la tâche.

Si la valeur par défaut de l’attribut "format-de-document-par-défaut" de l’objet imprimante est mis à 'application/flux-d’octets', l’objet imprimante ne prend pas seulement en charge l’auto-détection du format de document, mais cela va dépendre du résultat de l’application de l’auto-détection lorsque le client ne fournit pas l’attribut "format-de-document". Si le client fournit une valeur de format de document, l’imprimante DOIT s’appuyer sur l’attribut fourni, plutôt que de se fier à son algorithme d’auto-détection.

1. Si le client ne fournit pas une valeur de format de document, l’imprimante DOIT s’appuyer sur son réglage de valeur par défaut (qui peut être 'application/flux-d’octets' indiquant un mécanisme d’auto-détection).

2. Si le client fournit une valeur autre que 'application/flux-d’octets', le client fournit des informations valides sur le format des données documentaires et l’objet imprimante DOIT se fier à la valeur fournie par le client plutôt qu’au résultat de l’application d’un mécanisme automatique de détection de format. Par exemple, le client peut demander l’impression d’un fichier PostScript comme document 'texte/clair'. L’objet Imprimante DOIT imprimer une représentation de texte des commandes PostScript plutôt que d’interpréter le flux des commandes PostScript et d’imprimer le résultat.

3. Si le client fournit une valeur de 'application/flux-d’octets', il indique que l’objet imprimante DOIT utiliser son mécanisme d’auto-détection sur les données documentaires fournies par le client que l’auto-détection soit la valeur par défaut de l’objet imprimante ou non.

Note : Dans la mesure où le mécanisme d’auto-détection est probabiliste, si les demandes du client sont à la fois auto-détection ("format-de-document" mis à 'application/flux-d’octets') et fidélité vraie ("fidélité-d’attribut-ipp" mis à 'vrai'), l’objet imprimante pourrait n’être pas capable de garantir exactement ce que voulait l’utilisateur final (l’algorithme d’auto-détection pourrait confondre un format de document avec un autre), mais il est capable de garantir que son mécanisme d’auto-détection sera utilisé.

Lorsqu’une imprimante effectue l’auto-détection d’un document dans une tâche qui lui est soumise, il est RECOMMANDÉ que l’imprimante indique à l’utilisateur qu’une telle auto-détection est survenue et quel format de document a été auto-détecté en imprimant cette information sur la feuille de début de tâche de la tâche.

La syntaxe d’attribut de 'octetString' est une séquence d’octets codée dans un maximum de 1023 octets qui est indiquée dans les en-têtes de paragraphes en utilisant la notation : octetString(MAX). Ce type de syntaxe est utilisé pour des données opaques.

La syntaxe d’attribut de 'booléen' n’a que deux valeurs : 'vrai' et 'faux'.

La syntaxe d’attribut de 'entier' est une valeur d’entier qui est dans la gamme de - 2**31 (MIN) à 2**31 - 1 (MAX). Chaque attribut individuel peut spécifier explicitement la contrainte de gamme dans les en-têtes de paragraphe si la gamme est différente de la gamme complète des valeurs d’entier possibles. Par exemple : priorité-de-tâche (entier(1:100)) pour l’attribut "priorité-de-tâche". Cependant, l’application de cette contrainte supplémentaire est à la discrétion de l’objet IPP, et non du protocole.

La syntaxe d’attribut de 'gammeD’Entier' est une paire ordonnée d’entiers qui définit une gamme inclusive de valeurs d’entier. Le premier entier spécifie la borne inférieure et le second spécifie la borne supérieure. Si une contrainte de gamme est spécifiée dans la description d’en-tête pour un attribut, dans le présent document, dont la syntaxe d’attribut est 'gammeD’Entier' (c’est-à-dire, 'X:Y' indiquant X comme valeur minimum et Y comme valeur maximum), la contrainte s’applique alors aux deux entiers.

La syntaxe d’attribut de 'dateHeure' est une longueur standard fixée, représentation sur onze octets de la syntaxe "DateEtHeure" telle que définie dans la RFC 2579 [RFC2579]. La RFC 2579 identifie aussi une représentation en huit octets d’une valeur "DateEtHeure", mais les objets IPP DOIVENT utiliser la représentation à onze octets. Une interface d’utilisateur fournira une mise en correspondance des valeurs de dateHeure du protocole et des valeurs et phrases de présentation affichables sous une forme agréable au lecteur qui sont dans le langage naturel et le format de date de l’utilisateur, y compris le fuseau horaire.

La syntaxe d’attribut de 'résolution' spécifie une résolution bi-dimensionnelle dans les unités indiquées. Elle consiste en trois valeurs : une résolution de direction d’alimentation croisée (valeur d’entier positif), une résolution de direction d’alimentation (valeur d’entier positif), et une valeur d’unités. La sémantique des ces trois composants est tirée des valeurs suggérées du MIB d’imprimante [RFC1759]. A savoir que le composant résolution de direction d’alimentation croisée est le même que l’objet prtMarkerAddressabilityXFeedDir dans le MIB d’imprimante, le composant résolution de direction d’alimentation est le même que prtMarkerAddressabilityFeedDir dans le MIB d’imprimante MIB, et le composant unités est le même que l’objet prtMarkerAddressabilityUnit dans le MIB d’imprimante (à savoir que '3' indique des points par pouce et '4' indique des points par centimètre). Toutes les trois valeurs DOIVENT être présentes même si les deux premières valeurs sont les mêmes. Par exemple : '300', '600', '3' indique une résolution de direction d’alimentation croisée de 300 dpi, une résolution de direction d’alimentation de 600 dpi, car '3' indique des points par pouce (dpi, dots per inch).

La syntaxe d’attribut de '1setOf X' est une ou plusieurs valeurs de type X de syntaxe d’attribut. Ce type de syntaxe est utilisé pour les attributs multi-valeur. Le type de syntaxe s’appelle '1setOf' plutôt que simplement 'setOf' pour rappeler que l’ensemble des valeurs NE DOIT PAS être vide (c’est-à-dire, un ensemble de taille 0). Les ensembles ne sont normalement pas ordonnés. Cependant chaque description d’attribut de ce type peut spécifier que les valeurs DOIVENT être dans un certain ordre pour cet attribut.

4.2 Attributs de gabarit de tâche

Les attributs de gabarit d’imprimante décrivent le comportement de traitement de tâche. La prise en charge des attributs de gabarit d’imprimante par un objet Imprimante est FACULTATIVE (voir au paragraphe 12.2.3 une description de prise en charge pour les attributs FACULTATIFS). Ainsi, les clients fournissent FACULTATIVEMENT les attributs de gabarit d’imprimante dans les demandes de création.

Les attributs de gabarit d’imprimante se conforment aux règles suivantes. Pour chaque attribut de gabarit de tâche appelé "xxx" :

1. Si l’objet imprimante prend en charge "xxx" il DOIT alors prendre en charge à la fois l’attribut "xxx-par-défaut" (à moins qu’il y ait "Non" dans le tableau ci-dessous) et un attribut "xxx-pris-en-charge". Si l’objet imprimante ne prend pas en charge "xxx", il ne DOIT alors prendre en charge ni un attribut "xxx-par-défaut" ni un attribut "xxx-pris-en-charge", et il DOIT traiter un attribut "xxx" fourni par un client comme non accepté. Un attribut "xxx" peut être pris en charge pour certains formats de document et non pris en charge pour d’autres formats de document. Par exemple, on s’attend qu’un objet Imprimante ne prenne en charge que"orientation-demandée" pour certains formats de document (tels que 'texte/clair' ou 'texte/html') mais pas d’autres (tels que 'application/postscript').

2. "xxx" est FACULTATIVEMENT fourni par le client dans une demande de création. Si "xxx" est fourni, le client indique un comportement souhaité de traitement de tâche pour cette tâche. Lorsque "xxx" n’est pas fourni, le client indique que l’objet imprimante applique son comportement de traitement de tâche par défaut à l’heure de traitement de tâche si le contenu du document ne contient pas une instruction incorporée indiquant un comportement se rapportant à xxx. Comme un administrateur PEUT changer l’attribut de valeur par défaut après la soumission d’un objet Tâche mais avant son traitement, la valeur par défaut utilisée par l’objet imprimante à l’heure du traitement de tâche peut être différente de la valeur par défaut effective à l’heure de la soumission de la tâche.

3. L’attribut "xxx-pris-en-charge" est un attribut d’objet Imprimante qui décrit quels comportements de traitement sont pris en charge par cet objet Imprimante. Un client peut interroger l’objet imprimante pour trouver quels comportements se rapportant à xxx sont pris en charge en inspectant les valeurs retournées de l’attribut "xxx-pris-en-charge".

Note : Le "xxx" dans chaque nom d’attribut "xxx-pris-en-charge" est unique, même si un attribut "xxx-pris-en-charge" a habituellement plus d’une valeur, comme "feuilles-de-tâche-prises-en-charge", à moins que l’attribut de gabarit de tâche "xxx" ne soit pluriel, tel que "finitions" ou "côtés". Dans de tels cas les noms d’attribut "xxx-pris-en-charge" sont : "finitions-prises-en-charge" et "côtés-pris-en-charge".

4. L’attribut de valeur par défaut "xxx-par-défaut" décrit ce qui sera fait à l’heure de traitement lorsque aucune autre information de traitement de tâche n’est fournie par le client (explicitement comme un attribut IPP dans la demande de création ou implicitement comme instruction incorporée dans les données documentaires).

Si une application souhaite présenter à l’utilisateur final une liste des valeurs prises en charge entre lesquelles il puisse faire un choix, l’application DEVRAIT interroger l’objet imprimante sur ses attributs de valeurs prises en charge. L’application DEVRAIT aussi interroger les attributs de valeur par défaut. Si l’application limite alors les valeurs éligibles aux seules valeurs prises en charge, l’application peut garantir que les valeurs fournies par le client dans la demande de création tombent toutes dans l’ensemble des valeurs prises en charge à l’imprimante. Lors de l’interrogation de l’imprimante, le client PEUT énumérer chaque attribut par son nom dans la demande Obtenir-les-attributs-d’imprimante, ou le client PEUT juste nommer le groupe de "gabarit-d’imprimante" afin d’obtenir l’ensemble complet des attributs pris en charge (à la fois les attributs pris en charge et par défaut).

L’attribut "finitions" est un exemple d’attribut de gabarit de tâche. Il peut prendre un ensemble de valeurs telles que 'agrafage', 'perforer', et/ou 'couvrir'. Un client peut interroger l’objet imprimante sur l’attribut "finitions-prises-en-charge" et l’attribut "finitions-par-défaut". L’attribut pris en charge contient un ensemble de valeurs prises en charge. L’attribut de valeur par défaut contient la ou les valeurs de finition qui seront utilisées pour une nouvelle tâche si le client ne fournit pas un attribut "finitions" dans la demande de création et que les données documentaires ne contiennent aucune instruction de finition correspondante. Si le client fournit l’attribut "finitions" dans la demande de création, l’objet IPP valide la ou les valeurs pour s’assurer qu’elles sont un sous-ensemble des valeurs prises en charge identifiées dans l’attribut "finitions-prises-en-charge" de l’objet imprimante. Voir au paragraphe 3.1.7.

Le tableau ci-dessous résume les noms et relations pour tous les attributs de gabarit d’imprimante. La première colonne du tableau (marquée "Attribut de tâche") montre le nom et la syntaxe de chaque attribut de gabarit de tâche dans l’objet Tâche. Ce sont les attributs qui peuvent facultativement être fournis par le client dans une demande de création. Les deux dernières colonnes (marquée "Imprimante : Attribut de valeur par défaut" et "Imprimante : Attribut de valeurs acceptées") montre le nom et la syntaxe de chaque attribut de gabarit de tâche dans l’objet imprimante (l’attribut de valeur par défaut et l’attribut des valeurs prises en charge). Un "Non" dans le tableau signifie que l’imprimante NE DOIT PAS prendre en charge l’attribut (c’est-à-dire que l’attribut est simplement non applicable). Pour abréger le tableau, les entrées 'texte' et 'nom' ne montrent pas la longueur maximum de chaque attribut.

Cet attribut spécifie une priorité pour la programmation de la tâche. Une valeur plus élevée spécifie une priorité plus élevée. La valeur 1 indique la plus faible priorité possible. La valeur 100 indique la plus forte priorité possible. Parmi les tâches qui sont prêtes à imprimer, une imprimante DOIT imprimer toutes les tâches ayant une valeur de priorité de n avant d’imprimer celles ayant une valeur de priorité de n-1 pour tout n.

Si l’objet imprimante prend en charge cet attribut, il DOIT toujours prendre en charge la gamme complète de 1 à 100. Aucune restriction administrative n’est permise. De cette façon, un utilisateur final peut toujours utiliser pleinement la gamme complète avec tout objet Imprimante. Si des tâches privilégiées sont mises en œuvre en-dehors de IPP/1.1, elles DOIVENT avoir des priorités supérieures à 100, plutôt que de restreindre la gamme disponible pour les utilisateurs finaux.

Si le client ne fournit pas cet attribut et que cet attribut est pris en charge par l’objet imprimante, l’objet imprimante DOIT utiliser la valeur "priorité-de-tâche-par-défaut" de l’objet imprimante à l’heure de soumission de tâche (à la différence de la plupart des attributs de gabarit d’imprimante qui sont utilisés si nécessaire à l’heure du traitement de tâche).

La syntaxe pour "priorité-de-tâche-prise-en-charge" est aussi un entier (1:100). Cette seule valeur d’entier indique le nombre de niveaux de priorité pris en charge. L’objet Imprimante DOIT prendre la valeur fournie par le client et la transposer dans le plus proche entier en une séquence de n valeurs d’entier qui sont également distribuées sur la gamme de 1 à 100 en utilisant la formule :

où n est la valeur de "priorité-de-tâche-prise-en-charge" et x va de 0 à n-1.

Par exemple, si n = 1, la séquence des valeurs est 50 ; si n = 2, la séquence des valeurs est : 25 et 75 ; si n = 3, la séquence des valeurs est : 17, 50 et 83 ; si n = 10, la séquence des valeurs est : 5, 15, 25, 35, 45, 55, 65, 75, 85, et 95 ; si n = 100, la séquence des valeurs est : 1, 2, 3, ... 100.

Si la valeur de "priorité-de-tâche-prise-en-charge de l’objet imprimante est 10 et les valeurs fournies par le client dans la gamme de 1 à 10, l’objet imprimante les transpose à 5, dans la gamme de 11 à 20, l’objet imprimante les transpose à 15, etc.

Cet attribut spécifie la période de temps désignée durant laquelle la tâche DOIT devenir candidate à l’impression.

'pas-de-mise-en-garde' : immédiatement, s’il n’y a pas d’autres raisons pour mettre la tâche en garde

'indéfini' : - la tâche est mise en garde pour une durée indéfinie, jusqu’à ce qu’un client effectue une Libération-de-tâche (paragraphe 3.3.6)

Un administrateur DOIT associer les horaires d’impression autorisés à une période de temps désignée (par des moyens qui sortent du domaine d’application du présent document IPP/1.1). Un administrateur est invité à prendre des noms suggérant le type de période. Un administrateur PEUT définir des valeurs supplémentaires en utilisant la syntaxe d’attribut 'nom' ou 'mot-clé', selon la mise en œuvre.

Si la valeur de cet attribut spécifie une période de temps dans le futur, l’imprimante DEVRAIT ajouter la valeur 'mettre-la-tâche-en-garde-jusqu’à-spécifié' à l’attribut "causes-d’état-de-tâche" de la tâche, DOIT passer la tâche à l’état 'gardé-en-instance', et NE DOIT PAS programmer la tâche pour impression jusqu’à ce qu’arrive la période spécifiée.

Lorsque arrive la période spécifiée, l’imprimante DOIT retirer la valeur 'mettre-la-tâche-en-garde-jusqu’à-spécifié' de l’attribut "causes-d’état-de-tâche" de la tâche, s’il est présent. S’il n’y a pas d’autre cause d’état de tâche qui garde la tâche dans l’état 'gardé-en-instance', l’imprimante DOIT considérer la tâche comme candidate au traitement en passant la tâche à l’état 'en-instance'.

Si cette valeur d’attribut de tâche est la valeur désignée 'pas-de-mise-en-garde', ou si la période de temps spécifiée a déjà commencé, la tâche DOIT être candidate à traitement immédiat.

Si le client ne fournit pas cet attribut et que cet attribut est pris en charge par l’objet imprimante, l’objet imprimante DOIT utiliser la valeur "mettre-la-tâche-en-garde-jusqu’à-par-défaut" de l’objet imprimante à l’heure de la soumission de tâche (à la différence de la plupart des attributs de gabarit d’imprimante qui sont utilisés si nécessaire à l’heure du traitement de tâche).

Cet attribut détermine quelles feuilles de début/fin de tâche, s’il en est, DOIVENT être imprimées avec une tâche.

'standard' : une ou plusieurs feuilles de tâches standard spécifiques du site sont imprimées, par exemple, une seule feuille de début, ou deux feuilles, de début et de fin, sont imprimées.

Un administrateur PEUT définir des valeurs supplémentaires en utilisant la syntaxe d’attribut 'nom' ou 'mot-clé', selon la mise en œuvre.

L’effet de cet attribut sur les tâches ayant plusieurs documents PEUT être affecté par l’attribut de tâche "traitement-de-document-multiple" (paragraphe 4.2.4), selon la sémantique de feuille de tâche.

Cet attribut n’est pertinent que si une tâche comporte deux documents ou plus. Cet attribut DOIT être pris en charge avec au moins une valeur si l’imprimante prend en charge plusieurs documents par tâche (voir aux paragraphes 3.2.4 et 3.3.1). L’attribut contrôle les opérations de finition et le placement d’une ou plusieurs pages de flux d’impression dans les impressions et sur les feuilles de support. Lorsque la valeur de l’attribut "copies" dépasse 1, il contrôle aussi l’ordre dans lequel les copies qui résultent du traitement des documents sont produites. Pour expliquer cela, si "a" représente une instance de données documentaires, le résultat du traitement des données dans le document "a" est une séquence de feuilles de support représentées par "a(*)".

'document-unique' : Si un objet Tâche a plusieurs documents, disons que les données documentaires sont appelées a et b, le résultat du traitement de toutes les données documentaires (a puis b) DOIT être traité comme une seule séquence de feuilles de support pour les opérations de finition ; c’est-à-dire que la finition devrait être effectuée par l’enchaînement des séquences a(*),b(*). L’objet Imprimante NE DOIT PAS forcer les données dans chaque instance de document à être formatées sur une nouvelle page de flux d’impression, ni commencer une nouvelle impression sur une nouvelle feuille de support. Si plus d’une copie est faite, l’ordre des ensembles de feuilles support résultant du traitement des données documentaires DOIT être a(*), b(*), a(*), b(*), avec début sur une nouvelle feuille support.

'documents-séparés-copies-non-colligées' : Si un objet Tâche a plusieurs documents, disons que les données documentaires s’appellent a et b, le résultat du traitement des données dans chaque instance de document DOIT être traité comme une seule séquence de feuilles support pour les opérations de finition; c’est-à-dire que les ensembles a(*) et b(*) devraient être finis séparément. L’objet Imprimante DOIT forcer chaque copie du résultat du traitement des données d’un même document à commencer sur une nouvelle feuille support. Si plus d’une copie est faite, l’ordre des ensembles de feuilles support résultant du traitement des données documentaires DOIT être a(*), a(*), ..., b(*), b(*) ... .

'documents-séparés-copies-colligées' : Si un objet Tâche a plusieurs documents, disons que les données documentaires sont appelées a et b, le résultat du traitement des données dans chaque instance de document DOIT être traité comme une seule séquence de feuilles support pour les opérations de finition ; c’est-à-dire que les ensembles a(*) et b(*) devraient être finis séparément. L’objet Imprimante DOIT forcer chaque copie du résultat du traitement des données d’un même document à commencer sur une nouvelle feuille support. Si plus d’une copie est faite, l’ordre des ensembles de feuilles support résultant du traitement des données documentaires DOIT être a(*), b(*), a(*), b(*), ... .

'document-unique-nouvelle-feuille' : Comme pour 'document-unique', sauf que l’objet imprimante DOIT s’assurer que la première impression de chaque instance de document dans la tâche est placé sur une nouvelle feuille support. Cette valeur permet que plusieurs documents soient agrafés ensemble avec une seule agrafe lorsque chaque document commence sur une nouvelle feuille.

La valeur 'document-unique' est la même que 'documents-séparés-copies-colligées' par rapport à l’ordre des pages du flux d’impression, mais pas pour la génération de feuilles support, car 'document-unique' va mettre la première page du prochain document sur le verso d’une feuille si un nombre impair de pages a été produit jusque là pour la tâche, alors que 'documents-séparés-copies-colligées' force toujours le prochain document ou copie de document sur une nouvelle feuille. De plus, si l’attribut "finitions" spécifie 'agrafer', alors avec 'document-unique', les documents a et b sont agrafés ensemble comme un seul document sans considération pour les nouvelles feuilles, avec 'document-unique-nouvelle-feuille', les documents a et b sont agrafés ensemble comme un seul document, mais le document b commence sur une nouvelle feuille, mais avec 'documents-séparés-copies-non-colligées' et 'documents-séparés-copies-colligées', les documents a et b sont agrafés séparément.

Note : Aucune de ces valeurs ne donne le moyen de produire des feuilles non colligées au sein d’un document, c’est-à-dire où plusieurs copies de la feuille n sont produites avant la feuille n+1 du même document.

Les relations de cet attribut et des autres attributs qui contrôlent le traitement du document sont décrites au paragraphe 15.3.

Sur de nombreux appareils le nombre de copies colligées pris en charge sera limité par le nombre de bacs physiques de sortie sur l’appareil, et peut être différent du nombre de copies non colligées qui peut être pris en charge.

Note : L’effet de cet attribut sur les tâches à documents multiples est contrôlé par l’attribut de tâche "traitement-de-documents-multiples" (paragraphe 4.2.4) et les relations de cet attribut et des autres attributs qui contrôlent le traitement du document sont décrites au paragraphe 15.3.

Cet attribut identifie les opérations de finition que l’imprimante utilise pour chaque copie de chaque document imprimé dans la tâche. Pour les tâches avec plusieurs documents, l’attribut "traitement-de-documents-multiples" détermine ce qui constitue une "copie" pour les besoins de la finition.

Les valeurs suivantes sont plus spécifiques ; elles indiquent un coin ou un côté comme si le document était en portrait (voir ci-dessous) :

Les valeurs 'agrafe-xxx' sont spécifiées par rapport au document comme si le document était en mode portrait. Si le document est en fait en paysage ou en paysage inversé, le client fournit la valeur transformée appropriée. Par exemple, pour positionner une agrafe dans le coin supérieur gauche d’un document en paysage qu’on tient pour le lire, le client fournit la valeur 'agrafe-bas-gauche' (car le paysage se définit comme une rotation de + 90 degrés de l’image par rapport au support du portrait, c’est-à-dire, dans le sens contraire des aiguilles d’une montre). D’un autre côté, pour positionner une agrafe dans le coin supérieur gauche d’un document paysage inversé tenu à la main pour la lecture, le client fournit la valeur 'agrafe-haut-droite' (car le paysage inversé se définit comme une rotation de - 90 degrés de l’image par rapport au support en portrait, c’est-à-dire, dans le sens des aiguilles d’une montre).

L’angle (vertical, horizontal, diagonal) de chaque agrafe par rapport au document dépend de la mise en œuvre qui à son tour peut dépendre de la valeur de l’attribut.

Note : L’effet de cet attribut sur les tâches ayant plusieurs documents est contrôlé par l’attribut de tâche "traitement-de-document-multiple" (paragraphe 4.2.4) et les relations de cet attribut et des autres attributs qui contrôlent le traitement du document est décrit au paragraphe 15.3.

Si le client fournit une valeur de 'aucun' avec toute autre combinaison de valeurs, c’est la même chose que si seulement cette autre combinaison de valeurs avait été fournie (c’est-à-dire que la valeur 'aucun' n’a pas d’effet).

Cet attribut identifie la ou les gammes de pages du flux d’impression qu’utilise l’objet imprimante pour chaque copie de chaque document à imprimer. Rien n’est imprimé pour toute page identifiée comme n’existant pas dans le ou les documents. Les gammes DOIVENT être en ordre ascendant, par exemple : 1-3, 5-7, 15-19 et NE DOIVENT PAS se chevaucher, de sorte qu’un objet Imprimante sans dévidement puisse traiter la tâche en une seule fois. Si les gammes ne sont pas ascendantes ou se chevauchent, l’objet IPP DOIT rejeter la demande et retourner le code d’état 'erreur-client-mauvaise-demande'. L’attribut est associé aux pages du flux d’impression et non aux pages numérotées par l’application (par exemple, les numéros de page qui se trouvent dans les en-têtes ou pieds de page pour certaines applications de traitement de texte).

Pour les tâches comportant plusieurs documents, l’attribut "traitement-de-document-multiple" détermine ce qui constitue une "copie" pour les besoins de la ou des gammes de pages spécifiées. Lorsque "traitement-de-document-multiple" est 'document-unique', l’objet imprimante DOIT appliquer chaque gamme de pages fournie une seule fois à l’enchaînement des pages du flux d’impression. Par exemple, s’il y a huit documents de dix pages chacun, la gamme de pages '41:60' imprime les pages des 5^ème et 6^ème documents comme un seul document et aucune des pages des autres documents n’est imprimée. Lorsque "traitement-multi-document" est 'documents-séparés-copies-non-colligées' ou 'documents-séparés-copies-colligées', l’objet imprimante DOIT appliquer chaque gamme de pages fournie de façon répétitive à chaque copie du document. Pour la même tâche, la gamme de pages '1:3, 10:10' imprimerait les trois premières pages et la dixième page de chacun des huit documents de la tâche, comme huit documents séparés.

Dans la plupart des cas, les pages à imprimer seront générées exactement par un pilote d’appareil et cet attribut ne sera pas exigé. Cependant, lors de l’impression d’un document archivé qui a déjà été formaté, l’utilisateur final peut choisir d’imprimer seulement un sous-ensemble des pages contenues dans le document. Dans ce cas, si gamme de pages = n.m est spécifié, la première page à imprimer sera la page n. Toutes les pages suivantes du document sont imprimées jusqu’à et y compris la page m.

"gamme-de-pages-prise-en-charge" est une valeur booléenne qui indique si l’imprimante est capable ou non de prendre en charge l’impression des gammes de pages. Cette capacité peut varier d’une PDL à l’autre. Il n’y a pas d’attribut "gamme-de-pages-par-défaut". Si l’attribut "gamme-de-pages" n’est pas fourni par le client, toutes les pages du document devront être imprimées.

Cet attribut spécifie quelles contraintes sont imposées sur les pages du flux d’impression en matière de côtés d’une instance d’un support choisi, c’est-à-dire, une impression.

'un-côté' : impose que chaque page consécutive du flux d’impression soit sur le même côté de deux feuilles support consécutives.

'deux-côtés-bord-long' : impose que chaque paire consécutive de pages du flux d’impression soit sur les côtés recto et verso des feuilles support consécutives, de telle sorte que l’orientation de chaque paire de pages du flux d’impression sur le support soit correcte pour le lecteur comme si elles étaient reliées sur le bord long. Cette contrainte est parfois appelée 'duplex' ou 'tête-à-tête'.

'deux-côtés-bord-court' : impose que chaque paire de pages consécutives du flux d’impression soit sur le recto et le verso de feuilles de support consécutives, de telle sorte que l’orientation de chaque paire de pages du flux d’impression sur le support soit correcte pour le lecteur comme si elles étaient reliées sur le bord court. Cette contrainte est parfois appelée 'culbute' ou 'tête-bèche'.

'deux-côtés-bord-long', 'deux-côtés-bord-court', 'culbute', et 'duplex' fonctionnent de la même façon en portrait ou paysage. Cependant 'tête-bêche' est 'culbute' en portrait mais 'duplex' en paysage. 'tête-à-tête' commute de 'duplex' à 'culbute' du mode portrait au mode paysage.

Note : L’effet de cet attribut sur des tâches ayant plusieurs documents est contrôlé par l’attribut de tâche "traitement-de-document-multiple" (paragraphe 4.2.4) et les relations de cet attribut avec les autres attributs qui contrôlent le traitement du document sont décrites au paragraphe 15.3.

Cet attribut spécifie le nombre de pages du flux d’impression imposé sur un seul côté d’une instance d’un support choisi. Par exemple, si la valeur est :

Cet attribut contrôle principalement la translation, rotation et changement d’échelle des pages du flux d’impression.

Cet attribut indique l’orientation désirée pour les pages imprimées du flux d’impression ; il ne décrit pas l’orientation des pages du flux d’impression fourni par le client.

Pour certains formats de document (tels que 'application/postscript'), l’orientation désirée des pages du flux d’impression est spécifiée dans les données documentaires. Cette information est générée par un pilote d’appareil avant la soumission de la tâche d’impression. D’autres formats de document (tels que 'texte/clair') n’incluent pas la notion d’orientation désirée dans les données documentaires. Dans ce dernier cas il est possible que l’objet imprimante lie l’orientation désirée aux données documentaires après la soumission. On s’attend à ce qu’un objet Imprimante ne prenne en charge "orientations-demandées" que pour certains formats de document (par exemple, 'texte/clair' ou 'texte/html') mais pas pour d’autres (par exemple, 'application/postscript'). Cela n’est pas différent de ce qui se passe dans les autres attributs de gabarit de tâche, dans la mesure où le point 1 du paragraphe 4.2, souligne qu’un objet Imprimante peut ou non prendre en charge tout attribut de gabarit de tâche sur la base du format de document fourni par le client. Cependant, une mention particulière en est faite ici car il est très vraisemblable qu’un objet Imprimante ne va prendre en charge "orientation-demandée" que pour un sous-ensemble des formats de document pris en charge.

Cet attribut identifie le support qu’utilise l’imprimante pour toutes les impressions de la tâche.

Les valeurs pour "support" incluent noms de support, tailles de support, bacs d’alimentation et formes électroniques de sorte qu’un seul attribut spécifie le support. Si un objet Imprimante prend en charge un nom de support comme valeur de cet attribut, un tel nom de support sélectionne implicitement un bac d’alimentation qui contient le support spécifié. Si un objet Imprimante prend en charge une taille de support comme valeur de cet attribut, une telle taille de support choisit implicitement un nom de support qui à son tour choisit implicitement un bac d’alimentation qui contient le support ayant la taille spécifiée. Si un objet Imprimante prend en charge un bac d’alimentation comme valeur de cet attribut, un tel bac d’alimentation choisit implicitement le support qui est dans ce bac d’alimentation au moment où la tâche imprime. Ce cas inclut les bacs à alimentation manuelle. Si un objet Imprimante prend en charge une forme électronique comme valeur de cet attribut, une telle forme électronique choisit implicitement un nom de support qui à son tour choisit implicitement un bac d’alimentation qui contient le support spécifié par la forme électronique. La forme électronique choisit aussi implicitement une image que l’imprimante DOIT fusionner avec les données documentaires lors de l’impression de chaque page.

Les valeurs standard de mot-clé sont tirées de la norme ISO DPA [ISO10175], du MIB d’imprimante [RFC1759], et de ASME-Y14.1M [ASME-Y14.1M] et leur liste figure à la section 14. Un administrateur PEUT définir des valeurs supplémentaires en utilisant la syntaxe d’attribut 'nom' ou 'mot-clé', selon la mise en œuvre.

Il y a aussi un attribut d’imprimante supplémentaire appelé "support-prêt" qui diffère de "support-pris-en-charge" en ce que les valeurs légales n’incluent que le sous-ensemble des valeurs de "support-pris-en-charge" qui sont physiquement chargées et prêtes pour impression sans qu’une intervention de l’opérateur ne soit requise. Si un objet IPP prend en charge "support-pris-en-charge", il PEUT NE PAS prendre en charge"support-prêt".

Les relations de cet attribut et des autres attributs qui contrôlent le traitement du document sont décrites au paragraphe 15.3.

Cet attribut identifie la résolution utilisée par l’imprimante pour cette tâche.

Cet attribut spécifie la qualité d’impression qu’utilise l’imprimante pour la tâche.

4.3 Attributs de description de tâche

Les attributs de ce paragraphe forment le groupe d’attributs appelé "description-de-tâche". Le tableau suivant résume ces attributs. La troisième colonne indique si l’attribut est un attribut EXIGÉ qui DOIT être pris en charge par les objets imprimante. Si il n’est pas indiqué comme EXIGÉ, il est alors FACULTATIF. La taille maximum en octets pour les attributs 'texte' et 'nom' est indiquée entre parenthèses.

Cet attribut EXIGÉ contient l’URI pour la tâche. L’objet Imprimante, à réception d’une nouvelle tâche, génère un URI qui identifie la nouvelle tâche. L’objet Imprimante retourne la valeur de l’attribut "uri-de-tâche" au titre de la réponse à une demande de création. Le format précis d’un URI de tâche dépend de la mise en œuvre. Si l’objet imprimante prend en charge plus d’un URI et qu’il y a des relations entre l’URI de tâche nouvellement formé et l’URI de l’objet imprimante, l’objet imprimante utilise l’URI d’imprimante fourni par le client dans la demande de création. Par exemple, si la demande de création vient sur un canal sécurisé, le nouvel URI de tâche DOIT utiliser le même canal sécurisé.

Ceci peut être garanti parce que l’objet imprimante est responsable de la génération de l’URI de tâche et que l’objet imprimante est au courant de sa configuration et politique de sécurité tout comme de l’URI d’imprimante utilisé dans la demande de création.

Pour une description de cet attribut et de ses relations avec les attributs "id-de-tâche" et "tâche-d’uri-d’imprimante", voir le paragraphe 2.4 sur "Identité d’objet".

Cet attribut EXIGÉ contient l’ID de la tâche. A réception d’une nouvelle tâche, l’imprimante génère un ID qui identifie la nouvelle tâche sur cette imprimante. L’imprimante retourne la valeur de l’attribut "id-de-tâche" au titre de la réponse à une demande de création. La valeur 0 n’est pas incluse pour permettre la compatibilité avec les valeurs d’index SNMP qui ne peuvent non plus être 0.

Pour une description de cet attribut et de ses relations avec les attributs "uri-de-tâche" et "tâche-d’uri-d’imprimante", voir le paragraphe 2.4 sur "Identité d’objet".

Cet attribut EXIGÉ identifie l’objet imprimante qui a créé cet objet Tâche. Lorsque un objet Imprimante crée un objet Tâche, il remplit cet attribut avec l’URI d’objet imprimante qui était utilisé dans la demande de création. Cet attribut permet à un client d’identifier l’objet imprimante qui a créé cet objet Tâche lorsque seul l’URI de l’objet Tâche est disponible pour le client. Le client interroge l’objet Imprimante créateur pour déterminer quels langages, charsets, et opérations sont pris en charge pour cette tâche.

Pour une description de cet attribut et de ses relations avec les attributs "uri-de-tâche" et "id-de-tâche", voir le paragraphe 2.4 sur "Identité d’objet".

Similaire à "plus-d’info-d’imprimante", cet attribut contient l’URI qui référence des ressources avec plus d’informations sur cet objet Tâche, peut-être une page HTML contenant des informations sur la tâche.

Cet attribut EXIGÉ est le nom de la tâche. C’est un nom qui est plus lisible que la valeur d’attribut de "uri-de-tâche". Il n’a pas besoin d’être parmi les tâches. L’attribut "nom-de-tâche" de la tâche est réglé à la valeur fournie par le client dans l’attribut d’opération "nom de tâche" de la demande de création (voir au paragraphe 3.2.1.1). Si, cependant, l’attribut d’opération "nom-de-tâche" n’est pas fourni par le client dans la demande de création, l’objet imprimante, à la création de la tâche, DOIT générer un nom. L’imprimante DEVRAIT générer la valeur de l’attribut "nom-de-tâche" de la tâche à partir de la première des sources suivantes qui produisent une valeur : 1) l’attribut d’opération "nom-du-document" du premier (ou seul) document, 2) l’attribut "document-URI" du premier (ou seul) document, ou 3) tout autre morceau d’information spécifique de tâche et/ou de contenu de document.

Cet attribut EXIGÉ contient le nom de l’utilisateur final qui a soumis la tâche d’impression. L’objet Imprimante règle cet attribut au nom imprimable le plus authentifié qu’il peut obtenir du service d’authentification sur lequel l’opération IPP a été reçue. Dans le seul cas où ce service n’est pas disponible, l’objet imprimante utilise la valeur fournie par le client dans l’attribut d’opération "nom-de-l’utilisateur-demandeur" de l’opération de création (voir aux paragraphes 4.4.2, 4.4.3, et 8).

Note : L’objet Imprimante a besoin de conserver un identifiant d’utilisateur d’origine interne de quelque forme que ce soit, normalement comme accréditation d’un principal, avec l’objet Tâche. Dans la mesure où un attribut interne dépend de la mise en œuvre et n’intéresse pas les clients, il n’est pas spécifié comme attribut de description de tâche. Cet identifiant d’utilisateur d’origine est utilisé pour les vérifications d’autorisation (s’il en est) sur toutes les opérations ultérieures.

Cet attribut EXIGÉ identifie l’état en cours de la tâche. Quand bien même le protocole IPP définit sept valeurs d’état de tâche (plus la valeur hors-bande 'inconnu' - voir au paragraphe 4.1), les mises en œuvre ont seulement besoin de prendre en charge ces états qui sont appropriés à la mise en œuvre particulière. En d’autres termes, une imprimante ne prend en charge que les états de tâche mis en œuvre par l’appareil de sortie et disponibles pour la mise en œuvre d’objet imprimante.

La valeur finale pour cet attribut DOIT être soit 'terminé', soit 'annulé', soit 'avorté' avant que l’imprimante ne retire la tâche. La durée pendant laquelle cette tâche reste dans les états 'annulé', 'avorté', et 'terminé' dépend de la mise en œuvre. Voir au paragraphe 4.3.7.2.

Normalement une tâche progresse de gauche à droite. Les autres transitions d’état sont peu vraisemblables, mais ne sont pas interdites. Les transitions vers l’état 'annulé' à partir des états 'en-instance', 'gardé-en-instance', et 'traitement-en-cours-arrêté' ne sont pas montrées.

Les tâches atteignent un des trois états terminaux 'terminé', 'annulé', ou 'avorté', après qu’elles ont terminé toute activité, y compris d’empiler la sortie de support, et tout attribut d’état de tâche a atteint sa valeur finale pour la tâche.

Comme avec tous les autres attributs IPP, si la mise en œuvre ne peut pas déterminer la valeur correcte de cet attribut, elle DEVRAIT répondre par la valeur hors-bande 'inconnu' (voir au paragraphe 4.1) plutôt que d’essayer de deviner quelle valeur pourrait être incorrecte et donner à l’utilisateur final une fausse impression sur l’état de l’objet Tâche. Par exemple, si la mise en œuvre est juste une passerelle vers des systèmes d’impression dont elle peut normalement obtenir l’état, mais qui sont temporairement incapables de le faire, la mise en œuvre devrait alors retourner la valeur 'inconnu'. Cependant, si la mise en œuvre est une passerelle vers un système d’impression qui ne fournit jamais d’état détaillé sur la tâche d’impression, la mise en œuvre PEUT régler l’état de l’objet Tâche IPP à 'terminé', pourvu qu’elle établisse aussi la valeur 'en-file-d’attente-dans-l’appareil' dans l’attribut "causes-d’état-de-tâche" de la tâche (voir au paragraphe 4.3.8).

Ce paragraphe présente la répartition des sept états de tâche en phases : Tâche non terminée, Rétention de tâche, Historique de tâche, et Retrait de tâche. Ce paragraphe explique aussi la valeur 'tâche-redémarrable' de l’attribut de description de tâche "causes-d’état-de-tâche" à utiliser avec l’opération Redémarrer-la-tâche.

Tâche non terminée: Lorsqu’une tâche est dans les états 'en-instance', 'gardé-en-instance', 'traitement-en-cours', ou 'traitement-arrêté', la tâche n’est pas terminée.

Rétention de tâche : Lorsqu’une tâche entre dans un des trois états terminaux de tâche : 'terminé', 'annulé', ou 'avorté', l’objet imprimante IPP PEUT "retenir" la tâche dans une condition redémarrable pour une durée définie par la mise en œuvre. Cette durée PEUT être zéro seconde et PEUT dépendre de l’état terminal de la tâche. Cette phase est appelée Rétention de tâche. Lorsqu’elle est dans la phase Rétention de tâche, les données documentaires de la tâche sont retenues et un client peut redémarrer la tâche en utilisant l’opération Redémarrer-la-tâche. Si l’objet IPP prend en charge l’opération Redémarrer-la-tâche, il DEVRAIT indiquer alors que la tâche est redémarrable en ajoutant la valeur 'tâche-redémarrable' à l’attribut "causes-d’état-de-tâche" de la tâche (voir au paragraphe 4.3.8) durant la phase Rétention de tâche.

Historique de tâche : Après expiration de la phase Rétention de tâche pour une tâche, l’objet imprimante supprime les données documentaires pour la tâche et la tâche fait partie de l’Historique de tâche. L’objet Imprimante PEUT aussi supprimer un nombre quelconque des attributs de la tâche. Comme la tâche n’est plus redémarrable, l’objet imprimante DOIT retirer la valeur 'tâche-redémarrable' de l’attribut "causes-d’état-de-tâche" de la tâche, s’il est présent.

Retrait de tâche : Après que la tâche est restée dans l’Historique de tâche pendant une durée définie par le mise en œuvre, telle que lorsque le nombre de tâches excède un nombre fixé ou après une durée fixée (qui PEUT être zéro seconde), l’imprimante IPP retire la tâche du système.

En utilisant l’opération Obtenir-les-tâches et en fournissant la valeur 'non-terminé' pour l’attribut d’opération "quelles-tâches", un client demande des tâches dans la phase Tâche non terminée. En utilisant l’opération Obtenir-les-tâches et en fournissant la valeur 'terminé' pour l’attribut d’opération "quelles-tâches", un client demande des tâches dans les phases Rétention de tâche et Historique de tâche. En utilisant l’opération Obtenir-les-tâches, un client demande une tâche dans toute phase excepté Retrait de tâche. Après Retrait de tâche, les opérations Obtenir-les-attributs-de-tâche et Obtenir-les-tâches ne sont plus capables de retourner d’informations sur une tâche.

Cet attribut EXIGÉ fournit des informations supplémentaires sur l’état en cours de la tâche, c’est-à-dire, des informations qui augmentent la valeur de l’attribut "état-de-tâche" de la tâche.

Ces valeurs PEUVENT être utilisées avec tout état ou tous états de tâche pour lesquels la cause a un sens. Certaines de ces définitions de valeur indiquent les exigences de conformité ; le reste est FACULTATIF. De plus, lorsqu’elles sont mises en œuvre, l’imprimante DOIT retourner ces valeurs lorsque la cause s’applique et NE DOIT PAS les retourner lorsque la cause ne s’applique plus, que la valeur de l’attribut "état-de-tâche" de la tâche ait changé ou non. Lorsque la tâche n’a plus de raisons d’être dans l’état en cours, la valeur de l’attribut "causes-d’état-de-tâche" de la tâche DOIT être 'aucun'.

Note : Alors que des valeurs ne peuvent être ajoutées à l’attribut 'état-de-tâche' sans avoir un effet sur les clients déployés qui entreprennent des actions à réception des valeurs "état-de-tâche", il est prévu que des valeurs supplémentaires de "causes-d’état-de-tâche" puissent être définies et enregistrées sans avoir d’effet sur de tels clients en activité. En d’autres termes, l’attribut "causes-d’état-de-tâche" est destiné à être extensible.

Les valeur de mot-clé standard suivantes sont définies. Pour faciliter la compréhension, les valeurs sont présentées dans l’ordre dans lequel les causes vont vraisemblablement survenir (si elles sont mises en œuvre), en commençant par la valeur 'tâche-entrante' :

'aucun' : Il n’y a pas de cause à l’état en cours de la tâche. Cette cause d’état est sémantiquement équivalente à "causes-d’état-de-tâche" sans aucune valeur et DOIT être utilisée lorsqu’il n’y a pas d’autre valeur, car la syntaxe d’attribut 1setOf exige au moins une valeur.

'tâche-entrante' : Soit (1) l’imprimante a accepté l’opération Création-de-tâche et attend des opérations Document-d’envoi et/ou URI-d’envoi supplémentaires, soit (2) l’imprimante restitue/accepte des données documentaires par suite d’une opération Tâche-d’impression, URI-d’impression, Document-d’envoi ou URI-d’envoi.

'données-de-tâche-insuffisantes' : L’opération Création-de-tâche a été acceptée par l’imprimante, mais celle-ci attend des données documentaires supplémentaires avant qu’elle puisse passer la tâche à l’état 'traitement-en-cours'. Si une imprimante commence le traitement avant qu’elle ait reçue toutes les données, elle retire la cause 'données-de-tâche-insuffisantes', mais le 'tâche-entrante' reste. Si une imprimante commence un traitement après avoir reçu toutes les données, elle retire la cause 'données-de-tâche-insuffisantes' et le 'tâche-entrante' en même temps.

'erreur-d’accès-au-document' : Après acceptation d’une demande d’URI-d’impression ou d’URI-d’envoi, l’imprimante pourrait ne pas avoir d’accès à un ou plusieurs documents passés par référence. Cette cause est destinée à couvrir tout problème d’accès à un fichier, y compris que le fichier n’existe pas ou que l’accès est refusé à cause d’un problème de contrôle d’accès. L’imprimante PEUT aussi indiquer l’erreur d’accès au document en utilisant l’attribut de description de tâche "erreurs-d’accès-au-document-de-tâche" (voir au paragraphe 4.3.11). Que l’imprimante avorte la tâche et la passe à ‘état de tâche 'avorté' ou qu’elle imprime tous les documents qui sont accessibles et passe la tâche à l’état de tâche 'terminé' et ajoute la valeur 'terminé-avec-erreurs' dans l’attribut "causes-d’état-de-tâche" de la tâche dépend de la mise en œuvre et/ou de la politique du site. Cette valeur DEVRAIT être prise en charge si les opérations URI-d’impression ou URI-d’envoi sont prises en charge.

'soumission-interrompue' : La tâche n’a pas été soumise complètement pour une raison imprévue, telle que : (1) l’imprimante a eu une défaillance avant que la tâche ne soit fermée par le client, (2) l’imprimante ou la méthode de transfert du document a eu une défaillance d’une façon non récupérable avant que les données documentaires ne soient entièrement transférées à l’imprimante, (3) le client a eu une défaillance ou a échoué à clore la tâche avant la fin de temporisation. Voir au paragraphe 4.4.31.

'tâche-sortante' : L’imprimante transmet la tâche à l’appareil de sortie.

'mettre-la-tâche-en-garde-jusqu’à-spécifié' : La valeur de l’attribut"mettre-la-tâche-en-garde-jusqu’à" de la tâche était spécifiée avec une période de temps qui est toujours dans le futur. La tâche NE DOIT PAS être candidate au traitement jusqu’à ce que cette cause soit retirée et qu’il n’y ait pas d’autres raisons de mettre la tâche en garde. Cette valeur DEVRAIT être prise en charge si l’attribut de gabarit de tâche "mettre-la-tâche-en-garde-jusqu’à" est pris en charge.

'ressources-pas-prêtes' : Au moins une des ressources nécessaires à la tâche, telles que support, polices, objets de ressource, etc., n’est pas prête sur une des imprimantes physiques pour lesquelles la tâche est candidate. Cette condition PEUT être détectée lorsque la tâche est acceptée, ou ultérieurement lorsque la tâche est en-instance ou en traitement-en-cours, selon la mise en œuvre. La tâche peut rester dans l’état en cours ou être passée à l’état 'gardé-en-instance', selon la mise en œuvre et/ou la politique de programmation des tâches.

'arrêt-partiel-de-l’imprimante' : La valeur de l’attribut "causes-d’état-d’imprimante" de l’imprimante contient la valeur 'arrêt-partiel'.

'arrêt-de-l’imprimante' : La valeur de l’attribut "état-d’imprimante" de l’imprimante est 'arrêté'.

'interprétation-de-tâche' : La tâche est dans l’état 'traitement-en-cours', mais plus précisément, l’imprimante est en train d’interpréter les données documentaires.

'tâche-en-file-d’attente' : La tâche est dans l’état 'traitement-en-cours', mais plus précisément, l’imprimante a mis les données documentaires en file d’attente.

'tâche-de-transformation' : La tâche est dans l’état 'traitement-en-cours', mais plus précisément, l’imprimante est en train d’interpréter les données documentaires et de produire une autre représentation électronique.

'tâche-en-file-d’attente-pour-marquage' : La tâche est dans un des états 'gardé-en-instance', 'en-instance', ou 'traitement-en-cours', mais plus précisément, l’imprimante a terminé assez du traitement du document pour être capable de commencer le marquage et la tâche attend le marqueur. Les systèmes qui requièrent une intervention humaine pour libérer les tâches en utilisant l’opération Libération-de-tâche, mettent la tâche dans l’état de tâche 'gardé-en-instance'. Les systèmes qui choisissent automatiquement une tâche pour utiliser le marqueur mettent la tâche dans l’état de tâche 'en-instance' ou gardent la tâche dans l’état de tâche 'traitement-en-cours' tandis qu’elle attend le marquage, selon la mise en œuvre. Toutes les mises en œuvre mettent (ou remettent) la tâche dans l’état 'traitement-en-cours' lorsque le marquage commence.

'tâche-d’impression' : L’appareil de sortie est en train de marquer les supports. Cette valeur est utile pour les imprimantes qui passent beaucoup de temps en traitement (1) lorsque aucun marquage n’intervient et qu’elles veulent montrer que le marquage se fait maintenant ou (2) lorsque la tâche est dans un processus d’annulation ou d’avortement alors qu’elle reste dans l’état 'traitement-en-cours', mais le marquage n’est pas encore arrêté de sorte que l’impression ou le comptage des feuilles augmentent toujours pour la tâche.

'tâche-annulée-par-l’usager' : La tâche a été annulée par le propriétaire de la tâche en utilisant la demande Annuler-la-tâche, c’est-à-dire, par un utilisateur dont l’identité authentifiée est la même que la valeur de l’utilisateur d’origine qui a créé l’objet Tâche, ou par quelque autre utilisateur final autorisé, tel qu’un membre du groupe de sécurité du propriétaire de la tâche. Cette valeur DEVRAIT être prise en charge.

'tâche-annulée-par-l’opérateur' : La tâche a été annulée par l’opérateur à l’aide de la demande Annuler-la-tâche, c’est-à-dire, par un utilisateur qui a été authentifié comme ayant des privilèges d’opérateur (local ou distant). Si la politique de sécurité est de permettre à tous d’annuler toutes les tâches, cette valeur peut alors être utilisée lorsque la tâche est annulée par d’autres que le propriétaire de la tâche. Pour une telle politique de sécurité, en effet, tout le monde est un opérateur pour ce qui concerne l’annulation de tâches avec IPP. Cette valeur DEVRAIT être prise en charge si la mise en œuvre permet l’annulation de la tâche par d’autres que le propriétaire.

'tâche-annulée-à-l’appareil' : La tâche a été annulée par un utilisateur local non identifié, c’est-à-dire, un usager à la console de l’appareil. Cette valeur DEVRAIT être prise en charge si la mise en œuvre prend en charge l’annulation des tâches à la console.

'avorté-par-le-système' : La tâche (1) est en cours d’avortement, (2) a été avortée par le système et placée dans l’état 'avorté', ou (3) a été avortée par le système et placée dans l’état 'gardé-en-instance', de sorte qu’un utilisateur ou opérateur peut réessayer manuellement la tâche. Cette valeur DEVRAIT être prise en charge.

'compression-non-acceptée' : La tâche a été avortée par le système parce que l’imprimante a déterminé en tentant de décompresser les données du document que la compression n’est pas en fait parmi celles prises en charge par l’imprimante. Cette valeur DOIT être prise en charge, car "compressions" est un attribut d’opération EXIGÉ.

'erreur-de-compression' : La tâche a été avortée par le système parce que l’imprimante a rencontré une erreur dans les données documentaires en le décompressant. Si l’imprimante affiche cette raison, les données documentaires ont déjà passé tous les essais qui auraient conduit à la cause d’état de tâche 'compression-non-acceptée'.

'format-de-document-non-accepté' : La tâche a été avortée par le système parce que le format de document des données documentaires n’est pas parmi ceux pris en charge par l’imprimante. Si le client spécifie le format de document comme 'application/flux-d’octets', l’imprimante PEUT avorter la tâche et afficher cette cause même si le format est un membre de l’attribut d’imprimante "format-de-document-pris-en-charge", mais n’est pas parmi les formats de document auto-détectés. Cette valeur DOIT être prise en charge, car le "format-de-document" est un attribut d’opération EXIGÉ.

'erreur-de-format-de-document' : La tâche a été avortée par le système parce que l’imprimante a rencontré une erreur dans les données documentaires pendant leur traitement. Si l’imprimante affiche cette cause, les données documentaires ont déjà passé tous les essais qui auraient conduit à la cause d’état de tâche 'format-de-document-non-accepté'.

'traitement-au-point-d’arrêt' : Le demandeur a produit une opération Annuler-la-tâche ou l’objet imprimante a avorté la tâche, mais il est toujours en train d’effectuer certaines actions sur la tâche jusqu’à ce qu’un point d’arrêt spécifié survienne ou qu’une terminaison/purge de tâche soit terminée. Si la mise en œuvre exige un délai mesurable pour annuler la tâche dans les états de tâche 'traitement-en-cours' ou 'traitement-arrêté', l’objet IPP DOIT utiliser cette valeur pour indiquer que l’objet imprimante est toujours en train d’effectuer certaines actions sur la tâche alors que la tâche reste dans l’état 'traitement-en-cours' ou 'traitement-arrêté'. Après que tout attribut de description de tâche de la tâche ait arrêté de progresser, l’objet imprimante passe la tâche de l’état 'traitement-en-cours' aux états 'annulé' ou 'avorté'.

'service-hors-ligne' : L’imprimante est hors-ligne et n’accepte aucune tâche. Toutes les tâches 'en-instance' sont mises dans l’état 'gardé-en-instance'. Cette situation pourrait être vraie si l’entrée du service ou de transformation du document est endommagée ou cassée.

'tâche-terminé-avec-succès' : La tâche est terminée avec succès. Cette valeur DEVRAIT être prise en charge.

'tâche-terminée-avec-avertissements' : La tâche est terminée avec des avertissements. Cette valeur DEVRAIT être prise en charge si la mise en œuvre détecte des avertissements.

'tâche-terminée-avec-erreurs' : La tâche est terminée avec des erreurs (et aussi de possibles avertissements). Cette valeur DEVRAIT être prise en charge si la mise en œuvre détecte des erreurs.

'tâche-redémarrable' – Cette tâche est conservée (voir au paragraphe 4.3.7.2) et est capable d’être redémarrée en utilisant l’opération Redémarrer-la-tâche (voir au paragraphe 3.3.7). Si 'tâche-redémarrable' est une valeur de l’attribut 'causes-d’état-de-tâche' de la tâche, l’objet IPP DOIT alors accepter une opération Redémarrer-la-tâche pour cette tâche. Cette valeur DEVRAIT être prise en charge si l’opération Redémarrer-la-tâche est prise en charge.

'en-file-d’attente-dans-l’appareil' : La tâche a été transmise à un appareil ou système d’impression qui n’est pas capable de renvoyer l’état. L’imprimante règle l’attribut "état-de-tâche " de la tâche à 'terminé' et ajoute la valeur 'en-file-d’attente-dans-l’appareil' à l’attribut "causes-d’état-de-tâche" de la tâche pour indiquer que l’imprimante n’a pas d’informations supplémentaires sur la tâche et n’aura jamais de meilleures informations. Voir au paragraphe 4.3.7.1.

Cet attribut spécifie les informations sur les attributs "état-de-tâche" et "causes-d’état-de-tâche" en texte lisible par l’homme. Si l’objet imprimante prend en charge cet attribut, l’objet imprimante DOIT être capable de générer ce message dans tous les langages naturels identifiés par l’attribut "langage-naturel-généré-pris-en-charge" de l’imprimante (voir l’attribut d’opération "langage-naturel-des-attributs" spécifié au paragraphe 3.1.4.1).

La valeur NE DEVRAIT PAS contenir d’informations supplémentaires non contenues dans les valeurs des attributs "état-de-tâche" et "causes-d’état-de-tâche", telles que des informations d’interprétation d’erreur. Autrement, les programmes d’application pourraient tenter d’analyser le texte localisé. Pour de telles informations supplémentaires comme les erreurs d’interprétation pour l’usage des programmes d’application ou les erreurs spécifiques d’accès au document, de nouveaux attributs avec des valeurs de mot-clé doivent être développés et enregistrés.

Cet attribut spécifie des informations supplémentaires détaillées et techniques sur la tâche. L’imprimante PEUT NE PAS localiser le ou les messages, car ils sont destinés à être utilisés par l’administrateur de système ou d’autres personnels techniques expérimentés. La localisation peut obscurcir la signification technique de tels messages. Les clients NE DOIVENT PAS tenter d’analyser la valeur de cet attribut. Voir les erreurs supplémentaires qu’un programme peut traiter sous "erreurs-d’accès-au-document-de-tâche" (paragraphe 4.3.11).

Cet attribut fournit des information supplémentaires sur chaque erreur d’accès au document pour cette tâche rencontrée par l’imprimante après qu’elle a retourné une réponse à l’opération URI-d’impression ou URI-d’envoi et tenté ensuite d’accéder au ou aux documents fournis dans l’opération URI-d’imprimante ou URI-d’envoi. Pour les erreurs de protocole qui sont identifiées par le schéma d’URI dans l’attribut d’opération "uri-de-document", tels que 'http:' ou 'ftp:', le code d’erreur est retourné entre parenthèses, suivi par l’URI. Par exemple :

La plupart des protocoles Internet utilisent des codes d’erreur décimaux (à la différence d’IPP), de sorte que la représentation du code d’erreur ASCII est en décimal.

Cet attribut indique le nombre de documents dans la tâche, c’est-à-dire, le nombre de Document-d’envoi, URI-d’envoi, Tâche-d’impression, ou d’opérations URI-d’impression que l’imprimante a accepté pour cette tâche, sans considérer si les données documentaires ont atteint l’objet imprimante ou non.

Les mises en œuvre qui prennent en charge les opérations FACULTATIVES Création-de-tâche/Document-d’envoi/URI-d’envoi DEVRAIENT prendre en charge cet attribut de sorte que les clients puissent interroger le nombre de documents dans chaque tâche.

Cet attribut identifie l’appareil de sortie auquel l’objet imprimante a alloué cette tâche. Si un appareil de sortie met en œuvre un objet Imprimante incorporé, l’objet imprimante PEUT NE PAS mettre cet attribut. Si un serveur d’impression met en œuvre un objet Imprimante, la valeur PEUT être vide (chaîne de longueur zéro) ou non retournée jusqu’à ce que l’objet imprimante alloue un appareil de sortie à la tâche. Cet attribut est particulièrement utile lorsque un seul objet Imprimante prend en charge plusieurs appareils (aussi appelé "ventilation de sortie" - voir au paragraphe 2.1).

Ce paragraphe définit les attributs de description de tâche qui indiquent l’heure à laquelle certains événements surviennent pour une tâche. Si l’événement de tâche n’est pas encore survenu, l’objet IPP DOIT alors retourner la valeur hors-bande 'pas-de-valeur' (voir le début du paragraphe 4.1). Les attributs "heure-à-xxx(entier)" représentent l’heure comme un 'entier' représentant le nombre de secondes depuis que l’appareil a été mis sous tension (appelées de façon informelle "tics de temps"). Les attributs "date-heure-à-xxx(dateHeure)" représentent le temps comme 'dateHeure' représentant la date et l’heure (y compris un décalage par rapport à l’UTC).

Afin de remplir ces attributs, l’objet imprimante copie la ou les valeurs des attributs de description d’opération suivants à l’heure où l’événement survient :

1. la valeur dans l’attribut "heure-de-mise-sous-tension-de-l’imprimante" de l’imprimante pour les attributs "heure-à-xxx(entier)",

2. la valeur dans l’attribut "heure-en-cours-à-l’imprimante" de l’imprimante pour les attributs "date-heure-à-xxx(dateHeure)".

Si l’imprimante remet son attribut "heure de mise-sous-tension-de-l’imprimante" à 1 à la mise sous tension (voir au paragraphe 4.4.29) et a des tâches persistantes, elle DOIT alors changer tous les attributs de tâche "heure-à-xxx(entier)" (tics de temps) de tâche dont les événements sont survenus soit pour :

1. 0 pour indiquer que l’événement est survenu avant la plus récente mise sous tension, SOIT

2. le nombre négatif de secondes avant la mise sous tension la plus récente à laquelle l’événement a eu lieu, bien que le nombre négatif PUISSE NE PAS refléter le nombre de secondes exact.

Si un client interroge un attribut de tâche en tics de temps "heure-à-xxx(entier)" et trouve que la valeur est 0 ou négative, le client DOIT supposer que l’événement est survenu dans un autre moment de la vie de l’imprimante.

Note : Une imprimante ne change les valeurs d’aucun attribut de tâche "date-heure-à-xxx" (dateHeure)" à la mise sous tension.

Cet attribut EXIGÉ indique l’heure à laquelle l’objet Tâche a commencé le traitement après l’opération de création ou la plus récente opération Redémarrer-la-tâche. La valeur hors-bande 'pas-de-valeur' est retournée si la tâche n’a pas encore été dans l’état 'traitement-en-cours' (voir au début du paragraphe 4.1).

Cet attribut EXIGÉ indique l’heure à laquelle l’objet Tâche est terminé (ou annulé ou avorté). La valeur hors-bande 'pas-de-valeur' est retournée si la tâche n’est pas encore terminée, est annulée, ou avortée (voir au début du paragraphe 4.1).

4.3.14.4 heure-de-mise-sous-tension-de-tâche-d’imprimante (entier(1:MAX))

Cet attribut EXIGÉ de description de tâche indique la quantité de temps (en secondes) pendant laquelle la mise en œuvre d’imprimante a été sous tension et en fonctionnement. Cet attribut est un alias pour l’attribut de description d’opération "heure-de-mise-sous-tension-de-l’imprimante" (voir au paragraphe 4.4.29).

Un client PEUT demander cet attribut dans une demande Obtenir-les-attributs-de-tâche ou Obtenir-les-tâches et utiliser la valeur retournée en combinaison avec d’autres attributs de description de tâche d’heure d’événement afin d’afficher les attributs d’heure pour un utilisateur. La différence entre cet attribut et la valeur 'entier' d’un attribut "heure-à-xxx" est le nombre de secondes écoulées depuis que l’événement est survenu à "heure-à-xxx". Un client peut calculer l’heure d’horloge à laquelle l’événement de "heure-à-xxx" est survenu en soustrayant cette différence de l’heure d’horloge du client.

Cet attribut indique la date et l’heure à laquelle a été créé l’objet Tâche.

Cet attribut indique la date et l’heure à laquelle l’objet Tâche a débuté le traitement après l’opération de création ou la plus récente opération Redémarrer-la-tâche.

Cet attribut indique la date et l’heure à laquelle l’objet Tâche s’est terminé (ou a été annulé ou avorté).

Cet attribut indique le nombre de tâches qui sont "avant" cette tâche dans l’ordre chronologique relatif d’heure de fin attendue (c’est-à-dire, l’ordre tel qu’il est programmé). Pour des raisons d’efficacité, il est seulement nécessaire de calculer cette valeur lorsqu’une opération qui exige cet attribut est effectuée.

Cet attribut fournit un message d’un opérateur, d’un administrateur de système ou d’un processus "intelligent" pour indiquer à l’utilisateur final les raisons d’une modification ou d’une autre action de gestion effectuée sur une tâche.

Ce paragraphe définit les attributs de tâche qui décrivent la taille de la tâche. Ces attributs ne sont pas destinés à être des compteurs ; ils servent à porter des informations utiles d’acheminement et de programmation, s’ils sont connus. Pour ces attributs, l’objet imprimante peut essayer de calculer la valeur si elle n’est pas fournie dans la demande de création. Même si le client fournit une valeur pour ces trois attributs dans la demande de création, l’objet imprimante PEUT choisir de changer la valeur si l’objet imprimante est capable de calculer une valeur plus appropriée que la valeur fournie par le client. L’objet Imprimante peut être capable de déterminer la valeur correcte pour ces attributs juste à l’heure de la soumission de tâche ou à tout moment ultérieur.

Cet attribut spécifie la taille totale du ou des documents en k-octets, c’est-à-dire, en unités de 1024 octets nécessaires pour être traitées dans la tâche. La valeur DOIT être arrondie, de sorte qu’une tâche entre 1 et 1024 octets DOIT être indiquée comme 1, 1025 à 2048 DOIT être 2, etc.

Cette valeur NE DOIT PAS inclure de facteur multiplicatif provenant du nombre de copies spécifié par l’attribut "copies", indépendamment du fait que l’appareil peut ou non traiter plusieurs copies sans faire plusieurs passages de la tâche ou des données documentaires et indépendamment du fait que la sortie sera colligée ou non. Et donc, la valeur est indépendante de la mise en œuvre et indique la taille du ou des documents mesurée en k-octets indépendants du nombre de copies.

Cette valeur NE DOIT PAS non plus inclure le facteur multiplicatif dû aux instructions de copie incorporées dans les données documentaires. Si les données documentaires incluent effectivement des répliques des données documentaires, cette valeur va inclure une telle réplication. En d’autres termes, cette valeur est toujours la taille des données documentaires de source, plutôt qu’une mesure des copies à produire en sortie.

Cet attribut spécifie la taille totale en nombre d’impressions du ou des documents soumis (voir la définition d’impression au paragraphe 12.2.5).

Comme avec "k-octets-de-tâche", cette valeur NE DOIT PAS inclure les facteurs multiplicatifs apportés par le nombre de copies spécifié par l’attribut "copies", indépendamment du fait que l’appareil puisse traiter ou non plusieurs copies sans faire plusieurs passages sur la tâche ou les données documentaires, et indépendamment du fait que la sortie soit colligée ou non. Et donc la valeur est indépendante de la mise en œuvre et reflète la taille du ou des documents mesurée en impressions indépendantes du nombre de copies.

Comme avec "k-octets-de-tâche", cette valeur NE DOIT PAS non plus inclure le facteur multiplicatif dû aux instructions de copie incorporées dans les données documentaires. Si les données documentaires incluent effectivement des répliques des données documentaires, cette valeur inclura de telles réplications. En d’autres termes, cette valeur est toujours le nombre d’impressions des données documentaires de source, plutôt qu’une mesure du nombre d’impressions à produire par la tâche.

Cet attribut spécifie le nombre total de feuilles de support à produire pour cette tâche.

A la différence des attributs "k-octets-de-tâche" et "tâches-d’impression", cette valeur DOIT inclure les facteurs multiplicatifs apportés par le nombre de copies spécifié par l’attribut "copies" et une instruction 'nombre de copies' incorporée dans les données documentaires, s’il en est. Cette différence permet à l’administrateur de système de contrôler les limites inférieure et supérieure aussi bien de (1) la taille du ou des documents avec "k-octets-de-tâche-pris-en-charge" et "tâches-d’impression-prises-en-charge" et de (2) la taille de la tâche avec "feuilles-de-support-de-tâche-prises-en-charge".

Le présent paragraphe définit les attributs de tâche qui décrivent l’avancement de la tâche. Ces attributs sont destinés à être des compteurs. C’est-à-dire que la valeur pour une tâche qui n’a pas encore commencé le traitement DOIT être 0. Lorsque l’"état-de-tâche" de la tâche est 'traitement-en-cours' ou 'traitement-arrêté', cette valeur est prévue pour contenir la quantité de la tâche qui a été traitée à l’heure à laquelle les attributs sont demandés. Lorsque la tâche entre dans les états 'terminé', 'annulé', ou 'avorté', ces valeurs sont les valeurs finales pour la tâche.

Cet attribut spécifie le nombre total d’octets traités jusqu’à présent dans k-octets, c’est-à-dire, en unités de 1024 octets. La valeur DOIT être arrondie, de sorte qu’une tâche entre 1 et 1024 octets inclus DOIT être indiquée comme 1, 1025 à 2048 inclus DOIT être 2, etc.

Pour les mises en œuvre où plusieurs copies sont produites par l’interprète avec un seul passage sur les données, la valeur finale DOIT être égale à la valeur de l’attribut "k-octets-de-tâche". Pour les mises en œuvre où pour chaque copie plusieurs copies sont produites par l’interprète par le traitement des données, la valeur finale DOIT être un multiple de la valeur de l’attribut "k-octets-de-tâche".

Cet attribut de tâche spécifie le nombre d’impressions terminées jusqu’à présent pour la tâche. Pour les appareils d’impression, les impressions terminées incluent l’interprétation, le marquage, et l’empilage du résultat.

Cet attribut de tâche spécifie les feuilles de support marquées et empilées jusqu’à présent pour l’ensemble de la tâche, que ces feuilles aient été traitées sur un seul côté ou sur les deux.

Cet attribut EXIGÉ est rempli en utilisant la valeur fournie dans l’attribut "charset-des-attributs" du client dans la demande de création. Il identifie le charset (ensemble de caractères codés et méthode de codage) utilisé par tout attribut de tâche avec les attributs syntaxiques 'texte' et 'nom' qui étaient fournis par le client dans la demande de création. Voir au paragraphe 3.1.4 la description complète de l’attribut d’opération "charset-des-attributs".

Cet attribut n’indique pas le charset dans lequel les valeurs 'texte' et 'nom' sont mémorisées en interne dans l’objet Tâche. Le charset interne est défini par la mise en œuvre. L’objet IPP DOIT convertir le charset interne, quelle que soit sa forme, dans celle qui est demandée dans une opération comme spécifié au paragraphe 3.1.4.

Cet attribut EXIGÉ est rempli en utilisant la valeur fournie dans l’attribut "langage-naturel-des-attributs" du client dans la demande de création. Il identifie le langage naturel utilisé pour tout attribut de tâche avec les attributs syntaxiques 'texte' et 'nom' qui étaient fournis par le client dans la demande de création. Voir au paragraphe 3.1.4 une description complète de l’attribut d’opération "langage-naturel-des-attributs". Voir aux paragraphes 4.1.1.2 et 4.1.2.2 comment Outrepasser le langage naturel peut être fourni explicitement pour chaque valeur d’attribut 'texte' et 'nom' qui diffère de la valeur identifiée par l’attribut "langage-naturel-des-attributs".

4.4 Attributs de description d’imprimante

Ces attributs forment le groupe d’attributs appelé "description-d’imprimante". Le tableau suivant résume ces attributs, leur syntaxe, et si leur prise en charge est ou non EXIGÉE pour un objet Imprimante. Si ils ne sont pas indiqués comme "EXIGÉ", ils sont "FACULTATIF". La taille maximum en octets des attributs 'texte' et 'nom' est indiquée entre parenthèses.

Note : La façon dont ces attributs sont établis par un administrateur sort du domaine d’application du présent document IPP/1.1.

Cet attribut d’imprimante EXIGÉ contient au moins un URI pour l’objet imprimante. Il contient FACULTATIVEMENT plus d’un URI pour l’objet imprimante. Un administrateur détermine un ou plusieurs URI d’objet Imprimante et configure cet attribut pour qu’il contienne ces URI par des moyens qui sortent du domaine d’application du présent document IPP/1.1. Le format précis de cet URI dépend de la mise en œuvre et dépend du protocole. Voir aux deux paragraphes suivants une description de ces attributs "sécurité-d’uri-prise-en-charge" et "authentification-d’uri-prise-en-charge", qui sont tous deux des attributs compagnons EXIGÉS de cet attribut "uri-d’imprimante-acceptés". Voir au paragraphe 2.4 sur l’identité de l’objet Imprimante et au paragraphe 8.2 sur la sécurité et les URI pour plus d’informations.

Cet attribut d’imprimante EXIGÉ DOIT avoir la même cardinalité (contenir le même nombre de valeurs) que l’attribut "uri-d’imprimante-acceptés". Cet attribut identifie le mécanisme d’authentification client associé à chaque URI figurant sur la liste de l’attribut "uri-d’imprimante-acceptés". L’objet Imprimante utilise le mécanisme d’identifiant spécifié de l’utilisateur authentifié (voir au paragraphe 8.3). La "i^ème" valeur de "authentification-d’uri-prise-en-charge" correspond à la "i^ème" valeur de "uri-d’imprimante-acceptés" et elle décrit les mécanismes d’authentification utilisés par l’imprimante lors d’un accès via cet URI. Voir la [RFC2910] pour des détails complémentaires sur l’authentification du client.

'aucun' : Il n’y a pas de mécanisme d’authentification associé à l’URI. L’objet Imprimante suppose que l’utilisateur authentifié est "anonyme".

'nom-de-l’utilisateur-demandeur' : Lorsqu’un client effectue une opération dont la cible est l’URI associé, l’objet imprimante suppose que l’utilisateur authentifié est spécifié par l’attribut d’opération "nom-de-l’utilisateur-demandeur" (voir au paragraphe 8.3). Si l’attribut "nom-de-l’utilisateur-demandeur" est absent dans une demande, l’objet imprimante suppose que l’utilisateur authentifié est "anonyme".

'basique' : Lorsqu’un client effectue une opération dont la cible est l’URI associé, l’objet imprimante compare le client avec l’authentification http de base [RFC2617]. L’objet Imprimante suppose que l’utilisateur authentifié est le nom reçu via le mécanisme d’authentification de base.

'abrégé' : Lorsqu’un client effectue une opération dont la cible est l’URI associé, l’objet imprimante compare le client avec l’authentification http abrégée [RFC2617]. L’objet Imprimante suppose que l’utilisateur authentifié est le nom reçu via le mécanisme d’authentification abrégée.

'certificat' : Lorsqu’un client effectue une opération dont la cible est l’URI associé, l’objet imprimante s’attend à ce que le client fournisse un certificat. L’objet Imprimante suppose que l’utilisateur authentifié est le nom textuel contenu dans le certificat.

Cet attribut d’imprimante EXIGÉ DOIT avoir la même cardinalité (contenir le même nombre de valeurs) que l’attribut "uri-d’imprimante-acceptés". Cet attribut identifie les mécanismes de sécurité utilisés pour chaque URI figurant sur la liste de l’attribut "uri-d’imprimante-acceptés". La "i^ème" valeur dans "sécurité-d’uri-prise-en-charge" correspond à la "i^ème" valeur dans "uri-d’imprimante-acceptés" et elle décrit les mécanismes de sécurité utilisés pour accéder à l’objet imprimante via cet URI. Voir la [RFC2910] pour des détails complémentaires sur les mécanismes de sécurité.

'aucun' : Il n’y a aucun protocole de canal de communication sécurisé en usage pour l’URI donné.

'ssl3' : SSL3 [SSL] est le protocole de canal de communication sécurisé en usage pour l’URI donné.

'tls' : TLS [RFC2246] est le protocole de canal de communication sécurisé en usage pour l’URI donné.

Cet attribut est orthogonal à la définition d’un mécanisme d’authentification client. Précisément, 'aucun' n’exclut pas l’authentification du client. Voir au paragraphe 4.4.2.

Considérons l’exemple suivant : pour un seul objet Imprimante, un administrateur configure les attributs "uri-d’imprimante-acceptés", "authentification-d’uri-prise-en-charge" et "sécurité-d’uri-prise-en-charge" comme suit :

"uri-d’imprimante-acceptés": 'xxx://acme.com/open-use-printer', 'xxx://acme.com/restricted-use-printer', 'xxx://acme.com/private-printer'

Note : 'xxx' n’est pas un schéma valide. Voir le document IPP/1.1 "Transport et codage" [RFC2910] pour les schémas réels d’URI à utiliser dans les attributs cibles d’objet.

- Pour le premier URI, 'xxx://acme.com/open-use-printer', la valeur 'aucun' dans "sécurité-d’uri-prise-en-charge" indique qu’il n’y a pas de protocole de canal sécurisé configuré pour tourner sous HTTP. La valeur 'aucun' dans "authentification-d’uri-prise-en-charge" indique que tout utilisateur est 'anonyme'. Il n’y aura pas de vérification et l’imprimante ignorera le "nom-de-l’utilisateur-demandeur".

- Pour le second URI, 'xxx://acme.com/restricted-use-printer', la valeur 'aucun' dans "sécurité-d’uri-prise-en-charge" indique qu’il n’y a pas de protocole de canal sécurisé configuré pour tourner sous HTTP. La valeur 'abrégé' dans "authentification-d’uri-prise-en-charge" indique que l’imprimante va faire une vérification et que l’imprimante utilisera le nom fourni par le mécanisme abrégé pour déterminer l’utilisateur authentifié (voir au paragraphe 8.3).

- Pour le troisième URI, 'xxx://acme.com/private-printer', la valeur 'tls' dans "sécurité-d’uri-prise-en-charge" indique que TLS est utilisé pour sécuriser le canal. Le client DEVRAIT être préparé à utiliser le tramage TLS pour négocier une suite de chiffrement acceptable à utiliser lors de sa communication avec l’objet imprimante. Dans ce cas, le nom implique l’utilisation d’un canal de communications sécurisé, mais le fait est rendu explicite par la présence des valeurs 'tls' dans "sécurité-d’uri-prise-en-charge". Le client n’a pas besoin de comprendre quelle sécurité il doit utiliser dans les conventions de dénomination suivantes ni de faire l’analyse grammaticale de l’URI pour déterminer quels mécanismes de sécurité sont impliqués. la valeur 'basique' dans "authentification-d’uri-prise-en-charge" indique que l’imprimante va effectuer une vérification et qu’elle va utiliser le nom fourni par le mécanisme abrégé pour déterminer l’utilisateur authentifié (voir au paragraphe 8.3). Comme cette vérification survient dans une session tls, le canal est sécurisé.

On s’attend à ce que de nombreux objets imprimante IPP soient configurés pour ne prendre en charge qu’un seul canal (configuré pour utiliser l’accès TLS ou non) et seulement un mécanisme d’authentification. De tels objets imprimante n’ont qu’un seul URI dans la liste de l’attribut "uri-d’imprimante-acceptés". Peu importe la configuration de l’objet imprimante (qu’elle ait seulement un URI ou plus d’un URI), un client DOIT fournir seulement un URI dans l’attribut d’opération "uri-d’imprimante" cible.

Cet attribut d’imprimante EXIGÉ contient le nom de l’objet imprimante. C’est un nom qui est plus facile à mémoriser qu’un URI. Un administrateur détermine un nom d’imprimante et règle cet attribut à ce nom. Ce nom peut être la dernière partie de l’URI de l’imprimante ou il peut être sans relation. Dans les localisations non anglaises, un nom peut contenir des caractères qui ne sont pas permis dans un URI.

Cet attribut d’imprimante identifie la localisation de l’appareil. Cela peut inclure des choses comme : "Pièce 123A, second étage de l’immeuble XYZ".

Cet attribut d’imprimante identifie les informations descriptives sur cet objet Imprimante. Cela peut inclure des choses comme : "Cette imprimante peut être utilisée pour des impressions de transparents en couleur pour des présentations HR", ou "Par courtoisie pour les autres, veuillez n’imprimer que de petits travaux (1 à 5 pages) sur cette imprimante", ou même "Cette imprimante s’en va le 1^er juillet 1997, veuillez trouver une autre imprimante".

Cet attribut d’imprimante contient un URI utilisé pour obtenir plus d’informations sur cet objet Imprimante spécifique. Par exemple, ce peut être un type d’URI HTTP qui référence une page HTML accessible par un navigateur de la Toile. Les informations obtenues de cet URI sont destinées à l’attention de l’utilisateur final. Des caractéristiques en dehors du domaine d’application d’IPP peuvent être atteintes à partir de cet URI. Les informations sont destinées à être spécifiques de cette instance d’imprimante et des services spécifiques du site (par exemple, la tarification des tâches, les services offerts, l’assistance à l’utilisateur final). Le fabricant de l’appareil peut remplir cet attribut dès l’origine.

Cet attribut d’imprimante contient un URI à utiliser pour localiser l’installation du pilote de cet objet Imprimante. Cet attribut est destiné à être utilisé par un automate. La mécanique d’installation du pilote d’imprimante sort du domaine d’application du présent document IPP/1.1. Le fabricant de l’appareil peut remplir cet attribut dès l’origine.

Cet attribut d’imprimante identifie la marque et le modèle de l’appareil. Le fabricant de l’appareil peut remplir cet attribut dès l’origine.

Cet attribut d’imprimante contient un URI utilisé pour obtenir plus d’informations sur ce type d’appareil. Les informations obtenues de cet URI sont destinées à l’attention de l’utilisateur final. Des caractéristiques qui sortent du domaine d’application d’IPP peuvent être obtenues de cet URI (par exemple, dernières productions de la compagnie, mises à jour, pilotes d’imprimante, options disponibles, détails sur la prise en charge des couleurs). Les informations sont destinées à être en rapport avec cette imprimante sans considération de modifications ou services spécifiques du site. Le fabricant de l’appareil peut remplir cet attribut dès l’origine.

Cet attribut d’imprimante EXIGÉ identifie l’état en cours de l’appareil. L’attribut "causes-d’état-d’imprimante" abonde l’attribut "état-d’imprimante" pour donner des informations plus détaillées sur l’imprimante dans l’état d’imprimante donné.

Un objet Imprimante a seulement besoin de mettre à jour cet attribut avant de répondre à une opération qui demande cet attribut ; l’objet imprimante PEUT NE PAS mettre continuellement à jour cet attribut, car la notification asynchrone d’événement ne fait pas partie d’IPP/1.1. Une imprimante PEUT NE PAS mettre en œuvre toutes les valeurs si elles ne sont pas applicables à une mise en œuvre donnée.

Les valeurs de "cause-d’état-d’imprimante", telles que 'zone-de-dévidage-pleine' et 'arrêt-partiel', PEUVENT être utilisées pour fournir des informations complémentaires.

Cet attribut d’imprimante EXIGÉ fournit des détails complémentaires sur l’état de l’appareil. Certaines de ces définitions de valeur indiquent les exigences de conformité; le reste est FACULTATIF.

Chaque valeur de mot-clé PEUT avoir un suffixe pour indiquer son niveau de sévérité. Les trois niveaux sont : rapport (le moins sévère), avertissement, et erreur (le plus sévère).

- '-rapport' : Ce suffixe indique que la cause est un "rapport". Une mise en œuvre peut choisir d’omettre certains ou tous les rapports. Certains rapports spécifient une granularité plus fine sur l’état de l’imprimante ; d’autres servent de précurseur à un avertissement. Un rapport ne DOIT rien contenir qui puisse affecter la sortie de l’imprimante.

- '-avertissement' : Ce suffixe indique que la cause est un "avertissement". Une mise en œuvre peut choisir d’omettre certains ou tous les avertissements. Les avertissements servent de précurseur à une erreur. Un avertissement ne DOIT rien contenir qui empêche une tâche de se terminer, bien que dans certains cas, la sortie puisse être de qualité inférieure.

- '-erreur' : Ce suffixe indique que la cause est une "erreur". Une mise en œuvre DOIT inclure toutes les erreurs. Si cet attribut contient une ou plusieurs erreurs, l’imprimante DOIT être dans l’état arrêté.

Si la mise en œuvre n’ajoute aucun des trois suffixes, toutes les parties DOIVENT supposer que la cause est une "erreur".

Si un objet Imprimante contrôle plus d’un appareil de sortie, chaque valeur de cet attribut PEUT s’appliquer à un ou plusieurs des appareils de sortie. Une erreur sur un appareil de sortie qui n’arrête pas l’objet imprimante en entier PEUT apparaître comme un avertissement dans l’attribut "cause-d’état-d’imprimante" de l’imprimante. Si "état-d’imprimante" pour une telle imprimante a une valeur 'arrêté', il DOIT alors être une cause d’erreur parmi les valeurs de l’attribut "cause-d’état-d’imprimante".

'autre' : L’appareil a détecté une erreur autre que celles figurant sur la liste de ce document.

'aucun' : Il n’y a pas de cause. Cette cause d’état est sémantiquement équivalente à "causes-d’état-d’imprimante" sans aucune valeur et DOIT être utilisée, car la syntaxe d’attribut 1setOf exige au moins une valeur.

'passage-en-pause' : Quelqu’un a mis l’objet imprimante en pause en utilisant l’opération Pause-d’imprimante (voir au paragraphe 3.2.7) ou par un autre moyen, mais le ou les appareils mettent un temps appréciable pour s’arrêter. Ultérieurement, lorsque toute sortie sera arrêtée, "état-d’imprimante" devient 'arrêté', et la valeur 'en-pause' remplace la valeur 'passage-en-pause' dans l’attribut "causes-d’état-d’imprimante". Cette valeur DOIT être prise en charge, si l’opération Pause-d’imprimante est prise en charge et que la mise en œuvre prend un temps significatif pour passer en pause un appareil dans certaines circonstances.

'en-pause' : Quelqu’un a mis l’objet imprimante en pause en utilisant l’opération Pause-d’imprimante (voir au paragraphe 3.2.7) ou un autre moyen et "état-d’imprimante" de l’objet imprimante est 'arrêté'. Dans cet état, une imprimante NE DOIT PAS produire de sortie imprimée, mais elle DOIT effectuer d’autres opérations exigées par un client. Si une imprimante a imprimé une tâche alors que l’imprimante était en pause, l’imprimante DOIT reprendre l’impression de cette tâche lorsque l’imprimante n’est plus en pause et ne laisser aucune trace de cette pause dans la sortie imprimée. Cette valeur DOIT être prise en charge si l’opération Pause-d’imprimante est prise en charge.

'hors-tension' : Quelqu’un a retiré un objet Imprimante du service, et l’appareil peut être débranché ou retiré physiquement. Dans cet état, un objet Imprimante NE DOIT PAS produire de sortie imprimée, et à moins que l’objet imprimante ne soit constitué par un serveur d’impression qui est toujours actif, l’objet imprimante ne DOIT effectuer aucune autre opération demandée par un client, y compris de retourner cette valeur. Si un objet Imprimante a imprimé une tâche alors qu’il était hors-tension, l’imprimante PEUT NE PAS reprendre l’impression de cette tâche lorsqu’elle n’est plus hors-tension. Si l’imprimante reprend l’impression d’une telle tâche, elle peut laisser des traces d’une telle mise hors tension dans la sortie imprimée, par exemple, la partie imprimée avant la mise hors tension peut être imprimée une seconde fois.

'en-cours-de-connexion-à-l’appareil' : L’objet Imprimante a programmé une tâche sur l'appareil de sortie et est en cours de connexion à un appareil de sortie partagé sur le réseau (et peut n’être pas capable de réellement commencer à imprimer la tâche pendant un temps arbitrairement long selon l’utilisation de l’appareil de sortie par d’autres serveurs sur le réseau).

'délai-dépassé' : Le serveur a pu se connecter à l’appareil de sortie (ou y est toujours connecté), mais n’a pas pu obtenir une réponse de cet appareil de sortie.

'en-cours-d’arrêt' : L’objet Imprimante est en train d’arrêter l’appareil et sera arrêté dans un instant. Lorsque l’appareil est arrêté, l’objet imprimante va passer l’état de l’imprimante à 'arrêté'. La cause 'avertissement-d’arrêt' n’est jamais une erreur, même pour une imprimante avec un seul appareil de sortie. Lorsqu’un appareil de sortie cesse d’accepter des tâches, l’imprimante affiche cette cause alors que l’appareil de sortie termine l’impression.

'arrêt-partiel' : Lorsqu’un objet Imprimante contrôle plus d’un appareil de sortie, cette cause indique qu’un ou plusieurs appareils de sortie sont arrêtés. Si la cause est un rapport, moins de la moitié des appareils de sortie sont arrêtés. Si la cause est un avertissement, moins de la totalité des appareils de sortie sont arrêtés.

'zone-de-dévidage-pleine' : La limite de stockage permanent allouée pour le dévidage a été atteinte. L’imprimante est temporairement incapable d’accepter des tâches supplémentaires. L’imprimante retirera cette valeur lorsqu’elle sera capable d’accepter plus de tâches. Cette valeur DEVRAIT être utilisée par une imprimante sans dévidage qui n’accepte qu’un petit nombre de tâches à la fois ou par une imprimante à dévidage qui a rempli son espace de dévidage.

'déverrouillé' : Un ou plusieurs systèmes de verrouillage de l’imprimante sont ouverts.

'bac-d’entrée-absent' : Un ou plusieurs bacs d'entrée ne sont pas dans l’appareil.

'niveau-de-papier-faible' : Au moins un bac d’entrée a un faible niveau de papier.

'bac-de-sortie-manquant' : Un ou plusieurs bacs de sortie ne sont pas dans l’appareil.

'zone-de-sortie-presque-pleine' : Une ou plusieurs zones de sortie sont presque pleines (par exemple, bac, empileur, assembleuse).

'zone-de-sortie-pleine' : Une ou plusieurs zones de sortie sont pleines. (par exemple, bac, empileur, assembleuse).

'niveau-de-marquage-bas' : L’appareil a un niveau bas sur au moins un produit de marquage fourni. (Par exemple, toner, encre, ruban.)

'marquage-vide' : L’appareil est à court d’au moins un produit de marquage fourni. (Par exemple, toner, encre, ruban.)

'rebuts-de-marquage-presque-pleins' : Le réceptacle à rebuts de marquage de l’appareil est presque plein.

'rebuts-de-marquage-plein' : Le réceptacle à rebuts de marquage de l’appareil est plein.

'fusible-anormalement-chaud' : La température d’un fusible est anormalement élevée.

'fusible-anormalement-froid' : La température d’un fusible est anormalement faible.

'interprète-de-ressource-non-disponible' : Un interprète de ressource est indisponible (c’est-à-dire police de caractères, format).

Cet attribut d’imprimante spécifie les informations sur les attributs "état-d’imprimante" et "causes-d’état-d’imprimante" en texte lisible par l’homme. Si l’objet imprimante prend en charge cet attribut, l’objet imprimante DOIT être capable de générer ce message dans tous les langages naturels identifiés par le l’attribut "langage-naturel-généré-pris-en-charge" de l’imprimante (voir l’attribut d’opération "langage-naturel-des-attributs" spécifié au paragraphe 3.1.4.1).

Cet attribut EXIGÉ identifie la ou les versions de protocole IPP que cette imprimante prend en charge, y compris les versions majeures et mineures, c’est-à-dire, les numéros de version pour lesquels cette mise en œuvre d’imprimante satisfait les exigences de conformité. Pour la validation de numéro de version, l’imprimante confronte le paramètre (binaire à deux octets) "numéro-de-version" fourni par le client dans chaque demande (voir aux paragraphes 3.1.1 et 3.1.8) aux valeurs (US-ASCII) de mot-clé de cet attribut.

'1.0' : Satisfait aux exigences de conformité de la version 1.0 de IPP comme spécifié dans la RFC 2566 [RFC2566] et la RFC 2565 [RFC2565] y compris toutes extensions enregistrées conformément à la Section 6 et toute extension définie dans la présente version ou toute future version du document IPP "Modèle et sémantique" ou du document IPP "Codage et transport" suivant les règles, s’il en est, lorsque le paramètre "numéro-de-version" est '1.0'.

'1.1': Satisfait aux exigences de conformité de la version 1.1 de IPP comme spécifié dans le présent document et dans [RFC2910] y compris toutes extensions enregistrées conformément à la Section 6 et toute extension définie dans toutes futures versions du document IPP "Modèle et sémantique" ou du document IPP "Codage et transport" suivant les règles, s’il en est, lorsque le paramètre "numéro-de-version" est '1.1'.

Cet attribut d’imprimante EXIGÉ spécifie l’ensemble des opérations prises en charge pour cet objet Imprimante et objets Tâche contenus.

Cet attribut est codé comme tout autre syntaxe d’attribut enum conformément à la [RFC2910] en 32 bits. Cependant, toutes valeurs d’enum de 32 bits pour cet attribut NE DOIT PAS excéder 0x00008FFF, car ces mêmes valeurs sont aussi passées en deux octets dans le paramètre "id-d’opération" (voir au paragraphe 3.1.1) dans chaque demande de protocole avec les deux octets d’ordre élevé omis afin d’indiquer l'opération en cours [RFC2910].

Les valeurs standard enum et "id-d’opération" (voir au paragraphe 3.1.2) suivantes sont définies :

Cet attribut d’imprimante indique si l’imprimante prend en charge ou non plus d’un document par tâche, c’est-à-dire, plus d’une opération Document-d’envoi ou Données-d’envoi avec des données documentaires. Si l’imprimante prend en charge les opérations Création-de-tâche et Document-d’envoi (voir au paragraphe 3.2.4 et 3.3.1), elle DOIT prendre en charge cet attribut.

Cet attribut d’imprimante EXIGÉ identifie le charset que l’objet imprimante a reçu en configuration pour représenter les attributs d’imprimante 'texte' et 'nom' qui sont réglés par l’opérateur, administrateur de système, ou fabricant, c’est-à-dire, pour "nom-d’imprimante" (nom), "localisation-d’imprimante" (texte), "info-d’imprimante" (texte), et "marque-et-modèle-d’imprimante" (texte). Donc, la valeur de l’attribut "charset-configuré" de l’objet imprimante DOIT aussi être parmi les valeurs de l’attribut "charset-accepté" de l’objet imprimante.

Cet attribut d’imprimante EXIGÉ identifie l’ensemble des charsets que l’imprimante et les objets Tâche contenus prennent en charge dans les attributs avec la syntaxe d’attribut 'texte' et 'nom'. La valeur 'utf-8' DOIT au moins être présente, car les objets IPP DOIVENT prendre en charge le charset UTF-8 [RFC2279]. Si un objet Imprimante prend en charge un charset, cela signifie que pour tout attribut de syntaxe 'texte' et 'nom' l’objet IPP DOIT (1) accepter le charset dans les demandes et retourner le charset en tant que de besoin dans les réponses.

Si plus de charsets que UTF-8 sont pris en charge, l’objet IPP DOIT effectuer la conversion de charset entre les charsets comme décrit au paragraphe 3.1.4.2.

Cet attribut d’imprimante EXIGÉ identifie Le langage naturel Avec lequel l’objet imprimante a été configuré pour représenter les attributs d’imprimante 'texte' et 'nom' qui sont réglés par l’opérateur, l’administrateur de système, ou le fabricant, c’est-à-dire, pour "nom-d’imprimante" (nom), "localisation-d’imprimante" (texte), "info-d’imprimante" (texte), et "marque-et-modèle-d’imprimante" (texte). Lorsqu’il retourne ces attributs d’imprimante, l’objet imprimante PEUT les retourner dans le langage naturel configuré spécifié par cet attribut, au lieu du langage naturel demandé par le client dans l’attribut d’opération "langage-naturel-des-attributs". Voir au paragraphe 3.1.4.1 la spécification de la prise en charge FACULTATIVE de plusieurs langages naturels. Donc, la valeur de l’attribut "langage-naturel-configuré" de l’objet imprimante DOIT aussi être parmi les valeurs de l’attribut "langage-naturel-généré-pris-en-charge" de l’objet imprimante.

Cet attribut d’imprimante EXIGÉ identifie le ou les langages naturels que l’objet imprimante et les objets Tâche contenus prennent en charge dans les attributs avec la syntaxe d’attribut 'texte' et 'nom'. Le ou les langages naturels pris en charge dépendent de la mise en œuvre et/ou de la configuration. A la différence des charsets, les objets IPP DOIVENT accepter les demandes avec tout langage naturel ou tout Outrepasser le langage naturel, que le langage naturel soit pris en charge ou non.

Si un objet Imprimante prend en charge un langage naturel, cala signifie que pour tous les attributs pour lesquels l’imprimante ou l’objet Tâche génère des messages, c’est-à-dire, pour les attributs "message-d’état-de-tâche" et "message-d’état-d’imprimante" et les messages d’opération (voir au paragraphe 3.1.5) dans les réponses d’opération, l’imprimante et les objets Tâche DOIVENT être capables de générer des messages dans tous les langages naturels pris en charge par l’imprimante. Voir au paragraphe 3.1.4 la définition des attributs 'texte' et 'nom' dans les demandes et réponses d’opération.

Note : Un objet Imprimante qui prend en charge plusieurs langages naturels a souvent des catalogues de messages séparés, un pour chaque langage naturel pris en charge.

Cet attribut d’imprimante EXIGÉ identifie le format de document dans lequel l’objet imprimante a été configuré pour faire face au cas où le client ne fournit pas d’attribut d’opération "format-de-document" dans une des demandes d’opération qui fournissent les données documentaires. Les valeurs standard pour cet attribut sont Types de support Internet (parfois appelés types MIME). Pour des détails complémentaires, voir la description de la syntaxe d’attribut 'typeDeSupportMime' au paragraphe 4.1.9.

Cet attribut d’imprimante EXIGÉ identifie l’ensemble des formats de document que l’objet imprimante et les objets Tâche contenus peuvent prendre en charge. Pour des détails complémentaires, voir la description de la syntaxe d’attribut 'typeDeSupportMime' au paragraphe 4.1.9.

Cet attribut d’imprimante EXIGÉ indique si l’imprimante est actuellement capable d’accepter des tâches, c’est-à-dire, d’accepter des demandes Tâche-d’impression, URI-d’impression, et Création-de-tâche. Si la valeur est 'vrai', l’imprimante accepte des tâches. Si la valeur est 'faux', l’objet imprimante rejette actuellement toute tâche qui lui est soumise. Dans ce cas, l’objet imprimante retourne le code d’état 'erreur-serveur-refus-de-tâches'.

Cette valeur est indépendante des attributs "état-d’imprimante" et "causes-d’état-d’imprimante" parce que sa valeur n’affecte pas la tâche en cours ; elle affecte plutôt les tâches futures. Cet attribut, lorsqu’il est 'faux', est cause que l’imprimante rejette les tâches même lorsque "état-d’imprimante" est 'repos' ou, lorsqu’il est 'vrai', cause l’acceptation de tâches par l’objet imprimante même lorsque "état-d’imprimante" est 'arrêté'.

Cet attribut d’imprimante EXIGÉ contient un décompte du nombre de tâches qui sont 'en-instance', 'traitement-en-cours', 'gardé-en-instance', ou 'traitement-arrêté' et il est réglé par l’objet imprimante.

Cet attribut d’imprimante fournit un message provenant d’un opérateur, administrateur de système ou d’un processus "intelligent" pour indiquer à l’utilisateur final des informations sur ou l’état de l’imprimante, telles que pourquoi elle est indisponible ou lorsqu’on peut s’attendre qu’elle soit disponible.

Cet attribut d’imprimante identifie si l’appareil est capable d’un type d’impression couleur, y compris en surbrillance. Toutes les instructions documentaires ayant à faire avec la couleur sont incorporées dans le PDL du document (aucun ne sont des attributs IPP externes dans IPP/1.1).

Note : Les utilisateurs finaux sont capables de déterminer la nature et les détails de la prise en charge de la couleur en interrogeant l’attribut d’imprimante "info-suplémentaires-de-fabricant-d’imprimante".

Cet attribut d’imprimante spécifie quels schémas d’URI sont pris en charge pour utilisation dans l’attribut d’opération "uri-de-document" de l’opération URI-d’impression ou URI-d’envoi. Si un objet Imprimante prend en charge ces opérations facultatives, il DOIT prendre en charge l’attribut d’imprimante "schémas-d’uri-de-référence-pris-en-charge" avec au moins la valeur de schéma d’URI suivante :

'ftp' : L’objet Imprimante va utiliser une opération FTP 'get' telle que défini dans la RFC 2228 [RFC2228] en utilisant les URL de FTP comme défini par les [RFC2396] et [RFC2316].

L’objet Imprimante PEUT FACULTATIVEMENT prendre en charge d’autres schémas d’URI (voir au paragraphe 4.1.6).

Cet attribut d’imprimante EXIGÉ exprime la capacité d’une mise en œuvre particulière d’imprimante à essayer ou non d’outrepasser les instructions des données documentaires avec des attributs IPP.

- 'tenté' : Cette valeur indique que l’objet imprimante essaye de faire que les valeurs d’attribut IPP prennent le pas sur les instructions incorporées dans les données documentaires, cependant ce résultat n’est pas garanti.

- 'non-tenté' : Cette valeur indique que l’objet imprimante n’essaye pas de faire que les valeurs des attributs IPP prennent le pas sur les instructions incorporées dans les données documentaires.

La Section 15 contient une description complète de la façon dont cet attribut interagit avec les autres attributs IPP et les affecte, particulièrement l’attribut "fidélité-d’attribut-ipp".

Cet attribut d’imprimante EXIGÉ indique la quantité de temps (en secondes) pendant laquelle cette instance d’imprimante a été sous tension et en fonctionnement. La valeur est à croissance monotone commençant à 1 lorsque l’objet imprimante est démarré (initialisé, amorcé, etc.). Cette valeur est utilisée pour remplir les attributs de tâche de description de tâche d’heure d’événement "heure-de-création", "heure-du-traitement", et "heure-de-fin" (voir au paragraphe 4.3.14).

Si l’objet imprimante descend à une certaine valeur 'n', et revient ensuite, la mise en œuvre PEUT :

1. Savoir combien, de temps elle a été arrêtée, et reprendre à une valeur supérieure à 'n', ou

En d’autres termes, si l’appareil, ou les appareils que l’objet imprimante représente, redémarrent ou sont mis sous tension, l’objet imprimante PEUT continuer de compter cette valeur ou PEUT remettre cette valeur à 1 selon l’implémentation. Cependant, si le logiciel de l’objet imprimante cesse de tourner, et redémarre sans savoir la dernière valeur de "temps-de-fonction-de-l’imprimante", la mise en œuvre DOIT remettre cette valeur à 1. Si cette valeur est rétablie et que l’imprimante a des tâches persistantes, l’imprimante DOIT remettre les attributs de description de tâche d’heure d’événement "heure-à-xxx"(entier) conformément au paragraphe 4.3.14. Une mise en œuvre PEUT utiliser les deux alternatives, selon respectivement qu’elle démarre à chaud ou à froid.

Cet attribut d’imprimante indique la date et l’heure courante. Cette valeur est utilisée pour remplir les attributs de description de tâche d’heure d’événement : "date-heure-de-création", "date-heure-de-traitement", et "date-heure-de-fin" (voir au paragraphe 4.3.14).

La date et l’heure sont obtenus sur une base "au mieux" et n’ont pas besoin d’être très précises pour remplir leur rôle. Une mise en œuvre d’imprimante règle la valeur de cet attribut en obtenant la date et l’heure par un moyen dépendant de la mise en œuvre, comme d’obtenir la valeur d’un serveur horaire du réseau, d’une initialisation du temps en usine, ou du réglage par un administrateur. Voir [IPP-IIG] pour des exemples. Si une mise en œuvre prend en charge cet attribut et que la mise en œuvre sait qu’il n’a pas encore été réglé, elle DOIT alors retourner la valeur de cet attribut en utilisant 'pas-de-valeur' hors-bande qui signifie non configuré. Voir au début du paragraphe 4.1.

La zone horaire de cet attribut PEUT NE PAS être la zone horaire utilisée par les gens près de l’objet imprimante ou appareil. Le client NE DOIT PAS s’attendre à ce que la zone horaire de toute valeur 'dateHeure' reçue soit dans la zone horaire du client ou dans la zone horaire des gens proches de l’imprimante.

Le client DEVRAIT afficher à l’utilisateur tout attribut dateHeure en heure locale du client en convertissant la valeur 'dateHeure' retournée par le serveur dans la zone horaire du client, plutôt que d’utiliser la zone horaire retournée par l’imprimante dans les attributs qui utilisent la syntaxe d’attribut 'dateHeure'.

Cet attribut d’imprimante identifie la durée minimum (en secondes) pendant laquelle l’objet imprimante attend des opérations Document-d’envoi ou URI-d’envoi supplémentaires pour suivre un objet Tâche encore ouvert avant d’entreprendre aucune action de récupération, telles que celles indiquées au paragraphe 3.3.1. Si l’objet imprimante prend en charge les opérations Création-de-tâche et Document-d’envoi (voir aux paragraphes 3.2.4 et 3.3.1), il DOIT prendre en charge cet attribut.

Il est RECOMMENDÉ que les fabricants fournissent une valeur entre 60 et 240 secondes pour cet attribut. Une mise en œuvre PEUT permettre à un administrateur de système de régler cet attribut (par des moyens non définis dans le présent document IPP/1.1). S’il en est ainsi, l’administrateur de système PEUT être capable de mettre des valeurs en-dehors de cette gamme.

Cet attribut d’imprimante EXIGÉ identifie l’ensemble des algorithmes de compression pris en charge pour les données documentaires. La compression ne s’applique qu’aux données documentaires ; elle ne s’applique pas au codage de l’opération IPP elle-même. Les valeurs prises en charge sont utilisées pour valider les attributs d’opération "compression" fournis par le client dans les demandes Tâche-d’impression, Document-d’envoi, et URI-d’envoi.

'deflate' : technique de compression ZIP du domaine public (inflate/deflate) dans la RFC 1951 [RFC1951] technique de compression 'gzip' GNU zip décrite dans la RFC 1952 [RFC1952].

Cet attribut d’imprimante spécifie les limites supérieure et inférieure des tailles totales des tâches en K octets, c’est-à-dire, en unités of 1024 octets. Les valeurs prises en charge sont utilisées pour valider les attributs d’opération "k-octets-de-tâche" fournis par le client dans les demandes de création. L’attribut de description de tâche correspondant "k-octets-de-tâche" est défini au paragraphe 4.3.17.1.

Cet attribut d’imprimante spécifie les limites supérieure et inférieure pour le nombre d’impressions par tâche. Les valeurs prises en charge sont utilisées pour valider les attributs d’opération "tâches-d’impression" fournis par le client dans les demandes de création. L’attribut de description de tâche correspondant "tâches-d’impression" est défini au paragraphe 4.3.17.2.

4.4.35 feuilles-de-support-de-tâche-prises-en-charge (gammeD’Entier(0:MAX))

Cet attribut d’imprimante spécifie les limites supérieure et inférieure pour le nombre de feuilles de support par tâche. Les valeurs prises en charge sont utilisées pour valider les attributs d’opération "feuilles-de-support-de-tâche" fournies par le client dans les demandes de création. L’attribut de tâche "feuilles-de-support-de-tâche" correspondant est défini au paragraphe 4.3.17.3.

Cet attribut d’imprimante spécifie le nombre nominal de pages par minute au plus proche nombre entier qui peut être généré par cette imprimante (par exemple, simplex, noir-et-blanc). Cet attribut est informatif, sans garantie de service. Généralement, c’est la valeur utilisée dans la littérature commerciale pour décrire l’appareil.

Une valeur de 0 indique un appareil qui met plus de deux minutes pour traiter une page.

Cet attribut d’imprimante spécifie le nombre nominal de pages par minute au plus proche nombre entier qui peut être généré pat cette imprimante lorsqu’elle imprime de al couleur (par exemple, simplex, couleur). Pour les besoins de cet attribut, "couleur" signifie la même chose que l’attribut "couleur-prise-en-charge", à savoir que l’appareil est capable tout type d’impression couleur, y compris le surlignage en couleur. Cet attribut est informatif, sans garantie de service. Généralement, c’est la valeur utilisée dans la littérature commerciale pour décrire les capacités en couleur de cet appareil.

Une valeur de 0 indique un appareil qui met plus de deux minutes pour traiter une page.

Si un appareil couleur a plusieurs modes de couleur, il PEUT utiliser la valeur pages-par-minute pour cet attribut qui correspond au mode qui produit le nombre le plus élevé.

Les imprimantes seulement noir et blanc NE DOIVENT PAS prendre en charge cet attribut. Si cet attribut est présent, l’attribut de description d’imprimante "couleur-prise-en-charge" DOIT être présent et avoir une valeur 'vrai'.

Les valeurs de ces deux attributs retournés par l’opération Obtenir-les-attributs-d’imprimante PEUVENT être affectées par l’attribut "format-de-document" fourni par le client dans la demande Obtenir-les-attributs-d’imprimante. En d’autres termes, la mise en œuvre PEUT avoir des vitesses différentes selon le format de document traité. Voir au paragraphe 3.2.5.1 Obtenir-les-attributs-d’imprimante.

5. Conformité

La présente section décrit les questions et exigences de conformité. Le présent document introduit des entités de modélisation telles que des objets, des opérations, des attributs, des syntaxes d’attribut, et des valeurs d’attribut. Les paragraphes sur la conformité décrivent les exigences de conformité qui s’appliquent à ces entités de modélisation.

5.1 Exigences de conformité pour le client

Ce paragraphe décrit les exigences de conformité pour un client (voir au paragraphe 2.1), qu’il soit :

1. contenu dans un logiciel contrôlé par un utilisateur final, par exemple, activé par l’élément de menu "Imprimer" dans une application qui envoie des demandes IPP ou

2. le composant de serveur d’impression qui envoie des demandes IPP à un appareil de sortie ou un autre serveur d’impression "aval".

Un client conforme DOIT prendre en charge toute opération EXIGÉE comme défini dans le présent document. Pour chaque attribut inclus dans une demande d’opération, un client conforme DOIT fournir une valeur dont la syntaxe de type et de valeur se conforment aux exigences du document de modélisation, comme spécifié aux Sections 3 et 4. Un client conforme PEUT fournir toute extension normalisée par l’IETF et/ou extensions du fabricant dans une demande d’opération, tant que ces extensions satisfont aux exigences de la Section 6.

Autrement, il n’y a pas d’exigences de conformité quant aux interfaces d’utilisateur fournies par les clients IPP ou leurs applications. Par exemple, une application peut ne pas permettre qu’un l’utilisateur final soumette plusieurs documents par tâche, alors qu’une autre le permet. Une application peut interroger d’abord un objet Imprimante afin de fournir une boîte de dialogue d’interface d’utilisateur graphique (GUI, graphical user interface) avec des valeurs prises en charge et par défaut alors qu’une mise en œuvre différente ne le fera pas.

Lorsqu’il envoie une demande, un client IPP PEUT NE PAS fournir les attributs indiqués comme FACULTATIFS fournis par le client.

Un client DOIT être capable d’accepter toutes les syntaxes d’attribut définies au paragraphe 4.1, y compris leur gamme complète, qui peuvent lui être retournées dans une réponse d’un objet Imprimante. En particulier, pour chaque attribut que le client prend en charge dont la syntaxe d’attribut est 'texte', le client DOIT accepter et traiter à la fois les formes 'texteSansLangage' et 'texteAvecLangage'. De même, pour chaque attribut que le client prend en charge dont la syntaxe d’attribut est 'nom', le client DOIT accepter et traiter à la fois les formes 'nomSansLangage' et 'nomAvecLangage'. Pour les besoins de la présentation, la troncature des longues valeurs d’attribut n’est pas recommandée. Une approche recommandée serait que la mise en œuvre de client permette à l’utilisateur de dérouler les longues valeurs d’attribut.

Une réponse PEUT contenir des groupes d’attributs, des attributs, des syntaxes d’attribut, des valeurs, et des codes d’état auxquels le client ne s’attend pas. Donc, une mise en œuvre de client DOIT traiter de bonne grâce de telles réponses et ne pas refuser d’interopère avec une imprimante conforme qui retourne des extensions normalisées par l’IETF ou des extensions du fabricant, incluant des groupes d’attributs, des attributs, des syntaxes d’attribut, des valeurs d’attribut, des codes d’état, et des valeurs d’attribut hors-bande conformes à la Section 6. Les clients peuvent choisir d’ignorer tout paramètre, groupe d’attributs, attribut, syntaxe d’attribut, ou valeur qu’ils ne comprennent pas.

Alors qu’un client envoie des données à une imprimante, il DEVRAIT faire de son mieux pour empêcher qu’un canal soit fermé par une couche inférieure lorsque le canal est bloqué (c’est-à-dire plus de contrôle sur le flux) pour quelque raison que ce soit, par exemple, 'plus de papier' ou 'la tâche à accomplir n'a pas libéré suffisamment de mémoire'. Cependant, la couche qui a lancé la soumission d’impression (par exemple, un utilisateur final) PEUT clore le canal afin d’annuler la tâche. Lorsqu’un client ferme un canal, une imprimante PEUT imprimer tout ou partie de la portion du document reçue. Voir le document "Codage et transport" [RFC2910] pour des précisions.

Un client DOIT prendre en charge l’authentification du client comme défini dans le document IPP/1.1 Codage et transport [RFC2910]. Un client DEVRAIT prendre en charge la confidentialité d’opération et l’authentification du serveur, comme défini dans le document IPP/1.1 Codage et transport [RFC2910]. Voir aussi la Section 8 du présent document.

5.2 Exigences de conformité des objets IPP

Ce paragraphe spécifie les exigences de conformité pour les mises en œuvre conformes des objets IPP (voir la Section 2). Ces exigences s’appliquent à un objet IPP qu’il soit :

(1) un composant d’appareil (incorporé) qui accepte des demandes IPP et contrôle l’appareil ou

(2) un composant d’un serveur d’impression qui accepte des demandes IPP (où le serveur d’impression contrôle un ou plusieurs appareils en réseau utilisant IPP ou d’autres protocoles).

Les mises en œuvre conformes DOIVENT mettent en œuvre tous les objets de modélisation comme défini dans le présent document dans les paragraphes indiqués :

Les mises en œuvre d’objet IPP conformes DOIVENT mettre en œuvre toutes les opérations EXIGÉES du modèle, y compris les réponses EXIGÉES, comme défini au présent document dans les paragraphes indiqués :

Les objets IPP conformes DOIVENT prendre en charge tous les attributs d’opération EXIGÉS et toutes les valeurs de tels attributs si c’est indiqué dans la description. Les objets IPP conformes DOIVENT ignorer tous les attributs d’opération ou groupes d’attributs d’opération non acceptés ou inconnus reçus dans une demande, mais DOIVENT rejeter une demande qui contient un attribut d’opération pris en charge qui contient une valeur non acceptée.

Les objets IPP conformes PEUVENT retourner des réponses d’opération qui contiennent des groupes d’attributs, des noms d’attribut, des syntaxes d’attribut, des valeurs d’attribut, et des codes d’état qui sont des extensions de la présente norme. Les groupes d’attribut supplémentaires PEUVENT survenir dans n’importe quel ordre.

Le paragraphe suivant sur les attributs d’objet spécifie la prise en charge exigée pour les attributs d’objet.

Les objets IPP conformes DOIVENT prendre en charge tout attribut d’objet EXIGÉ, comme défini dans le présent document dans les paragraphes indiqués.

Si un objet prend en charge un attribut, il ne DOIT prendre en charge que les valeurs spécifiées dans le présent document ou par le mécanisme d’extension décrit au paragraphe 5.2.4. Il PEUT prendre en charge tout sous-ensemble non vide de ces valeurs. C’est-à-dire qu’il DOIT prendre en charge au moins une des valeurs spécifiées et au plus toutes.

Les clients IPP/1.1 DOIVENT satisfaire aux exigences de conformité pour les clients spécifiées dans le présent document et [RFC2910]. Les clients IPP/1.1 DOIVENT envoyer des demandes contenant un paramètre "numéro-de-version" avec une valeur '1.1'.

Les imprimantes et objet Tâches IPP/1.1 DOIVENT satisfaire aux exigences de conformité pour les objets IPP spécifiés dans le présent document et [RFC2910]. Les objets IPP/1.1 DOIVENT accepter les demandes contenant un paramètre "numéro-de-version" avec une valeur '1.1' (ou rejeter la demande si l’opération n’est pas prise en charge).

Il est en dehors du domaine d’application de la présente spécification d’obliger à la conformité avec les précédentes versions. IPP/1.1 a été délibérément conçu, cependant, pour faciliter la prise en charge des versions précédentes. On peut noter qu’à l’heure où la présente spécification est rédigée (1999), on s’attend à ce que les mises en œuvre d’imprimantes IPP/1.1 :

répondent de façon appropriée par une réponse contenant la même valeur de paramètre "numéro-de-version" que celle utilisée par le client dans la demande.

Il est recommandé que les clients IPP/1.1 essayent de fournir des numéros de version de remplacement si ils reçoivent une erreur 'erreur-serveur-version-non-prise-en-charge' retournée dans une réponse.

Un objet IPP conforme PEUT prendre en charge des extensions normalisées de l’IETF et des extensions du fabricant, tant que ces extensions satisfont aux exigences spécifiées à la Section 6.

Pour chaque attribut inclus dans une réponse d’opération, un objet IPP conforme DOIT retourner une valeur dont la syntaxe de type et de valeur est conforme aux exigences du document de modélisation comme spécifié aux Sections 3 et 4.

Un objet IPP DOIT être capable d’accepter toutes les syntaxes d’attribut définies au paragraphe 4.1, y compris leur gamme complète, dans toute opération dans laquelle un client peut fournir des attributs ou où l’administrateur de système peut configurer des attributs (par des moyens qui sortent du domaine d’application du présent document IPP/1.1). En particulier, pour chaque attribut que l’objet IPP prend en charge dont la syntaxe d’attribut est 'texte', l’objet IPP DOIT accepter et traiter à la fois les formes 'texteSansLangage' et 'texteAvecLangage'. De même, pour chaque attribut que l’objet IPP prend en charge dont la syntaxe d’attribut est 'nom', l’objet IPP DOIT accepter et traiter à la fois les formes 'nomSansLangage' et 'nomAvecLangage'. De plus, un objet IPP DOIT retourner au client dans une réponse d’opération des attributs conformes à la syntaxe spécifiée au paragraphe 4.1, y compris leur gamme complète si elle a été fournie précédemment par un client.

Une mise en œuvre d’imprimante IPP DEVRAIT contenir la prise en charge de l’authentification du client comme défini dans le document IPP/1.1 Codage et Transport [RFC2910]. Une mise en œuvre d’imprimante PEUT permettre à un administrateur de configurer l’imprimante de telle sorte que tous, certains ou aucun des utilisateurs soient authentifiés. Voir aussi la section 8 du présent document.

Une mise en œuvre d’imprimante IPP DEVRAIT contenir la prise en charge de la confidentialité de fonctionnement et de l’authentification du serveur comme défini dans le document IPP/1.1 Codage et Transport [RFC2910]. Une mise en œuvre d’imprimante PEUT permettre à un administrateur de configurer le degré de prise en charge de la confidentialité de fonctionnement et de l’authentification du serveur. Voir aussi la section 8 du présent document.

La sécurité NE DOIT PAS être compromise lorsque un client fournit un paramètre "numéro-de-version" inférieur dans une demande. Par exemple, si un objet Imprimante IPP/1.1 conforme accepte les demandes de version '1.0' et est configuré pour mettre en application l’authentification abrégée, il DOIT faire de même pour une demande de version '1.0'.

5.3 Exigences de charset et de langage naturel

Tous les clients et objets IPP DOIVENT prendre en charge le charset 'utf-8' comme défini au paragraphe 4.1.7.

Les objets IPP DOIVENT être capables d’accepter toute demande de client qui utilise correctement l’attribut d’opération "langage-naturel-des-attributs" ou le mécanisme Outrepasser le langage naturel sur tout attribut individuel que le langage naturel soit pris en charge par l’objet IPP ou non. Si un objet IPP prend en charge un langage naturel, il DOIT alors être capable de traduire (peut-être en consultant un tableau) toute valeur d’attribut 'texte' ou 'nom' généré dans un des langages pris en charge (voir au paragraphe 3.1.4). C’est-à-dire que l’objet IPP qui prend en charge un langage naturel PEUT NE PAS être un traducteur général de toute valeur arbitraire de 'texte' ou 'nom' fournie par le client dans ce langage naturel. Cependant, l’objet DOIT être capable de traduire (générer automatiquement) toutes ses propres valeurs d’attribut et de messages dans ce langage naturel.

6. Considérations relatives à l’IANA

La présente section décrit les procédures de définition de la sémantique pour les extensions normalisées de l’IETF et les extensions de fabricant au document IPP/1.1 Modèle et Sémantique suivantes :

Les extensions enregistrées pour être utilisées avec IPP/1.1 sont FACULTATIVES pour la conformité du client et de l’objet IPP au document IPP/1.1 "Modèle et sémantique" (ce document).

Ces procédures d’extension sont en ligne avec les directives établies par l’IESG [IANA-CON]. La section 11 décrit comment proposer la prise en considération de nouveaux enregistrements. L’IANA rejettera les propositions d’enregistrement qui ne comportent pas les informations demandées ou ne suivent pas le format approprié décrit à la section 11. Le document IPP/1.1 Modèle et Sémantique peut aussi être prolongé par une RFC appropriée qui spécifie une des extensions ci-dessus.

6.1 Extensions des types 'mot-clé' et 'enum'

IPP permet des extensions pour 'mot-clé' et 'enum' (voir aux paragraphes 4.1.2.3 et 4.1.4). Le présent document appose des préfixes aux types de syntaxe d’attribut de base 'mot-clé' et 'enum' afin de communiquer des informations supplémentaires au lecteur par son nom. Ces informations supplémentaires ne sont pas représentées dans le protocole parce que cela est sans importance pour un client ou objet Imprimante. La liste ci-dessous décrit les préfixes et leur signification.

"type1" : Ce document de spécification IPP doit être révisé (ou un autre document de normalisation de l’IETF qui enrichit le présent document) pour ajouter un nouveau mot-clé ou une nouvelle enum. Aucun mot-clé ou énumération (enum) défini par un fabricant n’est admis.

"type2" : Les développeurs peuvent, à tout moment, ajouter de nouvelles valeurs de mot-clé ou d’enum en proposant la spécification complète à l’IANA : iana@iana.org

IANA transmettra la proposition d’enregistrement à l’expert désigné pour IPP qui relira la proposition avec la liste de diffusion qu’il entretient à cet effet. Au départ, cette liste sera la liste de diffusion utilisée par le groupe de travail IPP : ipp@pwg.org

même après la dissolution du groupe de travail IPP, comme autorisé par [IANA-CON].

L’expert désigné pour IPP est appointé par le directeur de zone responsable d’IPP de l’IESG, conformément à [IANA-CON]. Lorsqu’un mot-clé ou enum de type2 est approuvé, l’expert désigné IPP devient le point de contact pour toute la maintenance qui pourrait être nécessaire à l’avenir pour cet enregistrement.

"type3" : Les développeurs peuvent, à tout moment, ajouter de nouvelles valeurs de mot-clé et d’enum en soumettant comme pour le type2 la spécification complète à l’IANA qui transmettra la proposition à l’expert désigné pour IPP. Bien qu’aucune révision technique supplémentaire ne soit exigée, l’expert désigné pour IPP peut, à sa convenance, transmettre la proposition à la même liste de diffusion que pour les enregistrements de type2 pour avis et commentaires.

Lorsqu’un mot-clé ou enum de type3 est approuvé par l’expert désigné pour IPP, le proposant original devient le point de contact pour toute future maintenance qui pourrait être nécessaire pour cet enregistrement.

Pour les mots-clé de type2 et de type3, le proposant inclut le nom du mot-clé dans la proposition d’enregistrement et le nom fait partie de la révision technique.

Après l’approbation des spécifications des enum de type2 et type3, l’expert désigné IPP alloue, en consultation avec l’IANA le prochain numéro d’enum disponible pour chaque valeur d’enum.

IANA publiera les spécifications d’enregistrement de valeur des attributs de mot-clé et enum de type2 et type3 approuvées dans : ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt

où xxx est le nom d’attribut qui spécifie les valeurs initiales et yyy.txt est un nom de fichier descriptif qui contient un ou plusieurs enum ou mot-clé approuvés en même temps. Par exemple, si plusieurs enum supplémentaires pour l’agrafage sont approuvés pour être utilisées avec l’attribut "finitions" (et les attributs "finitions-par-défaut" et "finitions-prises-en-charge"), IANA publiera les valeurs additionnelles dans le fichier :

Note : Certains attributs sont définis comme étant : 'mot-clé de type3' | 'nom' ce qui permet aux valeurs d’attribut d’être étendues par un administrateur de site avec des noms définis par l’administrateur. De tels noms ne sont pas enregistrés auprès de l’IANA.

Par définition, chacun des trois types ci-dessus relève d’une sorte de registre ou processus de révision pour que les extensions puissent être considérées comme valides. Chaque niveau supérieur (1, 2, 3) tend à être moins contraignant que le niveau précédent. Donc, toute valeur de type N PEUT être enregistrée en utilisant un processus prévu pour un typeM où M est inférieur à N, cependant un tel enregistrement N’EST PAS EXIGÉ. Par exemple, une valeur de type3 PEUT être enregistrée dans une forme de type 1 (en étant incluse dans une future version d’une spécification IPP), cependant, elle N’EST PAS EXIGÉE.

Le présent document définit les valeurs de mot-clé et enum pour tous les types ci-dessus, y compris les mots-clé de type3.

Pour les extensions de mot-clé de fabricant, les développeurs DEVRAIENT utiliser les mots-clé avec un préfixe discriminant convenable, tel que "xxx-" où xxx suit les règles syntaxiques des mots-clé (voir au paragraphe 4.1.3) et est le nom (en minuscules) pleinement qualifié de la compagnie enregistré auprès de l’IANA pour être utilisé dans les noms de domaine [RFC1035]. Par exemple, si la compagnie XYZ Corp. a obtenu le nom de domaine "XYZ.com", un mot-clé 'abc' de fabricant devrait être: 'xyz.com-abc'.

Note : La RFC 1035 [RFC1035] indique qu’alors que les majuscules et les minuscules sont admises dans les noms de domaines, aucune signification n’est attachée à la casse. C’est-à-dire que deux noms avec la même orthographe mais une casse différente seront traités comme identiques. Aussi, les étiquettes dans un nom de domaine doivent suivre les règles des noms d’hôte ARPANET : elles doivent commencer par une lettre, finir par une lettre ou un chiffre, et avoir seulement des lettres, des chiffres et des traits d’union comme caractères internes. Les étiquettes doivent être de 63 caractères au plus. Les étiquettes sont séparées par le caractère ".".

Pour les extensions d’enum de fabricant, les développeurs DOIVENT utiliser des valeurs dans la gamme d’entiers réservée qui est 2**30 à 2**31-1.

6.2 Extensibilité d’attribut

Les noms d’attributs (voir au paragraphe 4.1.3) sont des mots-clé de type2. Donc de nouveaux attributs peuvent être enregistrés et avoir le même statut que les attributs du présent document en suivant les règles d’extension du type2. Pour les extensions d’attributs de fabricant, les développeurs DEVRAIENT utiliser les mots-clé avec un préfixe discriminant convenable tel que décrit au paragraphe 6.1.

L’IANA publiera les spécifications approuvées d’enregistrement d’attribut sous forme de fichiers distincts : ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt

Si un nouvel attribut d’objet Imprimante est défini et que ses valeurs peuvent être affectées par un format spécifique de document, sa spécification devra contenir la phrase suivante :

"La valeur de cet attribut retourné dans une réponse à Obtenir-les-attributs-d’imprimante PEUT dépendre de l’attribut "format-de-document" fourni (voir au paragraphe 3.2.5.1)."

Si la spécification ne le fait pas, sa valeur dans la réponse à Obtenir-les-attributs-d’imprimante NE DOIT PAS alors dépendre du "format-de-document" fourni dans la demande. Lorsqu’un nouvel attribut de gabarit de tâche est enregistré, la valeur des attributs d’imprimante PEUT varier selon le "format-de-document" fourni dans la demande sans que la spécification n’ait à l’indiquer.

6.3 Extensibilité de syntaxe d’attribut

Les syntaxes d’attribut (voir au paragraphe 4.1) sont comme les enum de type2. Donc, les nouvelles syntaxes d’attribut peuvent être enregistrées et avoir le même statut que les syntaxes d’attribut du présent document en suivant les règles d’extension de type2 décrites au paragraphe 6.1. L’ensemble initial des codes de valeur qui identifient chaque syntaxe d’attribut ont été allouées dans le document "Codage et Transport" [RFC2910], et inclut la désignation d’une gamme pour les extensions de fabricant.

Pour les syntaxes d’attribut, l’expert désigné pour IPP alloue en consultation avec l’IANA le nouveau code de syntaxe d’attribut dans la gamme appropriée comme spécifié dans la [RFC2910]. L’IANA publiera les spécifications approuvées d’enregistrement de syntaxe d’attribut sous forme de fichiers distincts :

6.4 Extensibilité d’opération

Les opérations (voir à la section 3) peuvent aussi être enregistrées suivant les procédures de type2 décrites au paragraphe 6.1, bien que les nouvelles opérations majeures soient habituellement traitées par de nouvelles RFC de normalisation qui enrichissent le présent document. Pour les extensions d’opération du fabricant, les développeurs DOIVENT utiliser la gamme pour "id-d’opération" dans les demandes spécifiées au paragraphe 4.4.15 attributs d’imprimante "opérations-prises-en-charge".

Pour les opérations, l’expert désigné pour IPP alloue en consultation avec l’IANA le prochain code d’id-d’opération comme spécifié au paragraphe 4.4.15. L’IANA publiera les spécifications approuvées d’enregistrement d’opération sous forme de fichiers distincts :

6.5 Extensibilité de groupe d’attributs

Les groupes d’attributs (voir au paragraphe 3.1.3) passés dans les demandes et réponses peuvent être enregistrés en suivant les procédures de type2 décrites au paragraphe 6.1. L’ensemble initial des étiquettes de groupe d’attributs a été alloué dans le document "Codage et Transport" [RFC2910], incluant la désignation de la gamme pour l’extension du fabricant.

Pour les groupes d’attributs, l’expert désigné pour IPP alloue en consultation avec l’IANA le prochain code de groupe d’attributs dans la gamme appropriée comme spécifié dans la [RFC2910]. L’IANA publiera les spécifications approuvées d’enregistrement de groupe d’attributs sous forme de fichiers distincts :

6.6 Extensibilité de code d’état

Les opérations de code d’état (voir au paragraphe 3.1.6.1) peuvent aussi être enregistrées suivant les procédures de type2 décrites au paragraphe 6.1. Les valeurs pour les codes d’état sont allouées dans des gammes comme spécifié à la section 14 pour chaque classe de code d’état :

"redirection" - Une action complémentaire doit être entreprise afin de terminer la demande

"erreur-client" – La demande contient une mauvaise syntaxe ou ne peut être satisfaite

"erreur-serveur" - L’objet IPP a échoué à satisfaire une demande apparemment valide

Pour les extensions de code d’état d’opération du fabricant, les développeurs DOIVENT utiliser le haut de chaque gamme comme spécifié à la Section 13.

Pour les codes d’état d’opération, l’expert désigné pour IPP alloue en consultation avec l’IANA le prochain code d’état dans la gamme de classe appropriée comme spécifié à la Section 13. L’IANA publiera les spécifications approuvées d’enregistrement de code d’état sous forme de fichiers distincts :

6.7 Extensibilité de valeur d’attribut hors-bande

Les valeurs d’attribut hors-bande (voir au début du paragraphe 4.1) passées dans les demandes et réponses peuvent être enregistrées en suivant les procédures de type2 décrites au paragraphe 6.1. L’ensemble initial des étiquettes de valeur d’attribut hors-bande ont été allouées dans le document "Codage et Transport" [RFC2910].

Pour les étiquettes de valeur d’attribut hors-bande, l’expert désigné pour IPP alloue en consultation avec l’IANA le prochain code de valeur d’attribut hors-bande dans la gamme appropriée comme spécifié dans la [RFC2910]. L’IANA publiera les spécifications approuvées d’enregistrement d’étiquettes de valeur d’attribut hors-bande sous forme de fichiers distincts :

ftp.isi.edu/iana/assignments/ipp/hors-bande-attribute-valeur-tags/xxx-yyy-tag.txt

où 'xxx-yyy-tag' est le nom de la nouvelle étiquette de valeur d’attribut hors-bande.

6.8 Enregistrement des types/sous-types de MIME pour format-de-document

La syntaxe d’attribut "format-de-document" est 'typeDeSupportMime'. Cela signifie que les valeurs valides sont les types de support Internet (voir au paragraphe 4.1.9). La RFC 2045 [RFC2045] définit la syntaxe pour les types de support Internet valides. L’IANA tient le registre pour tous les types de support Internet.

6.9 Enregistrement des charsets à utiliser dans les valeurs d’attribut 'charset'

La syntaxe d’attribut "charset-des-attributs" est 'charset'. Cela signifie que les valeurs valides sont les noms des charsets. Lorsqu’un charset a plus d’un nom (alias) dans le registre de l’IANA, le nom étiqueté "(nom MIME préféré)", s’il est présent, DOIT être utilisé (voir au paragraphe 4.1.7). L’IANA tient le registre des charsets suivant les procédures de la [RFC2278].

7. Considérations relatives à l’internationalisation

Certains des attributs ont des valeurs qui sont des chaînes de texte et de noms qui sont destinées à la compréhension humaine plutôt que qu’à la compréhension de la machine (voir les syntaxes d’attribut de 'texte' et 'nom' aux paragraphes 4.1.1 et 4.1.2).

- identifie le charset et le langage naturel de la demande qui affectent chaque valeur d’attribut fourni 'texte' et 'nom', et

- demande le charset et le langage naturel pour les attributs retournés par l’objet IPP dans les réponses d’opération (comme décrit au paragraphe 3.1.4.1).

De plus, le client PEUT séparément et individuellement identifier Outrepasser le langage naturel d’un attribut fourni 'texte' ou 'nom' en utilisant la technique 'texteAvecLangage' et 'nomAvecLangage' décrite respectivement aux paragraphes 4.1.1.2 et 4.1.2.2.

Tous les objets IPP DOIVENT prendre en charge le charset UTF-8 [RFC2279] dans tous les attributs 'texte' et 'nom' pris en charge. Si un objet IPP prend en charge plus que le charset UTF-8, il DOIT les convertir entre eux afin de retourner le charset demandé au client conformément au paragraphe 3.1.4.2. Si un objet IPP prend en charge plus d’un langage naturel, il DEVRAIT retourner les valeurs 'texte' et 'nom' dans le langage naturel demandé lorsque ces valeurs sont générées par l’imprimante (voir au paragraphe 3.1.4.1).

Pour les imprimantes qui prennent en charge plusieurs charsets et/ou langages naturels dans les attributs 'texte' et 'nom', différentes tâches peuvent avoir été soumises dans différents charsets et/ou langages naturels. Toutes les réponses DOIVENT être retournées dans le charset demandé par le client. Cependant, l’opération Obtenir-les-tâches utilise le mécanisme 'texteAvecLangage' et 'nomAvecLangage' pour identifier les différents langages naturels avec chaque attribut de tâche retourné.

L’objet Imprimante a aussi des attributs charset et langage naturel configurés. Le client peut interroger l’objet imprimante pour déterminer la liste des charsets et langages naturels pris en charge par l’objet imprimante et les valeurs configurées de l’objet imprimante. Voir les attributs de description d’imprimante "charset-configuré", "charset-accepté", "langage-naturel-configuré", et "langage-naturel-généré-pris-en-charge" pour des détails complémentaires.

L’attribut "charset-accepté" identifie les charsets pris en charge. Si un charset est pris en charge, l’objet IPP DOIT être capable de convertir de et vers ce charset dans tout autre charset pris en charge. Dans de nombreux cas, un objet IPP va prendre en charge seulement un charset et il DOIT être le charset UTF-8.

L’attribut "charset-configuré" identifie le charset pris en charge qui est le charset natif donné par la configuration courante de l’objet IPP (défini par l’administrateur).

L’attribut "langage-naturel-généré-pris-en-charge" identifie l’ensemble des langages naturels pris en charge pour les messages générés ; il n’est pas lié aux ensembles de langages naturels qui doivent être acceptés pour les attributs 'texte' et 'nom' fournis par le client. Pour les attributs 'texte' et 'nom' fournis par le client, un objet IPP DOIT accepter TOUS les langages naturels fournis. Le simple fait qu’un objet Imprimante soit couramment configuré pour prendre en charge le langage naturel 'en-us' ne signifie pas que l’objet imprimante doive rejeter une tâche si le client fournit un nom de tâche qui est en 'fr-ca'.

L’attribut "langage-naturel-configuré" identifie le langage naturel pris en charge pour les messages générés qui est le langage naturel natif donné dans la configuration en cours de l’objet IPP (défini par l’administrateur).

Les attributs de type 'texte' et 'nom' sont remplis à partir de différentes sources. Ces attributs peuvent être catégorisés selon les groupes suivants (selon la source de l’attribut) :

1. Certains attributs sont fournis par le client (par exemple, les attributs d’opération "nom-de-tâche", "nom-du-document", et "nom-de-l’utilisateur-demandeur" fournis par le client avec les attributs "nom-de-tâche" et "nom-d’utilisateur-d’origine-de-tâche" de l’objet Tâche correspondant). L’objet IPP DOIT accepter ces attributs dans tout langage naturel quel que soit l’ensemble des langages pris en charge pour les messages générés.

2. Certains attributs sont fournis par l’administrateur du système (par exemple, les attributs "nom-d’imprimante" et "localisation-d’imprimante" de l’objet imprimante). Eux aussi peuvent être dans tout langage naturel. Si le langage naturel pour ces attributs est différent de ce que demande le client, ils doivent alors être rapportés en utilisant le mécanisme Outrepasser le langage naturel.

3. Certains attributs sont fournis par le fabricant de l’appareil (par exemple, l’attribut "marque-et-modèle-de-l’imprimante" de l’objet imprimante). Eux aussi peuvent être dans tout langage naturel. Si le langage naturel pour ces attributs est différent de ce que demande un client, ils doivent alors être rapportés en utilisant le mécanisme Outrepasser le langage naturel.

4. Certains attributs sont fournis par l’opérateur (par exemple, l’attribut "message-de-tâche-de-l’opérateur" de l’objet Tâche). Eux aussi peuvent être dans tout langage naturel. Si le langage naturel pour ces attributs est différent de ce que demande le client, ils doivent alors être rapportés en utilisant le mécanisme Outrepasser le langage naturel.

5. Certains attributs sont générés par l’objet IPP (par exemple, l’attribut "message-d’état-de-tâche" de l’objet Tâche, l’attribut "message-d’état-d’imprimante" de l’objet imprimante, et l’attribut d’opération "message-d’état"). Ces attributs peuvent seulement être en un des langages naturels de "langage-naturel-généré-pris-en-charge". Si un client demande un langage naturel autre qu’une des valeurs prises en charge pour ces attributs, l’objet IPP DEVRAIT répondre en utilisant la valeur de l’attribut "langage-naturel-configuré" (en utilisant le mécanisme Outrepasser le langage naturel si nécessaire).

Les attributs 'texte' et 'nom' spécifiés dans la présente version de ce document (d’autres seront enregistrés conformément aux procédures de la section 6) sont :

Règle 1 - Ni l’imprimante ni le client ne gèrent ces attributs de message, car ils sont destinés à être utilisés par l’administrateur de système ou autres personnels techniques expérimentés.

8. Considérations sur la sécurité

Il est difficile d’anticiper les risques qui pourraient exister dans un environnement IPP donné. Par exemple, si IPP est utilisé au sein d’une entreprise donnée sur un réseau privé, le risque d’exposer des données documentaires peut être assez faible pour que cette entreprise choisisse de ne pas utiliser de chiffrement de ces données. Cependant, si la connexion entre le client et l’objet IPP est sur un réseau public, le client peut souhaiter protéger le contenu des informations durant la transmission à travers le réseau en le chiffrant.

De plus, la valeur des informations en cours d’impression peut varier d’un environnement IPP à un autre. L’impression des chèques de paye, par exemple, aurait une valeur différente de l’impression d’informations publiques à partir d’un fichier. Il y a aussi la possibilité d’attaques de déni de service, mais les attaques de déni de service contre des ressources d’impression ne sont pas bien comprises et il n’y a pas de précédents publiés sur ce scénario.

Une fois que l’identité authentifiée du demandeur a été fournie à l’objet IPP, il utilise cette identité pour mettre en application toute politique d’autorisation qui peut être mise en place. Par exemple, la politique d’un site pourrait être que seul le propriétaire de la tâche soit autorisé à annuler une tâche. Les détails et mécanismes d’établissement d’une politique particulière de contrôle d’accès ne font pas partie de IPP/1.1, et doivent être établis via d’autres types de cadre de contrôle administratif ou d’accès. Cependant, il y a des codes d’état d’opération qui permettent à un serveur IPP de retourner des informations à un client sur toute violation potentielle de contrôle d’accès pour un objet IPP.

Durant une opération de création, l’identité du client est enregistrée dans l’objet Tâche dans un attribut défini par la mise en œuvre. Cette information peu être utilisée pour vérifier l’identité d’un client pour des opérations ultérieures sur cet objet Tâche afin de mettre en application toute politique de contrôle d’accès qui pourrait être utilisée. Voir des précisions au paragraphe 8.3 ci-dessous.

Comme les niveaux de sécurité ou les menaces spécifiques qui peuvent concerner un administrateur de système IPP ne peuvent être anticipés, IPP DOIT être capable de fonctionner avec différents mécanismes de sécurité et politiques de sécurité selon les demandes de l’installation individuelle. Les politiques de sécurité peuvent varier du très fort au très faible, et à pas du tout, et les mécanismes de sécurité correspondants seront nécessaires.

8.1 Scénarios de sécurité

Les paragraphes suivants décrivent les attaques de sécurité spécifiques des environnements IPP. Lorsque des exemples sont fournis, ils doivent être considérés comme des illustrations de l’environnement et non comme une description exhaustive. La totalité de ces environnements ne sera pas forcément prise en considération dans les mises en œuvre initiales d’IPP.

Cet environnement est typique des réseaux internes où les employés de bureau traditionnels impriment les résultats des applications de leur production personnelle sur des imprimantes partagées entre les membres de l’unité de production, ou dans lesquels des applications par lot impriment leurs résultats sur de grosses imprimantes de production. Bien que l’identité de l’utilisateur puisse être fiable dans cet environnement, un utilisateur peut vouloir protéger le contenu d’un document contre des attaques comme l’espionnage, la substitution ou l’altération.

Parmi les exemples de cet environnement on trouve l’impression d’un document créé par le client sur une imprimante à la disposition du public, telle que dans une boutique d’impressions commerciale; ou l’impression d’un document à distance sur l’imprimante d’un partenaire d’affaires. Cette dernière opération est fonctionnellement équivalente à l’envoi du document au partenaire d’affaires comme télécopie. L’impression d’informations sensibles sur une imprimante dans un domaine de sécurité différent exige de fortes mesures de sécurité. Dans cet environnement, l’authentification de l’imprimante est exigée ainsi que la protection contre les utilisateurs non autorisés de ressources d’impression. Comme le document traverse des domaines de sécurité, la protection contre l’espionnage et l’altération du document est aussi nécessaire. Il sera aussi important dans cet environnement de protéger les imprimantes contre le "pollupostage" et les documents à contenu malveillant.

Lorsque le document n’est pas mémorisé chez le client, l’impression peut être faite par référence. C’est-à-dire que la demande d’impression peut contenir une référence ou pointeur, au document, au lieu du document réel lui-même (voir aux paragraphes 3.2.2 et 3.3.2). Il n’existe pas actuellement de méthode standard pour que les entités distantes "évaluent" les accréditifs d’un client pour transmettre les demandes à un tiers. On suppose par anticipation que l’impression par référence sera utilisée pour accéder à des documents "publics". Les méthodes sophistiquées d’authentification de "mandataires" ne sont pas spécifiées dans le présent document.

8.2 URI dans les attributs d’opération, de tâche, et d’imprimante

L’attribut "uri-d’imprimante-acceptés" contient le ou les URI de l’objet imprimante. Son attribut compagnon, "sécurité-d’uri-prise-en-charge", identifie le mécanisme de sécurité utilisé pour chaque URI figurant sur la liste de l’attribut "uri-d’imprimante-acceptés". Pour chaque demande d’opération d’imprimante, un client DOIT fournir seulement un URI dans l’attribut d’opération "uri-d’imprimante». En d’autres termes, même si l’imprimante prend en charge plus d’un URI, le client n’interagit avec l’objet imprimante qu’en utilisant un seul de ses URI. Cette dualité n’est pas nécessaire pour les objets Tâche, car les objets imprimante sont les fabriques pour les objets Tâche, et l’objet imprimante va générer l’URI correct pour de nouveaux objets Tâche selon la configuration de la sécurité de l’objet imprimante.

8.3 URI pour chaque mécanisme d’authentification

Chaque URI a un mécanisme d’authentification associé. Si l’URI est le i^ème élément de "uri-d’imprimante-acceptés", le mécanisme d’authentification est alors le "i^ème" élément de "authentification-d’uri-prise-en-charge". Pour une liste de mécanismes d’authentification possibles, voir au paragraphe 4.4.2.

L’objet Imprimante utilise un mécanisme d’authentification pour déterminer le nom de l’usager qui effectue une opération. Cet usager est appelé l’"utilisateur authentifié". La crédibilité de l’authentification dépend du mécanisme que l’imprimante utilise pour obtenir le nom de l’utilisateur. Lorsque le mécanisme d’authentification est 'aucun', tous les utilisateurs authentifiés sont "anonymes".

Durant les opérations de création de tâche, l’imprimante initialise la valeur de l’attribut "nom-d’utilisateur-d’origine-de-tâche" (voir au paragraphe 4.3.6) pour être celle de l’utilisateur authentifié. L’utilisateur authentifié est dans ce cas appelé "propriétaire de la tâche".

Si une mise en œuvre peut être configurée pour prendre en charge plus d’un mécanisme d’authentification (voir au paragraphe 4.4.2), elle DOIT alors mettre en œuvre les règles de détermination d’égalité des noms d’utilisateur authentifié qui ont été authentifiés via différents mécanismes d’authentification. Une politique possible est que des noms identiques qui sont authentifiés via des mécanismes différents sont différents. Par exemple, un usager ne peut annuler sa tâche que si il utilise le même mécanisme d’authentification à la fois pour Annuler-la-tâche et Tâche-d’impression. Une autre politique est que des noms identiques qui sont authentifiés via des mécanismes différents soient les mêmes si le mécanisme d’authentification pour la dernière opération n’est pas moins fort que le mécanisme d’authentification pour l’opération de création antérieure. Par exemple, un usager ne peut annuler sa tâche que s’il utilise le même mécanisme d’authentification pour Annuler-la-tâche et Tâche-d’impression ou un plus fort. Avec cette seconde politique, une tâche soumise via l’authentification 'nom-de-l’utilisateur-demandeur' pourrait être annulée via 'authentification-abrégée'. Avec la première politique, la tâche ne pourrait être annulée de cette façon.

Un client est capable de déterminer le mécanisme d’authentification utilisé pour créer une tâche. C’est la i^ème valeur de l’attribut "authentification-d’uri-prise-en-charge" de l’imprimante (voir au paragraphe 4.4.2), où i est l’indice de l’élément de l’attribut "uri-d’imprimante-acceptés" de l’imprimante (voir au paragraphe 4.4.1) égal à l’attribut "tâche-d’uri-d’imprimante" de la tâche (voir au paragraphe 4.3.3).

8.4 Interrogations interdites

Dans nombre des opérations d’IPP, un client fournit une liste des attributs à retourner dans la réponse. Pour des raisons de sécurité, un objet IPP peut être configuré de façon à ne pas retourner tous les attributs (ou toutes les valeurs) que demande un client. Les attributs de tâche retournés PEUVENT dépendre de si l’utilisateur demandeur est le même que l’utilisateur qui a soumis la tâche. L’objet IPP PEUT même ne retourner aucun des attributs demandés. Dans de tels cas, l’état retourné est le même que si l’objet avait retourné tous les attributs demandés. Le client ne peut pas dire avec une telle réponse si l’attribut demandé était présent ou absent sur l’objet.

8.5 Opérations effectuées par des opérateurs et administrateurs de système

Pour les trois opérations d’imprimante Pause-d’imprimante, Reprise-d’imprimante, et Purger-les-tâches (voir aux paragraphes 3.2.7, 3.2.8 et 3.2.9), l’usager demandeur est supposé être un opérateur ou administrateur de l’objet imprimante (voir au paragraphe 1). Autrement, l’imprimante IPP DOIT rejeter l’opération et retourner : 'erreur-client-interdit', 'erreur-client-non-authentifié', ou 'erreur-client-non-autorisé' selon le cas approprié. Pour les opérations sur tâches, l’usager demandeur est supposé être le propriétaire de la tâche ou peut être un opérateur ou administrateur de l’objet imprimante. Les moyens d’autoriser un opérateur ou administrateur de l’objet imprimante ne sont pas spécifiés dans le présent document.

8.6 Interrogations sur des tâches soumises en utilisant des protocoles non-IPP

Si l’appareil que représente une imprimante IPP est capable d’accepter des tâches en utilisant d’autres protocole de soumission de tâche en plus d’IPP, il est RECOMMENDÉ qu’une telle mise en œuvre permette au moins que de telles tâches "étrangères" soient interrogées en utilisant Obtenir-les-tâches en retournant "id-de-tâche" et "uri-de-tâche" comme 'inconnu'. Une telle mise en œuvre PEUT NE PAS prendre en charge tous les mêmes attributs de tâche IPP que pour les tâches IPP. L’objet IPP retourne la valeur hors-bande 'inconnu' pour tout attribut demandé d’une tâche étrangère qui est prise en charge pour des tâches IPP, mais n’est pas une tâche étrangère.

Il est de plus RECOMMENDÉ, que l’imprimante IPP génère des valeurs "id-de-tâche" et "uri-de-tâche" pour de telles "tâches étrangères", si possible, de sorte qu’elles puissent être des cibles pour les autres opérations d’IPP, telles que Obtenir-les-tâches et Annuler-la-tâche. Une telle mise en œuvre doit aussi résoudre le problème de l’authentification de telles tâches étrangères. Une approche possible serait de traiter toute tâche étrangère comme appartenant à des usagers autres que les utilisateurs du client IPP. Une autre approche serait que la tâche étrangère appartienne à 'anonyme'. C’est seulement dans le cas où le client IPP a été authentifié comme opérateur ou administrateur de l’objet imprimante IPP que les tâches étrangères peuvent être interrogées par une demande IPP. Autrement, si la politique de sécurité est de permettre aux utilisateurs d’interroger les tâches des autres usagers, les tâches étrangères seraient alors aussi visibles à un client IPP utilisateur final utilisant Obtenir-les-tâches et Obtenir-les-attributs-de-tâche.

9. Références

[ASME-Y14.1M] Metric Drawing Sheet Size et Format (Taille et format des feuilles de dessin métriques), ASME Y14.1M-1995. Cette norme définit les tailles et formats de feuilles pour le dessin industriel.

[ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange (ASCII) (Ensemble de caractères codés à 7 bits de la norme américaine de code pour les échanges d’information (ASCII)), ANSI X3.4-1986. Cette norme est la spécification du charset US-ASCII.

[BCP-11] Bradner S. et R. Hovey, "The Organizations Involved in the IETF Standards Process" (Organisations impliquées dans le processus de normalisation de l’IETF), BCP 11, RFC 2028, octobre 1996.

[HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft - Hypertext Printing Protocol - HTPP/1.0" (Premier projet – Protocole d’impression Hypertexte), octobre 1996, disponible à ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz

[IANA-CON] Narten, T. et H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs" (Lignes directrices pour la rédaction d’une section sur les questions relatives à l’IANA dans les RFC), BCP 26, RFC 2434, octobre 1998.

[IANA-CS] IANA Registry of Coded Character Sets (Registre IANA des ensembles de caractères codés) : ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets

[IANA-MT] IANA Registry of Media Types (Registre IANA des types de support) : ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/

[IPP-IIG] Hastings, T., Manros, C., Kugler, C., Holst, H., et P. Zehler, "Protocole d’impression sur Internet/1.1 : draft-ietf-ipp-implementers-guide-v11-01.txt, travail en cours, 30 mai 2000.

[ISO10646-1] ISO/CEI 10646-1:1993, "Technologies de l’information – Ensemble de caractères codés universel multi-octet (UCS) - Partie 1 : Architecture et plan multilingue de base, JTC1/SC2."

[ISO8859-1] ISO/CEI 8859-1:1987, "Technologies de l’information – Ensemble de caractères codés à un octet 8 bits - Partie 1 : Alphabet Latin n°1", 1987, JTC1/SC2.

[ISO10175] ISO/CEI 10175 Application d’impression de document (DPA), juin 1996.

[LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P. Zehler, "LDPA - Lightweight Document Printing Application" (Application d’impression de document léger), octobre 1996, ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz

[P1387.4] Kirk, M. (editeur), POSIX System Administration - Part 4: Printing Interfaces (Administration de système POSIX – Partie 4 Interfaces d’impression), POSIX 1387.4 D8, 1994.

[PSIS] Herriot, R. (editeur), X/Open A Printing System Interoperability Specification (PSIS) (Spécification d’interfonctionnement de systèmes d’impression X/Open), août 1995.

[PWG] Printer Working Groupe (groupe de travail Imprimante), http://www.pwg.org.

[RFC1035] Mockapetris, P., "Domain Names - Implementation et Specification" (Noms de domaine – Mise en œuvre et spécification), STD 13, RFC 1035, novembre 1987.

[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol" (Protocole Daemon d’imprimante en ligne), août 1990.

[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. et J. Gyllenskog, "MIB d’imprimante", mars 1995.

[RFC1766] Alvestrand, H., "Tags for the Identification of Languages" (Etiquettes pour l’identification des langages), mars 1995.

[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3" (Spécification du format de données compressées DEFLATE version 1.3), mai 1996.

[RFC1952] Deutsch, P., "GZIP file format specification version 4.3" (Spécification du format de fichier GZIP version 4.3), mai 1996.

[RFC1977] Schryver, V., "PPP BSD Compression Protocol" (Protocole de compression,BSD PPP) août 1996.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3" (Processus de normalisation de l’Internet –révision 3), BCP 9, RFC 2026, octobre 1996.

[RFC2045] Freed, N. et N. Borenstein, ", Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" (Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet), RFC 2045, novembre 1996.

[RFC2046] Freed, N. et N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types" (Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support), RFC 2046, novembre 1996.

[RFC2048] Freed, N., Klensin, J. et J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures" (Extensions de messagerire Internet multi-objets (MIME) Partie 4 : Procédures d’enregistrement), RFC 2048, novembre 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" (Mots-clé àutiliser dans les RFC pour indiquer les niveaux d’exigence), BCP 14, RFC 2119, mars 1997.

[RFC2228] Horowitz, M. et S. Lunt, "FTP Security Extensions" (Extensions pour la sécurité sur FTP), octobre 1997.

[RFC2246] Dierks, T. et C. Allen, "The TLS Protocol Version 1.0" (Protocole TLS, version 1.0), janvier 1999.

[RFC2277] Alvestrand, H., "IETF Policy on Character Sets et Languages" (Politique de l’IETF d’ensembles de caractères et de langages), BCP 18, RFC 2277, janvier 1998.

[RFC2278] Freed, N. et J. Postel: "IANA CharSet Registration Procedures" (Procédures d’enregistrement des charsets de l’IANA), BCP 19, RFC 2278, janvier 1998.

[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646" (UTF-8, un format de transformation de la norme ISO 10646), RFC 2279, janvier 1998.

[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop" (Rapport de l’atelier d’architecture sur la sécurité de l’IAB), RFC 2316, avril 1998.

[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.

[RFC2565] Herriot, R., Butler, S., Moore, P. et R. Turner, "Protocole d’impression sur Internet/1.0: Codage et Transport", RFC 2565, avril 1999.

[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. et P. Powell, "Protocole d’impression sur Internet/1.0 : Modèle et sémantique", RFC 2566, avril 1999.

[RFC2567] Wright, D., "Objectifs conceptuels pour un protocole d’impression sur Internet", RFC 2567, avril 1999.

[RFC2568] Zilles, S., "Raisons de la structure, du modèle et du protocole du Protocole d’impression sur Internet", RFC 2568, avril 1999.

[RFC2569] Herriot, R., Hastings, T., Jacobs, N. et J. Martin, "Transposition entre les protocoles LPD et IPP", RFC 2569, avril 1999.

[RFC2579] McCloghrie, K., Perkins, D. et J. Schoenwaelder, "Textual Conventions for SMIv2" (Conventions textuelles pour SMVI, version 2), STD 58, RFC 2579, 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" (Protocole de transfert Hypertextexte), RFC 2616, juin 1999.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. et L. Stewart, "HTTP Authentication: Basic et Digest Access Authentication" (Authentification HTTP : Authentification d’accès de base et abrégée), RFC 2617, juin 1999.

[RFC2639] Hastings, T. et C. Manros, "Protocole d’impression sur Internet/1.0 : Codage et Transport", juillet 1999.

[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. et J. Wenn, "Protocole d’impression sur Internet/1.1 : Codage et Transport", RFC 2910, septembre 2000.

[SSL] Netscape, The SSL Protocol, Version 3 (Netscape, le protocole SSL, version 3), (version 3.02 du texte), novembre 1996.

[SWP] P. Moore, B. Jahromi, S. Butler, "Simple Web Printing SWP/1.0" (Impression simple sur la Toile, SWP/1.0), 7 ma 1997, ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf

10. Adresse des auteurs

Ceux qui mettent en œuvre le présent document de spécification sont encouragés à rejoindre la liste de diffusion IPP afin de participer à toutes discussions d’éclaircissement et de révision des propositions d’enregistrement des attributs et valeurs supplémentaires.

11. Formats des propositions d’enregistrement IPP

Pour l’enregistrement d’une proposition d’extension IPP, le proposant doit soumettre une application à l’IANA par courriel à "iana@iana.org" ou en remplissant le formulaire approprié des pages du site de l’IANA sur la Toile (http://www.iana.org). La présente section spécifie les informations demandées et les formats des propositions d’enregistrement pour les extensions à IPP comme indiqué à la section 6 pour les :

11.1 Enregistrement des valeurs d’attribut de mot-clé de type2

Spécification de cette valeur de mot-clé (suivant le style du paragraphe 4.1.2.3 du Modèle IPP) :

Note : Pour les mots-clé de type2, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.2 Enregistrement des valeurs d’attribut de mot-clé de type3

Spécification de cette valeur de mot-clé (suivant le style du paragraphe 4.1.2.3 du Modèle IPP) :

Note : Pour les mots-clé de type3, le proposant sera le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.3 Enregistrement des valeurs d’attribut d’énumération de type2

Valeur numérique (sera allouée par l’expert désigné IPP en consultation avec IANA) :

Spécification de cette valeur enum (suivant le style du paragraphe 4.1.4 du Modèle IPP) :

Note : Pour enum de type2, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.4 Enregistrement des valeurs d’attribut d’énumération de type3

Valeur numérique (sera allouée par l’expert désigné pour IPP en consultation avec IANA) :

Spécification de cette valeur enum (suivant le style du paragraphe 4.1.4 du Modèle IPP) :

Note : Pour enum de type3, le proposant sera le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.5 Enregistrement d’attribut

Types d’attribut (opération, gabarit de tâche, description de tâche, description d’imprimante) :

Syntaxe ou syntaxes d’attribut (inclut 1setOf et gamme comme au paragraphe 4.2) :

Si la syntaxe d’attribut est 'mot-clé' ou 'enum', est elle de type2 ou de type3 :

Si c’est un attribut d’imprimante, la valeur retourné PEUT elle dépendre du "format-de-document" (voir le paragraphe 6.2) :

Si c’est un attribut de gabarit de tâche, comment sa spécification dépend-elle de la valeur de l’attribut "traitement-de-document-multiple" :

Spécification de cet attribut (suivant le style du paragraphe 4.2 du Modèle IPP):

Note : Pour les attributs, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.6 Enregistrement de syntaxe d’attribut

Type de syntaxe d’attribut (entier, chaîneD’octet, chaîne-de-caractères, voir la [RFC2910]) :

Etiquette numérique conformément à la [RFC2910] (sera allouée par l’expert désigné IPP en consultation avec l’IANA) :

Spécification de cet attribut (suivant le style du paragraphe 4.1 du Modèle IPP):

Note : Pour les syntaxes d’attribut, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.7 Enregistrement d’opération

Valeur numérique d’id-d’opération conformément au paragraphe 4.4.15 (pour être allouée par l’expert désigné pour IPP en consultation avec l’IANA) :

Spécification de cette opération (suivant le style de la Section 3 du Modèle IPP) :

Note : Pour les opérations, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.8 Enregistrement de groupe d’attributs

Etiquette numérique conformément à la [RFC2910] (pour être allouée par l’expert désigné pour IPP en consultation avec l’IANA) :

Demandes d’opération et nombre de groupes pour chaque opération dans laquelle survient un groupe d’attributs :

Réponses d’opération et nombre de groupes pour chaque opération dans laquelle survient le groupe d’attributs :

Spécification de ce groupe d’attributs (suivant le style de la Section 3 du Modèle IPP) :

Note : Pour les groupes d’attributs, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.9 Enregistrement de code d’état

Valeur numérique (pour être allouée par l’expert désigné pour IPP en consultation avec l’IANA) :

Spécification de ce code d’état (suivant le style de la section 13 du Modèle IPP 13 APPENDICE B : Codes d’état et Messages suggérés de code d’état) :

Note : Pour les codes d’état, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

11.10 Enregistrement de valeur d’attribut hors-bande

Etiquette numérique conformément à la [RFC2910] (pour être allouée par l’expert désigné pour IPP en consultation avec l’IANA) :

Opérations avec lesquelles cette valeur d’attribut hors-bande peut être utilisée :

Attributs avec lesquels cette valeur d’attribut hors-bande peut être utilisée :

Spécification de cette valeur d’attribut hors-bande (suivant le style du début du paragraphe 4.1 du Modèle IPP) :

Note : Pour les valeurs d’attribut hors-bande, l’expert désigné va être le point de contact pour la spécification dont l’enregistrement est approuvé, pour le cas où de la maintenance serait nécessaire.

12. APPENDICE A : Terminologie

Le présent document de spécification utilise la terminologie définie dans cette section.

12.1 Terminologie de conformité

Dans le présent document, les mots-clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans la RFC 2119 [RFC2119].

Ce terme n’est pas inclus dans la RFC 2119. Le verbe "PEUT NE PAS" indique une action que le sujet de la phrase n’est pas obligé de mettre en œuvre afin de revendiquer la conformité à la norme. Le verbe "PEUT NE PAS" est utilisé à la place de "NE PEUT PAS" car "NE PEUT PAS" ressemble à une interdiction.

12.2 Terminologie de modélisation

Les mots-clé sont utilisés au sein du présent document comme identifiants des entités sémantiques au sein du modèle abstrait (voir au paragraphe 4.1.2.3). Les noms des attributs, certaines valeurs d’attribut, les syntaxes d’attribut, et les noms de groupe d’attributs sont représentés comme des mots-clé.

Un attribut est un élément d’information qui est associé à une instance d’un objet IPP. Un attribut consiste en un nom d’attribut et une ou plusieurs valeurs d’attribut. Chaque attribut a une syntaxe d’attribut spécifique. Tous les attributs d’objet sont définis à la section 4 et tous les attributs d’opération sont définis à la section 3.

Les attributs de gabarit de tâche sont décrits au paragraphe 4.2. Le client fournit facultativement des attributs de gabarit d’imprimante dans une demande de création (demandes d’opération qui créent des objets Tâche). L’objet Imprimante a des attributs associés qui définissent des valeurs prises en charge et des valeurs par défaut pour l’imprimante.

Chaque attribut est identifié de façon univoque dans le présent document par un nom d’attribut. Un nom d’attribut est un mot-clé. Le mot-clé de nom d’attribut est donné dans l’en-tête du paragraphe qui décrit cet attribut. Dans le cours du texte du présent document, les noms d’attribut sont indiqués entre deux guillemets doubles (") mais les guillemets ne font pas partie du mot-clé lui-même.

Les attributs qui sont en rapport sont groupés dans des groupes nommés. Le nom du groupe est un mot-clé. Le nom du groupe peut être utilisé au lieu de nommer explicitement tous les attributs du groupe. Les groupes d’attributs sont définis à la section 3.

Chaque attribut a une ou plusieurs valeurs. Les valeurs d’attribut sont représentées dans le type de syntaxe spécifié pour cet attribut. Dans le cours du texte du présent document, les valeurs des attributs sont indiquées entre des guillemets simples ('), que leur syntaxe d’attribut soit mot-clé, entier, texte, etc., et les guillemets ne font pas partie de la valeur elle-même.

Chaque attribut est défini en utilisant un type de syntaxe explicite. Dans le présent document, chaque type de syntaxe est défini comme un mot-clé avec une signification spécifique. Le document "Codage et Transport" [RFC2910] indique les règles de codage réelles "sur le réseau" pour chaque type de syntaxe. Les types de syntaxe d’attribut sont définis au paragraphe 4.1.

Par définition, un objet Imprimante ne prend en charge un attribut que si cet objet Imprimante répond à l’attribut correspondant rempli avec une ou des valeurs dans une réponse à une question pour cet attribut. Un objet Imprimante prend en charge une valeur d’attribut si la valeur est un des attributs"valeurs-prises-en-charge" de l’objet imprimante. L’appareil derrière un objet Imprimante peut afficher un comportement qui correspond à un attribut IPP, mais si l’objet imprimante, lorsqu’il est interrogé pour cet attribut, ne répond pas avec cet attribut, alors, pour ce qui concerne IPP, cette mise en œuvre ne prend pas en charge cette caractéristique. Si l’attribut "xxx-pris-en-charge" de l’objet imprimante n’est pas rempli avec une valeur particulière (même si cette valeur est une valeur légitime pour cet attribut), alors cet objet Imprimante ne prend pas en charge cette valeur particulière.

Une mise en œuvre conforme DOIT prendre en charge tout attribut EXIGÉ. Cependant, même pour les attributs EXIGÉS, la conformité à IPP n’oblige pas toutes les mises en œuvre à prendre en charge toutes les valeurs possibles représentant tout comportement et toute caractéristique de traitement de tâche possible. Par exemple, si une instance donnée d’imprimante ne prend en charge que certains formats de document, cette imprimante répond alors avec l’attribut "format-de-document-pris-en-charge" rempli avec un ensemble de valeurs, qui peut être d’une seule, tiré de l’ensemble total des valeurs possibles définies pour cet attribut. Cet ensemble limité de valeurs représente l’ensemble des formats de documents pris en charge par l’imprimante. La prise en charge d’un attribut et d’un certain ensemble de valeurs pour cet attribut permet aux utilisateurs finaux d’IPP d’être au courant et de faire usage des caractéristiques associées à cet attribut et ces valeurs. Si une mise en œuvre choisit de ne pas prendre en charge un attribut ou certaine valeur spécifique, les utilisateurs finaux IPP n’auront alors aucune possibilité de faire usage de cette caractéristique dans le contexte d’IPP lui-même. Cependant, du fait des pratiques existantes et des systèmes installés qui ne sont pas au courant d’IPP, il peut y avoir d’autres mécanismes en dehors du domaine d’application d’IPP pour contrôler ou demander la caractéristique "non prise en charge" (tels que des instructions incorporées aux données documentaires elles-mêmes).

1) Si un objet Imprimante n’est pas physiquement capable d’agrafer, l’attribut "finitions-prises-en-charge" NE DOIT PAS être rempli avec la valeur de 'agrafage'.

2) Un objet Imprimante est physiquement capable d’agrafer, cependant une mise en œuvre choisit de ne pas prendre en charge l’agrafage dans l’attribut IPP "finitions". Dans ce cas, 'agrafage' NE DOIT PAS être une valeur dans l’attribut "finitions-prises-en-charge" de l’objet Imprimante. Sans prise en charge pour la valeur 'agrafage', un utilisateur final IPP n’aurait aucun moyen au sein du protocole lui-même de demander qu’une tâche soit agrafée. Cependant, un formateur de données documentaires existant peut être capable de demander que le document soit agrafé directement avec une instruction incorporée au sein des données documentaires. Dans ce cas, la mise en œuvre IPP ne "prend pas en charge" l’agrafage, cependant l’utilisateur final est toujours capable d’un certain contrôle sur l’agrafage de la tâche terminée.

3) Un objet Imprimante est physiquement capable d’agrafage, et une mise en œuvre choisit de prendre en charge l’agrafage dans l’attribut IPP "finitions". Dans ce cas, 'agrafage' DOIT être une valeur dans l’attribut d’objet Imprimante "finitions-prises-en-charge". Faire cela permettrait aux utilisateurs finaux d’être au courant et de faire usage de la caractéristique d’agrafage en utilisant les attributs IPP.

Bien que la prise en charge des attributs de gabarit d’imprimante par un objet Imprimante soit FACULTATIVE, il est RECOMMENDÉ que si l’appareil derrière un objet Imprimante est capable de réaliser une caractéristique ou fonction qui correspond à un attribut IPP et à une valeur associée, cette mise en œuvre DEVRAIT alors prendre en charge cet attribut et valeur IPP.

L’ensemble des valeurs dans tous les attributs de valeurs prises en charge est réglé (rempli) par un processus administratif ou un mécanisme de détection automatique qui sort du domaine d’application du présent document IPP/1.1. Pour des raisons de politique administrative et de contrôle, un administrateur peut choisir de rendre visible seulement un sous-ensemble de toutes les valeurs possibles à l’utilisateur final. Dans ce cas, l’appareil de sortie réel derrière l’imprimante IPP abstraite peut être capable de certaines caractéristiques, cependant un administrateur spécifie que l’accès à cette caractéristique n’est pas exposé à l’utilisateur final dans le protocole IPP. Aussi, comme un objet Imprimante peut représenter un appareil d’impression logique (et pas simplement un appareil physique) le processus réel de prise en charge d’une valeur est indéfini et laissé à l’appréciation de la mise en œuvre. Cependant, si un objet Imprimante prend en charge une valeur, certaines actions manuelles humaines peuvent être nécessaires pour réaliser l’action sémantique associée à la valeur, mais aucune action de l’utilisateur final n’est requise.

Par exemple, si une des valeurs de l’attribut "finitions-prises-en-charge" est 'agrafage', le processus réel pourrait être une action d’agrafage automatique par un appareil physique contrôlé par une commande envoyée à l’appareil. Or, le processus réel d’agrafage pourrait être une action manuelle par un opérateur sur un objet Imprimante avec présence d’un opérateur.

Pour un autre exemple de la façon dont fonctionnent les attributs pris en charge, considérons un administrateur de système qui désire contrôler toutes les tâches d’impression de sorte qu’aucune feuille de tâche ne soit imprimée afin d’économiser le papier. Pour forcer la non-édition des feuilles de tâche, l’administrateur du système règle la seule valeur prise en charge pour l’attribut "feuilles-de-tâche-prises-en-charge" sur 'aucun'. Dans ce cas, si un client demande tout sauf 'aucun', la demande de création est rejetée ou la valeur "feuilles-de-tâche" est ignorée (selon la valeur de "fidélité-d’attribut-ipp"). Pour forcer l’utilisation de feuilles de début/fin de tâche sur toutes les tâches, l’administrateur n’inclut pas la valeur 'aucun' dans l’attribut "feuilles-de-tâche-prises-en-charge". Dans ce cas, si un client demande 'aucun', la demande de création est rejetée ou la valeur "feuilles-de-tâche" est ignorée (toujours selon la valeur de "fidélité-d’attribut-ipp").

Une "page-de-flux-d’impression" est une page conforme à la définition des pages dans le langage utilisé pour exprimer les données documentaires.

Une "impression" est l’image (qui peut être de nombreuses pages du flux d’impression dans différentes configurations) imposée sur une seule page de support.

13. APPENDICE B : Codes d’état et messages de code d’état suggérés

Cette section définit les valeurs et mots-clé d’énumération (enum) de code d’état qui sont utilisés pour fournir les informations de sémantique sur les résultats d’une demande d’opération. Chaque réponse d’opération DOIT inclure un code d’état. La réponse PEUT aussi contenir un message d’état qui donne une brève description textuelle de l’état. Le code d’état est destiné à être utilisé par un automate, et le message d’état est destiné à l’utilisateur final humain. Comme le message d’état est un composant FACULTATIF de la réponse d’opération, il n’est PAS EXIGE qu’une application IPP (c’est-à-dire, un navigateur, GUI, pilote d’imprimante, ou passerelle) examine ou affiche le message d’état, car il PEUT n’être pas retourné à l’application.

"redirection" - Une action ultérieure doit être entreprise afin de terminer la demande

"erreur-client" – La demande contient une mauvaise syntaxe ou ne peut pas être satisfaite

"erreur-serveur" - L’objet IPP a échoué à satisfaire une demande apparemment valide

Comme avec les énumérations de type2, les codes d’état IPP sont extensibles. Il n’est pas EXIGÉ que les clients IPP comprennent la signification de tous les codes d’état enregistrés, bien qu’une telle compréhension soit éminemment souhaitable. Cependant, les clients IPP DOIVENT comprendre la classe de tout code d’état, comme indiqué par le préfixe, et traiter toute réponse non reconnue comme équivalente au premier code d’état de cette classe, avec l’exception qu’une réponse non reconnue NE DOIT PAS être mise en cache. Par exemple, si un code d’état non reconnu "erreur-client-xxx-yyy" est reçu par le client, il peut supposer en toute sûreté qu’il y a quelque chose qui ne va pas dans sa demande et traiter la réponse comme si il avait reçu un code d’état "erreur-client-mauvaise-demande". Dans de tels cas, les applications IPP DEVRAIENT présenter le message FACULTATIF (s’il est présent) à l’utilisateur final car le message contient vraisemblablement des informations lisibles par l’homme qui vont aider à expliquer cet état inhabituel. Le nom de l’énumération est le message d’état suggéré en français.

La gamme des valeurs de code d’état va de 0x0000 à 0x7FFF. Les gammes de valeur pour chaque classe de code d’état sont les suivantes :

La moitié supérieure (128 valeurs) de chaque gamme (0x0n40 à 0x0nFF, pour n = 0 à 5) est réservée à l’utilisation par les fabricants au sein de chaque classe de code d’état. Les valeurs 0x0600 à 0x7FFF sont réservée à de futures allocations par les documents normatifs de l’IETF et NE DOIVENT PAS être utilisées.

13.1 Codes d’état

Chaque code d’état est décrit ci-dessous. Le paragraphe 13.1.5.9 contient un tableau qui indique quels codes d’état s’appliquent à quelles opérations. Le Guide de mise en œuvre [IPP-IIG] décrit les étapes suggérées pour le traitement des attributs IPP pour toutes les opérations, y compris les codes d’état en retour.

Cette classe de code d’état indique une réponse provisoire et n’est à utiliser que dans un but informatif.

Il n’y a pas de code d’état défini dans IPP/1.1 pour cette classe de code d’état.

Cette classe de code d’état indique que la demande du client a bien été reçue, comprise et acceptée.

La demande a réussi et aucun attribut de la demande n’a été changé ou ignoré. Dans le cas d’une réponse à une demande de création, le code d’état 'réussite-ok' indique que la demande a été bien reçue et validée, et que l’objet Tâche a été créé ; il n’indique pas que la tâche a été traitée. La transition de l’objet Tâche dans l’état 'terminé' est le seul indicateur de l’impression de la tâche.

La demande a réussi, mais certains attributs fournis ont été ignorés ou des valeurs non acceptées ont été remplacées par des valeurs prises en charge, ou ont été ignorées afin d’effectuer l’opération sans la rejeter. Les attributs, syntaxes d’attribut, ou valeurs non pris en charge DOIVENT être retournés dans le groupe des attributs non acceptés de la réponse, pour toute opération. Il y a une exception à cette règle pour les opérations d’interrogation : Obtenir-les-attributs-d’imprimante, Obtenir-les-tâches, et Obtenir-les-attributs-de-tâche uniquement pour les attributs d’opération "attributs-demandés". Lorsque les valeurs fournies de l’attribut d’opération "attributs-demandés" demandent des attributs qui ne sont pas pris en charge, l’objet IPP PEUT, mais n’y est pas obligé, retourner l’attribut "attributs-demandés" dans le groupe de réponse des attributs non pris en charge (avec seulement des valeurs non acceptées). Voir aux paragraphes 3.1.7 et 3.2.1.2.

La demande a réussie, mais certaines valeurs d’attribut fournies sont en conflit avec les valeurs des autres attributs fournis. Ces valeurs conflictuelles sont (1) substituées par d’autres valeurs (prises en charge) ou (2) les attributs ont été retirés afin de traiter la tâche sans la rejeter. Les attributs ou valeurs qui sont en conflit avec d’autres attributs et ont été substitués ou ignorés DOIVENT être retournés dans le groupe des attributs non acceptés de la réponse pour toute opération, comme ils ont été fournis par le client. Voir aux paragraphes 3.1.7 et 3.2.1.2.

Cette classe de code d’état indique qu’une action ultérieure doit être entreprise pour satisfaire la demande.

Il n’y a pas de codes d’état définis dans IPP/1.1 pour cette classe de code d’état.

Cette classe de code d’état est destinée aux cas dans lesquels le client semble avoir commis une erreur. L’objet IPP DEVRAIT retourner un message contenant une explication de la situation d’erreur et si elle est temporaire ou permanente.

La demande pourrait n’être pas comprise par l’objet IPP du fait d’une syntaxe mal formée (telle que la valeur d’un attribut de longueur fixée dont la longueur ne correspond pas à celle prescrite pour cet attribut – voir le Guide de mise en œuvre [IPP-IIG]). L’application IPP NE DEVRAIT PAS répéter la demande sans modification.

L’objet IPP comprend la demande, mais il refuse de la satisfaire. Des informations d’authentification ou des accréditifs d’autorisation supplémentaires ne seront d’aucune aide et la demande NE DEVRAIT PAS être répétée. Ce code d’état est couramment utilisé lorsque l’objet IPP ne souhaite pas révéler exactement pourquoi la demande a été refusée ou lorsque aucune autre réponse n’est applicable.

La demande exige une authentification de l’utilisateur. Le client IPP peut répéter la demande avec les informations d’authentification convenables. Si la demande a déjà inclus les informations d’authentification, ce code d’état indique alors que l’autorisation a été refusée à cause de ces accréditifs. Si cette réponse contient le même problème que la réponse précédente, et que l’agent utilisateur a déjà essayé l’authentification au moins une fois, le message de réponse peut alors contenir les informations de diagnostic pertinentes. Ce code d’état donne plus d’informations que "erreur-client-interdit".

Le demandeur n’est pas autorisé à effectuer la demande. Des informations d’authentification ou des accréditifs d’autorisation supplémentaires ne seront d’aucune aide et la demande NE DEVRAIT PAS être répétée. Ce code d’état est utilisé lorsque l’objet IPP souhaite faire savoir que les informations d’authentification sont compréhensibles, cependant, le demandeur est explicitement non autorisé à effectuer la demande. Ce code d’état donne plus d’informations que "erreur-client-interdit" et "erreur-client-non-authentifié".

Ce code d’état est utilisé lorsque la demande est pour quelque chose qui ne peut pas arriver. Par exemple, cela pourrait être une demande d’annuler une tâche qui a déjà été annulée ou avortée par le système. Le client IPP NE DEVRAIT PAS répéter la demande.

Le client n’a pas produit sa demande dans le délai pendant lequel l’objet IPP été prêt à attendre. Par exemple, un client a lancé une opération Création-de-tâche et puis, après un long délai, il lance une opération Document-d’envoi et ce code d’état d'erreur lui est retourné en réponse à la demande Document-d’envoi (voir au paragraphe 3.3.1). L’objet IPP peut avoir été forcé de libérer ses ressources qui ont été mises en garde pendant l’attente des documents additionnels. L’objet IPP a été forcé de clore la tâche car le client a mis trop longtemps. Le client NE DEVRAIT PAS répéter la demande sans modification.

L’objet IPP n’a rien trouvé qui corresponde à l’URI demandé. Aucune indication n’est donnée pour savoir si la condition est temporaire ou permanente. Par exemple, un client avec une vieille référence à une tâche (un URI) essaye d’annuler la tâche, cependant dans l’intervalle la tâche peut avoir été terminée et tout enregistrement s’y rapportant à l’imprimante a été effacé. Ce code d’état, 'erreur-client-introuvable' est retourné pour indiquer que la tâche référencée n’a pu être trouvée. Ce code d’état d’erreur est aussi utilisé lorsque un client fournit un URI comme référence aux données documentaires dans une opération URI-d’impression ou URI-d’envoi, mais que le document ne peut être trouvé.

En pratique, une application IPP devrait éviter les situations de non découverte en interrogeant d’abord une liste des URI d’imprimante et des URI de tâche valides et en la présentant à l’utilisateur final.

L’objet demandé n’est plus disponible et on ne connaît pas la nouvelle adresse. Cette condition devrait être considérée comme permanente. Les clients ayant des capacités d’édition de lien devraient supprimer les références à la demande d’URI après l’approbation de l’utilisateur. Si l’objet IPP ne sait pas, ou n’a pas de facilité pour déterminer si la condition est permanente ou non, le code d’état "erreur-client-introuvable" devrait être utilisé à la place.

Cette réponse est principalement destinée à faciliter les travaux de maintenance en notifiant au récepteur que les ressources sont volontairement indisponibles et que l’administrateur de l’objet IPP désire que les liaisons distantes à cette ressource soient supprimées. Il n’est pas nécessaire de marquer toutes les ressources indisponibles de façon permanente comme "parti" ou de garder la marque pendant une certaine durée – cela est laissé à la discrétion de l’administrateur de l’objet IPP et/ou de la mise en œuvre d’imprimante.

L’objet IPP refuse de traiter une demande parce que l’entité de demande est plus grande que ce que l’objet IPP veut ou est capable de traiter. Une imprimante IPP retourne ce code d’état lorsqu’elle limite la taille des tâches d’impression et qu’elle reçoit une tâche d’impression qui excède cette limite ou lorsque les attributs sont si nombreux que leur codage amène l’entité de demande à dépasser la capacité de l’objet IPP.

L’objet IPP refuse de servir la demande parce que un ou plusieurs des attributs fournis par le client ont une valeur de longueur de variable qui est plus longue que la longueur maximum spécifiée pour cet attribut. L’objet IPP peut n’avoir pas de ressources suffisantes (mémoire, mémoire tampon, etc.) pour traiter (même temporairement), interpréter et/ou ignorer une valeur plus grande que la longueur maximum. Une autre utilisation de ce code d’erreur est lorsque l’objet IPP prend en charge le traitement d’une grande valeur qui est inférieure à la longueur maximum, mais durant le traitement de la demande globale, l’objet peut dépasser la valeur pour certains autres composants du système qui ne sont pas capables d’accepter cette grande valeur. Pour plus de détails, voir le Guide de mise en œuvre [IPP-IIG].

Note : Pour les valeurs d’attribut qui sont des URI, cette condition rare n’a une chance de survenir que lorsque un client a improprement soumis une demande avec de longues informations d’interrogation (par exemple, une application IPP permet à un utilisateur final d’entrer dans un URI invalide), lorsque le client est tombé dans un URI "trou noir" de redirection (par exemple, un préfixe d’URI redirigé qui pointe sur un suffixe de lui-même), ou lorsque l’objet IPP est attaqué par un client qui tente d’exploiter les lacunes de la sécurité que présentent certains objets IPP qui utilisent des mémoires tampon de longueur fixe pour lire ou manipuler les Demande-d’URI.

L’objet IPP refuse de servir la demande parce que les données documentaires sont dans un format, spécifié dans l’attribut d’opération "format-de-document", qui n’est pas pris en charge par l’objet imprimante. Cette erreur est retournée indépendamment du "fidélité-d’attribut-ipp" fourni par le client. L’objet Imprimante DOIT retourner ce code d’état, même s’il y a d’autres attributs de gabarit d’imprimante qui ne sont pas non plus pris en charge, car cette erreur est un plus gros problème qu’avec les attributs de gabarit d’imprimante. Voir aux paragraphes 3.1.6.1, 3.1.7, et 3.2.1.1.

Dans une demande de création, si l’objet imprimante ne prend pas en charge un ou plusieurs attributs, syntaxes d’attribut, ou valeurs d’attribut fournis dans la demande et l’attribut d’opération "fidélité-d’attribut-ipp" fourni par le client avec la valeur 'vrai', l’objet imprimante DOIT retourner ce code d’état. L’objet Imprimante DOIT aussi retourner dans le groupe des attributs non acceptés tous les attributs et/ou valeurs fournis par le client qui ne sont pas pris en charge. Voir au paragraphe 3.1.7.

Par exemple, si la demande indique un support 'iso-a4', mais que ce type de support n’est pas pris en charge par l’objet imprimante. Ou si le client fournit un attribut de gabarit de tâche et que l’attribut lui-même n’est pas pris en charge par l’imprimante. Si l’attribut "fidélité-d’attribut-ipp" est 'faux', l’imprimante DOIT ignorer ou substituer les valeurs pour les attributs et valeurs de gabarit d’imprimante non pris en charge plutôt que rejeter la demande, et retourner ce code d’état.

Pour toute opération où un client demande des attributs (comme les opérations Obtenir-les-tâches, Obtenir-les-attributs-d’imprimante, ou Obtenir-les-attributs-de-tâche), si l’objet IPP ne prend pas en charge un ou plusieurs des attributs demandés, l’objet IPP ignore simplement les attributs demandés non pris en charge et traite la demande comme s’ils n’avaient pas été fournis, plutôt que de retourner ce code d’état. Dans ce cas, l’objet IPP DOIT retourner le code d’état 'réussite-ok-mais-attributs-substitués-ou-ignorés' et PEUT retourner les attributs non pris en charge comme valeurs des "attributs-demandés" dans le groupe des attributs non acceptés (voir au paragraphe 13.1.2.2).

Le schéma de l’URI fourni par le client dans une opération URI-d’impression ou URI-d’envoi n’est pas pris en charge. Voir aux paragraphes 3.1.6.1 et 3.1.7.

Pour toute opération, si l’imprimante IPP ne prend pas en charge le charset fourni par le client dans l’attribut d’opération "charset-des-attributs", l’imprimante DOIT rejeter l’opération et retourner cet état et tout attribut 'texte' ou 'nom' en utilisant le charset 'utf-8' (voir au paragraphe 3.1.4.1). Voir aux paragraphes 3.1.6.1 et 3.1.7.

La demande est rejetée parce que certaines valeurs d’attribut sont en conflit avec les valeurs d’autres attributs que le présent document n’autorise pas à substituer ou ignorer. L’objet Imprimante DOIT aussi retourner dans le groupe des attributs non acceptés les attributs en conflit fournis par le client. Voir aux paragraphes 3.1.7 et 3.2.1.2.

L’objet IPP refuse de servir la demande parce que les données documentaires, comme spécifié dans l’attribut d’opération "compression", sont compressées d’une façon qui n’est pas prise en charge par l’objet imprimante. Cette erreur est retournée indépendamment de "fidélité-d’attribut-ipp" fourni par le client. L’objet Imprimante DOIT retourner ce code d’état, même si d’autres attributs de gabarit d’imprimante ne sont pas non plus pris en charge, car cette erreur est un plus gros problème que ceux des attributs de gabarit d’imprimante. Voir aux paragraphes 3.1.6.1, 3.1.7, et 3.2.1.1.

L’objet IPP refuse de servir la demande parce que les données documentaires ne peuvent être décompressées lorsqu’on utilise l’algorithme spécifié par l’attribut d’opération "compression". Cette erreur est retournée indépendamment de "fidélité-d’attribut-ipp" fourni par le client. L’objet Imprimante DOIT retourner ce code d’état, même si d’autres attributs de gabarit d’imprimante ne sont pas non plus pris en charge, car cette erreur est un plus gros problème que ceux des attributs de gabarit d’imprimante. Voir aux paragraphes 3.1.7 et 3.2.1.1.

L’objet IPP refuse de servir la demande parce que l’imprimante a rencontré une erreur dans les données documentaires alors qu’elle les interprétait. Cette erreur est retournée indépendamment de "fidélité-d’attribut-ipp" fourni par le client. L’objet Imprimante DOIT retourner ce code d’état, même si d’autres attributs de gabarit d’imprimante ne sont pas non plus pris en charge, car cette erreur est un plus gros problème que celui des attributs de gabarit d’imprimante. Voir aux paragraphes 3.1.7 et 3.2.1.1.

L’objet IPP refuse de servir la demande d’URI-d’impression ou URI-d’envoi parce que l’imprimante a rencontré une erreur d’accès en tentant de valider l’accessibilité ou l’accès aux données documentaires spécifié dans l’attribut d’opération "uri-de-document". L’imprimante PEUT aussi retourner un code d’erreur d’accès spécifique du document en utilisant l’attribut d’opération "erreur-d’accès-au-document" (voir au paragraphe 3.1.6.4). Cette erreur est retournée indépendamment de "fidélité-d’attribut-ipp" fourni par le client. L’objet Imprimante DOIT retourner ce code d’état, même si il y a des attributs de gabarit d’imprimante qui ne sont pas non plus pris en charge, car cette erreur est un plus gros problème que celui des attributs de gabarit d’imprimante. Voir aux paragraphes 3.1.6.1 et 3.1.7.

Cette classe de codes d’état indique les cas dans lesquels l’objet IPP est informé de son erreur ou est incapable d’effectuer la demande. L’objet IPP DEVRAIT inclure un message contenant une explication de la situation d’erreur, et de sa condition temporaire ou permanente.

L’objet IPP a rencontré une condition inattendue qui l’empêche de satisfaire la demande. Ce code d’état d’erreur diffère de "erreur-serveur-erreur-temporaire" en ce qu’il implique un type d’erreur interne plus permanent. Il diffère aussi de "erreur-serveur-erreur-d’appareil" en ce qu’il implique une condition inattendue (à la différence d’un bourrage papier ou d’un problème de manque de toner, ce qui est indésirable mais attendu). Ce code d’état d’erreur indique qu’une intervention humaine qualifiée est probablement nécessaire.

L’objet IPP ne prend pas en charge la fonctionnalité requise pour satisfaire la demande. C’est la réponse appropriée lorsque l’objet IPP ne reconnaît pas une opération ou n’est pas capable de la prendre en charge. Voir aux paragraphes 3.1.6.1 et 3.1.7.

L’objet IPP est actuellement incapable de traiter la demande du fait d’un encombrement temporaire ou à cause de la maintenance de l’objet IPP. Cela implique une condition temporaire qui disparaîtra après un certain délai. Si ce délai est connu, sa durée peut être indiquée dans le message. Si aucun délai n’est donné, l’application IPP devrait traiter la réponse comme le serait une réponse "erreur-serveur-erreur-temporaire". Si la condition est plus permanente, les codes d’état d’erreur "erreur-client-parti" ou "erreur-client-introuvable" pourraient être utilisés.

L’objet IPP ne prend pas en charge, ou refuse de prendre en charge, la version de protocole IPP qui a été fournie comme valeur du paramètre d’opération "numéro-de-version" dans la demande. L’objet IPP indique qu’il est incapable ou non désireux de mener à son terme la demande en utilisant le même numéro de version majeure et mineure que fourni dans la demande autre que celle avec ce message d’erreur. La réponse d’erreur DEVRAIT contenir un attribut "message-d’état" (voir au paragraphe 3.1.6.2) décrivant pourquoi cette version n’est pas prise en charge et quelles autres versions sont prises en charge par cet objet IPP. Voir aux paragraphes 3.1.6.1, 3.1.7, et 3.1.8.

La réponse d’erreur DOIT identifier dans le paramètre d’opération "numéro-de-version" le numéro de version le plus proche que l’objet IPP prenne en charge. Par exemple, si un client fournit la version '1.0' et qu’un objet IPP/1.1 prend en charge la version '1.0', il répond alors par la version '1.0' dans toutes les réponses à une telle demande. Si l’objet IPP/1.1 ne prend pas en charge la version '1.0', il devrait alors accepter la demande et répondre par version '1.1', ou il peut aussi rejeter la demande et répondre avec ce code d’erreur et version '1.1'. Si un client fournit une version '1.2', l’objet IPP/1.1 devrait accepter la demande et retourner version '1.1' ou alors rejeter la demande et répondre avec ce code d’erreur et version '1.1'. Voir aux paragraphes 3.1.8 et 4.4.14.

Une erreur d’imprimante, telle qu’un bourrage papier, survient alors que l’objet IPP effectue une opération d’impression ou d’envoi. La réponse contient le vrai état de tâche (les valeurs des attributs "état-de-tâche" et "causes-d’état-de-tâche"). Des informations supplémentaires peuvent être retournées dans la valeur d’attribut FACULTATIF "message-d’état-de-tâche" ou dans le message d’état FACULTATIF qui décrit l’erreur plus en détail. Ce code d’état d’erreur n’est retourné que dans des situations où l’imprimante est incapable d’accepter la demande de création à cause d’une telle erreur d’appareil. Par exemple, si l’imprimante est incapable de dérouler les tâches, et peut seulement accepter une tâche à la fois, la raison pour laquelle elle rejette une demande de création est qu’il y a un bourrage papier sur l’imprimante. Dans de nombreux cas cependant, où l’objet imprimante peut accepter la demande bien que l’imprimante ait une condition d’erreur, le code d’état 'réussite-ok' sera retourné. Dans un tel cas, le client regardera les attributs d’objet de tâche retournés ou interrogera ensuite l’imprimante pour déterminer son état et les causes de cet état.

Une erreur temporaire telle qu’une erreur d’écriture de mémoire tampon pleine, un débordement de mémoire (c’est-à-dire que les données documentaires excèdent la mémoire de l’imprimante), ou une condition de disque plein, survient alors que l’imprimante IPP traite une opération. Le client PEUT réessayer la demande sans modification ultérieurement en espérant que la condition d’erreur interne temporaire ait reçu une solution. Autrement, à titre d’option de la mise en œuvre, un objet Imprimante PEUT différer la réponse jusqu’à ce que la condition temporaire soit résolue de sorte qu’aucune erreur ne soit retournée.

Une erreur temporaire indiquant que l’imprimante n’accepte pas de tâche actuellement, parce que l’administrateur a réglé la valeur de l’attribut "imprimante-acceptant-des-tâches" de l’imprimante à 'faux' (par des moyens qui sortent du domaine d’application du présent document IPP/1.1).

Une erreur temporaire indiquant que l’imprimante est trop occupée par le traitement des tâches en cours et/ou d’autres demandes. Le client DEVRAIT réessayer la demande inchangée ultérieurement en espérant que la condition d’occupation temporaire aura été résolue.

Une erreur indiquant que la tâche a été annulée par un opérateur ou par le système pendant que le client transmettait les données à l’imprimante IPP. Si un id-de-tâche et un uri-de-tâche ont été créés, ils sont alors retournés dans la réponse Tâche-d’impression, Document-d’envoi, ou URI-d’envoi comme d’habitude ; autrement, aucun id-de-tâche ni uri-de-tâche n’est retourné dans la réponse.

L’objet IPP ne prend pas en charge plusieurs documents par tâche et un client a tenté de fournir des données documentaires avec une seconde opération Document-d’envoi ou URI-d’envoi.

TI = Tâche-d’impression, UI = URI-d’impression, CT = Création-de-tâche, DE = Document-d’envoi, UE = URI-d’envoi, V = Valider-la-tâche, OA = Obtenir-les-attributs-de-tâche et Obtenir-les-attributs-d’imprimante, OT = Obtenir-les-tâches, A = Annuler-la-tâche

MG = Mettre-la-tâche-en-garde, LT = Libération-de-tâche, RT = Redémarrer-la-tâche

14. APPENDICE C : valeurs de mot-clé "support"

Les valeurs standard sont définies (tirées de DPA[ISO10175] et du MIB de l’imprimante [RFC1759]) comme :

Les valeurs standard suivantes sont définies pour les supports Nord Américains :

'na-letter-transparent' : Spécifie le support transparent de lettre nord américain

'iso-designated-long-envelope' : Spécifie le support d’enveloppe long conçu par ISO

'na-nombre-10-envelope' : Spécifie le support d’enveloppe d’affaire nord américain numéro 10

'na-number-9-envelope' : Spécifie l’enveloppe d’affaires nord américaine numéro 9

Les valeurs standard suivantes sont définies pour les supports moins communément utilisés :

'iso-a0-transparent' : Spécifie le support ISO A0 transparent : 841 mm x 1189 mm

'iso-a0-translucent' : Spécifie le support ISO A0 translucide : 841 mm x 1189 mm

'iso-a1-transparent' : Spécifie le support ISO A1 transparent : 594 mm x 841 mm

'iso-a1-translucent' : Spécifie le support ISO A1 translucide : 594 mm x 841 mm

'iso-a2-transparent' : Spécifie le support ISO A2 transparent : 420 mm x 594 mm

'iso-a2-translucent' : Spécifie le support ISO A2 translucide : 420 mm x 594 mm

'iso-a3-transparent' : Spécifie le support ISO A3 transparent : 297 mm x 420 mm

'iso-a3-translucent' : Spécifie le support ISO A3 translucide : 297 mm x 420 mm

'iso-a4-translucent' : Spécifie le support ISO A4 translucide : 210 mm x 297 mm

'iso-a5-transparent' : Spécifie le support ISO A5 transparent : 148 mm x 210 mm

'iso-a5-translucent' : Spécifie le support ISO A5 translucide : 148 mm x 210 mm

'jis-b0-transparent' : Spécifie le support JIS B0 transparent : 1030 mm x 1456 mm

'jis-b0-translucent' : Spécifie le support JIS B0 translucide : 1030 mm x 1456 mm

'jis-b1-transparent' : Spécifie le support JIS B1 transparent : 728 mm x 1030 mm

'jis-b1-translucent' : Spécifie le support JIS B1 translucide : 728 mm x 1030 mm

'jis-b2-transparent' : Spécifie le support JIS B2 transparent : 515 mm x 728 mm

'jis-b2-translucent' : Spécifie le support JIS B2 translucide : 515 mm x 728 mm

'jis-b3-transparent' : Spécifie le support JIS B3 transparent : 364 mm x 515 mm

'jis-b3-translucent' : Spécifie le support JIS B3 translucide : 364 mm x 515 mm

'jis-b4-transparent' : Spécifie le support JIS B4 transparent : 257 mm x 364 mm

'jis-b4-translucent' : Spécifie le support JIS B4 translucide : 257 mm x 364 mm

'jis-b5-transparent' : Spécifie le support JIS B5 transparent : 182 mm x 257 mm

'jis-b5-translucent' : Spécifie le support JIS B5 translucide : 182 mm x 257 mm

Les valeurs standard suivantes sont définies pour les supports d’ingénierie des normes américaines (c’est-à-dire de l’ANSI) :

'a-white' : Spécifie le support d’ingénierie ANSI taille A blanc : 8,5 pouces x 11 pouces

'a-transparent' : Spécifie le support d’ingénierie ANSI taille A transparent : 8,5 pouces x 11 pouces

'a-translucent' : Spécifie le support d’ingénierie ANSI taille A translucide : 8,5 pouces x 11 pouces

'b-white' : Spécifie le support d’ingénierie ANSI taille A blanc : 11 pouces x 17 pouces

'b-transparent' : Spécifie le support d’ingénierie ANSI taille B transparent : 11 pouces x 17 pouces)

'b-translucent' : Spécifie le support d’ingénierie ANSI taille B translucide : 11 pouces x 17 pouces

'c-white' : Spécifie le support d’ingénierie ANSI taille C blanc : 17 pouces x 22 pouces

'c-transparent' : Spécifie le support d’ingénierie ANSI taille C transparent : 17 pouces x 22 pouces

'c-translucent' : Spécifie le support d’ingénierie ANSI taille C translucide : 17 pouces x 22 pouces

'd-white' : Spécifie le support d’ingénierie ANSI taille D blanc : 22 pouces x 34 pouces

'd-transparent' : Spécifie le support d’ingénierie ANSI taille D transparent : 22 pouces x 34 pouces

'd-translucent' : Spécifie le support d’ingénierie ANSI taille D translucide : 22 pouces x 34 pouces

'e-white' : Spécifie le support d’ingénierie ANSI taille E blanc : 34 pouces x 44 pouces

'e-transparent' : Spécifie le support d’ingénierie ANSI taille E transparent : 34 pouces x 44 pouces

'e-translucent' : Spécifie le support d’ingénierie ANSI taille E translucide : 34 pouces x 44 pouces

Les valeurs standard suivantes sont définies pour les supports d’ingénierie des normes américaines (c’est-à-dire ANSI) pour les appareils qui fournissent la "coupe-synchro" (voir paragraphe 14.1) :

'axsynchro-white' : Spécifie le rouleau de papier qui a la largeur du plus long bord (11 pouces) du support d’ingénierie ANSI taille A blanc et coupe synchronisée avec les données.

'axsynchro-transparent ': Spécifie le rouleau de papier qui a la largeur du plus long bord (11 pouces) du support d’ingénierie ANSI taille A transparent et coupe synchronisée avec les données.

'axsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (11 pouces) du support d’ingénierie ANSI taille A translucide et coupe synchronisée avec les données.

'bxsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (17 pouces) du support d’ingénierie ANSI taille B blanc et coupe synchronisée avec les données.

'bxsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (17 pouces) du support d’ingénierie ANSI taille B transparent et coupe synchronisée avec les données.

'bxsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (17 pouces) du support d’ingénierie ANSI taille B translucide et coupe synchronisée avec les données.

'cxsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (22 pouces) du support d’ingénierie ANSI taille C blanc et coupe synchronisée avec les données.

'cxsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (22 pouces) du support d’ingénierie ANSI taille C transparent et coupe synchronisée avec les données.

'cxsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (22 pouces) du support d’ingénierie ANSI taille C translucide et coupe synchronisée avec les données.

'dxsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (34 pouces) du support d’ingénierie ANSI taille D blanc et coupe synchronisée avec les données.

'dxsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (34 pouces) du support d’ingénierie ANSI taille D transparent et coupe synchronisée avec les données.

'dxsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (34 pouces) du support d’ingénierie ANSI taille D translucide et coupe synchronisée avec les données.

'exsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (44 pouces) du support d’ingénierie ANSI taille E blanc et coupe synchronisée avec les données.

'exsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (44 pouces) du support d’ingénierie ANSI taille E transparent et coupe synchronisée avec les données.

'exsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (44 pouces) du support d’ingénierie ANSI taille E translucide et coupe synchronisée avec les données.

Les valeurs standard suivantes sont définies pour le support d’ingénierie architecturale américain :

'arch-a-white': Spécifie le support Architectural taille A blanc : 9 pouces x 12 pouces

'arch-a-transparent': Spécifie le support Architectural taille A transparent : 9 pouces x 12 pouces

'arch-a-translucent': Spécifie le support Architectural taille A translucide : 9 pouces x 12 pouces

'arch-b-white': Spécifie le support Architectural taille B blanc : 12 pouces x 18 pouces

'arch-b-transparent': Spécifie le support Architectural taille B transparent : 12 pouces x 18 pouces

'arch-b-translucent': Spécifie le support Architectural taille B translucide : 12 pouces x 18 pouces

'arch-c-white': Spécifie le support Architectural taille C blanc : 18 pouces x 24 pouces

'arch-c-transparent': Spécifie le support Architectural taille C transparent : 18 pouces x 24 pouces

'arch-c-translucent': Spécifie le support Architectural taille C translucide : 18 pouces x 24 pouces

'arch-d-white': Spécifie le support Architectural taille D blanc : 24 pouces x 36 pouces

'arch-d-transparent': Spécifie le support Architectural taille D transparent : 24 pouces x 36 pouces

'arch-d-translucent': Spécifie le support Architectural taille D translucide : 24 pouces x 36 pouces

'arch-e-white': Spécifie le support Architectural taille E blanc : 36 pouces x 48 pouces

'arch-e-transparent': Spécifie le support Architectural taille E transparent : 36 pouces x 48 pouces

'arch-e-translucent': Spécifie le support Architectural taille A translucide : 36 pouces x 48 pouces

Les valeurs standard suivantes sont définies pour le support d’ingénierie architecturale américain pour les appareils qui disposent de la "coupe-synchro" (voir au paragraphe 14.1) :

'arch-axsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (12 pouces) du support Architectural taille A blanc et coupe synchronisée avec les données.

'arch-axsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (12 pouces) du support Architectural taille A transparent et coupe synchronisée avec les données.

'arch-axsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (12 pouces) du support Architectural taille A translucide et coupe synchronisée avec les données.

'arch-bxsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (18 pouces) du support Architectural taille B blanc et coupe synchronisée avec les données.

'arch-bxsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (18 pouces) du support Architectural taille B transparent et coupe synchronisée avec les données.

'arch-bxsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (18 pouces) du support Architectural taille B translucide et coupe synchronisée avec les données.

'arch-cxsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (24 pouces) du support Architectural taille C blanc et coupe synchronisée avec les données.

'arch-cxsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (24 pouces) du support Architectural taille C transparent et coupe synchronisée avec les données.

'arch-cxsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (24 pouces) du support Architectural taille A translucide et coupe synchronisée avec les données.

'arch-dxsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (36 pouces) du support Architectural taille D blanc et coupe synchronisée avec les données.

'arch-dxsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (36 pouces) du support Architectural taille D transparent et coupe synchronisée avec les données.

'arch-dxsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (36 pouces) du support Architectural taille D translucide et coupe synchronisée avec les données.

'arch-exsynchro-white': Spécifie le rouleau de papier qui a la largeur du plus long bord (48 pouces) du support Architectural taille E blanc et coupe synchronisée avec les données.

'arch-exsynchro-transparent': Spécifie le rouleau de papier qui a la largeur du plus long bord (48 pouces) du support Architectural taille E transparent et coupe synchronisée avec les données.

'arch-exsynchro-translucent': Spécifie le rouleau de papier qui a la largeur du plus long bord (48 pouces) du support Architectural taille E translucide et coupe synchronisée avec les données.

Les valeurs standard suivantes sont définies pour les supports d’ingénierie japonaise et européenne normalisés (c’est-à-dire ISO), qui sont de taille longue fixée [ASME-Y14.1M] :

'iso-a1x3-white': Spécifie le support ISO A1X3 blanc qui a la largeur du plus long bord (841 mm) du support ISO A1

'iso-a1x3-transparent': Spécifie le support ISO A1X3 transparent qui a la largeur du plus long bord (841 mm) du support ISO A1.

'iso-a1x3-translucent': Spécifie le support ISO A1X3 translucide qui a la largeur du plus long bord (841 mm) du support ISO A1.

'iso-a1x4-white': Spécifie le support ISO A1X4 blanc qui a la largeur du plus long bord (841 mm) du support ISO A1.

'iso-a1x4-transparent': Spécifie le support ISO A1X4 transparent qui a la largeur du plus long bord (841 mm) du support ISO A1.

'iso-a1x4- translucent': Spécifie le support ISO A1X4 translucide qui a la largeur du plus long bord (841 mm) du support ISO A1.

'iso-a2x3-white': Spécifie le support ISO A2X3 blanc qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x3-transparent': Spécifie le support ISO A2X3 transparent qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x3-translucent': Spécifie le support ISO A2X3 translucde qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x4-white': Spécifie le support ISO A2X4 blanc qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x4-transparent': Spécifie le support ISO A2X4 transparent qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x4-translucent': Spécifie le support ISO A2X4 translucide qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x5-white': Spécifie le support ISO A2X5 blanc qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x5-transparent': Spécifie le support ISO A2X5 transparent qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a2x5-translucent': Spécifie le support ISO A2X5 translucide qui a la largeur du plus long bord (594 mm) du support ISO A2.

'iso-a3x3-white': Spécifie le support ISO A3X3 blanc qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x3-transparent': Spécifie le support ISO A3X3 transparent qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x3-translucent': Spécifie le support ISO A3X3 translucide qui a la largeur du plus long bord 420 mm) du support ISO A3.

'iso-a3x4-white': Spécifie le support ISO A3X4 blanc qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x4-transparent': Spécifie le support ISO A3X4 transparent qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x4-translucent': Spécifie le support ISO A3X4 translucide qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x5-white': Spécifie le support ISO A3X5 blanc qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x5-transparent': Spécifie le support ISO A3X5 transparent qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x5-translucent': Spécifie le support ISO A3X5 translucide qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x6-white': Spécifie le support ISO A3X6 blanc qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x6-transparent': Spécifie le support ISO A3X6 transparent qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x6-translucent': Spécifie le support ISO A3X6 translucide qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x7-white': Spécifie le support ISO A3X7 blanc qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x7-transparent': Spécifie le support ISO A3X7 transparent qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a3x7-translucent'': Spécifie le support ISO A3X7 translucide qui a la largeur du plus long bord (420 mm) du support ISO A3.

'iso-a4x3-white': Spécifie le support ISO A4X3 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x3-transparent': Spécifie le support ISO A4X3 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x3-translucent'': Spécifie le support ISO A4X3 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x4-white': Spécifie le support ISO A4X4 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x4-transparent': Spécifie le support ISO A4X4 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x4-translucent': Spécifie le support ISO A4X4 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x5-white': Spécifie le support ISO A4X5 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x5-transparent': Spécifie le support ISO A4X5 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x5-translucent': Spécifie le support ISO A4X5 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x6-white': Spécifie le support ISO A4X6 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x6-transparent': Spécifie le support ISO A4X6 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x6-translucent': Spécifie le support ISO A4X6 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x7-white': Spécifie le support ISO A4X7 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x7-transparent': Spécifie le support ISO A4X7 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x7-translucent': Spécifie le support ISO A4X7 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x8-white': Spécifie le support ISO A4X8 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x8-transparent': Spécifie le support ISO A4X8 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x8-translucent': Spécifie le support ISO A4X8 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x9-white': Spécifie le support ISO A4X9 blanc qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x9-transparent': Spécifie le support ISO A4X9 transparent qui a la largeur du plus long bord (297 mm) du support ISO A4.

'iso-a4x9-translucent': Spécifie le support ISO A4X9 translucide qui a la largeur du plus long bord (297 mm) du support ISO A4.

Les valeurs standard suivantes sont définies pour les normes japonaises et européennes (c’est-à-dire ISO) de support d’ingénierie, qui sont de taille longue fixée [ASME-Y14.1M] ou en alimentation par rouleau, pour les appareils disposant de la "coupe-synchro" (voir au paragraphe 14.1) :

'iso-a0xsynchro-white' : Spécifie le papier qui a la largeur du plus long bord (1189 mm) du support ISO A0 blanc et coupe synchronisée avec les données.

'iso-a0xsynchro-transparent' : Spécifie le papier qui a la largeur du plus long bord (1189 mm) du support ISO A0 transparent et coupe synchronisée avec les données.

'iso-a0xsynchro-translucent' : Spécifie le papier qui a la largeur du plus long bord (1189 mm) du support ISO A0 translucide et coupe synchronisée avec les données.

'iso-a1xsynchro-white' : Spécifie le papier qui a la largeur du plus long bord (841 mm) du support ISO A1 blanc et coupe synchronisée avec les données.

'iso-a1xsynchro-transparent' : Spécifie le papier qui a la largeur du plus long bord (841 mm) du support ISO A1 transparent et coupe synchronisée avec les données.

'iso-a1xsynchro-translucent' : Spécifie le papier qui a la largeur du plus long bord (841 mm) du support ISO A1 translucide et coupe synchronisée avec les données.

'iso-a2xsynchro-white' : Spécifie le papier qui a la largeur du plus long bord (594 mm) du support ISO A2 blanc et coupe synchronisée avec les données.

'iso-a2xsynchro-transparent' : Spécifie le papier qui a la largeur du plus long bord (594 mm) du support ISO A2 transparent et coupe synchronisée avec les données.

'iso-a2xsynchro-translucent' : Spécifie le papier qui a la largeur du plus long bord (594 mm) du support ISO A2 translucide et coupe synchronisée avec les données.

'iso-a3xsynchro-white' : Spécifie le papier qui a la largeur du plus long bord (420 mm) du support ISO A3 blanc et coupe synchronisée avec les données.

'iso-a3xsynchro-transparent' : Spécifie le papier qui a la largeur du plus long bord (420 mm) du support ISO A3 transparent et coupe synchronisée avec les données.

'iso-a3xsynchro-translucent' : Spécifie le papier qui a la largeur du plus long bord (420 mm) du support ISO A3 translucide et coupe synchronisée avec les données.

'iso-a4xsynchro-white' : Spécifie le papier qui a la largeur du plus long bord (297 mm) du support ISO A4 blanc et coupe synchronisée avec les données.

'iso-a4xsynchro-transparent' : Spécifie le papier qui a la largeur du plus long bord (297 mm) du support ISO A4 transparent et coupe synchronisée avec les données.

'iso-a4xsynchro-translucent' : Spécifie le papier qui a la largeur du plus long bord (297 mm) du support ISO A4 translucide et coupe synchronisée avec les données.

Les valeurs standard suivantes sont définies pour les supports d’ingénierie aux normes américaines (c’est-à-dire ANSI), les supports d’ingénierie architecturale américaine, et les supports d’ingénierie aux normes japonaises et européennes (c’est-à-dire ISO), qui sont de taille longue fixée [ASME-Y14.1M] ou à alimentation par rouleau, pour les appareils qui disposent de la "coupe-synchro" et/ou de "auto-sélection" (voir au paragraphe 14.1) :

'auto-white': Spécifie que l’imprimante choisit le support blanc avec la taille fixe appropriée (par exemple, a1, a2, etc.) ou la taille synchronisée sur les données, et le choix est défini par la mise en œuvre.

'auto-transparent': Spécifie que l’imprimante choisit le support transparent avec la taille fixe appropriée (par exemple, a1, a2, etc.) ou la taille synchronisée sur les données, et le choix est défini par la mise en œuvre.

'auto-translucent': Spécifie que l’imprimante choisit le support translucide avec la taille fixe appropriée (par exemple, a1, a2, etc.) ou la taille synchronisée sur les données, et le choix est défini par la mise en œuvre.

'auto-fixed-size-white': Spécifie que l’imprimante choisit le support blanc avec la taille fixe appropriée (par exemple, a1, a2, etc.) ou la taille longue fixe appropriée dont la liste figure ci-dessus.

'auto-fixed-size-transparent': Spécifie que l’imprimante choisit le support transparent avec la taille fixe appropriée (par exemple, a1, a2, etc.) ou la taille longue fixe appropriée dont la liste figure ci-dessus.

'auto-fixed-size-translucent': Spécifie que l’imprimante choisit le support translucide avec la taille fixe appropriée (par exemple, a1, a2, etc.) ou la taille longue fixe appropriée dont la liste figure ci-dessus.

'auto-synchro-white': Spécifie que l’imprimante choisit le papier blanc avec la largeur appropriée et le coupe en synchronisation avec les données.

'auto-synchro-transparent': Spécifie que l’imprimante choisit le papier transparent avec la largeur appropriée et le coupe en synchronisation avec les données.

'auto-synchro-translucent': Spécifie que l’imprimante choisit le papier translucide avec la largeur appropriée et le coupe en synchronisation avec les données.

Les valeurs standard suivantes sont définies pour les bacs d’entrée (tirées de ISO DPA et du MIB d’imprimante) :

Les valeurs standard suivantes sont définies pour les tailles de support (tiré de ISO DPA) :

'iso-a0' : Spécifie la taille ISO A0 : 841 mm par 1189 mm comme défini dans ISO 216

'iso-a1' : Spécifie la taille ISO A1 : 594 mm par 841 mm comme défini dans ISO 216

'iso-a2' : Spécifie la taille ISO A2 : 420 mm par 594 mm comme défini dans ISO 216

'iso-a3' : Spécifie la taille ISO A3 : 297 mm par 420 mm comme défini dans ISO 216

'iso-a4' : Spécifie la taille ISO A4 : 210 mm par 297 mm comme défini dans ISO 216

'iso-a5' : Spécifie la taille ISO A5 : 148 mm par 210 mm comme défini dans ISO 216

'iso-a6' : Spécifie la taille ISO A6 : 105 mm par 148 mm comme défini dans ISO 216

'iso-a7' : Spécifie la taille ISO A7 : 74 mm par 105 mm comme défini dans ISO 216

'iso-a8' : Spécifie la taille ISO A8 : 52 mm par 74 mm comme défini dans ISO 216

'iso-a9' : Spécifie la taille ISO A9 : 37 mm par 52 mm comme défini dans ISO 216

'iso-a10' : Spécifie la taille ISO A10 : 26 mm par 37 mm comme défini dans ISO 216

'iso-b0' : Spécifie la taille ISO B0 : 1000 mm par 1414 mm comme défini dans ISO 216

'iso-b1' : Spécifie la taille ISO B1 : 707 mm par 1000 mm comme défini dans ISO 216

'iso-b2': Spécifie la taille ISO B2 : 500 mm par 707 mm comme défini dans ISO 216

'iso-b3': Spécifie la taille ISO B3 : 353 mm par 500 mm comme défini dans ISO 216

'iso-b4': Spécifie la taille ISO B4 : 250 mm par 353 mm comme défini dans ISO 216

'iso-b5': Spécifie la taille ISO B5 : 176 mm par 250 mm comme défini dans ISO 216

'iso-b6': Spécifie la taille ISO B6 : 125 mm par 176 mm comme défini dans ISO 216

'iso-b7': Spécifie la taille ISO B7 : 88 mm par 125 mm comme défini dans ISO 216

'iso-b8': Spécifie la taille ISO B8 : 62 mm par 88 mm comme défini dans ISO 216

'iso-b9': Spécifie la taille ISO B9 : 44 mm par 62 mm comme défini dans ISO 216

'iso-b10': Spécifie la taille ISO B10 : 31 mm par 44 mm comme défini dans ISO 216

'na-letter': Spécifie la taille lettre nord américaine : 8,5 pouces par 11 pouces

'na-legal': Spécifie la taille légale nord américaine : 8,5 pouces par 14 pouces

'iso-c3': Spécifie la taille ISO C3 : 324 mm par 458 mm comme défini dans ISO 269

'iso-c4': Spécifie la taille ISO C4 : 229 mm par 324 mm comme défini dans ISO 269

'iso-c5': Spécifie la taille ISO C5 : 162 mm par 229 mm comme défini dans ISO 269

'iso-c6': Spécifie la taille ISO C6 : 114 mm par 162 mm comme défini dans ISO 269

'iso-designated-long': Spécifie la taille ISO conception longue : 110 mm par 220 mm comme défini dans ISO 269

'na-10x13-envelope': Spécifie la taille nord américaine 10x13 : 10 pouces par 13 pouces

'na-9x12-envelope': Spécifie la taille nord américaine 9x12 : 9 pouces par 12 pouces

'na-nombre-10-envelope': Spécifie la taille d’enveloppe d’affaires nord américaine numéro 10 : 4,125 pouces par 9,5 pouces

'na-7x9-envelope': Spécifie la taille d’enveloppe nord américaine 7x9 pouces

'na-9x11-envelope': Spécifie la taille d’enveloppe nord américaine 9x11 pouces

'na-10x14-envelope': Spécifie la taille d’enveloppe nord américaine 10x14 pouces

'na-nombre-9-envelope': Spécifie la taille d’enveloppe d’affaires nord américaine numéro 9

'monarch-envelope': Spécifie la taille d’enveloppe Monarque (3,87 x 7,5 pouces)

Les valeurs standard suivantes sont définies pour les tailles de support d’ingénierie aux normes américaines (c’est-à-dire ANSI) :

'a' : Spécifie la taille de support d’ingénierie ANSI A : 8,5 pouces x 11 pouces

'b' : Spécifiela taille de support d’ingénierie ANSI B : 11 pouces x 17 pouces

'c' : Spécifie la taille de support d’ingénierie ANSI C : 17 pouces x 22 pouces

'd' : Spécifie la taille de support d’ingénierie ANSI D : 22 pouces x 34 pouces

'e' : Spécifie la taille de support d’ingénierie ANSI E : 34 pouces x 44 pouces

Les valeurs standard suivantes sont définies pour les tailles de support d’ingénierie architecturale américaine :

'arch-a' : Spécifie la taille de support architectural A : 9 pouces x 12 pouces

'arch-b' : Spécifie la taille de support architectural B : 12 pouces x 18 pouces

'arch-c' : Spécifie la taille de support architectural C : 18 pouces x 24 pouces

'arch-d' : Spécifie la taille de support architectural D : 24 pouces x 36 pouces

'arch-e' : Spécifie la taille de support architectural E : 36 pouces x 48 pouces

14.1. Exemples

Ci-dessous figurent des exemples illustrant les définitions de valeur de support d’ingénierie.

Exemple 1 : "coupe-synchro", un appareil qui coupe le rouleau de papier en synchronisme avec les données.

Largeur de données (ombragée) : largeur A1 < largeur des données < (largeur A1) x 2

Exemple 2 : "Auto-Coupe", un appareil coupant le rouleau de papier à des largeurs de support de taille fixée multiples.

Largeur des données (ombragé) : largeur A1 < largeur des données < (largeur A1) x 2

Exemple 4 : "coupe-synchro", un appareil coupant le papier de taille fixe en synchronisation avec les données.

Largeur des données (ombragé) : (largeur A4) x 2 < largeur des données < (largeur A4 ) x 3

15. APPENDICE D : Traitement des attributs IPP

Lors de la soumission d’une tâche d’impression à un objet Imprimante, le modèle IPP permet à un client de fournir des attributs d’opération et de gabarit d’imprimante avec les données documentaires. Ces attributs de gabarit d’imprimante dans la demande de création affectent le rendu, la production et la finition des documents dans la tâche. Des types d’instructions similaires peuvent aussi être contenus dans le document à imprimer, c’est-à-dire, incorporés dans les données d’impression elles-mêmes. De plus, l’imprimante a un ensemble d’attributs qui décrivent quelles options de rendu et de finition sont prises en charge par cette imprimante. Ce modèle, qui permet souplesse et puissance, introduit aussi la possibilité qu’au moment de la soumission de tâche, ces attributs fournis par le client entrent en conflit avec :

- ce que la mise en œuvre est capable de réaliser (c’est-à-dire, ce que l’imprimante prend en charge), aussi bien qu’avec

Les paragraphes suivants décrivent comment sont traités ces deux types de conflit dans le modèle IPP.

15.1 Fidélité

S’il y a un conflit entre ce que la demande du client et ce qu’un objet Imprimante prend en charge, le client peut demander un des deux mécanismes de traitement de conflit possibles :

1) soit rejeter la tâche car celle-ci ne peut être traitée exactement comme spécifié, soit

2) permettre à l’imprimante d’effectuer tout changement nécessaire pour procéder au traitement de la tâche au mieux qu’elle peut.

"Imprimer la tâche exactement comme spécifié sans exception, et si cela ne peut être fait, ne pas se soucier d’imprimer la tâche du tout." Dans le second cas, le client indique à l’objet imprimante : "Il est plus important de s’assurer que la tâche est imprimée plutôt que de procéder exactement comme spécifié ; s’assurer simplement que la tâche est imprimée même si certains attributs fournis par le client doivent être changés ou ignorés."

Le modèle IPP tient compte de cette situation par l’introduction d’un attribut "fidélité-d’attribut-ipp".

Dans une demande de création, "fidélité-d’attribut-ipp" est un attribut d’opération booléen qui est FACULTATIVEMENT fourni par le client. La valeur 'vrai' indique qu’une totale fidélité aux attributs et valeurs de gabarit d’imprimante fournis par le client est requise. Le client demande que la tâche soit imprimée exactement comme spécifié, et si cela n’est pas possible, que la tâche DOIT alors être rejetée plutôt que traitée incorrectement. La valeur 'faux' indique qu’une tentative raisonnable d’impression de la tâche est acceptable. Si une imprimante ne prend pas en charge certains attributs de gabarit d’imprimante ou valeurs fournis par le client, l’imprimante DOIT les ignorer, ou respectivement, leur substituer toute valeur prise en charge pour des valeurs non acceptées. L’imprimante peut choisir de substituer la valeur par défaut associée à cet attribut, ou utiliser une autre valeur prise en charge qui est semblable à la valeur demandée non acceptée. Par exemple, si un client fournit une valeur "support" de 'na-letter', l’imprimante peut choisir de substituer 'iso-a4' plutôt qu’une valeur par défaut de 'envelope'. Si le client ne fournit pas l’attribut "fidélité-d’attribut-ipp", l’imprimante suppose une valeur de 'faux'.

Chaque mise en œuvre d’imprimante DOIT prendre en charge les deux types d’impression de "fidélité" (c'est-à-dire selon que le client fournit une valeur de 'vrai' ou 'faux') :

- Si le client fournit 'faux' ou ne fournit pas l’attribut, l’objet imprimante DOIT toujours accepter la demande en ignorant les attributs de gabarit d’imprimante non acceptés et en substituant des valeurs prises en charge à des valeurs non acceptées des attributs de gabarit d’imprimante pris en charge.

- Si le client fournit 'vrai', l’objet imprimante DOIT rejeter la demande si le client fournit des attributs de gabarit d’imprimante non acceptés.

Comme un client peut toujours interroger une imprimante pour savoir exactement ce qui est et n’est pas pris en charge, "fidélité-d’attribut-ipp" mis à 'faux' est utile lorsque :

1) l’utilisateur final utilise une interface de ligne de commande pour demander des attributs qui pourraient n’être pas pris en charge,

2) dans un contexte GUI, si l’utilisateur final s’attend à ce que la tâche puisse être déplacée sur une autre imprimante et préfère un résultat non optimal à rien du tout,

3) l’utilisateur final veut seulement quelque chose de raisonnable au lieu de rien du tout.

15.2 Outrepasser le langage de description de page (PDL)

Si il y a un conflit entre la valeur d’un attribut de gabarit de tâche IPP et une instruction correspondante dans les données documentaires, la valeur de l’attribut IPP DEVRAIT prendre le pas sur l’instruction documentaire. Considérons le cas où un fichier de données documentaires formaté antérieurement est envoyé à une imprimante IPP. Dans ce cas, si le client fournit des attributs à l’heure de soumission de tâche, le client désire que ces attributs outrepassent les instructions incorporées. Considérons le cas où un document formaté antérieurement a incorporé une commande pour charger le support 'iso-a4'. Cependant, le document est passé à un utilisateur final qui n’a accès qu’à une imprimante ayant chargé le support 'na-letter'. Cet utilisateur final veut très vraisemblablement soumettre ce document à une imprimante IPP ayant l’attribut de gabarit de tâche "support" réglé à 'na-letter'. L’attribut de soumission de tâche devrait prendre le pas sur l’instruction PDL incorporée. Cependant, jusqu’à ce que les compagnies qui fournissent les interprètes de données documentaires permettent aux attributs IPP externes de prendre le pas sur les instructions de production de tâche incorporées, une imprimante peut n’être pas capable de prendre en charge la sémantique par laquelle les attributs IPP outrepassent les instructions incorporées.

Le modèle IPP tint compte de cette situation en introduisant un attribut "outrepasser-pdl-pris-en-charge" qui décrit les capacités des objets imprimante à outrepasser les instructions incorporées dans le flux de données PDL. La valeur de l’attribut "outrepasser-pdl-pris-en-charge" est configurée par des moyens qui sortent du domaine d’application du présent document IPP/1.1.

- 'tenté' : cette valeur indique que l’objet imprimante tente de faire prendre aux valeurs d’attribut IPP le pas sur les instructions incorporées dans les données documentaires, cependant sans garantie.

- 'non-tenté' : cette valeur indique que l’objet imprimante ne tente pas de faire pendre le pas aux valeurs d’attribut IPP sur les instructions incorporés dans les données documentaires.

A l’heure du traitement de tâche, une mise en œuvre qui prend en charge la valeur de 'tenté' peut effectuer plusieurs actions différentes :

1) Générer une séquence de commande spécifique de l’appareil de sortie pour réaliser la caractéristique représentée par la valeur d’attribut IPP.

2) Analyser les données documentaires elles-mêmes et remplacer l’instruction incorporée en conflit par une nouvelle instruction incorporée qui corresponde aux intentions de la valeur de l'attribut IPP.

3) Indiquer à l’imprimante que les attributs externes fournis prennent le pas sur les instructions incorporées et passer ensuite les valeurs d’attribut IPP externes à l’interprète des données documentaires.

4) N’importe quoi d’autre qui permette à la sémantique que les attributs IPP outrepassent les instructions de données documentaires incorporées.

Comme 'tenté' n’offre aucune espèce de garantie, bien qu’un objet Imprimante donné puisse ne pas faire du très bon travail en tentant de s’assurer que les attributs IPP prennent le pas sur les instructions incorporées dans les données documentaires, il serait quand même une mise en œuvre conforme.

Au moment du traitement de la tâche, une mise en œuvre qui prend en charge la valeur de 'non-tenté' peut effectuer une des actions suivantes :

1) Simplement ajouter aux données documentaires l’instruction PDL qui correspond à l’attribut PDL fourni par le client, de sorte que si les données documentaires ont aussi la même instruction PDL, elles vont outrepasser ce que l’objet imprimante a ajouté. En d’autres termes, cette mise en œuvre utilise la même sémantique de mise en œuvre pour les attributs IPP fournis par le client que l’objet imprimante par défaut.

2) Analyser les données documentaires et remplacer l’instruction incorporée conflictuelle par une nouvelle instruction incorporée qui s’approche de, mais ne correspond pas exactement, la sémantique voulue par la valeur de l’attribut IPP.

Note : L’attribut "fidélité-d’attribut-ipp" s’applique à la capacité de l’imprimante à accepter ou rejeter d’autres attributs de gabarit d’imprimante non pris en charge. En d’autres termes, si "fidélité-d’attribut-ipp" est mis à 'vrai', une tâche est acceptée si et seulement si les attributs et valeurs de gabarit d’imprimante fournis par le client sont pris en charge par l’imprimante. Savoir si ces attributs affectent réellement le traitement de la tâche lorsque les données documentaires contiennent des instructions incorporées dépend de la capacité de l’imprimante à outrepasser les instructions incorporées dans les données documentaires avec la sémantique des attributs IPP. Si les attributs des données documentaires peuvent être outrepassés ("outrepasser-pdl-pris-en-charge" réglé à 'tenté'), l’imprimante fait une tentative d’utilisation des attributs IPP lorsqu’elle traite la tâche. Si les attributs des données documentaires ne peuvent pas être outrepassés ("outrepasser-pdl-pris-en-charge" réglé à 'non-tenté'), l’imprimante ne fait aucune tentative pour outrepasser les instructions incorporées dans les données documentaires avec les attributs IPP lorsqu’elle traite la tâche, et donc, les attributs IPP peuvent échouer à affecter le traitement de la tâche et sa sortie lorsque l’instruction correspondante est incorporée dans les données documentaires.

15.3 Utilisation des attributs de gabarit de tâche durant le traitement de document

L’objet Imprimante utilise certains des attributs de gabarit d’imprimante de l’objet Tâche durant le traitement des données documentaires associées à cette tâche. Cela inclut, mais n’y est pas limité, "orientation-demandée", "jusqu’à", "côtés", "support", et "copies". Le traitement de chaque document dans un objet tâche DOIT suivre les étapes ci-dessous. Ces étapes ne sont destinées qu’à identifier quand et comment les attributs doivent être utilisés dans le traitement des données documentaires et toute étape de remplacement qui aboutit au même effet peut être utilisée pour mettent en œuvre ce document de spécification.

1. L’utilisation de l’attribut "format-de-document" fourni par le client ou d’une forme d’algorithme de détection de format de document (si la valeur de "format-de-document" n’est pas assez spécifique), détermine si les données documentaires ont ou non déjà été formatées pour l’impression. Si les données documentaires ont été formatées, passer alors à l’étape 2. Autrement, les données documentaires DOIVENT être formatées. L’algorithme de détection de format est défini par la mise en œuvre et n’est pas spécifié par le présent document. Le formatage des données documentaires utilise l’attribut "orientation-demandée" pour déterminer comment les données d’impression formatées devraient être placées dans une page de flux d’impression, voir au paragraphe 4.2.10 pour les détails.

2. Les données documentaires sont sous la forme d’un flux d’impression dans un type de support connu. L’attribut "gamme-de-pages" est utilisé pour choisir dans le flux d’impression, comme spécifié au paragraphe 4.2.7, une sous-séquence des pages à traiter et imager.

3. L’entrée pour cette étape est une séquence de pages du flux d’impression. Cette étape est contrôlée par l’attribut "jusqu’à". Si la valeur de "jusqu’à" est N, durant le traitement des pages du flux d’impression, chacune des N pages du flux d’impression est alors positionnée, comme spécifié au paragraphe 4.2.9, pour créer une seule impression. Si un document donné n’a pas N pages de plus du flux d’impression, l’achèvement de l’impression est alors contrôlé par l’attribut "traitement-de-document-multiple",comme décrit au paragraphe 4.2.4 ; lorsque la valeur de cet attribut est 'document-unique' ou 'document-unique-nouvelle-feuille', les pages du flux d’impression des données documentaires des documents suivants sont utilisées pour compléter l’impression.

La taille (échelonnement), position (translation) et rotation des pages du flux d’impression sur l’impression sont définies par la mise en œuvre. Noter que durant ce processus, les pages du flux d’impression peuvent être rendues dans une forme convenable pour le placement de l’impression ; ce rendu est contrôlé par les valeurs des attributs "résolution-d’imprimante" et "qualité-d’impression" comme décrit aux paragraphes 4.2.12 et 4.2.13. Dans le cas N = 1, l’impression est presque la même que la page du flux d’impression ; les différences seront seulement dans la taille, position et rotation de la page de flux d’impression et/ou décoration, comme une trame de la page, ajoutée par la mise en œuvre.

4. La collection des impressions est placée, en séquence, sur les côtés des feuilles de support. Ce placement est contrôlé par l’attribut "côtés" et l’orientation de la page de flux d’impression, comme décrit au paragraphe 4.2.8. L’orientation des pages du flux d’impression affecte l’orientation de l’impression ; par exemple, si "jusqu’à" égale 2, alors normalement, deux pages portrait du flux d’impression deviennent une impression paysage. Noter que le placement des impressions sur les feuilles de support est aussi contrôlé par l’attribut "traitement-de-document-multiple" comme décrit au paragraphe 4.2.4.

5. Les attributs "copies" et "traitement-de-document-multiple" sont utilisés pour déterminer comment sont crées de nombreuses copies de chaque instance de support et dans quel ordre. Voir aux paragraphes 4.2.5 et 4.2.4 pour les détails.

6. Lorsque le nombre correct de copies est créé, les instances de support sont finies conformément aux valeurs de l’attribut "finitions" comme décrit dans 4.2.6. Noter que parfois les opérations de finition peuvent exiger une intervention manuelle à effectuer sur les copies, spécialement les copies non colligées. Le présent document permet que toute étape du traitement soit effectuée automatiquement ou manuellement à la discrétion de l’objet imprimante.

16. APPENDICE E : Schéma d’annuaire générique

La présente section définit un schéma générique pour une entrée dans un service d’annuaire. Un service d’annuaire est un moyen par lequel les utilisateurs du service peuvent localiser les fournisseurs de service. Dans les environnements IPP, cela signifie que les imprimantes IPP peuvent être enregistrées (automatiquement ou avec l’aide d’un administrateur) comme entrées de type imprimante dans l’annuaire un utilisant un mécanisme spécifique de la mise en œuvre comme attributs d’entrée, champs de type d’entrée, branches spécifiques. Les clients de l’annuaire peuvent rechercher ou feuilleter les entrées de type imprimante. Les clients utilisent le service d’annuaire pour trouver des entrées sur la base du nom, du contexte organisationnel, ou faire des recherches filtrées selon les valeurs des attributs des entrées. Par exemple, un client peut trouver toutes les imprimantes dans la rubrique "département local". L’authentification et l’autorisation font souvent partie d’un service d’annuaire de sorte qu’un administrateur puisse fixer des limites aux utilisateurs finaux afin qu’il ne leur soit permis que de trouver les entrées auxquelles ils ont des droits d’accès certains. IPP par lui-même n’exige aucun protocole ou fournisseur spécifique de service annuaire.

Note : Certaines mises en œuvre de service annuaire permettent la notion de "pseudonyme" (ou alias). C’est-à-dire, un objet d’entrée d’annuaire peut apparaître comme plusieurs objets d’entrée d’annuaire avec des noms différents pour chaque objet. Dans chaque cas, chaque pseudonyme se réfère au même objet d’entrée d’annuaire qui se réfère à un seul objet imprimante IPP.

Le schéma générique est un sous-ensemble des attributs de description d’opération et de gabarit de tâche d’imprimante IPP (paragraphes 4.2 et4.4). Ces attributs sont identifiés comme RECOMMENDÉ ou FACULTATIF pour l’entrée d’annuaire. Cet étiquetage pour la conformité n’EST PAS le même étiquetage de conformité que celui appliqué aux attributs des objets Imprimante IPP. L’étiquetage de conformité dans le présent Appendice est destiné à s’appliquer aux gabarits d’annuaire et aux mises en œuvre d’imprimante IPP qui y souscrivent par l’ajout d’une ou plusieurs entrées à un annuaire. Les attributs RECOMMENDÉS DEVRAIENT être associés à chaque entrée d’annuaire. Les attributs FACULTATIFS PEUVENT être associés à l’entrée d’annuaire (s’ils sont connus ou pris en charge). De plus, tout attribut d’entrée d’annuaire DEVRAIT refléter les valeurs d’attribut en cours pour l’objet Imprimante correspondant.

Les noms des attributs dans les schémas et entrées d’annuaire DEVRAIENT être autant que possible les mêmes que les noms d’attribut de l’imprimante IPP.

L’attribut "uri-d’imprimante-acceptés" de l’objet imprimante est un des attributs d’entrée d’annuaire RECOMMENDÉS pour faire une passerelle entre le service d’annuaire et l’objet imprimante IPP. Le client de l’annuaire interroge l’attribut "uri-d’imprimante-acceptés" (ou un équivalent) dans l’entrée d’annuaire et puis le client IPP s’adresse à l’objet imprimante IPP en utilisant un de ses URI. L’attribut "sécurité-d’uri-prise-en-charge" identifie le protocole utilisé (s’il en est) pour sécuriser un canal.

Les attributs suivants définissent le schéma générique pour les entrées d’annuaire de type IMPRIMANTE :

17. APPENDICE F : Différences entre les documents "Modèle et sémantique" IPP/1.0 et IPP/1.1

Le présent Appendice est divisé en deux listes qui résument les différences entre IPP/1.1 (le présent document) et IPP/1.0 [RFC2566]. Les numéros de paragraphe se réfèrent aux numéros du présent document, qui dans certains cas ont changé par rapport à la RFC 2566. Lorsqu’un changement affecte plusieurs paragraphes, l’élément figure une fois dans l’ordre du premier paragraphe affecté et les numéros des paragraphes affectés restants sont indiqués.

La première liste contient des extensions et précisions et la seconde contient des changements dans la sémantique ou la conformité. Cependant, les mises en œuvre d’objet client et IPP de IPP/1.0 PEUVENT mettre en œuvre toutes les extensions et précisions du présent document.

Les extensions et précisions suivantes ont été incorporées au présent document :

1. paragraphe 2.1 – précise que le terme "client" peut être contenu dans un logiciel contrôlé par l’utilisateur final ou faire partie d’un serveur d’impression qui contrôle l’appareil.

2. Section 2 - précise que les termes "objet IPP" et "objet Imprimante" peuvent être incorporés dans l’objet appareil ou faire partie d’un serveur d’impression qui accepte des demandes IPP.

3. paragraphe 2.4 – ajoute la description d’un nouvel attribut de description d’opération "authentification-d’uri-prise-en-charge".

4. paragraphes 3.1.3, 3.1.6, 3.2.5.2, et 3.2.6.2 – précise le traitement d’erreur pour les attributs d’opération qui ont leur propre code d’état.

5. paragraphe 3.1.3 – précise que plusieurs occurrences du même attribut dans un groupe d’attributs est un groupe malformé. Une imprimante IPP PEUT rejeter la demande ou choisir un des attributs.

6. paragraphe 3.1.6 – ce paragraphe est réorganisé en sous-paragraphes pour décrire séparément les attributs "code-d’état", "message-d’état", "message-d’état-détaillé", et "erreur-d’accès-au-document".

7. paragraphe 3.1.6.1 – précise les codes d’états d’erreur et leurs relations avec les attributs d’opération.

8. paragraphe 3.1.6.3 –ajout de l’attribut d’opération FACULTATIF "message-d’état-détaillé (texte(MAX))" pour fournir des informations détaillées complémentaires sur une réponse.

9. paragraphes 3.1.6.4 et 3.2.2 – ajout de l’attribut d’opération FACULTATIF "erreur-d’accès-au-document (texte(MAX))" à utiliser avec les réponses à URI-d’impression et URI-d’envoi.

10. paragraphe 3.1.7 – ajout de ce nouveau paragraphe pour préciser le retour d’attributs non acceptés pour toutes les opérations, y compris le seul retour d’attributs qui étaient dans la demande. Le texte est déplacé du paragraphe 3.2.1.2 Attributs non acceptés.

11. paragraphes 3.1.7 et 4.1 – précisent le codage des valeurs "hors-bande" 'non-accepté' et 'inconnu'.

12. paragraphe 3.1.8 – précise que seul le paramètre numéro de version sera porté dans les versions majeure ou mineure futures du protocole.

13. paragraphe 3.1.8 - adoucit l’exigence d’augmenter le numéro de version majeure dans les futures versions du document Modèle et Sémantique.

14. paragraphe 3.1.9, et 3.2.5 – ajoute l’état 'traitement-en-cours' à la liste des états de tâche dans lesquels peut être une tâche après une opération Création-de-tâche.

15. paragraphe 3.1.9 – précise qu’une imprimante non déroulante PEUT accepter zéro ou plusieurs tâches à la suite pendant le traitement d’une tâche et contrôler leur écoulement. Les demandes de créations ultérieures sont rejetées avec l’état d’erreur 'erreur-serveur-occupé'.

16. paragraphe 3.2.1.1 – précise la validation de l’attribut d’opération "compression" et ses relations avec la validation de l’attribut "format-de-document" et le retour des attributs non acceptés.

17. paragraphes 3.2.1.1, 4.3.8, 13.1.4.16, et 13.1.4.17 – ajoutent les codes d’état 'erreur-client-compression-non-acceptée', 'erreur-client-erreur-de-compression' et les causes d’état de tâche 'compression-non-acceptée' et 'erreur-de-compression'.

18. paragraphes 3.2.1.1 et 4.3.8 – ajout des causes d’état de tâche 'format-de-document-non-accepté' et 'erreur-de-format-de-document'.

19. paragraphes 3.2.2, 4.3.8 et 13.1.4.19 – ajout du code d’état 'erreur-client-erreur-d’accès-au-document' et de la cause d’état de tâche 'erreur-d’accès-au-document'.

20. paragraphe 3.2.5.2 et 3.2.6.2 – précise que le groupe des attributs non acceptés NE DOIT PAS inclure des attributs non demandés dans la demande Obtenir-les-attributs-d’imprimante.

21. paragraphe 3.2.6 – précise que "limite" prend le pas sur "quelles-tâches" et "mes-tâches'.

22. paragraphe 3.2.6.2 – précise que Obtenir-les-tâches retourne 'réussite-ok' lorsqu’il n’y a aucune tâche à retourner.

23. paragraphes 3.2.7, 3.2.8, et 3.2.9 – ajout des opérations FACULTATIVES Pause-d’imprimante, Reprise-d’imprimante, et Purger-les-tâches.

24. paragraphe 3.3.1 – précise que l’autorisation exigée d’une demande Document-d’envoi DOIT être du même utilisateur que de la Création-de-tâche ou d’un opérateur.

25. paragraphe 3.3.1.1 – précise qu’un Document-d’envoi Création-de-tâche avec "dernier-document" = 'vrai' et pas de données n’est pas une erreur; c’est une tâche sans document.

26. paragraphes 3.3.5, 3.3.6, et 3.3.7 – ajout des opérations FACULTATIVES Mettre-la-tâche-en-garde, Libération-de-tâche, et Redémarrer-la-tâche. Précise l’opération Redémarrer-la-tâche de sorte que l’imprimante DOIT retourner chercher tous les documents passés par référence (URI-d’impression ou URI-d’envoi).

27. paragraphe 4.1 – précise que le codage des valeurs hors-bande est spécifié dans le document "Codage et Transport".

28. paragraphe 4.1 – précise que l’exigence que les clients NE DOIVENT PAS envoyer de valeurs "hors-bande" dans les demandes ne s’applique qu’aux opérations définies dans le présent document. Les autres opérations peuvent définir des valeurs "hors-bande" que les clients peuvent fournir.

29. paragraphes 4.1.1 et 4.1.2 – précise que les valeurs maximum 'texte' et 'nom' de 1023 et 255 sont pour les portions 'texteSansLangage' de la forme 'texteAvecLangage', de sorte que le nombre d’octets maximum pour les données réelles de texte et nom est le même pour les formes avec et sans langage; la partie 'langageNaturel' est dans l’ajout.

30. paragraphe 4.1.9 – précise que les valeurs 'typeDeSupportMime' peuvent inclure tout paramètre du registre IANA, et non seulement des paramètres de charset.

31. paragraphe 4.1.9.1 – précise que l’auto-détection de 'application/flux-d’octets' peut survenir au moment de la demande de création et/ou au moment du traitement de tâche/document.

32. paragraphe 4.1.9.1 – précise que l’auto-détection implique que l’imprimante examine un certain nombre d’octets des données documentaires en utilisant une méthode dépendant de la mise en œuvre.

33. paragraphe 4.1.14 - précise que la localisation de dateHeure par le client inclut la zone horaire.

34. paragraphe 4.2 - précise que xxx-pris-en-charge a de multiples mots-clé et/ou noms par l’ajout de parenthèses au tableau pour donner : (1setOf (type3 mot-clé | nom))

35. paragraphe 4.2.2 - ajoute la valeur de mot-clé 'indéfini' à l’attribut "mettre-la-tâche-en-garde-jusqu’à" à utiliser avec les opérations de création et les opérations Mettre-la-tâche-en-garde et Redémarrer-la-tâche.

36. paragraphe 4.2.6 - ajoute plus de valeurs d’énumération à l’attribut de gabarit de tâche "finitions".

37. paragraphe 4.2.6 - précise que la définition de paysage est une rotation de l’image par rapport au support.

38. paragraphe 4.3.7 - ajoute qu’un serveur de transmission qui ne peut obtenir aucun état de tâche PEUT retourner l’état de tâche comme 'terminé', pourvu qu’il retourne aussi la nouvelle cause d’état de tâche 'en-file-d’attente-dans-l’appareil'.

39. paragraphe 4.3.7.2 - ajoute le paragraphe Partition des états de tâche pour préciser les concepts de Rétention de tâche, Historique de tâche, et Retrait de tâche.

40. paragraphe 4.3.8 – ajoute la cause d’état de tâche 'données-de-tâche-insuffisantes' pour indiquer si des données suffisantes sont arrivées pour que commence le traitement du document.

41. paragraphe 4.3.8 - ajoute la cause d’état de tâche 'erreur-d’accès-au-document' pour indiquer une erreur d’accès quelconque.

42. paragraphe 4.3.8 – ajoute la cause d’état de tâche 'tâche-en-file-d’attente-de-marquage' pour indiquer si la tâche a terminé un traitement et est en attente du marquage.

43. paragraphe 4.3.8 - ajoute les causes d’état de tâche 'compression-non-acceptée' et 'erreur-de-compression' pour indiquer non prise en charge de la compression ou une erreur de traitement de compression après l’acceptation de la création.

44. paragraphe 4.3.8 - ajoute les causes d’état de tâche 'format-de-document-non-accepté' et 'erreur-de-format-de-document' pour indiquer une erreur de document non pris en charge ou de traitement de format de document après l’acceptation de la création.

45. paragraphe 4.3.8 - ajoute la cause d’état de tâche 'en-file-d’attente-dans-l’appareil' pour indiquer qu’une tâche a été transmise à un système d’impression ou appareil qui ne fournit aucun état de tâche.

46. paragraphe 4.3.10 - ajoute "message-détaillés-d’état-de-tâche (1setOf texte(MAX))" pour retourner des messages d’erreur détaillés.

47. paragraphe 4.3.11 - ajoute "erreurs-d’accès-au-document-de-tâche (1setOf texte(MAX))".

48. paragraphe 4.3.14.2 - précise que l’heure enregistrée est celle du premier traitement depuis l’opération de création ou l’opération Redémarrer-la-tâche.

49. paragraphes 4.3.14.2 et 4.3.14.3 - précisent, respectivement, que la valeur hors-bande 'pas-de-valeur' est retournée si la tâche n’a pas commencé le traitement ou ne l’a pas terminé.

50. paragraphe 4.3.14 - ajoute les attributs de description de tâche FACULTATIFS d’heure d’événement "date-heure-de-création", "date-heure-de-traitement", et "date-heure-de-fin".

51. paragraphe 4.4.3 - ajoute la valeur 'tls' à l’attribut "sécurité-d’uri-prise-en-charge".

52. paragraphe 4.4.3 – précise que "sécurité-d’uri-prise-en-charge" est orthogonal à Authentification du client de sorte que 'aucun' n’exclut pas l’Authentification du client.

53. paragraphe 4.4.11 – simplifie les descriptions de "état-d’imprimante" en le généralisant pour permettre à des appareils d’extrémité haute d’interpréter une ou plusieurs tâches tout en en marquant une autre. Indique que les "causes-d’état-d’imprimante" 'zone-de-déroulement-pleine' et 'arrêt-partiel' peuvent être utilisées pour fournir des informations d’état complémentaires.

54. paragraphe 4.4.12 - ajoute la valeur de mot-clé 'passage-en-pause' à l’attribut "causes-d’état-d’imprimante" à utiliser avec l’opération Pause-d’imprimante.

55. paragraphe 4.4.12 – remplace le mot-clé dupliqué 'produit-de-marquage-bas' par le mot-clé manquant 'toner-vide' pour l’attribut "causes-d’état-d’imprimante". (Cette correction a été faite avant la publication de la RFC 2566).

56. paragraphe 4.4.12 – précise la "cause-d’état-d’imprimante" 'zone-de-déroulement-pleine' pour inclure les imprimantes sans déroulement et indiquer lorsqu’elles peuvent ou non accepter une autre tâche.

57. paragraphe 4.4.15 - ajoute des valeurs d’énumération à l’attribut "opérations-prises-en-charge" pour les nouvelles opérations. Précise que les valeurs de cet attribut sont codées comme toute enum, à savoir des valeurs de 32 bits.

58. paragraphe 4.4.30 - précise que les valeurs dateHeure de "heure-courante-d’imprimante" sont sur une base "au mieux". Si une date et heure appropriée ne peut être obtenue, la mise en œuvre retourne la valeur hors-bande 'pas-de-valeur'. Précise aussi que la zone horaire PEUT NE PAS être celle qu’utilisent les gens proches de l’appareil et que le client DEVRAIT afficher les attributs dateHeure dans le temps local de l’utilisateur.

59. paragraphe s 4.4.36 et 4.4.37 - ajoute les attributs de description d’opération FACULTATIFS "pages-par-minute" et "pages-couleur-par-minute".

60. paragraphe 5.1 - précise que les exigences de conformité du client s’appliquent aux clients contrôlés par un utilisateur final et aux clients dans les serveurs.

61. paragraphe 5.1 - précise que toute réponse PEUT contenir des groupes d’attributs, des attributs, des syntaxes d’attribut, ou des valeurs d’attribut supplémentaires.

62. paragraphe 5.1 - précise qu’un client DEVRAIT faire de son mieux pour empêcher qu’un canal soit fermé par une couche inférieure lorsque les flux du canal sont contrôlés par l’imprimante IPP.

63. paragraphe 5.2 - précise que les exigences d’objet IPP s’appliquent aux objets incorporés dans des appareils ou qui font partie de serveurs.

64. paragraphe 5.2.2 - précise que les objets IPP PEUVENT retourner des réponses d’opération qui contiennent des groupes d’attributs, noms d’attribut, syntaxes d’attribut, valeurs d’attribut, et codes d’état qui sont des extensions à la présente norme.

65. Section 6 – change la terminologie de "extensions privées" pour celle de "extensions du fabricant" et indique qu’elles sont enregistrées auprès de l’IANA avec les extensions normalisées de l’IETF.

66. paragraphe 6.7 – insère ce paragraphe sur l’enregistrement des valeurs d’attribut hors-bande auprès de l’IANA comme extensions.

67. paragraphe 8.3 – précise les utilisateurs des URI pour chaque mécanisme d’authentification du client.

68. paragraphe 8.5 - ajoute la discussion de la sécurité sur les nouvelles opérations d’opérateur/administrateur.

69. paragraphe 13.1.4.16 - ajoute erreur-client-compression-non-acceptée (0x040F)

71. paragraphe 13.1.4.18 - ajoute erreur-client-erreur-format-de-document (0x0411)

72. paragraphe 13.1.4.19 - ajoute erreur-client-erreur-d’accès-au-document (0x0412)

73. paragraphe 13.1.5.10 - ajoute erreur-serveur-documents-multiples-non-acceptés (0x0509)

74. section 14 - ajoute 'a-white', 'b-white', 'c-white', 'd-white', et 'e-white' et précise que les valeurs 'a', 'b', 'c', 'd', et 'e' existantes sont des valeurs de taille. Ajout des tailles d’ingénierie américaine, japonaise, et européenne, rempli les noms de support -transparent et - translucide et les tirages pour les tailles de coupe synchronisée.

75. section 16 – adoucit la RECOMMANDATION pour les attributs d’imprimante IPP dans un schéma d’annuaire de façon qu’ils puissent avoir des équivalents.

76. section 16 - ajoute les attributs d’imprimante FACULTATIFS "pages-par-minute" et "pages-couleur-par-minute" au schéma d’annuaire.

77. section 16 - ajoute l’attribut d’imprimante FACULTATIF "tâches-multi-document-prises-en-charge" au schéma d’annuaire.

78. section 16 - ajoute les attributs RECOMMANDÉS "authentification-d’uri-prise-en-charge", "versions-ipp-prises-en-charge", et "compression-prise-en-charge" au schéma d’annuaire.

Les changements de sémantique et/ou conformité ont été incorporés dans le présent document :

1. paragraphe 3.1.6.3 – permet à une imprimante de localiser l’attribut de réponse d’opération "message-d’état-détaillé", mais indiqué d’une façon qui peut rendre obscure la signification technique de tels messages.

2. paragraphes 3.1.8, 5.2.4, et 13.1.5.4 – les clients et objets IPP DOIVENT prendre en charge la version 1.1 des exigences de conformité. Il est recommandé qu’ils inter opèrent avec 1.0. Précise aussi que les imprimantes IPP DOIVENT accepter les demandes '1.1'. Il est recommandé qu’elles acceptent aussi les demandes '1.x'.

3. paragraphes 3.2.1.1 et 4.4.32 – changement de l’opération "compression" et de l’attribut de description d’opération "compression-prise-en-charge" de FACULTATIF à EXIGÉ.

4. paragraphes 3.2.1.2 et 4.3.8 – changement de "causes-d’état-de-tâche" de RECOMMENDÉ à EXIGÉ, de sorte que "causes-d’état-de-tâche" DOIT être retourné dans les réponses d’opérations de création.

5. paragraphes 3.2.4, 3.3.1, 4.4.16, et 16 – changement de Création-de-tâche/Document-d’envoi de sorte qu’ils PEUVENT être mis en œuvre alors que seules sont prises en charge des tâches d’un seul document. Ajout de l’attribut de description d’opération booléen "tâches-multi-document-prises-en-charge" pour indiquer si Création-de-tâche/Document-d’envoi prend en charge des tâches multi-document ou non. Ajout au schéma d’annuaire.

6. paragraphe 4.1.9 – suppression de 'texte/clair; charset=iso-10646-ucs-2', car le binaire n’est pas légal avec le type 'texte'.

7. paragraphe 4.1.9.1 - ajoute la RECOMMENDATION qu’une imprimante indique par impression sur la feuille de démarrage de tâche de la tâche que l’auto-détection est survenue et quel format de document a été auto-détecté.

8. paragraphe 4.2.4 – indique que l’attribut de gabarit de tâche "traitement-de-document-multiple" DOIT être pris en charge avec au moins une valeur si l’imprimante prend en charge plusieurs documents par tâche.

9. paragraphe 4.3.7.2 – indique que la cause d’état de tâche 'tâche-redémarrable' DEVRAIT être prise en charge si l’opération Redémarrer-la-tâche est prise en charge.

10. paragraphe 4.3.8 – changement de "causes-d’état-de-tâche" de RECOMMENDÉ à EXIGÉ.

11. paragraphe 4.3.8 – précise la conformité des valeurs de l’attribut "causes-d’état-de-tâche" en copiant les exigences de conformité des autres sections du document de sorte qu’il soit clair à la lecture de la définition de "causes-d’état-de-tâche" quelles valeurs DOIVENT ou DEVRAIENT être prises en charge. Les valeurs 'aucun', 'compression-non-acceptée', et 'format-de-document-non-accepté' DOIVENT être prises en charge. L’attribut 'mettre-la-tâche-en-garde-jusqu’à-spécifié' DEVRAIT être spécifié si le gabarit de tâche "mettre-la-tâche-en-garde-jusqu’à" est pris en charge. Les valeurs suivantes DEVRAIENT être prises en charge : 'tâche-annulée-par-l’usager', 'avorté-par-le-système', et 'tâche-bien-terminée'. 'tâche-annulée-par-opérateur' DEVRAIT être pris en charge si la mise en œuvre permet d’annuler par un autre que le propriétaire de la tâche. 'tâche-annulée-à-l’appareil' DEVRAIT être pris en charge si l’appareil prend en charge l’annulation de tâches à la console. 'tâche-terminée-avec-avertissements' DEVRAIT être pris en charge, si la mise en œuvre détecte les avertissements. 'tâche-terminée-avec-erreurs' DEVRAIT être pris en charge si la mise en œuvre détecte les erreurs. 'tâche-redémarrable' DEVRAIT être pris en charge si l’opération Redémarrer-la-tâche est prise en charge.

12. paragraphe 4.3.10 – permet à une imprimante de localiser l’attribut de description de tâche "message-d’état-détaillé-detâche", mais indique qu’une telle localisation peut rendre obscure la singification technique de tels messages.

13. paragraphe 4.3.14 - changement des attributs de description de tâche d’heure d’événement "heure-de-création", "heure-de-traitement", et "heure-de-fin" de FACULTATIF à EXIGÉ.

14. paragraphe 4.3.14.4 - ajoute l’attribut de description de tâche EXIGÉ "heure-de-mise-sous-tension-de-tâche-d’imprimante (entier(1:MAX))" comme un alias pour "heure-de-mise-sous-tension-d’imprimante" pour réduire le nombre des opérations d’obtention des heures de tâche.

15. paragraphe 4.4.2 - ajoute l’attribut de description d’opération EXIGÉ "authentification-d’uri-prise-en-charge (1setOf type2 mot-clé)" pour décrire l’authentification du client utilisée par chaque URI d’imprimante.

16. paragraphe 4.4.12 – changement de l’attribut de description d’opération "causes-d’état-d’imprimante" de FACULTATIF à EXIGÉ.

17. paragraphe 4.4.12 - changement de la valeur 'pause' de "causes-d’état-d’imprimante" en DOIT si l’opération Pause-d’imprimante est prise en charge.

18. paragraphe 4.4.14 - ajoute l’attribut de description d’opération EXIGÉ "versions-ipp-prises-en-charge (1setOf mot-clé)", car les imprimantes IPP/1.1 n’ont pas à prendre en charge les exigences de conformité de la version '1.0' . Le paragraphe 4.4.16 - ajoute l’attribut de description d’opération "tâches-multi-document-prises-en-charge (booléen)" de sorte qu’un client puisse dire si une imprimante qui prend en charge Création-de-tâche/Document-d’envoi prend en charge ou non les tâches multi-document. Cet attribut est EXIGÉ si l’opération Création-de-tâche est prise en charge.

19. paragraphe 4.4.24 – changement de l’attribut de description d’opération "compte-de-tâches-en-file-d’attente" de RECOMMENDÉ à EXIGÉ.

20. paragraphe 4.4.32 - changement de l’attribut de description d’opération "compression-prise-en-charge (1setOf type3 mot-clé)" de FACULTATIF à EXIGÉ.

21. paragraphe 5.1 – changement des exigences de sécurité du client de SSL3 non normalisé RECOMMENDÉ à DOIT prendre en charge l’authentification du client comme défini dans le document IPP/1.1 Codage et Transport [RFC2910]. Un client DEVRAIT prendre en charge la confidentialité de fonctionnement et l’authentification du serveur comme défini dans le document IPP/1.1 Codage et Transport [RFC2910].

22. paragraphe 5.2.7 – changement des exigences de sécurité de l’objet IPP de SSL3 non normalisé de FACULTATIF à DEVRAIT contenir la prise en charge de l’authentification du client comme défini dans le document IPP/1.1 Codage et Transport [RFC2910]. Une mise en œuvre d’imprimante PEUT permettre à un administrateur de configurer l’imprimante de telle sorte que tous, certains, ou aucun des utilisateurs, soient authentifiés. Une mise en œuvre d’imprimante IPP DEVRAIT contenir la prise en charge de la confidentialité de fonctionnement et l’authentification du serveur comme défini dans le document IPP/1.1 Codage et Transport [RFC2910]. Une mise en œuvre d’imprimante PEUT permettre à un administrateur de configurer le degré de prise en charge de la confidentialité de fonctionnement et l’authentification du serveur. La sécurité NE DOIT PAS être compromise lorsque le client fournit un numéro de version inférieur dans une demande.

23. section 14 (Appendice C) : Correction typographique, changement du mot-clé 'iso-10-white' en 'iso-a10-white'.

Voir aussi dans le document "IPP/1.1 Codage et Transport" [RFC2910] les différences entre IPP/1.0 [RFC2565] et IPP/1.1 [RFC2910].

18. Déclaration de Copyright

Le présent document et ses traductions peuvent être copiés et fournis à des tiers, et les travaux dérivés qui le commentent ou l’expliquent ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou en partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus sur de telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, ni en retirant la déclaration de copyright ou les références à la Société Internet ou à d’autres organisations Internet, excepté en tant que de besoin pour le développement des normes Internet auquel cas les procédures de protection des droits de propriété intellectuelle définies dans le traitement des normes de l’Internet doivent être suivies, ou autant qu’il est nécessaire pour la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ni ses successeurs ou ayant-droits.

Le présent document et les informations qu’il contient sont fournies sur une base "EN L’ÉTAT" et 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.

Le financement de la fonction d’édition des RFC est actuellement fourni par Internet Society.

Attribut de tâche	Imprimante : Attribut de valeur par défaut	Imprimante : Attribut de valeurs acceptées
priorité-de-tâche (entier 1:100)	priorité-de-tâche-par-défaut (entier 1:100)	priorité-de-tâche-prise-en-charge (entier 1:100)
mettre-la-tâche-en-garde-jusqu’à (type3 mot-clé \| nom)	mettre-la-tâche-en-garde-jusqu’à-defaut (type3 mot-clé \| nom)	mettre-la-tâche-en-garde-jusqu’à-pris-en-charge (1setOf \|(type3 mot-clé \| nom)
feuilles-de-tâche (type3 mot-clé nom)	feuilles-de-tâche-par-défaut (type3 mot-clé \|nom)	feuilles-de-tâche-prises-en-charge (1setOf type3 mot-clé \| nom))
traitement-de-document-multiple (type2 mot-clé)	traitement-par-défaut-de-document-multiple (type2 mot-clé)	traitement-de-document-multiple-pris-en-charge (1setOf type2 mot-clé)
copies (entier (1:MAX))	copies-par-défaut (entier (1:MAX))	copies-prises-en-charge (gammeD’Entier (1:MAX))
Finitions (1setOf type2 enum)	finitions-par-défaut (1setOf type2 enum)	finitions-prises-en-charge (1setOf type2 enum)
gamme-de-pages (1setOf gammeD’Entier(1:MAX))	Aucun	gamme-de-pages-prise-en-charge (booléen)
côtés (type2 mot-clé)	côtés-par-défaut (type2 mot-clé)	côtés-pris-en-charge (1setOf type2 mot-clé)
nombre-max (entier (1:MAX))	nombre-max-par-défaut (entier (1:MAX))	nombre-max-pris-en-charge (1setOf (entier(1:MAX) \| gammeD’Entier\| (1:MAX)))
orientation-demandée (type2 enum)	orientation-demandée-par-défaut (type2 enum)	orientation-demandée-prise-en-charge (1setOf type2 enum)
support (type3 mot-clé \| nom)	support-par-défaut (type3 mot-clé \| nom)	support-pris-en-charge (1setOf (type3 mot-clé \| nom)) support-prêt (1setOf (type3 mot-clé \| nom))
résolution-d’imprimante (résolution)	résolution-d’imprimante-par-défaut (résolution)	résolution-d’imprimante-prise-en-charge (1setOf resolution)
qualité-d’imprimante (type2 enum)	qualité-d’imprimante-par-défaut (type2 enum)	qualité-d’imprimante-prise-en-charge (1setOf type2 enum)

Valeur	Nom symbolique et description
'3'	'aucun' : n’effectuer aucune finition.
'4'	'agrafe' : Agrafer le ou les documents avec une ou plusieurs agrafes. Le nombre exact et le placement des agrafes sont définis par le site.
'5'	'percer' : Cette valeur indique qu’il faut des trous dans le document fini. Le nombre exact et le placement des trous sont définis par le site. La spécification de percement PEUT être satisfaite (d’une manière spécifique du site et de la mise en œuvre) soit par forage/perforage, soit en substituant un support pré-percé.
'6'	'couverture' : Cette valeur est spécifiée lorsque on souhaite choisir une couverture non imprimée (ou pré-imprimée) pour le document. Cela ne se substitue pas à la spécification d’une couverture imprimée (sur le stock de support de couvertures) par le document lui-même.
'7'	'reliure' : Cette valeur indique qu’une reliure sera appliquée au document ; le type et le placement de la reliure sont définis par le site.
8'	'brochure-médiane' : Relier le ou les documents avec une ou plusieurs agrafes (broches métalliques) le long de la pliure médiane. Le nombre exact et le placement des agrafes et de la pliure médiane sont définis par la mise en œuvre et/ou le site.
'9'	'brochure-latérale' : Relier le ou les documents avec une ou plusieurs agrafes (broches métalliques) le long d’un côté. Le nombre exact et le placement des agrafes sont définis par la mise en œuvre et/ou le site.
'10'-'19'	Réservé pour des valeurs d’énumération de finitions génériques futures.

'20'	'agrafe-haut-gauche' : Relier le ou les documents avec une ou plusieurs agrafes dans le coin haut gauche.
'21'	'agrafe-bas-gauche' : Relier le ou les documents avec une ou plusieurs agrafes dans le coin bas gauche.
'22'	'agrafe-haut-droite' : Relier le ou les documents avec une ou plusieurs agrafes dans le coin haut droite.
'23'	'agrafe-bas-droite' : Relier le ou les documents avec une ou plusieurs agrafes dans le coin bas droite.
'24	'broche-bord-gauche' : Relier le ou les documents avec une ou plusieurs agrafes (broches métalliques) le long du bord gauche. Le nombre exact et le placement des agrafes sont définis par la mise en œuvre et/ou le site.
'25'	'broche-bord-haut' : Relier le ou les documents avec une ou plusieurs agrafes (broches métalliques) le long du bord haut. Le nombre exact et le placement des agrafes sont définis par la mise en œuvre et/ou le site.
'26'	'broche-bord-droite': Relier le ou les documents avec une ou plusieurs agrafes (broches métalliques) le long du bord droit. Le nombre exact et le placement des agrafes sont définis par la mise en œuvre et/ou le site.
'27'	'broche-bord-bas': Relier le ou les documents avec une ou plusieurs agrafes (broches métalliques) le long du bord bas. Le nombre exact et le placement des agrafes sont définis par la mise en œuvre et/ou le site.
'28'	'deux-agrafes-gauche' : Relier le ou les documents avec deux agrafes (broches métalliques) le long du bord gauche en supposant un document portrait (voir ci-dessus).
'29'	'deux-agrafes-haut' : Relier le ou les documents avec deux agrafes (broches métalliques) le long du bord haut en supposant un document portrait (voir ci-dessus).
'30'	'deux-agrafes-droite' : Relier le ou les documents avec deux agrafes (broches métalliques) le long du bord droit en supposant un document portrait (voir ci-dessus).
'31'	'deux-agrafes-bas' : Relier le ou les documents avec deux agrafes (broches métalliques) le long du bord bas en supposant un document portrait (voir ci-dessus).

Valeur	Description
'1'	L’imprimante DOIT placer une page du flux d’impression sur un seul côté d’une instance du support choisi (PEUT ajouter une translation, rotation ou changement d’échelle).
'2'	L’imprimante DOIT placer deux pages du flux d’impression sur un seul côté d’une instance du support choisi (PEUT ajouter une translation, rotation ou changement d’échelle).
'4'	L’imprimante DOIT placer quatre pages du flux d’impression sur un seul côté d’une instance du support choisi (PEUT ajouter une translation, rotation ou changement d’échelle).

Valeur	Nom symbolique et description
'3'	'portrait' : Le contenu sera affiché le long du bord court du support.
'4'	'paysage' : Le contenu sera affiché le long du bord long du support. Paysage est défini comme étant une rotation de la page du flux d’impression pour qu’elle soit tournée de + 90 degrés par rapport au support (c’est-à-dire dans le sens trigonométrique) par rapport à l’orientation portrait. Note : La direction + 90 a été choisie parce que la finition simple sur le long bord est sur le même bord en portrait ou en paysage.
'5'	'paysage-inversé' : Le contenu sera affiché le long du bord long du support. Paysage-inversé est défini comme une rotation de la page de flux d’impression tournée de – 90 degrés par rapport au support (c’est-à-dire dans le sens des aiguilles d’une montre) par rapport à l’orientation portrait. Note : la valeur 'paysage-inversé' a été ajoutée parce que certaines applications font tourner le paysage de – 90 degrés par rapport au portrait, plutôt que + 90 degrés.
'6'	'portrait-inversé' : Le contenu sera affiché le long du bord court du support. Portrait-inversé est défini comme étant une rotation de la page de flux d’impression pour qu’elle soit tournée de 180 degrés par rapport au support par rapport à l’orientation portrait. Note : la valeur 'portrait-inversé' a été ajoutée pour être utilisée avec l’attribut "finitions" dans les cas où le bord opposé est souhaité pour les finitions d’un document en portrait sur des appareils à finitions simples qui n’ont qu’une seule position de finition. Et donc un document portrait 'texte'/clair' peut être agrafé "sur la droite" par un appareil de finition simple en utilisation normale avec certains langages du Moyen Orient comme l’hébreu.

Paramètre/attribut	Code d’état
numéro-de-version	erreur-serveur-version-non-acceptée
id-d’opération	erreur-serveur-opération-non-acceptée
charset-des-attributs	erreur-client-charset-non-accepté
compression	erreur-client-compression-non-acceptée
format-de-document	erreur-client-format-de-document-non-accepté
uri-de-document	erreur-client-schéma-d’uri-non-accepté

"état-d’imprimante" en cours	Nouvel "état-d’imprimante"	"causes-d’état-d’imprimante"	Code d’état et action de réponse de l’imprimante IPP :
'repos'	'arrêté'	'pause'	'réussite-ok'
'traitement-en-cours'	'traitement-en-cours'	'passage-en-pause'	OPTION 1 : 'réussite-ok' ; plus tard, quand toute sortie est arrêtée, l’"état-d’imprimante" devient 'arrêté', et la valeur 'pause' remplace la valeur 'passage-en-pause' dans l’attribut "causes-d’état-d’imprimante"
'traitement-en-cours'	'arrêté'	'pause'	OPTION 2 : 'réussite-ok'; toute sortie d’appareil s’arrête immédiatement
'arrêté'	'arrêté'	'pause'	'réussite-ok'

"état-de-tâche" en cours	Nouvel "état-de-tâche"	Code d’état et action en réponse de l’objet IPP :
'en-instance'	'annulé'	'réussite-ok'
'gardé-en-instance'	'annulé' 'réussite-ok'
'traitement-en-cours'	'annulé'	'réussite-ok'
'traitement-en-cours'	'traitement-en-cours'	'réussite-ok' (voir la règle 1)
'traitement-en-cours'	'traitement-en-cours'	'erreur-client-impossible' (voir la règle 2)
'traitement-arrêté'	'annulé'	'réussite-ok'
'traitement-arrêté'	'traitement-arrêté'	'réussite-ok' (voir la règle 1)
'traitement-arrêté'	'traitement-arrêté'	'erreur-client-impossible' (voir la règle 2)
'terminé'	'terminé	'erreur-client-impossible'
'annulé'	'annulé'	'erreur-client-impossible'
'avorté'	'avorté'	'erreur-client-impossible'

Valeur	Nom symbolique et description
'3'	'brouillon' : la plus faible qualité disponible sur l’imprimante
'4'	'normale' : la qualité normale ou intermédiaire de l’imprimante
'5	'supérieure' : la meilleure qualité disponible sur l’imprimante

Attribut	Syntaxe	EXIGÉ ?
uri-de-tâche	Uri	EXIGÉ
id-de-tâche	entier(1:MAX)	EXIGÉ\|
tâche-d’uri-d’imprimante	Uri	EXIGÉ
plus-d’info-de-tâche	Uri
nom-de-tâche	nom (MAX)	EXIGÉ
nom-d’utilisateur-de-tâche-d’origine	nom (MAX)	EXIGÉ
état-de-tâche	type1 enum	EXIGÉ
causes-d’état-de-tâche	1setOf type2 mot-clé	EXIGÉ
message-d’état-de-tâche	texte (MAX)
messages-d’état-détaillés-de-tâche	1setOf texte (MAX)
erreurs-d’accès-au-document-de-tâche	1setOf texte (MAX)
nombre-de-documents	entier (0:MAX)
appareil-de-sortie-alloué	nom (127)
heure-de-création	entier (MIN:MAX)	EXIGÉ
heure-de-traitement	entier (MIN:MAX)	EXIGÉ
heure-de-fin	entier (MIN:MAX)	EXIGÉ
heure-de-tâche-d’imprimante	entier (1:MAX)	EXIGÉ
date-et-heure-de-création	dateHeure
date-et-heure-de-traitement	dateHeure
date-et-heure-de-fin	dateHeure
nombre-de-tâches-prévues	entier (0:MAX)
message-de-tâche-de-l’opérateur	texte (127)
k-octets-de-tâche	entier (0:MAX)
tâches-d’impression	entier (0:MAX)
feuilles-de-support-de-tâche	entier (0:MAX)
k-octets-de-tâche-traités	entier (0:MAX)
tâches-d’impression-terminées	entier (0:MAX)
feuilles-de-support-de-tâche-terminées	entier (0:MAX)
charset-des-attributs	charset	EXIGÉ
langage-naturel-des-attributs	langageNaturel	EXIGÉ

Valeurs	Nom symbolique et description
'3'	'en-instance' : La tâche est candidate à commencer le traitement, mais n’est pas déjà en cours de traitement.
'4'	'gardé-en-instance' : La tâche n’est pas candidate au traitement pour une raison quelconque mais retournera à l’état 'en-instance' dès que les causes auront disparu. L’attribut "causes-d’état-de-tâche" de tâche DOIT indiquer pourquoi la tâche n’est plus candidate au traitement.
'5'	'traitement-en-cours' : Un ou plusieurs de : 1. la tâche utilise, ou essaye d’utiliser, des traitements purement logiciels qui analysent, créent ou interprètent un PDL, etc., 2. la tâche utilise, ou essaye d’utiliser, un ou plusieurs matériels qui interprètent un PDL, font des marques sur un support, et/ou effectuent des finitions, telles que l’agrafage, etc., 3. l’objet imprimante a fait que la tâche est prête pour l’impression, mais l’appareil de sortie n’est pas en train de l’imprimer, soit parce que la tâche n’a pas atteint l’appareil de sortie, soit parce que la tâche est en file d’attente sur l’appareil de sortie ou autre dévidoir, attendant que l’appareil de sortie l’imprime. Lorsque la tâche est dans l’état 'traitement-en-cours', l’état de tâche entier inclut l’état détaillé représenté dans les attributs "état-d’imprimante", "causes-d’état-d’imprimante", et "message-d’état-d’imprimante" de l’objet imprimante. Les mises en œuvre PEUVENT, bien qu’elles PEUVENT NE PAS, inclure des valeurs supplémentaires dans l’attribut "causes-d’état-de-tâche" de la tâche pour indiquer la progression de la tâche, telles que l’appareil de sortie est en train de faire des marques sur le papier et/ou la valeur 'traitement-en-cours-au-point-d’arrêt' pour indiquer que l’objet IPP est dans un processus d’annulation ou d’avortement de la tâche. La plupart des mises en œuvre ne se soucient pas de la nuance.
'6'	'traitement-arrêté' : La tâche s’est arrêtée en cours de traitement pour un certain nombre de raisons et va retourner à l’état 'traitement-en-cours' aussitôt que ces raisons auront disparu. L’attribut "causes-d’état-de-tâche" de la tâche PEUT indiquer pourquoi la tâche a arrêté le traitement. Par exemple, si l’appareil de sortie est arrêté, la valeur 'imprimante-arrêtée' PEUT être incluse dans l’attribut "causes-d’état-de-tâche" de la tâche. Note : lorsqu’un appareil de sortie est arrêté, il indique habituellement sa condition dans une forme lisible pour l’homme au niveau de l’appareil. Un client peut obtenir à distance un état d’appareil plus complet en interrogeant les attributs de l’objet imprimante "état-d’imprimante", "causes-d’état-d’imprimante" et "message-d’état-d’imprimante".
'7'	'annulé' : La tâche a été annulée par une opération Annuler-la-tâche et l’objet imprimante a terminé l’annulation de la tâche et tous les attributs d’état de tâche ont atteint leurs valeurs finales pour la tâche. Tandis que l’objet imprimante annule la tâche, la tâche reste dans son état en cours, mais l’attribut "causes-d’état-de-tâche" de la tâche DEVRAIT contenir la valeur 'traitement-au-point-d’arrêt' et une des valeurs 'annulé-par-l’usager', 'annulé-par-l’opérateur', ou 'annulé-à-l’appareil'. Lorsque la tâche passe à l’état 'annulé', la valeur 'traitement-au-point-d’arrêt', si elle est présente, DOIT être retirée, mais le 'annulé-par-xxx', s’il est présent, DOIT rester.
'8'	'avorté' : La tâche a été avortée par le système, normalement pendant que la tâche était dans l’état 'traitement-en-cours' ou 'traitement-arrêté' et l’imprimante a terminé d’avorter la tâche et tous les attributs d’état de tâche ont atteint leurs valeurs finales pour la tâche. Tandis que l’objet imprimante avorte la tâche, la tâche reste dans son état en cours, mais l’attribut "causes-d’état-de-tâche" de la tâche DEVRAIT contenir les valeurs 'traitement-au-point-d’arrêt' et 'avorté-par-le-système'. Lorsque la tâche passe à l’état 'avorté', la valeur 'traitement-au-point-d’arrêt', si elle est présente, DOIT être retirée, mais la valeur 'avorté-par-le-système', si elle est présente, DOIT rester.
'9'	'terminé' : La tâche a terminé avec succès ou avec des avertissements ou erreurs après le traitement et toutes les feuilles de support de la tâche ont été bien empilées dans le ou les bacs de sortie appropriés et tous les attributs d’état de tâche ont atteint leurs valeurs finales pour la tâche. L’attribut "causes-d’état-de-tâche" de la tâche DEVRAIT contenir une des valeurs 'terminé-avec-succès', 'terminé-avec-avertissements', ou 'terminé-avec-erreurs'.

Valeur	Nom symbolique et description
'3'	'repos' : Indique que les nouvelles tâches peuvent commencer le traitement sans attendre.
'4'	'traitement-en-cours' : Indique que les tâches sont en cours de traitement ; de nouvelles tâches devront attendre avant traitement.
'5'	'arrêté' : Indique qu’aucune tâche ne peut être traitée et une intervention est nécessaire.

Valeur	Nom d’opération
0x0000	réservé, non utilisé
0x0001	Réservé, non utilisé
0x0002	tâche-d’impression
0x0003	URI-d’impression
0x0004	valider-la-tâche
0x0005	création-de-tâche
0x0006	document-d’envoi
0x0007	URI-d’envoi
0x0008	annuler-la-tâche
0x0009	obtenir-les-attributs-de-tâche
0x000A	obtenir-les-tâches
0x000B	obtenir-les-attributs-d’imprimante
0x000C	mettre-la-tâche-en-garde
0x000D	libération-de-tâche
0x000E	redémarrer-la-tâche
0x000F	réservé pour une opération future
0x0010	pause-d’imprimante
0x0011	reprise-d’imprimante
0x0012	purger-les-tâches
0x0013-0x3FFF	réservé pour de futures opérations normalisées de l’IETF (voir au paragraphe 6.4)
0x4000-0x8FFF	réservé pour des extensions du fabricant (voir au paragraphe 6.4)

Attributs	Source
Attributs d’opération :
nom-de-tâche (nom)	client
nom-du-document (nom)	client
nom-de-l’utilisateur-demandeur (nom)	client
message-d’état (texte)	objet Tâche ou Imprimante
message-d’état-détaillé (texte)	objet Tâche ou Imprimante - voir la règle 1
erreur-d’accès-au-document (texte)	objet Tâche ou Imprimante - voir la règle 1
Attributs de gabarit de tâche :
mettre-la-tâche-en-garde-jusqu’à (mot-clé \| nom)	client ou configuré par l’administrateur
mettre-la-tâche-en-garde-jusqu’à-défaut (mot-clé \| nom)	client ou configuré par l’administrateur
mettre-la-tâche-en-garde-jusqu’à-prise-en-charge (mot-clé \| nom)	client ou configuré par l’administrateur
feuilles-de-tâche (mot-clé \| nom)	client ou configuré par l’administrateur
feuilles-de-tâche-par-défaut (mot-clé \| nom)	client ou configuré par l’administrateur
feuilles-de-tâche-prises-en-charge (mot-clé \| nom)	client ou configuré par l’administrateur
support (mot-clé \| nom)	client ou configuré par l’administrateur
support-par-défaut (mot-clé \| nom)	client ou configuré par l’administrateur
support-pris en charge (mot-clé \| nom)	client ou configuré par l’administrateur
support-prêt (mot-clé \| nom)	client ou configuré par l’administrateur
Attributs de description de tâche :
nom-de-tâche (nom)	client ou objet Imprimante
nom-d’utilisateur-d’origine-de-tâche (nom)	objet Imprimante
message-d’état-de-tâche (texte)	objet Tâche ou Imprimante
appareil-de-sortie-alloué (nom(127))	administrateur
message-de-tâche-de-l’opérateur (texte(127))	opérateur
message-d’état-de-tâche-détaillé (1setOf texte)	objet Tâche ou Imprimante - voir la règle 1
erreurs-d’accès-au-document-de-tâche (1setOf texte)	objet Tâche ou Imprimante - voir la règle 1
Attributs de description d’imprimante :
nom-d’imprimante (nom(127))	administrateur
localisation-d’imprimante (texte(127))	administrateur
info-d’imprimante (texte(127))	administrateur
marque-et-modèle-d’imprimante (texte(127))	administrateur ou fabricant
message-d’état-d’imprimante (texte)	objet Imprimante
message-d’imprimante-de-l’opérateur (texte(127))	opérateur

Scott A. Isaacson, Editor	Tom Hastings	Robert Herriot
Novell, Inc.	Xerox Corporation	Xerox Corp.
122 E 1700 S	737 Hawaii St. ESAE 231	3400 Hill View Ave, Building 1
Provo, UT 84606	El Segundo, CA 90245	Palo Alto, CA 94304
tél : 801-861-7366	tél : 310-333-6413	tél : 650-813-7696
fax: 801-861-2517	fax : 310-333-5514	fax : 650-813-6860
mél : sisaacson@novell.com	mél : hastings@cp10.es.xerox.com	mél : robert.herriot@pahv.xerox.com

Roger deBry	Patrick Powell
Utah Valley State College	Astart Technologies
	9475 Chesapeake Dr., Suite D
Orem, UT 84058	San Diego, CA 95123
tél : (801) 222-8000	tél : (619) 874-6543
	fax : (619) 279-8424
mél : debryro@uvsc.edu	mél : papowell@astart.com

Chuck Adams – Tektronix	Shivaun Albright - HP
Stefan Andersson – Axis	Jeff Barnett – IBM
Ron Bergman - Hitachi Koki Imaging	Dennis Carney - IBM Systems
Keith Carter – IBM	Angelo Caruso - Xerox
Rajesh Chawla - TR Computing	Nancy Chen – Okidata Solutions
Josh Cohen – Microsoft	Jeff Copeland - QMS
Andy Davidson – Tektronix	Roger deBry – IBM
Maulik Desai – Auco	Mabry Dozier - QMS
Lee Farrell - Canon Information	Satoshi Fujitami - Ricoh Systems
Steve Gebert – IBM	Sue Gleeson - Digital
Charles Gordon – Osicom	Brian Grimshaw - Apple
Jerry Hadsell – IBM	Richard Hart - Digital
Tom Hastings – Xerox	Henrik Holst - I-data
Stephen Holmstead	Zhi-Hong Huang - Zenographics
Scott Isaacson – Novell	Babek Jahromi - Microsoft
Swen Johnson – Xerox	David Kellerman - Northlake Software
Robert Kline – TrueSpectra	Charles Kong - Panasonic
Carl Kugler – IBM	Dave Kuntz - Hewlett-Packard
Takami Kurono – Brautre	Rick Landau - Digital
Scott Lawrence - Agranot Systems	Greg LeClair - Epson
Dwight Lewis – Lexmark	Harry Lewis – IBM
Tony Liao - Vivid Image	Roy Lomicka - Digital
Pete Loya – HP	Ray Lutz - Cognisys
Mike MacKay - Novell, Inc.	David Manchala - Xerox
Carl-Uno Manros – Xerox	Jay Martin - Underscore
Stan McConnell – Xerox	Larry Masinter - Xerox
Sandra Matts - Hewlett Packard	Peter Michalek - Shinesoft
Ira McDonald - High North Inc.	Mike Moldovan – G3 Nova
Tetsuya Morita – Ricoh	Yuichi Niwa - Ricoh
Pat Nogay – IBM	Ron Norton - Printronics
Hugo Parra, Novell	Bob Pentecost - Hewlett-Packard
Patrick Powell – Astart	Jeff Rackowitz - Intermec Technologies
Eric Random – Peerless	Rob Rhoads – Intel
Xavier Riley – Xerox	Gary Roberts - Ricoh
David Roach – Unisys	Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer	Richard Schneider - Epson Industry
Kris Schoff – HP	Katsuaki Sekiguchi - Canon
Bob Setterbo – Adobe	Gail Songer - Peerless
Hideki Tanaka – Cannon	Devon Taylor - Novell
Mike Timperman – Lexmark	Atsushi Uchino - Epson

Mot-clé d’état IPP	Opérations IPP
	TI	UI	CT	DE	UE	V	OA	OT	A
réussite-ok	x	x	x	x	x	x	x	x	x
réussite-ok-mais-attributs-substitués-ou-ignorés	x	x	x	x	x	x	x	x	x
réussite-ok-mais-conflit-d’attributs	x	x	x	x	x	x	x	x	x
erreur-client-mauvaise-demande	x	x	x	x	x	x	x	x	x
erreur-client-interdit	x	x	x	x	x	x	x	x	x
erreur-client-non-authentifié	x	x	x	x	x	x	x	x	x
erreur-client-non-autorisé	x	x	x	x	x	x	x	x	x
erreur-client-impossible	x	x	x	x	x	x	x	x	x
erreur-client-délai-dépassé				x	x
erreur-client-introuvable	x	x	x	x	x	x	x	x	x
erreur-client-parti	x	x	x	x	x	x	x	x	x
erreur-client-trop-grande-entité-de-demande	x	x	x	x	x	x	x	x	x
erreur-client-valeur-de-demande-trop-longue	x	x	x	x	x	x	x	x	x
erreur-client-format-de-document-non-accepté	x	x		x	x	x	x
erreur-client-attributs-ou-valeurs-non-acceptés	x	x	x	x	x	x	x	x	x
erreur-client-schéma-d’uri-non-accepté		x			x
erreur-client-charset-non-accepté	x	x	x	x	x	x	x	x	x
erreur-client-conflit-d’attributs	x	x	x	x	x	x	x	x	x
erreur-client-compression-non-acceptée	x	x		x	x	x
erreur-client-erreur-de-compression	x	x		x	x
erreur-client-erreur-format-de-document	x	x		x	x
erreur-client-erreur-d’accès-au-document		x			x
erreur-serveur-erreur-interne	x	x	x	x	x	x	x	x	x
erreur-serveur-opération-non-acceptée		x	x	x	x
erreur-serveur-service-indisponible	x	x	x	x	x	x	x	x	x
erreur-serveur-version-non-acceptée	x	x	x	x	x	x	x	x	x
erreur-serveur-erreur-d’appareil	x	x	x	x	x
erreur-serveur-erreur-temporaire	x	x	x	x	x
erreur-serveur-tâches-non-acceptées	x	x	x			x
erreur-serveur-occupé	x	x	x	x	x	x	x	x	x
erreur-serveur-tâche-annulée	x			x	x
erreur-serveur-documents-multiples-non-accepté				x	x

Mot-clé d’état IPP	Opérations IPP
	MG	LT	RT	PI	RI	PT
réussite-ok	x	x	x	x	x	x
réussite-ok-mais-attributs-substitués-ou-ignorés	x	x	x	x	x	x
réussite-ok-mais-conflit-d’attributs	x	x	x	x	x	x
erreur-client-mauvaise-demande	x	x	x	x	x	x
erreur-client-interdit	x	x	x	x	x	x
erreur-client-non-authentifié	x	x	x	x	x	x
erreur-client-non-autorisé	x	x	x	x	x	x
erreur-client-impossible	x	x	x	x	x	x
erreur-client-délai-dépassé
erreur-client-introuvable	x	x	x	x	x	x
erreur-client-parti	x	x	x	x	x	x
erreur-client-entité-de-demande-trop-grande	x	x	x	x	x	x
erreur-client-valeur-de-demande-trop-longue	x	x	x	x	x	x
erreur-client-format-de-document-non-accepté
erreur-client-attributs-ou-valeurs-non-acceptés	x	x	x	x	x	x
erreur-client-schéma-d’uri-non-accepté
erreur-client-charset-non-accepté	x	x	x	x	x	x
erreur-client-conflit-d’attributs	x	x	x	x	x	x
erreur-client-compression-non-acceptée
erreur-client-erreur-de-compression
erreur-client-erreur-format-de-document
erreur-client-erreur-d’accès-au-document
erreur-serveur-erreur-interne	x	x	x	x	x	x
erreur-serveur-opération-non-acceptée	x	x	x	x	x	x
erreur-serveur-service-indisponible	x	x	x	x	x	x
erreur-serveur-version-non-acceptée	x	x	x	x	x	x
erreur-serveur-erreur-d’appareil
erreur-serveur-erreur-temporaire	x	x	x	x	x	x
erreur-serveur-tâches-non-acceptées
erreur-serveur-occupé	x	x	x	x	x	x
erreur-serveur-tâche-annulée
erreur-serveur-documents-multiples-non-acceptés