Résumé

  • RFC 3382 a donné à IPP une syntaxe facultative pour réunir, dans une même valeur, des membres nommés de types différents, y compris des collections imbriquées et de futurs membres facultatifs.
  • L’ordre n’avait aucune autorité sémantique : une imprimante pouvait restituer les membres autrement, de sorte que les noms uniques et les limites de collection devaient porter le sens.

Trois valeurs entrent dans une collection. À la sortie, les trois sont toujours présentes, mais leur ordre a changé. Le client qui lit « deuxième position » comme « deuxième identité » conclura à une corruption. Celui qui suit RFC 3382 cherchera le nom, la syntaxe et la limite de la collection. La réorganisation n’aura alors rien détruit.

Publié en septembre 2002 sur la voie de normalisation, le RFC répondait à une lacune d’IPP. Le protocole savait déjà transporter beaucoup de valeurs simples ou répétées. Il ne disposait pas encore d’un mécanisme général pour déclarer que plusieurs attributs hétérogènes décrivaient ensemble une seule structure. Le texte évoquait le dictionnaire PostScript et la Map de Java : l’analogie portait sur l’association par nom, pas sur l’adoption d’un objet de langage complet.

Une collection comprenait un ou plusieurs attributs membres. Chacun gardait son nom et sa syntaxe : entier, mot-clé, plage ou autre type IPP. Un membre pouvait lui-même être une collection, voire un ensemble de collections. Le contenant n’aplatissait donc pas les différences. Il ajoutait une frontière qui disait : ces valeurs appartiennent à la même unité.

Cette frontière ne promettait aucun ordre. Les membres pouvaient apparaître dans n’importe quelle séquence, et une imprimante pouvait les stocker puis les renvoyer autrement que le client ne les avait envoyés. La position était une propriété d’une sérialisation particulière. Elle ne pouvait pas devenir un raccourci fiable pour le sens.

Le nom devait en contrepartie être défini avec précision. Le document qui créait un attribut collection devait préciser son nom, sa cardinalité, son contexte, la manière d’annoncer les membres pris en charge, puis, pour chaque membre, le nom, le niveau d’exigence, la syntaxe, la sémantique, les contraintes, les valeurs admises et les valeurs par défaut. RFC 3382 fournissait une grammaire ; il ne dispensait pas les auteurs de l’écrire.

Dans une définition donnée, les noms des membres devaient être uniques. Le même mot pouvait être réutilisé dans une autre collection ou dans l’espace IPP plus large, car la frontière donnait la portée. Cette règle rendait possibles deux choses à la fois : la réutilisation locale d’un vocabulaire et une résolution sans ambiguïté à l’intérieur d’une valeur.

Deux occurrences du même nom dans une valeur rendaient la collection mal formée. Le client ne devait pas l’émettre et l’imprimante ne devait pas la retourner. Une imprimante qui la recevait pouvait rejeter la requête, ou l’accepter en ne retenant qu’un exemplaire selon son implémentation. Le RFC n’a jamais établi de règle portable « le premier gagne » ou « le dernier gagne ». L’ordre ne pouvait pas réparer une violation de l’unicité.

L’imbrication étendait le modèle sans le rendre informe. La collection entière n’avait pas une limite universelle de longueur, mais chaque membre restait soumis aux limites de sa propre syntaxe. Les feuilles demeuraient des valeurs IPP, et un document normatif devait toujours énumérer la structure permise.

L’extension facultative reposait sur la même discipline. Une définition pouvait prévoir des membres optionnels et permettre à des textes ultérieurs d’en ajouter. Une ancienne implémentation n’avait pas à prétendre comprendre le nouveau membre. Elle devait pouvoir signaler ce qu’elle ne prenait pas en charge sans détacher l’erreur de sa collection.

Le groupe Unsupported Attributes servait précisément à conserver ce contexte. Un membre non pris en charge ou en conflit pouvait être renvoyé à l’intérieur d’une collection. Son nom seul n’aurait pas toujours suffi, puisqu’un même nom pouvait exister dans plusieurs portées. La limite indiquait quelle occurrence avait échoué.

Sur le fil, les balises begin-collection, member-name et end-collection encadraient la structure. Leur dessin tenait compte des anciens analyseurs IPP afin qu’ils ne prennent pas simplement un nom de membre pour un attribut ordinaire de niveau supérieur. La compatibilité ne signifiait pas compréhension automatique ; elle cherchait à empêcher l’ignorance de devenir une interprétation fausse.

Les exemples media-col et job-sheet-col restaient illustratifs. Ils montraient comment définir membres requis, membres facultatifs, découverte et imbrication. Ils ne constituaient pas à eux seuls la définition d’attributs déployés. Un autre document devait encore faire le travail normatif.

RFC 3380 traitait parallèlement de l’atomicité d’une modification d’attributs de travail. RFC 3381 expliquait des compteurs de progression dépendant de l’assemblage. RFC 3382 se concentrait sur un autre seuil : conserver l’unité de plusieurs valeurs sans sacraliser leur ordre physique.

Il mettait à jour RFC 2910 et RFC 2911. Les bases IPP/1.0 se trouvaient dans RFC 2565 et RFC 2566 ; les besoins et choix de conception dans RFC 2567 et RFC 2568. RFC 8010 et RFC 8011 ont plus tard consolidé encodage et modèle. Cette chronologie n’est ni un recensement d’implémentations ni une preuve d’impression réussie.

La leçon reste actuelle parce que les positions acquièrent facilement une fausse autorité. Un tableau semble stable jusqu’à ce qu’un sérialiseur le normalise, qu’un membre optionnel s’intercale ou qu’un intermédiaire reconstruise la structure. Si un simple mélange modifie le résultat métier, le consommateur dépend d’une promesse que RFC 3382 refusait explicitement.

La lecture de Lu Heng sur la spécification initiale minimale éclaire cette retenue : normaliser un contenant réutilisable, les devoirs de sa définition et une voie d’extension, sans décider à l’avance de toutes les collections futures. Sa lecture des couches de réalité rappelle que l’ordre encodé, l’identité du membre, le support annoncé, l’acceptation de la requête et l’action physique sont des faits différents.

RFC 3382 n’a donc pas seulement ajouté des délimiteurs. Il a séparé appartenance et présentation. La collection conservait la relation ; les noms uniques et les frontières conservaient l’intelligibilité. L’ordre pouvait changer sans emporter le sens avec lui.

Sources