Protocole/1.1 d’impression sur Internet : codage et transport

Statut du présent Mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.

Déclaration de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

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éfinit les règles de codage des opérations IPP et les attributs d’IPP dans un nouveau type de support MIME Internet appelé "application/ipp". Le présent document définit aussi les règles du transport sur le protocole de transfert par hypertexte (http, Hypertext Transfer Protocol) d’un corps de message dont le type de contenu est "application/ipp". Le présent document définit un nouveau schéma nommé 'ipp' pour identifier les imprimantes et les tâches IPP.

L’ensemble complet des documents IPP comporte :

Objectifs de conception pour un protocole d’impression sur Internet [RFC2567]

Fondements de la structure, modèle et protocole du protocole d’impression sur Internet [RFC2568]

Protocole/1.1 d’impression sur Internet : Modèle et sémantique [RFC2911]

Protocole/1.1 d’impression sur Internet : Codage et transport [RFC2910] (le présent document)

Protocole/1.1 d’impression sur Internet : Guide de mise en œuvre [RFC3196]

Transposition entre les protocoles LPD et IPP [RFC2569]

Le document "Objectifs de conception pour un protocole d’impression sur Internet" porte un large regard sur la fonction d’impression distribuée, et énumère des scénarios réels qui aident à préciser 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 : Guide de mise en œuvre" donne des directives et conseils pour la mise en œuvre de clients et objets IPP.

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. Terminologie pour la conformité

3. Codage de la couche fonctionnement

3.1 Figure du codage

3.1.1 Demande et réponse

3.1.2 Groupe d’attributs

3.1.3 Attribut

3.1.4 Figure du codage d’un attribut à une valeur

3.1.5 Valeur supplémentaire

3.1.6 Autre figure du codage d’une demande ou d’une réponse

3.2 Syntaxe de codage

3.3 Groupe d’attribut

3.4 Paramètres requis

3.4.1 Numéro de version

3.4.2 ID d’opération

3.4.3 Code d’état

3.4.4 id de demande

3.5 Etiquettes

3.5.1 Etiquettes de délimitation

3.5.2 Etiquettes de valeur

3.6 Longueur de nom

3.7 Nom (d’attribut)

3.8 Longueur de valeur

3.9 Valeur (d’attribut)

3.10 Données

4. Codage de la couche transport

4.1 uri d’imprimante et uri de tâche

5. Schéma d’URL IPP

6. Considérations sur l’IANA

7. Considérations d’internationalisation

8. Considérations sur la sécurité

8.1 Exigences de conformité pour la sécurité

8.1.1 Authentification abrégée

8.1.2 Sécurité de la couche Transport (TLS)

8.2 Utilisation d’IPP avec TLS

9. Interopérabilité avec les mises en œuvre IPP/1.0

9.1 Le paramètre "numéro de version"

9.2 Sécurité et schéma d’URL

10. Références

11. Adresse des auteurs

12. Autres participants :

13. Appendice A : Exemples de protocole

13.1 Demande Tâche d’impression

13.2 Réponse (réussie) à Tâche d’impression

13.3 Réponse (échec) à Tâche d’impression

13.4 Réponse à Tâche d’impression (réussite avec attributs ignorés)

13.5 Demande URI d’imprimante

13.6 Demande Création de tâche

13.7 Demande Obtenir les tâches

13.8 Réponse à Obtenir les tâches

14. Appendice B : Enregistrement des informations de type de support MIME pour "application/ipp"

15. Appendice C : Changements par rapport à IPP/1.0

1. Introduction

Le présent document contient les règles pour les opérations de codage IPP et décrit deux couches : la couche transport et la couche fonctionnement.

La couche transport consiste en demandes ou réponses HTTP/1.1. La RFC 2616 [RFC2616] décrit HTTP/1.1. Le présent document spécifie les en-têtes HTTP qu’accepte une mise en oeuvre de IPP.

La couche fonctionnement consiste en un corps de message dans une demande ou réponse HTTP. Le document "Protocole/1.1 d’impression sur Internet : modèle et sémantique" [RFC2911] définit la sémantique d’un tel corps de message et les valeurs acceptées. Le présent document spécifie le codage d’une opération IPP. Il est donc fait référence au document [RFC2911] mentionné ci-dessus sous le nom de "document modèle IPP" ou simplement "document modèle".

Note : les numéros de version de IPP (1.1) et HTTP (1.1) ne sont pas liés. Ils trouvent juste être 1.1.

2. Terminologie pour la conformité

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit par la [RFC2119].

3. Codage de la couche fonctionnement

La couche fonctionnement est la partie corps de message de la demande ou réponse HTTP et elle DOIT contenir une seule demande d’opération IPP ou réponse d’opération IPP. Chaque demande ou réponse consiste en une séquence de valeurs et de groupes d’attributs. Les groupes d’attributs consistent en une séquence d’attributs dont chacun est un nom et une valeur. Les noms et les valeurs sont finalement des séquences d’octets.

Le codage consiste en octets comme type le plus primitif. Il y a plusieurs types construits à partir d’octets, mais trois importants types sont les entiers, les chaînes de caractères et les chaînes d’octets, sur lesquels la plupart des autres types de données sont construits. Chaque chaîne de caractères dans ce codage DOIT être une séquence de caractères où les caractères sont associés à un charset (ensemble de caractères) et un langage naturel. Une chaîne de caractères DOIT être en "ordre de lecture" avec le premier caractère dans la valeur (conformément à l’ordre de lecture) étant le premier caractère dans le codage. Une chaîne de caractères dont le charset associé est US-ASCII dont le langage naturel associé est l’anglais des USA est appelée plus loin une CHAINE-US-ASCII. Une chaîne de caractères dont le charset associé et le langage naturel sont spécifiés dans une demande ou réponse comme décrit dans le document modèle est appelée plus loin une CHAINE-LOCALISÉE. Une chaîne d’octets DOIT être dans "l’ordre du document modèle IPP" avec le premier octet dans la valeur (conformément à l’ordre du document modèle IPP) étant le premier octet dans le codage. Chaque entier dans ce codage DOIT être codé comme un entier algébrique en utilisant le codage binaire à complément à deux avec le format gros boutien (connu aussi comme "l’ordre du réseau" et l’"octet de plus fort poids en premier"). Le nombre d’octets pour un entier DOIT être 1, 2 ou 4, selon l’utilisation dans le protocole. De tels entiers à un octet, appelés à l’avenir OCTET-ALGEBRIQUE, sont utilisés pour le numéro de version et les champs d’étiquette. De tels entiers à deux octets, appelés à l’avenir COURT-ALGEBRIQUE sont utilisés pour l’id-d’opération, le code d’état et les champs de longueur. Les entiers à quatre octets, appelés à l’avenir ENTIERS-ALGEBRIQUES, sont utilisés pour les champs de valeur et l’id de demande.

Les deux sections suivantes présentent le codage de la couche fonctionnement de deux façons :

- informelle par des figures et la description

- formelle par la forme de Backus-Naur augmentée (ABNF, Augmented Backus-Naur Form), comme spécifié dans la RFC 2234 [RFC2234].

Une opération de demande ou réponse DOIT utiliser le codage décrit dans ces deux sections.

3.1 Figure du codage

3.1.1 Demande et réponse

Une opération de demande ou réponse est codée comme suit :

Les trois premiers champs du diagramme ci-dessus contiennent la valeur des attributs décrits au paragraphe 3.1.1 du document modèle.

Le quatrième champ est le champ "groupe d’attribut", et il survient 0 ou plusieurs fois. Chaque champ "groupe d’attribut" représente un seul groupe d’attributs, tel qu’un groupe d’attributs d’opération ou un groupe d’attributs de tâche (voir le document modèle). Le document modèle IPP spécifie les groupes d’attributs demandés et leur ordre pour chaque opération de demande et de réponse.

Le champ "fin d’étiquette d’attributs" est toujours présent, même lorsque "données" n’est pas présent. Le document modèle spécifie pour chaque opération de demande et de réponse si le champ "données" est présent ou absent.

3.1.2 Groupe d’attributs

Chaque champ "groupe d’attributs" est codé comme suit :

Le champ "début-d’étiquette-de-groupe-d’attributs" marque le début d’un champ "groupe-d’attribut" et sa valeur identifie le type de groupe d’attribut, par exemple, groupe d’attributs d’opération contre groupe d’attributs de tâche. Le champ "début-d’étiquette-de-groupe-d’attributs" marque aussi la fin du précédent groupe d’attributs excepté pour le champ "début-d’étiquette-de-groupe-d’attributs" dans le premier champ "groupe-d’attributs" d’une demande ou réponse. Le champ "début-d’étiquette-de-groupe-d’attributs" agit comme une terminaison de "groupe-d’attributs" parce qu’un champ "groupe-d’attributs" ne peut pas résider à l’intérieur d’un autre champ "groupe-d’attributs". Un champ "groupe-d’attributs" contient zéro ou plus champs "attribut".

Note : les valeurs du champ "début-d’étiquette-de-groupe-d’attributs" et du champ "fin-d’étiquette-d’attribut" sont appelées "étiquettes-de-délimitation".

3.1.3 Attribut

Un champ "attribut" est codé comme suit :

Lorsqu’un attribut est à une seule valeur (par exemple "copies" avec une valeur de 10) ou multi-valeur avec une valeur (par exemple, "côtés-acceptés" avec seulement la valeur 'un côté') il est codé avec seulement un champ "attribut-à-une-valeur". Lorsqu’un attribut est multi-valeur avec n valeurs (par exemple "côtés-acceptés" avec les valeurs 'un-côté' et 'bordure-en-long-de-deux-côtés'), il est codé avec un champ "attribut-à-une-valeur" suivi par n-1 champs "valeur-supplémentaire".

3.1.4 Figure du codage d’un attribut à une valeur

Chaque champ "attribut à une valeur" est codé comme suit :

Un champ "attribut-à-une-valeur" est codé avec cinq sous-champs :

Le champ "étiquette-de-valeur" spécifie la syntaxe d’attribut, par exemple 0x44 la syntaxe d’attribut 'mot-clé'.

Le champ "longueur-du-nom" spécifie la longueur du champ "nom" en octets, par exemple u dans le diagramme ci-dessus ou 15 pour le nom "côtés-acceptés".

Le champ "nom" contient le nom textuel de l’attribut, par exemple "côtés-acceptés".

Le champ "longueur-de-valeur" spécifie la longueur du champ "valeur" en octets, par exemple v dans le diagramme ci-dessus ou 9 pour la valeur (mot-clé) 'un-côté'.

Le champ "valeur" contient la valeur de l’attribut, par exemple, la valeur textuelle 'un-côté'.

3.1.5 Valeur supplémentaire

Chaque champ "valeur-supplémentaire" est codé comme suit :

Une "valeur-supplémentaire" est codée avec quatre sous-champs :

Le champ "étiquette-de-valeur" spécifie la syntaxe d’attribut, par exemple, 0x44 pour la syntaxe d’attribut 'mot-clé'.

Le champ "longueur-du-nom" a la valeur 0 afin de signifier que c’est une "valeur-supplémentaire". La valeur du champ "longueur-du-nom" distingue un champ "valeur-supplémentaire" ("longueur-du-nom" est 0) d’un champ "attribut à une valeur" ("longueur-du-nom" n’est pas 0).

Le champ "longueur-de-valeur" spécifie la longueur du champ "valeur" en octets, par exemple w dans le diagramme ci-dessus ou 19 pour la valeur (mot-clé) 'bordure-longue-à-deux-côtés'.

Le champ "valeur" contient la valeur de l’attribut, par exemple, la valeur textuelle 'bordure-longue à-deux-côtés'.

3.1.6 Autre figure du codage d’une demande ou d’une réponse

Du point de vue d’un analyseur qui effectue une action fondée sur une valeur "étiquette", le codage consiste en :

Ce qui suit montre à quels champs s’attend l’analyseur après chaque type d’"étiquette" :

- "étiquette-de-début-de-groupe-d’attribut" : attend zéro champs "attribut" ou plus

- "étiquette-de-valeur" : attend le reste d’un "attribut-à-une-valeur" ou une "valeur-supplémentaire".

- "étiquette-de-fin-d’attributs" : attend que les champs "attribut" soient finis et qu’il y ait des "données" facultatives.

3.2 Syntaxe de codage

La syntaxe ci-dessous est ABNF [RFC2234] excepté que 'chaînes-de-littéraux' DOIT être sensible à la casse. Par exemple 'a' signifie 'a' minuscule et non 'A' majuscule. De plus, les champs, OCTET-ALGEBRIQUE et COURT-ALGEBRIQUE sont représentés comme valeurs '%x' qui montrent leur gamme de valeurs.

message-ipp = demande-ipp / réponse-ipp

demande-ipp = numéro-de-version id-d’opération id-de-demande
*groupe-d’attributs données d’étiquette-de-fin-d’attributs

réponse-ipp = numéro-de-version code-d’état id-de-demande
*groupe-d’attributs données d’étiquette-de-fin-d’attributs

groupe-d’attributs = étiquette-de-début-de-groupe-d’attribut *attribut

numéro-de-version = numéro-de-version-majeure numéro-de-version-mineure

numéro-de-version-majeure = OCTET-ALGEBRIQUE

numéro-de-version-mineure = OCTET-ALGEBRIQUE

id-d’opération = COURT-ALGEBRIQUE ; transposé du modèle défini ci-dessous

code-d’état = COURT-ALGEBRIQUE ; transposé du modèle défini ci-dessous

id-de-demande = ENTIER-ALGEBRIQUE ; dont la valeur est > 0

attribut = attribut-à-une-valeur *valeur-supplémentaire

attribut-à-une-valeur = étiquette-de-valeur longueur-de-nom nom valeur-longueur valeur

valeur-supplémentaire = étiquette-de-valeur longueur-de-nom-zéro longueur-de-valeur valeur

longeur-de-nom = COURT-ALGEBRIQUE ; nombre d’octets de 'nom'

nom = LALPHA *( LALPHA / CHIFFRE / "-" / "_" / "." )

longueur-de-valeur = COURT-ALGEBRIQUE ; nombre d’octets de 'valeur'

valeur = CHAINE-D’OCTET

données = CHAINE-D’OCTET

longueur-de-nom-zéro = %x00.00 ; longueur-de-nom de 0

étiquette-de-valeur = %x10-FF ; voir au paragraphe 3.7.2

étiquette-de-début-de-groupe-d’attribut = %x00-02 / %04-0F ; voir au paragraphe 3.7.1

étiquette-de-fin-d’attribut = %x03 ; étiquette de 3 ; voir au paragraphe 3.7.1

OCTET-ALGEBRIQUE = OCTET

COURT-ALGEBRIQUE = 2OCTETS

ENTIER-ALGEBRIQUE = 4OCTETS

CHIFFRE = %x30-39 ; "0" to "9"

LALPHA = %x61-7A ; "a" to "z"

OCTET = %x00-FF

CHAINE-D’OCTET= *OCTET

La syntaxe ci-dessous définit des termes supplémentaires auxquels il est fait référence dans le présent document. Cette syntaxe fournit un groupage de remplacement des étiquettes de délimitation.

étiquette-de-limite = étiquette-de-début-de-groupe-d’attribut / étiquette-de-fin-d’attribut ; voir au paragraphe 3.7.1

étiquette-de-limite = %x00-0F ; voir au paragraphe 3.7.1

étiquette-de-début-de-groupe-d’attribut = %x00 / étiquette-d’attribut-d’opération / étiquette-d’attributs-de-tâche / étiquette-d’attributs-d’imprimante / étiquette-d’attributs-non-acceptés / %x06-0F

étiquette-d’attribut-d’opération = %x01 ; étiquette de 1

étiquette-d’attributs-de-tâche = %x02 ; étiquette de 2

étiquette-d’attributs-d’imprimante = %x04 ; étiquette de 4

étiquette-d’attributs-non-acceptés = %x05 ; étiquette de 5

3.3 Groupe d’attribut

Chaque champ "groupe-d’attribut" DOIT être codé avec le champ "étiquette-de-début-de-groupe-d’attribut" suivi par zéro ou plus sous-champs "attribut".

Le Tableau ci-dessous établit la correspondance entre le nom de groupe du document modèle et la valeur du champ "étiquette-de-début-de-groupe-d’attribut" :

Pour chaque demande et réponse d’opération, le document modèle prescrit les groupes d’attributs exigés et facultatifs, avec leur ordre. Au sein de chaque groupe d’attribut, le document modèle prescrit les attributs exigés et facultatifs, avec leur ordre.

Lorsque le document modèle exige un groupe d’attributs dans une demande ou réponse et que le groupe d’attribut ne contient aucun attribut, une demande ou réponse DEVRAIT coder le groupe d’attributs avec le champ "étiquette-de-début-de-groupe-d’attribut" suivi par zéro champ "attribut". Par exemple, si le client demande un seul attribut non pris en charge avec l’opération Obtenir-les-attributs-d’imprimante, l’imprimante ne DOIT retourner aucun champ "attribut", et elle DEVRAIT retourner un champ "étiquette-de-début-de-groupe-d’attribut" pour le groupe d’attributs d’imprimante. Le groupe des attributs non acceptés n’en est pas un exemple. Conformément au document modèle, le groupe des attributs non acceptés ne DEVRAIT être présent que si le groupe des attributs non acceptés contient au moins un attribut.

Un récepteur d’une demande DOIT être capable de traiter ce qui suit comme des équivalents de groupe d’attributs vide :

a) Un champ "étiquette-de-début-de-groupe-d’attributs" avec zéro champ "attribut" suivant.

b) Un champ "étiquette-de-début-de-groupe-d’attributs" attendu mais manquant.

Lorsque le document modèle exige une séquence d’un nombre inconnu de groupes d’attributs, chacun du même type, le codage DOIT contenir un champ "étiquette-de-début-de-groupe-d’attributs" pour chaque groupe d’attribut même lorsqu’un champ "groupe-d’attributs" ne contient aucun sous-champ "attribut". Par exemple, l’opération Obtenir-les-tâches peut ne retourner aucun attribut pour certaines tâches et pas pour d’autres. Le champ "étiquette-de-début-de-groupe-d’attributs" suivi par zéro champ "attribut" dit au récepteur qu’il y a une tâche dans la file d’attente pour laquelle aucune information n’est disponible, excepté qu’elle est dans la file.

3.4 Paramètres requis

Certains éléments d’opération sont appelés paramètres dans le document modèle [RFC2911]. Ils DOIVENT être codé dans une position particulière et NE DOIVENT PAS apparaître comme des attributs d’opération. Ces paramètres sont décrits dans les paragraphes ci-dessous.

3.4.1 numéro-de-version

Le champ "numéro-de-version" DOIT consister en numéro-de-version majeure et mineure, chacun d’eux DOIT être représenté par un OCTET-ALGEBRIQUE. Le numéro-de-version majeure DOIT être le premier octet du codage et le numéro-de-version mineure DOIT être le second octet du codage. Le protocole décrit dans le présent document DOIT avoir un numéro-de-version majeure de 1 (0x01) et un numéro-de-version mineure de 1 (0x01). L’ABNF pour ces deux octets DOIT être %x01.01.

3.4.2 id-d’opération

Le champ "id-d’opération" DOIT contenir une valeur id-d’opération définie dans le document modèle. La valeur DOIT être codée comme un COURT-ALGEBRIQUE et DOIT être dans les troisième et quatrième octets du codage d’une demande d’opération.

3.4.3 code-d’état

Le champ "code-d’état" DOIT contenir une valeur de code-d’état définie dans le document modèle. La valeur DOIT être codée comme un COURT-ALGEBRIQUE et elle DOIT être dans les troisième et quatrième octets du codage d’une réponse d’opération.

Le code-d’état est un attribut d’opération dans le document modèle. Dans le protocole, le code-d’état est dans une position particulière, en-dehors des attributs d’opération.

Si un code-d’état IPP est retourné, le code-d’état HTTP DOIT alors être 200 (réussite-ok). Avec toute autre valeur de code-d’état HTTP, la réponse HTTP NE DOIT PAS contenir un corps de message, et donc aucun code d’état IPP n’est retourné.

3.4.4 id-de-demande

Le champ "id de demande" DOIT contenir une valeur id de demande comme défini dans le document modèle. La valeur DOIT être codée comme un SIGNED-INTEGER et elle DOIT être dans les octets six à huit du codage.

3.5 Etiquettes

Il y a deux sortes d’étiquettes :

- étiquettes de délimitation : elles délimitent les sections majeures du protocole, à savoir les attributs et les données

- étiquettes de valeur : elles spécifient le type de chaque valeur d’attribut.

3.5.1 Etiquettes de délimitation

Le tableau suivant spécifie les valeurs pour les étiquettes de délimitation :

Lorsqu’un champ "étiquette-de-début-de-groupe d’attributs" survient dans le protocole, il signifie que zéro ou plus attributs suivants jusqu’à la prochaine étiquette de délimitation DOIVENT être des attributs appartenant au groupe d’attributs spécifié par la valeur de "étiquette-de-début-de-groupe-d’attributs". Par exemple, si la valeur de "étiquette-de-début-de-groupe-d’attributs" est 0x01, les attributs suivants DOIVENT être membres du groupe d’attributs d’opération.

"étiquette-de-fin-d’attributs" (valeur 0x03) DOIT survenir exactement une fois dans une opération. Elle DOIT être la dernière "étiquette-de-délimitation". Si l’opération a un groupe de contenu-de-document, les données de document dans ce groupe DOIVENT suivre "étiquette-de-fin-d’attributs".

L’ordre et la présence des champs "groupe-d’attributs" (dont le début est marqué par le sous-champ "étiquette-de-début-de-groupe-d’attributs") pour chaque demande d’opération et chaque réponse d’opération DOIT être celle définie dans le document modèle. Pour des détails complémentaires, voir au paragraphes 3.7 "Nom (d’attribut) et 13 "Appendice A : exemples de protocole".

Une imprimante DOIT traiter une "étiquette-de-délimitation" (valeurs de 0x00 à 0x0F) différemment d’une "étiquette de valeur" (valeurs de 0x10 à 0xFF) de sorte que l’imprimante sache qu’il y a un groupe entier d’attributs qu’elle ne comprend pas par opposition à une seule valeur qu’elle ne comprend pas.

3.5.2 Etiquettes de valeur

Les tableaux restants indiquent les valeurs pour le champ "étiquette-de-valeur", qui est le premier octet d’un attribut. Le champ "étiquette-de-valeur" spécifie le type de la valeur de l’attribut.Le tableau suivant spécifie les valeurs "hors bande" pour le champ "étiquette de valeur".

Le tableau suivant spécifie les valeurs d’entier pour le champ "étiquette-de-valeur" :

NOTE : 0x20 est réservé pour "entier générique" s’il devait jamais en être besoin.

Le tableau suivant spécifie les valeurs de chaîne d’octets pour le champ "étiquette de valeur" :

Le tableau suivant spécifie les valeurs de chaîne-de-caractères pour le champ "étiquette-de-valeur" :

NOTE : 0x40 est réservé pour "chaîne-de-caractères-générique" s’il devait jamais en être besoin.

NOTE : une valeur d’attribut a toujours un type, qui est explicitement spécifié par son étiquette ; une telle valeur d’étiquette est "nomSansLangage". Un nom d’attribut a un type implicite, qui est mot-clé.

Les valeurs 0x60-0xFF sont réservées pour de futures définitions de type dans des documents de normalisation de l’IETF.

L’étiquette 0x7F est réservée pour étendre les types au-delà des 255 valeurs disponibles avec un seul octet. Une valeur d’étiquette de 0x7F DOIT signifier que les 4 premiers octets du champ valeur sont interprétés comme la valeur de l’étiquette. Noter que cette extension future n’affecte pas les analyseurs qui ne sont pas au courant de cette étiquette particulière. L’étiquette est traitée comme toute autre étiquette inconnue, et la longueur de valeur spécifie la longueur d’une valeur, qui contient une valeur que l’analyseur traite de façon atomique. Les valeurs de 0x00 à 0x37777777 sont réservées pour définition dans les futurs documents de normalisation de l’IETF. Les valeurs de 0x40000000 à 0x7FFFFFFF sont réservées pour des extensions des fabricants.

3.6 longueur-de-nom

Le champ "longueur-de-nom" DOIT consister en un COURT-ALGEBRIQUE. Ce champ DOIT spécifier le nombre d’octets dans le champ "nom" qui suit immédiatement. La valeur de ce champ exclut les deux octets du champ "longueur-de-nom". Par exemple, si le champ "nom" contient "côtés", la valeur de ce champ est 5.

Si un champ "longueur-de-nom" a une valeur de zéro, le champ "nom" suivant DOIT être vide, et la valeur suivante DOIT être traitée comme une valeur supplémentaire pour l’attribut codé dans le plus proche champ "attribut-à-une-valeur" précédent. Au sein d’un groupe d’attributs, si deux ou plus attributs ont le même nom, le groupe d’attributs est mal formé (voir au paragraphe 3.1.3 de la [RFC2911]). Le nom de longueur zéro est le seul mécanisme pour les attributs à plusieurs valeurs.

3.7 Nom (d’attribut)

Le champ "nom" DOIT contenir le nom d’un attribut. Le document modèle [RFC2911] spécifie de tels noms.

3.8 Longueur de valeur

Le champ "longueur-de-valeur" DOIT consister en un COURT-ALGEBRIQUE. Ce champ DOIT spécifier le nombre d’octets dans le champ "valeur" suivant immédiatement. Les valeurs de ce champ excluent les deux octets du champ "longueur-de-valeur". Par exemple, si le champ "valeur" contient la valeur de mot-clé (texte) 'un côté', la valeur de ce champ est 9.

Pour tout type représenté par des entiers algébriques binaires, l’envoyeur DOIT coder la valeur en exactement quatre octets.

Pour tout type représenté par des chaînes de caractères, l’envoyeur DOIT coder la valeur avec tous les caractères de la chaîne et sans aucun caractère de bourrage.

Pour les champs"étiquette-de-valeur" "hors-bande" définis dans le présent document, tels que "non-accepté", la "longueur-de-valeur" DOIT être 0 et la "valeur" vide ; la "valeur" n’a pas de signification lorsque "étiquette-de-valeur" a une de ces valeurs "hors-bande". Pour les champs "étiquette-de-valeur" "hors-bande" de l’avenir, la même règle s’appliquera à moins que la définition n’établisse explicitement que la "longueur de valeur" PEUT être différente de zéro et la "valeur" non vide.

3.9 Valeur (d’attribut)

Les types de syntaxe (spécifiés par le champ "étiquette-de-valeur") et la plupart des détails de la représentation des valeurs d’attribut sont définies dans le document modèle IPP. Le Tableau ci-dessous abonde les informations du document modèle, et définit les types de syntaxe provenant du document modèle sous la forme de cinq types de base, définis à la section 3, "Codage de la couche fonctionnement". Les cinq types sont CHAINE-US-ASCII, CHAINE-LOCALISEE, ENTIER-ALGEBRIQUE, COURT-ALGEBRIQUE, OCTET-ALGEBRIQUE, et CHAINE-D’OCTET.

Le type de syntaxe d’attribut de la valeur détermine son codage et la valeur de son "étiquette-de-valeur".

3.10 Données

Le champ "données" DOIT inclure toutes données exigées par l’opération

4. Codage de la couche transport

HTTP/1.1 [RFC2616] est la couche transport pour ce protocole.

La couche fonctionnement a été conçue avec l’hypothèse que la couche transport contient les informations suivantes :

- l’URI de la tâche cible ou de l’opération d’imprimante

- la longueur totale des données dans la couche fonctionnement, comme une seule longueur ou comme une séquence de tronçons dont chacun a sa longueur.

Il est EXIGÉ qu’une mise en œuvre d’imprimante prenne en charge HTTP sur le port bien connu 631 alloué par l’IANA (le port IPP par défaut), bien qu’une mise en œuvre d’imprimante puisse aussi bien prendre en charge HTTP sur un autre port.

Chaque opération HTTP DOIT utiliser la méthode POST dans laquelle l’URI-de-demande est l’objet cible de l’opération, et le "Type-de-contenu" du corps de message dans chaque demande et réponse DOIT être "application/ipp". Le corps de message DOIT contenir la couche fonctionnement et DOIT avoir la syntaxe décrite au paragraphe 3.2 "Syntaxe de codage". Une mise en oeuvre client DOIT adhérer aux règles pour les clients décrites pour HTTP1.1 [RFC2616]. Une mise en œuvre d’imprimante (serveur) DOIT adhérer aux règles pour un serveur d’origine décrites pour HTTP1.1 [RFC2616].

Un serveur IPP envoie une réponse pour chaque demande qu’il reçoit. Si un serveur IPP détecte une erreur, il PEUT envoyer une réponse avant qu’il ait lu la demande entière. Si la couche HTTP du serveur IPP termine avec succès le traitement des en-têtes HTTP, elle PEUT envoyer une réponse intermédiaire, telle que "100 Continue", sans données IPP avant d’envoyer la réponse IPP. Un client DOIT s’attendre à une telle variété de réponses de la part d’un serveur IPP. Pour des informations complémentaires sur HTTP/1.1, consulter les documents HTTP [RFC2616].

Un serveur HTTP DOIT prendre en charge le tronçonnement des demandes IPP, et un client IPP DOIT prendre en charge le tronçonnement des réponses IPP conformément à HTTP/1.1 [RFC2616]. Note : cette règle cause un conflit avec les mises en œuvre non-conformes de HTTP/1.1 qui ne prennent pas en charge le tronçonnement pour les méthodes POST, et cette règle peut causer un conflit avec les mises en œuvre non-conformes de HTTP/1.1 qui ne prennent pas en charge le tronçonnement pour les scripts CGI.

4.1 uri-d’imprimante et uri-de-tâche

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

Certains éléments d’opération sont codés deux fois, une fois comme URI-de-demande sur la ligne de demande http, et une seconde fois comme attribut d’opération EXIGÉ dans l’entité application/ipp. Ces attributs sont l’URI cible de l’opération et sont appelés uri-d’imprimante et uri-de-tâche.

Note : L’URI cible est inclus deux fois dans une opération qui se réfère au même objet IPP, mais les deux URI NE DOIVENT PAS être littéralement identiques. L’un peut être un URI relatif et l’autre peut être un URI absolu. HTTP/1.1 permet aux clients de générer et envoyer un URI relatif plutôt qu’un URI absolu. Un URI relatif identifie une ressource avec le domaine du serveur HTTP, mais n’inclut pas de schéma, hôte ou port. Les affirmations suivantes caractérisent l’utilisation des URL dans la transposition d’IPP en HTTP/1.1 :

1. Bien que cela puisse être redondant, un client DOIT fournir la cible de l’opération à la fois comme attribut d’opération et comme URI à la couche HTTP. La raison de cette décision est de maintenir un ensemble cohérent de règles pour transposer application/ipp à des couches de communication qui peuvent être nombreuses, même lorsque les URL ne sont pas utilisés comme mécanisme d’adressage dans la couche transport.

2. Bien que ces deux URL puissent n’être pas littéralement identiques (l’un étant relatif et l’autre étant absolu), ils DOIVENT tous deux référencer le même objet IPP. Cependant, une imprimante PEUT NE PAS vérifier que les deux URL référencent le même objet IPP, et PEUT NE PAS prendre de mesures si elle détermine que les deux URL sont différents.

3. L’URI dans la couche HTTP est relatif ou absolu et sert au serveur HTTP pour acheminer la demande HTTP à la ressource appropriée par rapport à ce serveur HTTP. Le serveur HTTP n’a pas besoin d’être au courant de l’URI au sein de la demande d’opération.

4. Une fois que la ressource de serveur HTTP commence à traiter la demande HTTP, elle peut obtenir la référence à l’objet d’imprimante IPP approprié de l’URI HTTP (en se servant du contexte du serveur HTTP pour les URL relatifs) ou de l’URI au sein de la demande d’opération ; le choix est celui de la mise en œuvre.

5. Les URI HTTP peuvent être relatifs ou absolus, mais l’URI cible dans l’opération DOIT être un URI absolu.

5. Schéma d’URL IPP

Le document IPP/1.1 définit un nouveau schéma 'ipp' comme valeur d’un URL qui identifie un objet imprimante IPP ou un objet de tâche IPP. Les attributs IPP qui utilisent le schéma 'ipp' sont spécifiés ci-dessous. Parce que la couche HTTP ne prend pas en charge le schéma 'ipp', un client DOIT transposer les URL 'ipp' en URL 'http', et suivre ensuite les règles HTTP [RFC2616] [RFC2617] pour la construction d’une ligne de requête et des en-têtes HTTP. La transposition est simple parce que le schéma 'ipp' implique toute la même sémantique de protocole que le schéma 'http' [RFC2616], excepté qu’il représente un service d’impression et que le numéro de port implicite (par défaut) qu’utilisent les clients pour se connecter à un serveur est le port 631.

Dans le reste de la présente section, le terme 'ipp-URL' signifie un URL dont le schéma est 'ipp' et dont le port implicite (par défaut) est 631. Le terme 'http-URL' signifie un URL dont le schéma est 'http', et le terme 'https-URL' signifie un URL dont le schéma est 'https'.

Un client et un objet IPP (c’est-à-dire, le serveur) DOIVENT prendre en charge la valeur ipp-URL dans les attributs IPP suivants :

attributs de tâche :

uri-de-tâche

uri-de-tâche-d’imprimante

attributs d’imprimante :

uri-d’imprimante-pris-en-charge

attributs d’opération :

uri-de-tâche

uri-d’imprimante

Chacun des attributs ci-dessus identifie un objet imprimante ou tâche. L’URL-ipp est conçu comme la valeur des attributs de la liste, et pour aucun autre attribut. Tous ces attributs ont un type de syntaxe de 'uri', mais il y a des attributs avec un type de syntaxe de 'uri' qui n’utilisent pas le schéma 'ipp', par exemple, 'plus-d’info-de-tâche'.

Si une imprimante enregistre son URL dans un service d’annuaire, l’imprimante DOIT enregistrer un URL-ipp.

Les interfaces d’utilisateurs sont en dehors du domaine d’application du présent document. Mais si le logiciel expose les valeurs URL-ipp de l’un des cinq attributs ci-dessus à un utilisateur humain, il est EXIGÉ que l’humain voie l’URL-ipp comme il est.

Lorsqu’un client envoie une demande, il DOIT convertir un URL-ipp cible en URL-http cible pour la couche HTTP conformément aux règles suivantes :

1. changer le schéma 'ipp' en 'http'

2. ajouter un port 631 explicite si l’URL ne contient pas de port explicite. Note : le port 631 est le port bien connu alloué par l’IANA pour le schéma 'ipp'.

Le client DOIT utiliser l’URL-http cible à la fois dans la ligne de requête HTTP et dans les en-têtes HTTP, comme spécifié par HTTP [RFC2616] [RFC2617]. Cependant, le client DOIT utiliser l’URL-ipp cible pour la valeur d’attribut d’opération "uri-d’imprimante" ou "uri-de-tâche" au sein du corps d’application/ipp de la demande. Le serveur DOIT utiliser l’URL-ipp pour la valeur des attributs "uri-d’imprimante", "uri-de-tâche" ou "uri-d’imprimante-pris-en-charge" au sein du corps d’application/ipp de la réponse.

Par exemple, lorsqu’un client IPP envoie directement une demande (c’est-à-dire, sans mandataire) un URL-ipp "ipp://myhost.com/myprinter/myqueue", il ouvre une connexion TCP avec le port 631 (le port ipp implicite) sur l’hôte "myhost.com" et envoie les données suivantes :

POST /myprinter/myqueue HTTP/1.1

Hôte : myhost.com:631

Type de contenu : application/ipp

Codage de transfert : tronçonné

...

"uri d’imprimante" "ipp://myhost.com/myprinter/myqueue"

(codé en corps de message application/ipp)

...

Un autre exemple serait qu’un client IPP envoie la même demande que ci-dessus via un mandataire "myproxy.com" ; il ouvre une connexion TCP avec le port mandataire 8080 sur l’hôte mandataire "myproxy.com" et envoie les données suivantes :

POST http://myhost.com:631/myprinter/myqueue HTTP/1.1

Hôte : myhost.com:631

Type de contenu : application/ipp

Codage de transfert : tronçonné

...

"uri d’imprimante" "ipp://myhost.com/myprinter/myqueue"

(codé en corps de message application/ipp)

...

Le mandataire se connecte alors au serveur IPP d’origine avec des en-têtes qui sont les mêmes que dans l’exemple "sans mandataire" ci-dessus.

6. Considérations sur l’IANA

La présente section décrit les procédures d’allocation de codage pour les extensions de normes IETF suivantes et les extensions de fabricants au document IPP/1.1 Codage et Transport

1. syntaxes d’attribut – voir au paragraphe 6.3 de la [RFC2911]

2. groupes d’attributs - voir au paragraphe 6.5 de la [RFC2911]

3. valeurs d’attribut hors bande - voir au paragraphe 6.7 de la [RFC2911].

Ces extensions suivent les procédures d’enregistrement de "type2" définies à la section 6 de la [RFC2911]. Les extensions enregistrées pour être utilisées avec IPP/1.1 sont FACULTATIVES pour la conformité d’objet client et IPP au document IPP/1.1 Codage et Transport.

Ces procédures d’extension sont conformes aux lignes directrices telles qu’établies par l’IESG [IANA-CON]. La section 11 de la [RFC2911] 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 exigées ou ne suivent pas le format approprié décrit à la section 11 de la [RFC2911]. Le document IPP/1.1 Codage et Transport peut aussi être étendu par une RFC appropriée qui spécifie une des extensions ci-dessus.

7. Considérations d’internationalisation

Voir la section sur "Considérations d’internationalisation" dans le document "Protocole/1.1 d’impression sur Internet : Modèle et sémantique" [RFC2911] pour des informations sur l’internationalisation. Le présent document n’ajoute aucune question supplémentaire.

8. Considérations sur la sécurité

Le document Modèle et sémantique IPP [RFC2911] discute des exigences de sécurité de haut niveau (authentification du client, authentification du serveur et confidentialité du fonctionnement). L’authentification du client est le mécanisme par lequel le client prouve son identité au serveur d’une façon sécurisée. L’authentification du serveur est le mécanisme par lequel le serveur prouve son identité au client d’une façon sécurisée. La confidentialité du fonctionnement est définie comme un mécanisme de protection du fonctionnement contre l’espionnage.

8.1 Exigences de conformité pour la sécurité

La présente section définit les exigences de sécurité pour les clients et les objets IPP.

8.1.1 Authentification abrégée

Les clients IPP DOIVENT prendre en charge :

L’authentification abrégée [RFC2617].

MD5 et MD5-sess DOIVENT être mis en œuvre et pris en charge.

Le dispositif d’intégrité du message PEUT NE PAS être utilisé.

Les imprimantes IPP DEVRAIT prendre en charge :

L’authentification abrégée [RFC2617].

MD5 et MD5-sess DOIVENT être mis en œuvre et pris en charge.

Le dispositif d’intégrité du message PEUT NE PAS être utilisé.

Les raisons pour lesquelles les imprimantes IPP DEVRAIENT (plutôt que DOIVENT) prendre en charge l’authentification abrégée sont :

1. Alors que l’authentification du client est importante, il y a une certaine classe d’imprimantes où cela n’a pas de sens. Plus précisément, un appareil de bas de gamme avec un espace de mémoire morte limité et un faible débit de papier peut n’avoir pas besoin d’authentification du client. Cette classe d’appareils a normalement besoin de concepteurs de micro logiciels pour faire les transactions entre les protocoles et les fonctionnalités pour arriver aux solutions de plus faible coût possibles. Ce n’est pas simplement la taille du code qui est gravée dans les décisions du concepteur, mais aussi les essais, la maintenance, la capacité d’utilisation et la réponse aux besoins du marché pour chaque caractéristique livrée au consommateur. Forcer de tels appareils de bas de gamme à fournir de la sécurité afin d’exciper de la conformité à IPP/1.1 n’aurait aucun sens commercial et pourrait éventuellement entraver l’adoption de la norme.

2. Les appareils d’impression qui ont un fort volume de débit et ont de l’espace de mémoire morte disponible ont un argument irrésistible en faveur de la prise en charge de l’authentification du client car elle est la sauvegarde de l’appareil contre un accès non autorisé. Ces appareils seraient sujets à de lourdes pertes de produits d’entretien et de papier si des accès non autorisés devaient survenir.

8.1.2 Sécurité de la couche Transport (TLS)

Les imprimantes IPP DEVRAIENT prendre en charge la sécurité de la couche Transport (TLS) [RFC2246] pour l’authentification du serveur et la confidentialité du fonctionnement. Les imprimantes IPP PEUVENT aussi prendre en charge TLS pour l’authentification du client. Si une imprimante IPP prend en charge TLS, elle DOIT prendre en charge la suite de chiffrement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA comme recommandé par la RFC 2246 [RFC2246]. Toutes les autres suites de chiffrement sont FACULTATIVES. Une imprimante IPP PEUT prendre en charge l’authentification de base (décrite dans HTTP/1.1 [RFC2617]) pour l’authentification du client si le canal est sécurisé. TLS avec la suite de chiffrement recommandée ci-dessus peut fournir un tel canal sécurisé.

Si un client IPP prend en charge TLS, il DOIT prendre en charge la suite de chiffrement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA comme recommandé par la RFC 2246 [RFC2246]. Toutes les autres suites de chiffrement sont FACULTATIVES.

Le document IPP Modèle et sémantique définit deux attributs d’imprimante ("authentification-d’uri-prise-en-charge" et "sécurité-d’uri-prise-en-charge") que le client peut utiliser pour découvrir la politique de sécurité d’une imprimante. Ce document souligne aussi les considérations spécifiques d’IPP sur la sécurité et devrait être la principale référence pour les implications sur la sécurité par rapport au protocole IPP lui-même. Pour la compatibilité amont avec IPP version 1.0, les clients et imprimantes IPP peuvent aussi prendre en charge SSL3 [ssl]. Cela s’ajoute à la sécurité exigée dans le présent document.

8.2 Utilisation d’IPP avec TLS

IPP/1.1 utilise le mécanisme "Mise à niveau avec TLS au sein de HTTP/1.1" de la [RFC2817]. Une demande IPP initiale n’utilise jamais TLS. Le client demande une connexion TLS sécurisée en utilisant l’en-tête HTTP "Upgrade" (mettre à niveau) tandis que le serveur donne son accord dans la réponse HTTP. Le basculement sur TLS survient parce que le serveur accorde la demande du client de mettre à niveau sur TLS, ou parce qu’un serveur demande à passer à TLS dans sa réponse. La communication sécurisée commence avec une réponse de serveur acceptant de basculer sur TLS.

9. Interopérabilité avec les mises en œuvre IPP/1.0

Il est en dehors du domaine d’application de la présente spécification d’obliger à la conformité aux versions précédentes. IPP/1.1 a cependant été délibérément conçu pour faciliter la prise en charge des versions antérieures. Il vaut la peine de noter que, à l’heure de la rédaction de la présente spécification (1999), nous nous attendons à ce que les mises en œuvre d’imprimantes IPP/1.1 : comprennent toute demande valide dans le format de IPP/1.0, ou 1.1 ; répondent de façon appropriée et que cette réponse contienne la même valeur de paramètre "numéro-de-version" que celle utilisée par le client dans la demande.

Et nous nous attendons à ce que les clients IPP/1.1 comprennent toute réponse valide dans le format de IPP/1.0, ou 1.1.

9.1 Le paramètre "numéro-de-version"

Les règles suivantes concernent le paramètre "numéro-de-version" (voir au paragraphe 3.3) :

1. Les clients DOIVENT envoyer des demandes contenant un paramètre "numéro-de-version" avec une valeur de '1.1' et DEVRAIENT essayer de fournir des numéros de version de remplacement s’ils reçoivent un retour d’erreur 'erreur-serveur, version-non-acceptée' dans une réponse.

2. Les objets IPP DOIVENT accepter les demandes qui contiennent un paramètre "numéro-de-version" avec une valeur de '1.1' (ou rejeter la demande pour des raisons autres que 'erreur-serveur, version-non-acceptée').

3. Il est recommandé que les objets IPP acceptent toute demande avec la principale version '1' (ou rejettent la demande pour des raisons autres que 'erreur-serveur, version-non-acceptée'). Voir le paragraphe "versions" de la [RFC2911].

4. Dans tous les cas, la sécurité NE DOIT PAS être compromise lorsqu’un client fournit un paramètre "numéro-de-version" inférieur dans une demande. Par exemple, si un objet imprimante conforme à IPP/1.1 accepte des demandes de version '1.0' et qu’il est configuré pour mettre en application l’authentification abrégée, il DOIT faire de même pour une demande en version '1.0'.

9.2 Sécurité et schéma d’URL

Les règles suivantes concernent la sécurité, le paramètre "numéro-de-version", et le schéma d’URL fournis dans les attributs et réponses cibles :

1. Lorsqu’un client fournit une demande, l’attribut d’opération cible "uri-d’imprimante" ou "uri-de-tâche" DOIT avoir le même schéma que celui indiqué dans une des valeurs de l’attribut d’imprimante "uri-d’imprimante-accepté".

2. Lorsque le serveur retourne les attributs de description de tâche "uri-de-tâche-d’imprimante" ou "uri-de-tâche", il DEVRAIT retourner le même schéma ('ipp', 'https', 'http', etc.) que celui fourni par le client dans l’attribut d’opération cible "uri-d’imprimante" ou "uri-de-tâche" dans la demande Obtenir-les-attributs-de-tâche ou Obtenir-les-tâches, plutôt que le schéma utilisé lors de la création de la tâche. Cependant, lorsqu’un client demande des attributs de tâche en utilisant les opérations Obtenir-les-attributs-de-tâche ou Obtenir-les-tâches, les tâches et attributs de tâche que retourne le serveur dépendent (1) de la sécurité en vigueur lors de la création de la tâche, (2) de la sécurité en vigueur dans la demande d’interrogation, et (3) de la politique de sécurité en vigueur.

3. Il est recommandé que si un serveur enregistre un URL-ipp non sécurisé dans un service d’annuaire (voir l’appendice "Schéma générique d’annuaire" de la [RFC2911]), il enregistre alors aussi un URL-http pour l’interopérabilité avec les clients IPP/1.0 (voir la section 9).

4. Dans tous les cas, la sécurité NE DOIT PAS être compromise lorsqu’un client fournit un schéma d’URL 'http' ou autre non sécurisé dans les attributs d’opération cible "uri-d’imprimante" et "uri-de-tâche " d’une demande.

10. Références

[dpa] ISO/IEC 10175 Document Printing Application (DPA) (Application d’impression de document), juin 1996.

[iana] IANA Registry of Coded Character Sets (Registre IANA des ensembles de caractères codés) : ftp://ftp.isi.edu/in-notes/iana/assignments/caractère-sets.

[IANA-CON] Narten, T. et H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs" (Lignes directrices pour la rédaction de la section sur les considérations relatives à l’IANA dans les RFC), BCP 26, RFC 2434, octobre 1998.

[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: Implementer's Guide" (Protocole 1.1 d’impression sur Internet : Guide pour la mise en œuvre), travail en cours.

[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages" (Norme pour le format des messages de texte ARPA sur Internet), STD 11, RFC 822, août 1982.

[RFC1123] Braden, S., "Requirements for Internet Hosts - Application and Support" (Exigences pour les hôtes Internet : application et prise en charge), STD 3, RFC 1123, octobre 1989.

[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" (Protocole Daemon d’imprimante en ligne), RFC 1179, août 1990.

[RFC2223] Postel, J. et J. Reynolds, "Instructions to RFC Authors" (Instructions pour les auteurs de RFC), RFC 2223, octobre 1997.

[RFC1738] Berners-Lee, T., Masinter, L. et M. McCahill, "Uniform Resource Locators (URL)" (Localiseurs de ressource universels) (RFC 1738, décembre 1994.

[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB" (MIB d’imprimante), RFC 1759, mars 1995.

[RFC1766] Alvestrand, H., "Tags for the Identification of Languages" (Etiquettes d’identification des langues), RFC 1766, mars 1995.

[RFC1808] Fielding, R., "Relative Uniform Resource Locators" (Localiseurs de ressource uniformes relatifs), RFC 1808, juin 1995.

[RFC1903] Case, J., McCloghrie, K., Rose, M. et S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)" (Conventions textuelles pour la version 2 du protocole simple de gestion de réseau), RFC 1903, janvier 1996.

[RFC2046] Freed, N. et N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types" (Extensions multi-objets de messagerie Internet (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 multi-objets de messagerie Internet (MIME) Partie 4 : Procédures d’enregistrement), BCP 13, 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 le niveau d’exigence), BCP 14, RFC 2119, mars 1997.

[RFC2184] Freed, N. et K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations" (Extensions MIME de valeurs de paramètre de de mot codé : Ensembles de caractères, langages et continuations), RFC 2184, août 1997.

[RFC2234] Crocker, D. et P. Overall, "Augmented BNF for Syntax Specifications: ABNF" (BNF augmentée pour les spécifications de syntaxe : ABNF), RFC 2234, novembre 1997.

[RFC2246] Dierks, T. et C. Allen, "The TLS Protocol" (Protocole TLS), RFC 2246. janvier 1999.

[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. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport" (Protocole /1.0 d’impression sur Internet : codage et transport), RFC 2565, avril 1999.

[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics" (Protocole /1.0 d’impression sur Internet : modèle et sémantique), RFC 2566, avril 1999.

[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol" (Objectifs de conception pour un protocole d’impression sur Internet), RFC2567, avril 1999.

[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" (Arguments pour la structure, le modèle et le protocole du Protocole d’impression sur Internet), RFC 2568, avril 1999.

[RFC2569] Herriot, R., Hastings, T., Jacobs, N. et J. Martin, "Mapping between LPD and IPP Protocols" (Transposition entre les protocoles LPD et IPP), RFC 2569, avril 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. et T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1" (Protocole de transfert hypertexte – HTTP/1.1), RFC 2616, juin 1999.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. et L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication" (Authentification HTTP : authentification d’accès basique et abrégée), RFC 2617, juin 1999.

[RFC2817] Khare, R. et S. Lawrence, "Upgrading to TLS Within HTTP/1.1" (Mise à niveau en TLS au sein de HTTP/1.1), RFC 2817, May 2000.

[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. et J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport" (Protocole /1.1 d’impression sur Internet : codage et transport), RFC 2910, septembre 2000.

[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics" (Protocole /1.1 d’impression sur Internet : modèle et sémantique), RFC 2911, septembre 2000.

[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.

11. Adresse des auteurs

Page Web d’IPP : http://www.pwg.org/ipp/

Liste de diffusion IPP : ipp@pwg.orgPour s’abonner à la liste de diffusion ipp, envoyer le courriel suivant :

1) s’adresser à majordomo@pwg.org

2) laisser la ligne «subject» en blanc

3) mettre les deux lignes suivantes dans le corps du message :

subscribe ipp

end

12. Autres participants :

13. Appendice A : Exemples de protocole

13.1 Demande Tâche d’impression

Ci-après figure un exemple de demande Tâche d’impression avec le nom de tâche, les copies et les côtés spécifiés. L’attribut "ipp-attribute-fidelity" est réglé à 'vrai' de sorte que la demande d’impression va échouer si les attributs "copies" ou "côtés" ne sont pas pris en charge ou si leurs valeurs ne sont pas acceptées.

13.2 Réponse (réussie) à Tâche-d’impression

Ci-après figure un exemple de réponse de réussite de Tâche d’impression à la précédente demande Tâche-d’impression. L’imprimante accepte les attributs "copies" et "côtés"avec les valeurs fournies. Le code d’état retourné est 'réussite-ok'.

13.3 Réponse (échec) à Tâche-d’impression

Ci-après figure un exemple d’échec de réponse à Tâche-d’impression à la précédente demande Tâche-d’impression. Elle échoue parce que, dans ce cas, l’imprimante ne prend pas en charge l’attribut "côtés" et parce que la valeur '20' pour l’attribut "copies" n’est pas acceptée. Donc, aucune tâche n’est créée, et aucun attribut d’opération "id-de-tâche" ni "uri-de-tâche" n’est retourné. Le code d’erreur retourné est 'erreur-client-attributs-ou-valeurs-non-acceptés' (0x040B).

13.4 Réponse à Tâche-d’impression (réussite avec attributs ignorés)

Ci-après figure un exemple de réponse réussie de Tâche-d’impression à une demande Tâche-d’impression comme la précédente demande Tâche-d’impression, excepté que la valeur de 'fidélité-d’attributs-ipp' est faux. La demande d’impression réussit, même si, dans ce cas, l’imprimante n’accepte ni l’attribut "côtés"ni la valeur '20' pour l’attribut "copies". Une tâche est donc créée, et des attributs d’opération "id-de-tâche" et "uri-de-tâche" sont tous deux retournés. Les attributs non pris en charge sont aussi retournés dans un groupe d’attributs non acceptés. Le code d’erreur retourné est 'réussite-ok-attributs-ignorés-ou-substitués' (0x0001).

13.5 Demande d’URI-d’imprimante

Ci-après figure un exemple de demande URI-d’imprimante avec des paramètres copies et nom-de-tâche :

13.6 Demande Création-de-tâche

Ci-après figure un exemple de demande Création-de-tâche sans paramètre ni attribut :

13.7 Demande Obtenir-les-tâches

Voir ci-après un exemple de demande Obtenir-les-tâches avec des paramètres mais pas d’attribut :

13.8 Réponse à Obtenir-les-tâches

Ce qui suit est une réponse à Obtenir-les-tâches à une précédente demande avec trois tâches. L’imprimante ne retourne pas d’informations sur la seconde tâche (pour des raisons de sécurité) :

14. Appendice B : Enregistrement des informations de type de support MIME pour "application/ipp"

Le présent appendice contient les informations dont a besoin l’IANA pour enregistrer un type de support MIME. Les informations selon cette section seront transmises à l’IANA pour enregistrer l’application/ipp dont le contenu est défini à la section 3 "Codage de la couche fonctionnement" du présent document:

Nom de type MIME : application

Nom de sous-type MIME : ipp

Un type de contenu de "application/ipp" indique un corps de message (demande ou réponse) du Protocole d’impression sur Internet. Il y a actuellement une version: IPP/1.1, dont la syntaxe est décrit en section 3 "Codage de la couche fonctionnement" de la [RFC2910], et dont la sémantique est décrite dans la [RFC2911].

Paramètres exigés : aucun

Paramètres facultatifs : aucun

Considérations sur le codage : Les demandes/réponses du protocole IPP/1.1 PEUVENT contenir des lignes longues et contiennent TOUJOURS des données binaires (par exemple les longueurs de valeur d’attributs).

Considérations de sécurité : Les demandes/réponses du protocole IPP/1.1 n’introduisent aucun risque pour la sécurité qui ne soit déjà inhérent aux protocoles de transport sous-jacents. Les règles d’interopérabilité des mélanges de versions de protocole de la [RFC2911] aussi bien que les règles de codage du protocole dans la [RFC2910] sont complètes et non ambiguës.

Considérations d’interopérabilité : Les demandes (générées par les clients) et les réponses (générées par les serveurs) IPP/1.1 DOIVENT satisfaire à toutes les exigences de conformité imposées par les spécifications normatives [RFC2911] et [RFC2910]. Les règles de codage du protocole spécifiées dans la [RFC2910] sont complètes, de sorte que l’interopérabilité entre les mises en œuvre conformes est garantie (bien que la prise en charge de caractéristiques facultatives spécifiques ne soit pas assurée). Toutes les valeurs d’attribut IPP/1.1 de "charset" et "langage-naturel" qui sont une CHAINE-LOCALISEE sont explicites au sein des demandes/réponses du protocole IPP (sans recours à des informations externes dans HTTP, SMTP, ou autres en-têtes de transport de messages).

Spécifications publiées :

[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. et J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport" (Protocole /1.1 d’impression sur Internet :codage et transport), RFC 2910, septembre 2000.

[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics" (Protocole /1.1 d’impression sur Internet : modèle et sémantique), RFC 2911, septembre 2000.

Applications qui utilisent ce type de support :

Les clients d’impression et serveurs d’impression du protocole d’impression sur Internet (IPP), qui communiquent en utilisant HTTP/1.1 (voir la [RFC2910]), SMTP/ESMTP, FTP, ou un autre protocole de transport. Les messages de type "application/ipp" s’auto-suffisent et sont indépendants du transport, y compris le contexte de "charset" et "langage-naturel" pour toute valeur CHAINE-LOCALISÉE.

Adresse personnelle & de messagerie à contacter pour toute précision :

Utilisation prévue : COMMUNE

15. Appendice C : Changements par rapport à IPP/1.0

IPP/1.1 est identique à IPP/1.0 [RFC2565] avec les modifications suivantes :

1. Les valeurs d’attributs qui identifient un objet imprimante ou tâche utilisent un nouveau schéma 'ipp'. Les schémas 'http' et 'https' ne sont pris en charge que pour la compatibilité amont. Voir la section 5.

2. Les clients DOIVENT prendre en charge l’authentification abrégée, les imprimantes IPP DEVRAIENT prendre en charge l’authentification abrégée. Voir au paragraphe 8.1.1

3. TLS est recommandé pour la sécurité du canal. De plus, SSL3 peut être pris en charge pour la compatibilité amont. Voir au paragraphe 8.1.2

4. Il est recommandé que les objets IPP/1.1 acceptent toute demande avec un numéro de version principal de '1'. Voir au paragraphe 9.1.

5. Les objets IPP DEVRAIENT retourner le schéma d’URL demandé pour les attributs de tâche "uri-de-tâche-d’imprimante" et "uri-de-tâche", plutôt que le schéma d’URL utilisé pour créer la tâche. Voir au paragraphe 9.2.

6. Les sections sur l’IANA et sur l’internationalisation ont été ajoutées. Les termes "utilisation privée" et "expérimental" ont été remplacés par "extension du fabricant". Les allocations réservées pour les étiquettes de groupe d’attribut, les étiquettes de syntaxe d’attribut, et les valeurs d’attribut hors bande ont été précisées en ce qui concerne celles qui sont réservées pour les futurs documents de normalisation de l’IETF et celles qui sont réservées pour les extensions de fabricants. Les deux sortes d’extensions utilisent les procédures d’enregistrement de type2 comme défini dans la [RFC2911].

7. Il est précisé que les définitions de valeurs futures "hors bande" peuvent utiliser le champ valeur si des informations supplémentaires sont nécessaires.

Déclaration de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Remerciement