Кратко

  • RFC 3382 добавил в IPP необязательный синтаксис коллекций: именованные элементы разных типов можно было передавать одним значением, вкладывать друг в друга и дополнять будущими необязательными элементами.
  • Порядок не имел нормативного смысла. Принтер мог вернуть элементы в другой последовательности, поэтому значение закреплялось за уникальным именем и границей коллекции, а не за позицией.

Клиент отправляет три элемента. Принтер возвращает те же три, но переставляет их. Потребитель, считающий вторую позицию идентификатором, увидит повреждение. Потребитель, следующий RFC 3382, сопоставит имя, синтаксис, значение и окружающую коллекцию. Представление изменилось, но состав мог остаться прежним.

Документ вышел в сентябре 2002 года на Standards Track и закрыл структурный пробел Internet Printing Protocol. IPP уже умел передавать многие простые и повторяющиеся значения, однако общего средства для объединения разнородных атрибутов в одну единицу не было. Сравнение с PostScript dictionary и Java Map касалось поиска по имени, а не переноса целой объектной модели языка программирования.

Коллекция содержала один или несколько member attributes. У каждого сохранялись собственные имя и синтаксис: целое число, ключевое слово, диапазон или другой тип IPP. Элемент мог быть другой коллекцией либо набором коллекций. Контейнер не стирал различия, а проводил границу вокруг связанных значений.

Эта граница не обещала последовательности. Элементы могли идти в любом порядке, а принтер мог хранить и возвращать их иначе, чем получил. Поэтому второй элемент не обязан был всегда означать высоту, а последний — цвет. Позиция относилась к конкретной сериализации; идентичность задавалась именем внутри области.

Документ, определявший реальный атрибут-коллекцию, должен был указать имя, одно- или многозначность, контекст, способ объявления поддерживаемых элементов, а для каждого элемента — обязательность, синтаксис, семантику, ограничения, поддерживаемые значения и значения по умолчанию. RFC давал грамматику, но не освобождал будущие спецификации от точного определения.

Имена обязаны были быть уникальными внутри одной коллекции. То же имя могло появляться в другой коллекции или общем пространстве IPP: граница задавала область видимости. Это позволяло повторно использовать лексику, сохраняя однозначный поиск внутри значения.

Два элемента с одинаковым именем делали значение некорректным. Клиент не должен был его отправлять, принтер — возвращать. Получив такой запрос, принтер мог отклонить его или принять, использовав лишь один повтор, в зависимости от реализации. RFC не установил правила «первый побеждает» или «последний побеждает». Порядок не восстанавливал утраченную уникальность.

Вложенность увеличивала выразительность. Единого ограничения длины всей коллекции не было, но каждый элемент сохранял ограничение своего синтаксиса. Это была не бесформенная запись: листья оставались значениями IPP, допустимая структура по-прежнему требовала опубликованного определения.

Необязательные элементы обеспечивали развитие. Старая реализация могла не знать новое поле, однако неподдерживаемое следовало показать в правильном контексте. В Unsupported Attributes Group проблемный элемент можно было вернуть внутри коллекции. Плоская ошибка потеряла бы область, объясняющую, какое именно употребление имени не поддерживается.

На проводе структуру ограничивали begin-collection, member-name и end-collection. Схема учитывала старые анализаторы IPP, чтобы они не приняли внутреннее имя за обычный атрибут верхнего уровня. Совместимость не давала им понимания новой семантики; она ограничивала последствия незнания.

media-col и job-sheet-col служили иллюстрациями. Они показывали обязательные и необязательные элементы, обнаружение поддержки и вложенность, но сами не были определениями развёрнутых атрибутов. Для этого требовался отдельный нормативный документ.

RFC 3380 рассматривал атомарное изменение атрибутов задания, RFC 3381 — счётчики прогресса, зависящие от порядка комплектования. RFC 3382 отвечал на другую задачу: как передать типизированные значения одной единицей, не наделяя физическую последовательность смыслом.

Расширение обновило RFC 2910 и RFC 2911. Основы IPP/1.0 находились в RFC 2565 и RFC 2566, требования и проектирование — в RFC 2567 и RFC 2568. Позднее RFC 8010 и RFC 8011 свели кодирование и модель. Эта хронология не доказывает внедрение, поведение продукта или успешную печать.

Различие между составом и порядком сохраняет значение, потому что программы легко приписывают позиции ложный авторитет. Анализатор создаёт массив, интерфейс отображает его, и третий элемент получает смысл, которого спецификация не давала. Нормализация, вставка необязательного элемента или восстановление из отображения разрушает такое допущение.

Линза минимальной начальной спецификации Lu Heng показывает сдержанность решения: стандартизовать переиспользуемый контейнер и обязанности будущих определений, не решая заранее все будущие случаи. Его линза слоёв реальности разделяет порядок кодирования, идентичность, поддержку, принятие запроса и физический результат.

RFC 3382 позволил представлению двигаться, не разрушая отношения. Коллекция удерживала элементы вместе; уникальные имена и границы сохраняли понятность. Порядок оставался случайным свойством одной кодировки.

Источники