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 :
1. valeurs d’attribut de mot-clé 2. valeurs d’attribut d’énumération 3. attributs
4. syntaxes d’attribut 5. opérations
6. groupes d’attributs 7. codes d’état
8. valeurs d’attribut hors-bande
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 :
ftp.isi.edu/iana/assignments/ipp/attribute-values/finitions/stapling.txt
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
où "xxx-yyy" est le nouveau nom d’attribut.
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 :
ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt où 'xxx-yyy' est le nom de la nouvelle syntaxe d’attribut.
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 :
ftp.isi.edu/iana/assignments/ipp/opérations/Xxx-Yyy.txt où "Xxx-Yyy" est le nouveau nom d’opération.
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 :
ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-tag.txt où 'xxx-yyy-tag' est le nom de la nouvelle étiquette de groupe d’attributs.
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 :
"informationnel" - Demande reçue, poursuite du traitement
"réussite" – L’action a bien été reçue, comprise et acceptée
"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 :
ftp.isi.edu/iana/assignments/ipp/code-d’états/xxx-yyy.txt où "xxx-yyy" est le nouveau mot-clé de code d’état d’opération.
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].