RFC 8011 | Протокол интернет-печати (IPP)/1.1: модель и семантика

Аннотация

Протокол интернет-печати (IPP) — это протокол прикладного уровня для распределенной печати с использованием интернет-инструментов и технологий. Этот документ описывает упрощенную модель, состоящую из абстрактных объектов, атрибутов и операций, которая не зависит от кодирования и транспорта. Модель состоит из нескольких объектов, включая принтеры и рабочие места. Задания по выбору поддерживают несколько документов.

Скачать оригинальный документ на английском языке RFC 8011 PDF

Семантика IPP позволяет конечным пользователям и операторам запрашивать возможности принтера; отправить задания на печать; узнать о статусе заданий на печать и принтеров; и отмените, удерживайте и отпустите задания на печать. Семантика IPP также позволяет операторам приостанавливать и возобновлять работу и принтеры.

Проблемы безопасности, интернационализации и каталогов также решаются с помощью модели и семантики. Кодирование и транспортировка сообщений IPP описаны в «Протокол печати через Интернет/1.1: Кодирование и транспортировка» (RFC 8010).

Этот документ устарел RFC 2911, 3381 и 3382.

Оглавление

1. Введение
1.1. Упрощенная модель печати
2. Условные обозначения, используемые в этом документе
2.1. Требования языка
2.2. Терминология печати
2.3. Терминология модели
2.3.1. Администратор
2.3.2. Атрибуты
2.3.2.1. Имя группы атрибутов
2.3.2.2. Имя атрибута
2.3.2.3. Синтаксис атрибута
2.3.2.4. Значение атрибута
2.3.3. Конечный пользователь
2.3.4. Отпечаток
2.3.5. Входная страница
2.3.6. Операция по созданию задания
2.3.7. Ключевое слово
2.3.8. Медиа Лист
2.3.9. Оператор
2.3.10. Набор
2.3.11. Поддержка атрибутов
2.3.12. Завершение статуса
2.4. Сокращения
3. Объекты IPP
3.1. Принтер объекта
3.2. Задание объекта
3.3. Отношения объекта
3.4. Идентичность объекта
4. Операции IPP
4.1. Общая семантика
4.1.1. Обязательные параметры
4.1.2. Идентификаторы операций и идентификаторы запросов
4.1.3. Атрибуты
4.1.4. Набор символов и атрибуты задания на естественном языке
4.1.4.1. Атрибуты операции Запроса
4.1.4.2. Атрибуты операции Ответа
4.1.5. Операционные цели
4.1.6. Значения кода состояния ответа операции и сообщения о состоянии
4.1.6.1. «status-code» (type2 enum) — код состояния
4.1.6.2. «status-message» (text(255)) — статус-сообщение
4.1.6.3. «detailed-status-message» (text(MAX)) — подробное статус-сообщение
4.1.6.4. «document-access-error» (text(MAX)) — ошибка доступа к документу
4.1.7. Неподдерживаемые атрибуты
4.1.8. Версии
4.1.9. Операции по созданию задания
4.2. Операции с принтером
4.2.1. Операция задания на печать
4.2.1.1. Запрос задания на печать
4.2.1.2. Ответ задания на печать
4.2.2. Операция печати URI
4.2.3. Операция проверки задания
4.2.4. Операция создания задания
4.2.5. Операция получения атрибутов принтера
4.2.5.1. Запрос на получение атрибутов принтера
4.2.5.2. Ответ на получение атрибутов принтера
4.2.6. Операция на получение задания
4.2.6.1. Запрос на получение задания
4.2.6.2. Ответ на получение задания
4.2.7. Операция паузы принтера
4.2.7.1. Запрос паузы принтера
4.2.7.2. Ответ паузы принтера
4.2.8. Операция возобновления работы принтера
4.2.9. Операция очистки заданий
4.3. Операции Задания
4.3.1. Операция отправки документа
4.3.1.1. Запрос отправки документа
4.3.1.2. Ответ отправки документа
4.3.2. Операция отправки URI
4.3.3. Операция отмены задания
4.3.3.1. Запрос отмены задания
4.3.3.2. Ответ отмены задания
4.3.4. Операция получения атрибутов задания
4.3.4.1. Запрос на получение атрибутов задания
4.3.4.2. Ответ на получение атрибутов задания
4.3.5. Операция задержки задания
4.3.5.1. Запрос удержания задания
4.3.5.2. Ответ задержки задания
4.3.6. Операция выпуска задания
4.3.7. Перезапуск задания
4.3.7.1. Запрос перезапуска задания
4.3.7.2. Ответ перезапуска задания
5. Атрибуты объекта
5.1. Синтаксис атрибутов
5.1.1. Значения вне диапазона — ’unknown’, ’unsupported’, ’no-value’ — «неизвестно», «не поддерживается» и «нет значения»
5.1.2. ’text’ — текст
5.1.2.1. ’textWithoutLanguage’ — текст без языка
5.1.2.2. ’textWithLanguage’ — текст с языком
5.1.3. ’name’ — имя
5.1.3.1. ’nameWithoutLanguage’ — имя без языка
5.1.3.2. ’nameWithLanguage’ — имя с языком
5.1.3.3. Соответствующие значения атрибутов ’name’
5.1.4. ’keyword’ — ключевое слово
5.1.5. ’enum’ — перечисление
5.1.6. ’uri
5.1.7. ’uriScheme’ — схема URI
5.1.8. ’charset’ — кодировка»
5.1.9. ’naturalLanguage’ — естественный язык»
5.1.10. ’mimeMediaType’ — медиа типы MIME
5.1.10.1. ’application/octet-stream’ — автоматическое определение формата документа
5.1.11. ’octetString’ — строка октетов
5.1.12. ’boolean’ — логическое
5.1.13. ’integer’ — целое число
5.1.14. ’rangeOfInteger’ — диапазон целых чисел
5.1.15. ’dateTime’ — дата время
5.1.16. ’resolution’ — разрешающая способность
5.1.17. ’collection’ — коллекция
5.1.18. ’1setOf X’
5.2. Атрибуты шаблона задания
5.2.1. job-priority (integer(1:100)) — приоритет задания
5.2.2. job-hold-until (type2 keyword | name(MAX)) — удержание задания
5.2.3. job-sheets (type2 keyword | name(MAX)) — рабочие листы
5.2.4. multiple-document-handling (type2 keyword) — обработка нескольких документов
5.2.5. copies (integer(1:MAX)) — копии
5.2.6. finishings (1setOf type2 enum) — отделки
5.2.7. page-ranges (1setOf rangeOfInteger(1:MAX)) — диапазоны страниц
5.2.8. sides (type2 keyword) — стороны
5.2.9. number-up (integer(1:MAX)) — число вверх
5.2.10. orientation-requested (type2 enum) — запрашиваемая ориентация
5.2.11. media (type2 keyword | name(MAX)) — медиа
5.2.12. printer-resolution (resolution) — разрешение принтера
5.2.13. print-quality (type2 enum) качество печати
5.3. Описание задания и атрибуты статуса
5.3.1. job-id (integer(1:MAX)) — идентификатор задания
5.3.2. job-uri (uri) — URI задания
5.3.3. job-printer-uri (uri) — URI принтера задания
5.3.4. job-more-info (uri) — больше информации о задании
5.3.5. job-name (name(MAX)) — название задания
5.3.6. job-originating-user-name (name(MAX)) — имя пользователя происходящего задания
5.3.7. job-state (type1 enum) — состояние задания
5.3.7.1. Серверы пересылки
5.3.7.2. Разделение состояний задания
5.3.8. job-state-reasons (1setOf type2 keyword) — причины состояния задания
5.3.9. job-state-message (text(MAX)) — сообщение о состоянии задания
5.3.10. job-detailed-status-messages (1setOf text(MAX)) — сообщения о статусе задания
5.3.11. job-document-access-errors (1setOf text(MAX)) — ошибки доступа к документу задания
5.3.12. number-of-documents (integer(0:MAX)) — количество документов
5.3.13. output-device-assigned (name(127)) — назначенное устройство вывода
5.3.14. Атрибуты статуса задания времени события
5.3.14.1. time-at-creation (integer(MIN:MAX)) — время создания
5.3.14.2. time-at-processing (integer(MIN:MAX)) — время обработки
5.3.14.3. time-at-completed (integer(MIN:MAX)) — время завершения
5.3.14.4. job-printer-up-time (integer(1:MAX)) — время работы задания принтера
5.3.14.5. date-time-at-creation (dateTime|unknown) — дата время при создании
5.3.14.6. date-time-at-processing (dateTime|unknown|no-value) — дата время при обработке
5.3.14.7. date-time-at-completed (dateTime|unknown|no-value) — дата время на завершение
5.3.15. number-of-intervening-jobs (integer(0:MAX)) — количество промежуточных заданий
5.3.16. job-message-from-operator (text(127)) — задание сообщение от оператора
5.3.17. Атрибуты размера задания
5.3.17.1. job-k-octets (integer(0:MAX)) — задание k-октеты
5.3.17.2. job-impressions (integer(0:MAX)) — задание отпечатка
5.3.17.3. job-media-sheets (integer(1:MAX)) — задание медиа листы
5.3.18. Атрибуты прогресса задания
5.3.18.1. job-k-octets-processed (integer(0:MAX)) — k-октеты обрабатываются в задании
5.3.18.2. job-impressions-completed (integer(0:MAX)) — задания отпечатка завершены
5.3.18.3. job-media-sheets-completed (integer(0:MAX)) — рабочие медиа листы завершены
5.3.19. attributes-charset (charset) — кодировка атрибутов
5.3.20. attributes-natural-language (naturalLanguage) — атрибуты естественного языка
5.4. Описание принтера и атрибуты состояния
5.4.1. printer-uri-supported (1setOf uri) — поддерживается URI принтера
5.4.2. uri-authentication-supported (1setOf type2 keyword) — поддерживается URI-аутентификация
5.4.3. uri-security-supported (1setOf type2 keyword) — поддержка uri-безопасности
5.4.4. printer-name (name(127)) — имя принтера
5.4.5. printer-location (text(127)) — местоположение принтера
5.4.6. printer-info (text(127)) — информация о принтере
5.4.7. printer-more-info (uri) — больше информации о принтере
5.4.8. printer-driver-installer (uri) — установщик драйвера принтера
5.4.9. printer-make-and-model (text(127)) — изготовитель и модель принтера
5.4.10. printer-more-info-manufacturer (uri) — принтер больше информации о производителе
5.4.11. printer-state (type1 enum) — состояние принтера
5.4.12. printer-state-reasons (1setOf type2 keyword) — причины состояния принтера
5.4.13. printer-state-message (text(MAX)) — сообщение о состоянии принтера
5.4.14. ipp-versions-supported (1setOf type2 keyword) — поддержка ipp-версий
5.4.15. operations-supported (1setOf type2 enum) — поддерживаемые операции
5.4.16. multiple-document-jobs-supported (boolean) — поддерживается работа с несколькими документами
5.4.17. charset-configured (charset) — настроенная кодировка
5.4.18. charset-supported (1setOf charset) — поддержка кодировки
5.4.19. natural-language-configured (naturalLanguage) — настроенный на естественном языке
5.4.20. generated-natural-language-supported (1setOf naturalLanguage) — сгенерированный естественный язык поддерживается
5.4.21. document-format-default (mimeMediaType) — формат документа по-умолчанию
5.4.22. document-format-supported (1setOf mimeMediaType) — поддерживаемый формат документа
5.4.23. printer-is-accepting-jobs (boolean) — принтер принимает задания
5.4.24. queued-job-count (integer(0:MAX)) — количество заданий в очереди
5.4.25. printer-message-from-operator (text(127)) — принтер сообщение от оператора
5.4.26. color-supported (boolean) — поддержкой цвета
5.4.27. reference-uri-schemes-supported (1setOf uriScheme) — поддержка опорных схем uri
5.4.28. pdl-override-supported (type2 keyword) — поддерживается pdl-переопределение
5.4.29. printer-up-time (integer(1:MAX)) — время работы принтера
5.4.30. printer-current-time (dateTime|unknown) — текущее время принтера
5.4.31. multiple-operation-time-out (integer(1:MAX)) — время ожидания нескольких операций
5.4.32. compression-supported (1setOf type2 keyword) — поддерживается сжатие
5.4.33. job-k-octets-supported (rangeOfInteger(0:MAX)) — поддерживаются задания k-октетов
5.4.34. job-impressions-supported (rangeOfInteger(0:MAX)) — поддержка заданий отпечатков
5.4.35. job-media-sheets-supported (rangeOfInteger(1:MAX)) — поддерживаются листы заданий носителя
5.4.36. pages-per-minute (integer(0:MAX)) — страниц в минуту
5.4.37. pages-per-minute-color (integer(0:MAX)) — страниц в минуту цвет
6. Соответствие
6.1. Требования к клиенту
6.2. Требования соответствия объекта IPP
6.2.1. Объекты
6.2.2. Операции
6.2.3. Атрибуты объекта IPP
6.2.4. Версии
6.2.5. Расширения
6.2.6. Синтаксис атрибутов
6.2.7. Безопасность
6.3. Требования к кодировке и естественному языку
7. Соображения IANA
7.1. Расширяемость объектов
7.2. Расширяемость атрибутов
7.3. Расширяемость ключевых слов
7.4. Расширяемость Enum
7.5. Расширяемость группы атрибутов
7.6. Расширяемость значения атрибута вне диапазона
7.7. Расширяемость синтаксиса атрибута
7.8. Расширяемость операций
7.9. Расширяемость кода состояния
8. Вопросы интернационализации
9. Вопросы безопасности
9.1. Сценарии безопасности
9.1.1. Клиент и Cервер в одном домене безопасности
9.1.2. Клиент и Сервер в разных доменах безопасности
9.1.3. Печать по ссылке
9.2. URI в атрибутах операции, задания и принтера
9.3. URI для каждого механизма аутентификации
9.4. Запрещенные Запросы
9.5. Операции, выполняемые Операторами и Администраторами
9.6. Запросы о заданиях, отправленных с использованием протоколов, отличных от IPP
10. Изменения с RFC 2911
11. Ссылки
11.1. Нормативные ссылки
11.2. Информационные ссылки

Приложение А. Форматы для заявок на регистрацию IPP
A.1. Регистрация атрибутов
А.2. Регистрация значения атрибута type2 ’keyword’
А.3. Регистрация значения атрибута type2 ’enum’
А.4. Регистрация операций
А.5. Регистрация кода состояния

Приложение B. Значения кода состояния и рекомендуемые сообщения кода состояния
B.1. Значения «Status-Code» — кода состояния
B.1.1. «Информационные» значения кода состояния
B.1.2. «Успешные» значения кодов состояния
B.1.2.1. successful-ok (0x0000) — успешно-нормально
B.1.2.2. successful-ok-ignored-or-substituted-attributes (0x0001) — успешно-нормально-игнорируемые-или-замещенные-атрибуты
B.1.2.3. successful-ok-conflicting-attributes (0x0002) — успешно-нормально-конфликтующие атрибуты
B.1.3. Значения кода состояния «Redirection» — перенаправление
B.1.4. Значения кода состояния «Client Error» — ошибки клиента
B.1.4.1. client-error-bad-request (0x0400) — ошибка клиента плохой запрос
B.1.4.2. client-error-forbidden (0x0401) — ошибка клиента запрещено
B.1.4.3. client-error-not-authenticated (0x0402) — ошибка клиента не аутентифицировано
B.1.4.4. client-error-not-authorized (0x0403) — ошибка клиента не авторизовано
B.1.4.5. client-error-not-possible (0x0404) — ошибка клиента невозможно
B.1.4.6. client-error-timeout (0x0405) — ошибка клиента перерыв
B.1.4.7. client-error-not-found (0x0406) — ошибка клиента не найдено
B.1.4.8. client-error-gone (0x0407) — ошибка клиента ушло израсходовано
B.1.4.9. client-error-request-entity-too-large (0x0408) — ошибка клиента слишком большой объект запроса
B.1.4.10. client-error-request-value-too-long (0x0409) — ошибка клиента значение запроса слишком длинное
B.1.4.11. client-error-document-format-not-supported (0x040a) — ошибка клиента формат документа не поддерживается
B.1.4.12. client-error-attributes-or-values-not-supported (0x040b) — ошибка клиента атрибуты или значения не поддерживаются
B.1.4.13. client-error-uri-scheme-not-supported (0x040c) — ошибка клиента uri-схема не поддерживается
B.1.4.14. client-error-charset-not-supported (0x040d) — ошибка клиента кодировка не поддерживается
B.1.4.15. client-error-conflicting-attributes (0x040e) — ошибка клиента конфликтующие атрибуты
B.1.4.16. client-error-compression-not-supported (0x040f) — ошибка клиента сжатие не поддерживается
B.1.4.17. client-error-compression-error (0x0410) — ошибка клиента ошибка сжатия
B.1.4.18. client-error-document-format-error (0x0411) — ошибка клиента ошибка формата документа
B.1.4.19. client-error-document-access-error (0x0412) — ошибка клиента ошибка доступа
B.1.5. Значения кода состояния «Server Error» — ошибки сервера
B.1.5.1. server-error-internal-error (0x0500) — ошибка сервера внутренняя ошибка
B.1.5.2. server-error-operation-not-supported (0x0501) — ошибка сервера операция не поддерживается
B.1.5.3. server-error-service-unavailable (0x0502) — ошибка сервера сервис недоступен
B.1.5.4. server-error-version-not-supported (0x0503) — ошибка сервера версии не поддерживается
B.1.5.5. server-error-device-error (0x0504) — ошибка сервера ошибка оборудования
B.1.5.6. server-error-temporary-error (0x0505) — ошибка сервера временная ошибка
B.1.5.7. server-error-not-accepting-jobs (0x0506) — ошибка сервера нет принятых заданий
B.1.5.8. server-error-busy (0x0507) — ошибка сервера занято
B.1.5.9. server-error-job-canceled (0x0508) — ошибка сервера задание отменено
B.1.5.10. server-error-multiple-document-jobs-not-supported (0x0509) — ошибка сервера несколько заданий документа не поддерживается
B 2. Значения кода состояния для операций IPP

Приложение C. Обработка атрибутов IPP
C.1. Точность
С.2. Переопределение языка описания страниц (PDL)
С.3. Использование атрибутов шаблона задания при обработке документа

Приложение D. Общая схема каталогов
Подтверждения
Адреса авторов

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc8011.

Уведомление об авторских правах

Copyright (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

1. Введение

Протокол интернет-печати (IPP) — это протокол прикладного уровня для распределенной печати с использованием интернет-инструментов и технологий. Версия 1.1 IPP (IPP / 1.1) фокусируется в основном на функциональности конечного пользователя, включая несколько административных операций. Версии IPP 2.0, 2.1 и 2.2 предоставляют много новых операций и определяются отдельно.

Этот документ является лишь одним из набора документов, которые полностью определяют IPP. Полный комплект документов IETF IPP включает в себя:

  • Цели разработки протокола печати через Интернет [RFC2567]
  • Обоснование структуры модели и протокола для печати через Интернет [RFC2568]
  • Протокол интернет-печати / 1.1: Модель и семантика (данный документ)
  • Протокол интернет-печати / 1.1: Кодирование и транспорт [RFC8010]
  • Протокол интернет-печати / 1.1: Руководство для разработчика [RFC3196]
  • Протокол интернет-печати / 1.1: Схема IPP URL [RFC3510]
  • Протокол интернет-печати (IPP) через транспортную привязку HTTPS и схему URI «ipps» [RFC7472]
  • Протокол интернет-печати (IPP): требования к административным операциям задания, принтера и устройства [RFC3239]
  • Протокол интернет-печати (IPP): задания и операции по настройке принтера [RFC3380]
  • Протокол интернет-печати (IPP): административные операции заданий и принтеров [RFC3998]
  • Протокол интернет-печати (IPP): требования к уведомлениям IPP [RFC3997]
  • Интернет-протокол печати (IPP): уведомления о событиях и подписки [RFC3995]
  • Протокол интернет-печати (IPP): метод доставки ippget для уведомлений о событиях [RFC3996]
  • Сопоставление протоколов LPD и IPP [RFC2569]

Всем, кто читает эти документы впервые, настоятельно рекомендуется прочитать документы IPP в указанном выше порядке. Дополнительные спецификации IPP были опубликованы рабочей группой IPP рабочей группы IEEE-ISTO по печати [PWG-IPP-WG]. Следующие стандарты настоятельно рекомендуются к прочтению:

  • Стандартизированные имена PWG Media 2.0 (MSN2) [PWG5101.1]
  • IPP Finishings 2.0 (FIN) [PWG5100.1]
  • Протокол печати через Интернет (IPP): расширение атрибута «выходной лоток» [PWG5100.2]
  • Протокол интернет-печати (IPP): Атрибуты производственной печати — набор 1 [PWG5100.3] (для атрибута шаблона задания «media-col»)
  • Стандарт для протокола печати через Интернет (IPP): объект документа [PWG5100.5]
  • Стандарт для протокола печати через Интернет (IPP): переопределение страниц [PWG5100.6]
  • Стандарт для протокола печати через Интернет (IPP): продление рабочих мест [PWG5100.7]
  • Стандарт для протокола печати через Интернет (IPP): атрибуты «-actual» [PWG5100.8]
  • Протокол печати через Интернет (IPP): расширения состояния принтера v1.0 [PWG5100.9]
  • Протокол интернет-печати (IPP): задания и расширения принтера — набор 2 (JPS2) [PWG5100.11]
  • IPP версии 2.0, 2.1 и 2.2 [PWG5100.12]
  • IPP: задания и расширения принтера — набор 3 (JPS3) [PWG5100.13]
  • IPP везде [PWG5100.14]
  • Служба факсов IPP [PWG5100.15]
  • Расширения печати на основе транзакций IPP [PWG5100.16]
  • Служба сканирования IPP (SCAN) [PWG5100.17]
  • Расширения общей инфраструктуры IPP (INFRA) [PWG5100.18]
  • Руководство по внедрению IPP v2.0 (IG) [PWG5100.19]

Этот документ организован следующим образом:

  • Остальная часть Раздела 1 представляет собой введение в упрощенную модель IPP для распределенной печати;
  • Раздел 2 определяет терминологию и условные обозначения, используемые в этом документе;
  • Раздел 3 знакомит с типами объектов, описанными в этом документе, с их базовым поведением, атрибутами и взаимодействиями;
  • Раздел 4 определяет основные операции для IPP / 1.1. Операции IPP являются синхронными — каждая операция имеет запрос и ответ;
  • Раздел 5 определяет основные атрибуты (и их синтаксис), которые используются в модели;
  • Разделы 6 и 7 суммируют требования соответствия реализации для объектов, которые поддерживают соображения протокола и IANA соответственно;
  • Разделы 8 и 9 охватывают вопросы интернационализации и безопасности для IPP; а также
  • Приложения предоставляют ссылку на значения кода состояния, обработку атрибутов IPP и общую схему каталогов.

1.1. Упрощенная модель печати

Для достижения своей цели реализации работоспособного протокола печати для Интернета протокол Интернет-печати (IPP) основан на упрощенной модели печати, которая абстрагирует многие компоненты реальных печатных решений. Интернет является распределенной вычислительной средой, в которой заказчики услуг печати (клиенты, приложения, драйверы принтеров и т. Д.) Взаимодействуют и взаимодействуют с поставщиками услуг печати. Этот документ (иногда называемый здесь документом «Модель и семантика») описывает простую абстрактную модель для IPP, даже если базовые конфигурации могут быть сложными «n-уровневыми» системами клиент / сервер. Важным упрощающим этапом в модели IPP является раскрытие только ключевых объектов и интерфейсов, необходимых для печати. Модель, описанная в этом документе, не включает функции, интерфейсы и отношения, которые выходят за рамки IPP / 1.1. IPP / 1.1 включает в себя многие соответствующие идеи и уроки, извлеченные из других спецификаций и разработок [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. На IPP сильно влияет модель печати, представленная в стандарте Приложения для печати документов (DPA) [ISO10175]. Хотя DPA определяет как конечного пользователя, так и административные функции, в IPP / 1.1 основное внимание уделяется функциональности конечного пользователя с несколькими дополнительными необязательными операциями для администраторов и операторов.

Модель IPP включает важные компоненты распределенной печати в следующие типы объектов IPP:

Каждый тип объекта имеет связанный набор операций (см. Раздел 4) и атрибутов (см. Раздел 5).

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

Рисунок 1 - Модель протокола IPP
Рисунок 1 — Модель протокола IPP

Объект «IPP Printer» («Принтер») включает функции, обычно связанные с физическими устройствами вывода, а также функции буферизации, планирования и управления несколькими устройствами, часто связанные с сервером печати. Принтеры при желании регистрируются в качестве записей в каталоге, где Конечные пользователи находят и выбирают их на основе какого-то отфильтрованного механизма контекстного поиска (см. Приложение D). Каталог используется для хранения относительно статичной информации о принтере, что позволяет конечным пользователям искать и находить принтеры, которые соответствуют их критериям поиска — например, имя, местоположение, контекст, возможности принтера и т. Д. Более динамичная информация, такая как Состояние загруженного и готового носителя, количество заданий на принтере, ошибки, предупреждения и т. д. напрямую связаны с самим принтером, а не с записью в каталоге, которая ссылается только на принтер.

Клиенты IPP («Клиенты») внедряют IPP на стороне Клиента и дают Конечным пользователям (или программам, выполняющимся от имени Конечных пользователей) возможность запрашивать Принтеры и отправлять задания на печать и управлять ими. Сервер IPP — это та часть объекта Printer, которая реализует протокол на стороне сервера. Остальная часть объекта «Принтер» реализует семантику приложения самой службы печати (или шлюзы). Принтеры могут быть встроены в устройство вывода или реализованы на хосте в сети, который обменивается данными с устройством вывода.

Когда задание отправляется на принтер, и принтер проверяет атрибуты в запросе на отправку, принтер создает новый объект задания IPP («Задание»). Затем конечный пользователь взаимодействует с этим новым заданием, запрашивая его состояние и отслеживая ход выполнения задания. Конечный пользователь также может отменить свои задания на печать, используя операцию отмены задания. Конечный пользователь также может удерживать, отпускать и перезапускать свои задания на печать, используя, если они реализованы, дополнительные операции удержания задания, освобождения задания и повторного запуска задания.

Привилегированный оператор или администратор принтера может отменить, удержать, разблокировать и перезапустить любое задание пользователя, используя ОБЯЗАТЕЛЬНОЕ задание отмены и необязательные операции удержания задания, освобождения задания и повторного запуска задания. Кроме того, привилегированный оператор или администратор принтера может приостановить, возобновить или очистить (задание) принтера с помощью опциональных операций Pause-Printer, Resume-Printer и Purge-Jobs, если они реализованы.

Служба уведомлений определена в «Протокол печати через Интернет (IPP): уведомления о событиях и подписки» [RFC3995]. Используя такую службу уведомлений, Конечный пользователь может асинхронно регистрироваться и получать события, относящиеся к принтеру и заданию. В противном случае конечный пользователь может запросить состояние принтеров и может отслеживать ход выполнения заданий, опрашивая операции Get-Printer-Attributes, Get-Jobs и Get-Job-Attributes.

 

2. Условные обозначения, используемые в этом документе

2.1. Требования языка

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

1. ОБЯЗАН — MUST. Это слово или термины «ТРЕБУЕТСЯ — REQUIRED» или «ДОЛЖЕН — SHALL» означают, что определение является абсолютным требованием спецификации.

2. НЕ ОБЯЗАН — MUST NOT. Эта фраза или фраза «НЕ ДОЛЖЕН — SHALL NOT» означают, что определение является абсолютным запретом спецификации.

3. СЛЕДУЕТ — SHOULD. Это слово или прилагательное «РЕКОМЕНДУЕТСЯ — RECOMMENDED» означают, что могут существовать веские причины в определенных обстоятельствах игнорировать конкретный элемент, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбрать другой курс.

4. НЕ СЛЕДУЕТ — SHOULD NOT. Эта фраза или фраза «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED» означают, что могут существовать веские причины в определенных обстоятельствах, когда конкретное поведение является приемлемым или даже полезным, но все последствия должны быть поняты, а случай тщательно взвешен, прежде чем реализовывать какое-либо поведение. описано с этим ярлыком.

5. ВОЗМОЖЕН — MAY. Это слово, или прилагательное «ДОПОЛНИТЕЛЬНО — OPTIONAL», означает, что предмет действительно необязателен. Один продавец может включить товар, потому что этого требует конкретный рынок, или потому что продавец чувствует, что он улучшает продукт, в то время как другой продавец может опустить тот же товар. Реализация, которая не включает в себя конкретную опцию, «ОБЯЗАН — MUST» быть подготовлена ​​к взаимодействию с другой реализацией, которая включает опцию, хотя, возможно, с уменьшенной функциональностью. В том же духе реализация, которая включает конкретную опцию, «ОБЯЗАН — MUST» быть подготовлена ​​к взаимодействию с другой реализацией, которая не включает эту опцию (за исключением, конечно, функции, предоставляемой опцией).

Ключевое слово «УСТАРЕЛО» в этом документе относится к операции, атрибуту или значению, которые НЕ ДОЛЖНЫ использоваться или поддерживаться в новых реализациях.

2.2. Терминология печати

Клиент: Инициатор исходящих запросов сеанса IPP и отправитель исходящих запросов операции IPP (пользовательский агент протокола передачи гипертекста (HTTP / 1.1), как определено в [RFC7230]).

Документ: объект, созданный и управляемый принтером, который содержит описание, обработку и информацию о состоянии. Объект Document может иметь прикрепленные данные и привязан к одному заданию [PWG5100.5].

URI «ipp»: URI IPP, как определено в [RFC3510].
URI «ipps»: URI IPP, как определено в [RFC7472].

Задание: объект, созданный и управляемый принтером, который содержит описание, обработку и информацию о состоянии. Задание также содержит ноль или более объектов Document.

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

Устройство вывода: одно логическое или физическое устройство.

Физическое устройство: аппаратная реализация устройства конечной точки, например механизм маркировки, факс-модем и т. Д.

Принтер: прослушиватель для входящих запросов сеанса IPP и приемник входящих запросов операции IPP (сервер HTTP / 1.1, как определено в [RFC7230]), который представляет одно или несколько физических устройств или логическое устройство.

2.3. Терминология модели

2.3.1. Администратор

Конечный пользователь, который также уполномочен управлять всеми аспектами устройства вывода или принтера, включая создание экземпляров принтера и управление авторизацией других конечных пользователей и операторов [RFC2567].

2.3.2. Атрибуты

Атрибут — это элемент информации, который связан с экземпляром объекта IPP (принтер, задание и т. д.). Атрибут состоит из имени атрибута и одного или нескольких значений атрибута. Каждый атрибут имеет определенный синтаксис атрибута. Все атрибуты объекта определены в Разделе 5, а все атрибуты операций определены в Разделе 4.

Атрибуты шаблона задания описаны в разделе 5.2. Клиент дополнительно предоставляет атрибуты шаблона задания в запросе на создание задания (запросы операции, которые создают объекты задания). Объект «Принтер» имеет связанные атрибуты, которые определяют поддерживаемые значения по умолчанию для принтера.

2.3.2.1. Имя группы атрибутов

Связанные атрибуты сгруппированы в именованные группы. Название группы является ключевым словом. Имя группы можно использовать вместо явного именования всех атрибутов в группе. Группы атрибутов определены в разделе 4.

2.3.2.2. Имя атрибута

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

2.3.2.3. Синтаксис атрибута

Каждый атрибут определяется с использованием явного синтаксического типа. В этом документе каждый тип синтаксиса определяется как ключевое слово с определенным значением. Документ «Кодирование и транспорт» [RFC8010] указывает действительные правила кодирования «на проводе» для каждого типа синтаксиса. Типы синтаксиса атрибутов определены в разделе 5.1.

2.3.2.4. Значение атрибута

Каждый атрибут имеет одно или несколько значений. Значения атрибута представлены в синтаксическом типе, указанном для этого атрибута. При выполнении текста в этом документе значения атрибутов указываются внутри одинарных кавычек (’), независимо от того, является ли их синтаксис атрибута ключевым словом, целым числом, текстом и т. д., Где кавычки не являются частью самого значения.

2.3.3. Конечный пользователь

Конечный пользователь — это лицо или программный процесс, которому разрешено выполнять основные функции печати, включая поиск / обнаружение принтера, создание локального экземпляра принтера, просмотр состояния принтера, просмотр возможностей принтера, отправку задания на печать, просмотр состояния задания на печать. и изменение атрибутов задания на печать [RFC2567].

2.3.4. Отпечаток

Отпечаток — это содержимое, наложенное на одну сторону листа носителя с помощью механизма маркировки, независимо от того, сколько раз сторона листа прошла какой-либо маркер. Impression содержит одну или несколько входных страниц, которые накладываются (масштабируются, переводятся и / или поворачиваются) во время обработки данных документа.

2.3.5. Входная страница

Страница ввода — это страница в соответствии с определением «страниц» на языке, который используется для выражения данных документа.

2.3.6. Операция по созданию задания

Операция создания задания — это любая операция, которая вызывает создание объекта задания, например операции Create-Job, Print-Job и Print-URI, определенные в этом документе.

2.3.7. Ключевое слово

Ключевые слова используются в этом документе в качестве идентификаторов семантических объектов в абстрактной модели (см. Раздел 5.1.4). Имена атрибутов, некоторые значения атрибутов, синтаксисы атрибутов и имена групп атрибутов представлены в виде ключевых слов.

2.3.8. Медиа Лист

Лист носителя — это отдельный экземпляр носителя, независимо от того, выполняется ли печать на одной или обеих сторонах носителя. Носители также включают разделы рулонных носителей.

2.3.9. Оператор

Оператор — это Конечный пользователь, который также имеет особые права на устройство вывода или принтер. Оператор обычно контролирует состояние принтера, а также управляет заданиями на устройстве вывода [RFC2567] и контролирует их. Оператор может запрашивать и контролировать принтер, задания и документы на основе политики сайта.

2.3.10. Набор

Набор — это логическая граница между доставленными листами печатных материалов. Например, в случае единого документа на десять страниц с разбором страниц и запроса на 50 копий каждая из 50 печатных копий документа составляет набор. Если бы страницы не были совмещены, то 50 экземпляров каждой из отдельных страниц в документе представляли бы каждый комплект. Отделочные процессы работают на наборах.

2.3.11. Поддержка атрибутов

По определению принтер поддерживает атрибут только в том случае, если этот принтер принимает его в запросе или отвечает соответствующим атрибутом, заполненным некоторыми значениями в ответе на запрос этого атрибута. Принтер поддерживает значение атрибута, если это один из атрибутов «поддерживаемых значений» принтера. Устройство позади принтера может демонстрировать поведение, которое соответствует некоторому атрибуту IPP, но если принтер, когда запрашивается для этого атрибута, не отвечает с атрибутом, то, что касается IPP, эта реализация не поддерживает эту функцию , Если атрибут «xxx-поддерживаемый» принтера не заполнен конкретным значением (даже если это значение является допустимым значением для этого атрибута), то этот принтер не поддерживает это конкретное значение.

Соответствующая реализация поддерживает все ОБЯЗАТЕЛЬНЫЕ атрибуты. Однако даже для ОБЯЗАТЕЛЬНЫХ атрибутов соответствие IPP не требует, чтобы все реализации поддерживали все возможные значения, представляющие все возможные способы и функции обработки заданий. Например, если данный экземпляр принтера поддерживает только определенные форматы документа, то этот принтер отвечает атрибутом «document-format-support», заполненным набором значений или, возможно, только одним значением, взятым из всего возможного набора значения, определенные для этого атрибута. Этот ограниченный набор значений представляет набор поддерживаемых форматов документов для принтера. Поддержка атрибута и некоторого набора значений для этого атрибута позволяет конечным пользователям IPP знать и использовать функции, связанные с этим атрибутом, и этими значениями. Если реализация решит не поддерживать атрибут или какое-либо конкретное значение, то конечные пользователи IPP не смогут использовать эту функцию в контексте самого IPP. Однако из-за существующей практики и унаследованных систем, которые не поддерживают IPP, может быть какой-то другой механизм, выходящий за рамки IPP, для управления или запроса «неподдерживаемой» функции (такой как встроенные инструкции в самих данных документа).

Например, рассмотрим следующее для атрибута «finishings-supported» (отделка поддерживается).

1) Если принтер физически не способен сшивать, атрибут «отделка поддерживается» НЕ ДОЛЖЕН заполняться значением «сшивание».

2) принтер физически способен сшивать; однако реализация выбирает не поддерживать сшивание в атрибуте «отделки» IPP. В этом случае, «штапель» НЕ ДОЛЖЕН быть значением в атрибуте «Описание отделки поддерживается». Без поддержки значения ‘staple’ у конечного пользователя IPP не будет средств в самом протоколе для запроса сшивания задания. Однако существующий форматер данных документа может быть в состоянии запросить сшивание документа напрямую с помощью встроенной инструкции в данных документа. В этом случае реализация IPP не поддерживает «сшивание»; однако, Конечный пользователь все еще может иметь некоторый контроль над сшиванием завершенного задания.

3) Принтер физически способен сшивать, а реализация выбирает поддержку сшивания в атрибуте IPP «отделка». В этом случае, «штапель» ДОЛЖЕН быть значением в атрибуте принтера «отделка поддерживается». Это позволяет конечным пользователям узнавать и использовать функцию сшивания с использованием атрибутов IPP.

Несмотря на то, что поддержка атрибутов шаблонов заданий принтером является необязательной в IPP / 1.1, принтеры, чье связанное устройство (устройства) способно реализовать любую функцию или функцию, соответствующую атрибуту IPP и некоторому связанному значению, ДОЛЖНЫ поддерживать этот атрибут и значение IPP.

Набор значений в любом из поддерживаемых атрибутов значений устанавливается (заполняется) каким-либо административным процессом или механизмом автоматического определения, который выходит за рамки этого документа. Из соображений административной политики и контроля Администратор может сделать так, чтобы конечному пользователю было доступно только подмножество возможных значений. В этом случае реальное устройство вывода за абстракцией принтера IPP может быть способным к определенной функции; однако администратор указывает, что доступ к этой функции не будет предоставляться конечному пользователю через IPP. Кроме того, поскольку принтер может представлять логическое устройство печати (а не только физическое устройство), фактический процесс поддержки значения не определен и оставлен на усмотрение реализации. Однако, если принтер поддерживает значение, для реализации семантического действия, связанного со значением, могут потребоваться какие-то ручные действия со стороны человека, но действия конечного пользователя не требуются.

Например, если одно из значений в атрибуте «отделка поддерживается» — «сшивание», фактическим процессом может быть автоматическое сшивание физическим устройством, управляемое какой-либо командой, отправленной на устройство. Или фактический процесс сшивания может быть ручным действием оператора на принтере с участием оператора.

В качестве другого примера функционирования поддерживаемых атрибутов рассмотрим администратора, который хочет контролировать все задания на печать, чтобы листы заданий не печатались для экономии бумаги. Чтобы запретить использование листов заданий, администратор устанавливает единственное поддерживаемое значение для атрибута «поддерживаются листы заданий» равным «нет». В этом случае, если клиент запрашивает что-либо, кроме «none», запрос на создание задания отклоняется или значение «листов заданий» игнорируется (в зависимости от значения «ipp-attribute-fidelity»). Чтобы принудительно использовать начальные / конечные листы заданий во всех заданиях, администратор не включает значение «none» в атрибут «поддерживаются задания». В этом случае, если клиент запрашивает «нет», запрос на создание задания отклоняется или значение «листы заданий» игнорируется (опять же, в зависимости от значения «ipp-attribute-fidelity»).

Атрибуты шаблона задания обычно будут иметь соответствующие атрибуты «Описание принтера» с поддержкой xxx и «xxx-default», которые содержат поддерживаемые значения и значения по умолчанию для этого атрибута. Для возможностей, которые не связаны с заданием, соглашение должно иметь атрибут «Описание ххх», поддерживаемый принтером, в котором перечислены поддерживаемые значения, и «Ххх-сконфигурированный» атрибут описания принтера, который содержит значение, используемое принтером. Например, атрибут «Описание поддерживаемого charset» принтера (раздел 5.4.18) содержит список поддерживаемых наборов символов для принтера, в то время как атрибут «Описание набора символов» для принтера (раздел 5.4.17) указывает набор символов, используемый Принтер.

2.3.12. Завершение статуса

Конечное состояние для задания или другого объекта называется его завершающим состоянием. Например, состояния «прервано», «отменено» и «выполнено» — это состояния завершения.

2.4. Сокращения

ABNF: Augmented Backus-Naur Form [RFC5234]
ASCII: American Standard Code for Information Interchange [RFC20]
HTTP: Hypertext Transfer Protocol [RFC7230]
HTTPS: HTTP over TLS [RFC2818]
IANA: Internet Assigned Numbers Authority
IEEE: Institute of Electrical and Electronics Engineers
IESG: Internet Engineering Steering Group
IPP: Internet Printing Protocol (this document, [RFC8010], and [PWG5100.12])
ISTO: IEEE Industry Standards and Technology Organization
LPD: Line Printer Daemon Protocol [RFC1179]
PWG: IEEE-ISTO Printer Working Group
RFC: Request for Comments
TCP: Transmission Control Protocol [RFC793]
TLS: Transport Layer Security [RFC5246]
URI: Uniform Resource Identifier [RFC3986]
URL: Uniform Resource Locator [RFC3986]
UTF-8: Unicode Transformation Format — 8-bit [RFC3629]

ABNF: расширенная форма Бэкуса-Наура [RFC5234]
ASCII: американский стандартный код для обмена информацией [RFC20]
HTTP: протокол передачи гипертекста [RFC7230]
HTTPS: HTTP поверх TLS [RFC2818]
IANA: Управление по присвоению номеров в Интернете
IEEE: Институт инженеров по электротехнике и электронике
IESG: Руководящая группа по интернет-инжинирингу
IPP: протокол печати через Интернет (этот документ [RFC8010] и [PWG5100.12])
ISTO: организация отраслевых стандартов и технологий IEEE
LPD: протокол демона линейного принтера [RFC1179]
PWG: рабочая группа IEEE-ISTO по принтерам
RFC: запрос комментариев
TCP: протокол управления передачей [RFC793]
TLS: безопасность транспортного уровня [RFC5246]
URI: унифицированный идентификатор ресурса [RFC3986]
URL: унифицированный указатель ресурса [RFC3986]
UTF-8: формат преобразования Unicode — 8 бит [RFC3629]

3. Объекты IPP

Этот документ определяет объекты IPP типов Printer и Job. Каждый тип объекта моделирует соответствующие аспекты реальной сущности, такой как настоящий принтер или реальное задание на печать. Каждый тип объекта определяется как набор возможных атрибутов, которые могут поддерживаться экземплярами этого типа объекта. Для каждого объекта (экземпляра) фактический набор поддерживаемых атрибутов и значений описывает конкретную реализацию. Атрибуты и значения объекта описывают его состояние, возможности, реализуемые функции, функции обработки заданий, а также поведение и характеристики по умолчанию. Например, тип объекта «Принтер» определяется как набор атрибутов, которые потенциально поддерживает каждый объект «Принтер». Таким же образом тип объекта Job определяется как набор атрибутов, которые потенциально поддерживаются каждым объектом Job.

Каждый атрибут, включенный в набор атрибутов, определяющих тип объекта, помечается как:

  • «REQUIRED — ОБЯЗАТЕЛЬНО»: каждый объект ДОЛЖЕН поддерживать атрибут.
  • «RECOMMENDED — РЕКОМЕНДУЕТСЯ»: каждый объект ДОЛЖЕН поддерживать атрибут.
  • «OPTIONAL — ДОПОЛНИТЕЛЬНО»: каждый объект МОЖЕТ поддерживать атрибут.

Некоторые определения значений атрибутов указывают, что объект ДОЛЖЕН или ДОЛЖЕН поддерживать значение; в противном случае поддержка значения является необязательной. Однако, если реализация поддерживает атрибут, она ДОЛЖНА поддерживать хотя бы одно из возможных значений для этого атрибута.

3.1. Принтер объекта

Основным компонентом модели IPP является объект принтера. Объект Printer реализует серверную часть протокола IPP / 1.1. Используя протокол, конечные пользователи могут запрашивать атрибуты объекта «Принтер» и отправлять задания на печать объекту «Принтер». Фактические компоненты реализации, лежащие в основе абстракции принтера, могут принимать разные формы и разные конфигурации. Однако абстракция модели позволяет деталям конфигурации реальных компонентов оставаться непрозрачными для конечного пользователя. Раздел 4 подробно описывает каждую из операций принтера.

Возможности и состояние объекта Printer описываются его атрибутами. Атрибуты принтера делятся на две группы:

  • атрибуты «задание-шаблон»: эти атрибуты описывают поддерживаемые возможности обработки заданий и значения по умолчанию для объекта «Принтер» (см. раздел 5.2)
  • атрибуты «printer-description»: эти атрибуты описывают идентификацию, состояние, местоположение принтера, ссылки на другие источники информации об объекте Printer и т. д. (см. раздел 5.4).

Поскольку объект «Принтер» является абстракцией универсального устройства вывода документов и поставщика услуг печати, объект «Принтер» может использоваться для представления любого реального или виртуального устройства с семантикой, совместимой с объектом «Принтер», например факсимильного устройства, устройства формирования изображения или даже CD-писатель.

Вот некоторые примеры конфигураций, поддерживающих объект Printer:

  • 1. Устройство вывода без возможности спулинга
  • 2. Устройство вывода со встроенным спулером
  • 3. Сервер печати, поддерживающий IPP с одним или несколькими соответствующими устройствами вывода
  • 3a. Соответствующие выходные устройства являются или не способны спулинга заданий
  • 3b. Возможно, соответствующие устройства вывода поддерживают IPP

На рисунке 2 показаны некоторые примеры реализации принтеров поверх различных конфигураций распределенной печати. Вложенный случай ниже представляет конфигурации 1 и 2 выше. Элементы «размещенный принтер» и «разветвитель» представляют конфигурации 3a и 3b соответственно.

В этом документе термин «клиент» относится к программному объекту, который отправляет запросы операции IPP на принтер IPP и принимает ответы операции IPP. Клиент МОЖЕТ быть:

  1. содержится в программном обеспечении, контролируемом Конечным пользователем, например, активированным с помощью пункта меню «Печать» в приложении, или
  2. компонент сервера печати, который отправляет запросы IPP либо на устройство вывода, либо на другой «нисходящий» сервер печати.

Термин «Принтер IPP» — это сетевой объект, который принимает запросы операции IPP и возвращает ответы операции IPP. Таким образом, объект IPP Printer МОЖЕТ быть:

  1. (встроенный) компонент устройства, который принимает IPP-запросы и контролирует устройство, или
  2. компонент сервера печати, который принимает запросы IPP (где сервер печати управляет одним или несколькими сетевыми устройствами, используя IPP или другие протоколы).

Условные обозначения:

##### — указывает на объект «Принтер», который либо встроен в устройство вывода, либо размещен на сервере. Объект «Принтер» может или не может быть в очереди или в очереди.

any (любой) — указывает любой сетевой протокол или прямое соединение, включая IPP

встроенный принтер:

Рисунок 2 - Архитектура объектов принтера IPP
Рисунок 2 — Архитектура объектов принтера IPP

3.2. Задание объекта

Объект Job используется для моделирования задания на печать. Объект Job содержит ноль или более документов. Информация, необходимая для создания объекта задания, отправляется в запросе на создание задания от конечного пользователя через клиент IPP на принтер. Принтер проверяет запрос на создание задания, и если принтер принимает запрос, принтер создает новый объект задания. Раздел 4 подробно описывает каждую из операций Job.

Характеристики и состояние объекта Job описываются его атрибутами. Атрибуты работы сгруппированы в две группы следующим образом:

  • атрибуты «задание-шаблон»: эти атрибуты могут быть предоставлены клиентом или конечным пользователем и включают инструкции по обработке задания, предназначенные для переопределения любых значений по умолчанию для принтера и / или инструкций, встроенных в данные документа (см. раздел 5.2).
  • атрибуты «описание работы»: эти атрибуты описывают идентификацию, состояние, размер задания и т. д. Клиент предоставляет некоторые из этих атрибутов, а принтер генерирует другие (см. раздел 5.3).

Реализация ДОЛЖНА поддерживать по крайней мере один документ на каждый объект задания. Реализация МОЖЕТ поддерживать несколько документов на один объект задания. Документ является либо:

  • поток данных документа в формате, поддерживаемом принтером (обычно это язык описания страниц — PDL), или
  • ссылка на такой поток данных документа.

Все инструкции по обработке задания моделируются как атрибуты объекта задания. Эти атрибуты называются «Атрибуты шаблона задания», и они в равной степени применяются ко всем документам в объекте задания.

3.3. Отношения объекта

У объектов IPP есть отношения, которые поддерживаются постоянно наряду с постоянным хранением атрибутов объекта.

Объект «Принтер» может представлять собой одно или несколько физических устройств вывода или логическое устройство, которое «обрабатывает» задания, но фактически не использует физическое устройство вывода для нанесения отметок на бумаге. Примерами логических устройств являются издатель веб-страниц или шлюз в онлайн-архив документов или хранилище. Принтер содержит ноль или более объектов Job.

Объект Job содержится ровно в одном принтере; однако идентичные данные документа, связанные с заданием, могут быть отправлены либо на тот же, либо на другой принтер. В этом случае будет создан второй объект Job, который будет почти идентичен первому Job; тем не менее, он будет иметь новые (разные) идентификаторы объекта задания (см. раздел 3.4).

Задание либо пустое (до добавления каких-либо документов), либо содержит один или несколько документов. Если содержащийся документ является потоком данных документа, этот поток может содержаться только в одном документе. Однако могут быть идентичные копии потока в других документах в том же или разных заданиях. Если содержащийся документ является просто ссылкой на поток данных документа, другие документы (в том же или другом задании) содержат ту же ссылку.

3.4. Идентичность объекта

Все объекты IPP (принтеры, задания и т. Д.) Идентифицируются унифицированным идентификатором ресурса (URI) [RFC3986], чтобы на них можно было постоянно и однозначно ссылаться. Поскольку каждый URL является специализированной формой URI, хотя в остальной части этого документа используется более общий термин «URI», его использование предназначено также для охвата более конкретного понятия «URL».

Администратор настраивает принтеры для поддержки или не поддержки аутентификации и / или конфиденциальности сообщений с использованием безопасности транспортного уровня (TLS) [RFC5246]; механизм настройки безопасности выходит за рамки этого документа. В некоторых ситуациях оба типа соединений (как аутентифицированных, так и не аутентифицированных) могут быть установлены с использованием одного канала связи, который имеет своего рода механизм согласования. В других ситуациях используются несколько каналов связи, по одному для каждого типа конфигурации безопасности. Раздел 9 содержит полное описание всех соображений безопасности и конфигураций.

Если принтер поддерживает более одного канала связи, некоторые или все эти каналы могут поддерживать и / или требовать различных механизмов безопасности. В таких случаях администратор может предоставить одновременную поддержку этих нескольких каналов связи в виде нескольких URI для одного принтера, где каждый URI представляет один из каналов связи с принтером. Для поддержки этой гибкости тип объекта «Принтер IPP» определяет многозначный идентификационный атрибут, называемый атрибутом «printer-uri-support», который ДОЛЖЕН содержать хотя бы один URI. Атрибут «printer-uri-support» имеет два сопутствующих атрибута: атрибут «uri-security-Поддерживается» и атрибут «Uri-аутентификация-поддерживается». Оба имеют такую ​​же мощность, что и «printer-uri-support». Назначение атрибута «uri-security-Поддерживается» состоит в том, чтобы указать механизмы безопасности (если таковые имеются), используемые для каждого URI, указанного в «printer-uri-support». Назначение атрибута «uri-authentication-Поддерживается» состоит в том, чтобы указать механизмы аутентификации (если таковые имеются), используемые для каждого URI, перечисленного в «printer-uri-support». Эти три атрибута полностью описаны в разделах 5.4.1, 5.4.2 и 5.4.3.

Когда задание отправляется на принтер через запрос на создание задания, клиент предоставляет только один URI принтера. Предоставляемый клиентом URI принтера ДОЛЖЕН быть одним из значений в атрибуте принтера «printer-uri-support».

IPP / 1.1 не определяет, как Клиент получает предоставленный Клиентом URI, но РЕКОМЕНДУЕТСЯ, чтобы Принтер был зарегистрирован как запись в службе каталогов. Конечные пользователи и программы могут затем опросить каталог, выполнив поиск принтеров. Приложение D определяет общую схему для записей объекта Printer в службе каталогов и описывает, как эта запись действует как мост к фактическому IPP-принтеру. Запись в каталоге, представляющая принтер IPP, включает в себя, возможно, множество URI для этого принтера в качестве значений в одном из его атрибутов.

Когда Клиент отправляет запрос на создание задания на принтер, принтер проверяет его и создает новый объект задания. Принтер назначает новому заданию числовой идентификатор, который хранится в атрибуте задания «идентификатор задания», и URI, хранящийся в атрибуте задания «задание задания». Как числовой идентификатор, так и URI могут быть использованы клиентами в качестве цели для последующих операций задания; числовой идентификатор является предпочтительным. Принтер генерирует числовой идентификатор и URI задания на основе настроенной политики безопасности и URI, используемого клиентом в запросе на создание задания.

Например, рассмотрим принтер, который поддерживает как канал связи, защищенный с помощью TLS (использование HTTP поверх TLS с URI-схемой «https»), так и другой открытый канал связи, который не защищен с помощью TLS (с использованием простой схемы «http»). URI). Если клиент отправляет задание с использованием защищенного URI, принтер назначает новому заданию также защищенный URI. Если клиент должен был отправить задание с использованием URI открытого канала, принтер может назначить новому заданию URI открытого канала. Клиенты ДОЛЖНЫ использовать атрибуты «printer-uri» и «job-id», чтобы указывать на задание, чтобы избежать двусмысленности в отношении безопасности канала связи.

Кроме того, принтер также заполняет атрибут задания «job-printer-uri». Это ссылка на принтер, который создал задание. Если у Клиента есть доступ только к идентификатору задания «job-uri», Клиент может запросить атрибут задания «job-printer-uri», чтобы определить, какой принтер создал задание. Если принтер поддерживает более одного URI, он выбирает один URI, предоставленный клиентом при создании задания, для создания значения и заполнения атрибута задания «job-printer-uri».

В дополнение к идентификаторам объекты IPP имеют имена — «имя-принтера» для принтеров и «имя-задания» для заданий. Имя объекта не гарантируется быть уникальным для всех экземпляров всех объектов. Имя принтера выбирается и устанавливается администратором через какой-либо механизм, выходящий за рамки этого документа. Название работы может быть выбрано и предоставлено Клиентом, отправившим работу. Если Клиент не предоставляет имя работы, принтер генерирует имя для новой работы. Во всех случаях имя имеет только локальное значение.

Подведём итоги:

  • Каждый принтер идентифицируется одним или несколькими URI. Атрибут «Printer-uri-Поддерживаемый» принтера содержит URI.
  • Атрибут принтера «uri-security-Поддерживается» определяет протоколы безопасности канала связи, которые были настроены для различных URI принтера (например, «tls» или «none»).
  • Атрибут «Поддержка uri-аутентификации» принтера определяет механизмы аутентификации, которые были настроены для различных URI принтера (например, «дайджест», «нет» и т. д.).
  • Каждое задание идентифицируется числовым идентификатором, который является 32-разрядным положительным целым числом. Атрибут «Job-id» задания содержит идентификатор задания. Идентификатор задания уникален только в контексте принтера, который создал задание.
  • Каждое задание также идентифицируется URI. Атрибут Job-uri Job содержит URI, хотя его использование клиентами НЕ УСТАРЕЛО.
  • Каждое задание имеет атрибут «job-printer-uri», который содержит URI принтера, который использовался для создания задания. Этот атрибут используется для определения принтера, создавшего задание, когда для задания задан только URI. Эта связь необходима для определения языков, наборов символов и операций, которые поддерживаются в этом задании (основа для такой поддержки исходит от создания принтера).
  • У каждого принтера есть имя, которое не обязательно уникально. Администратор выбирает и устанавливает это имя через некоторый механизм, выходящий за рамки этого документа IPP/1.1. Атрибут «имя принтера» принтера содержит имя.
  • Каждое задание имеет имя, которое не обязательно уникально. Клиент может указать это имя в запросе на создание вакансии. Если Клиент не предоставляет это имя, Принтер генерирует имя для Задания. Атрибут Job-name содержит название.

4. Операции IPP

Объекты IPP (принтеры (Printers), задания (Jobs) и т. д.) поддерживают операции. Операция состоит из запроса (request) и ответа (response). Когда Клиент (Client) связывается с Принтером (Printer) или его Заданиями (Jobs), Клиент (Client) при необходимости отправляет запрос операции на URI Принтера (Printer URI) и числовой идентификатор объекта. Операционные запросы и ответы имеют параметры, которые идентифицируют операцию. Операции также имеют атрибуты, которые влияют на характеристики времени выполнения операции (предполагаемая цель, информация о локализации и т. д.). Эти специфичные для операции атрибуты называются «operation attributes» (атрибутами операции) (по сравнению с атрибутами объекта, такими как Printer attributes (атрибуты принтера) или Job attributes (атрибуты задания)). Каждый запрос несет с собой любые атрибуты операции, атрибуты объекта и/или данные документа, необходимые для выполнения операции. Каждый запрос требует ответа от объекта. Каждый ответ указывает на успех или неудачу операции с кодом состояния (status-code) в качестве параметра ответа. Ответ содержит любые атрибуты операции, атрибуты объекта и/или сообщения о состоянии, сгенерированные во время выполнения запроса операции.

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

Операции принтера, определенные в этом документе:

Print-Job (Раздел 4.2.1)
Print-URI (Раздел 4.2.2)
Validate-Job (Раздел 4.2.3)
Create-Job (Раздел 4.2.4)
Get-Printer-Attributes (Раздел 4.2.5)
Get-Jobs (Раздел 4.2.6)
Pause-Printer (Раздел 4.2.7)
Resume-Printer (Раздел 4.2.8)
Purge-Jobs (Раздел 4.2.9)

Значение кода состоянияОперация протокола IPPОписаниеОбъект IPPОпределено в RFC 8011
PJPrint-JobЗадание на печатьПринтерРаздел 4.2.1
PUPrint-URIПечать URIПринтерРаздел 4.2.2
VValidate-JobПодтвердить заданиеПринтерРаздел 4.2.3
CJCreate-JobСоздать заданиеПринтерРаздел 4.2.4
GA (для принтера и задания)Get-Printer-AttributesПолучить атрибуты принтераПринтерРаздел 4.2.5
GJGet-JobsПолучить заданиеПринтерРаздел 4.2.6
PPPause-PrinterПриостановить ПринтерПринтерРаздел 4.2.7
RPResume-PrinterВозобновить принтерПринтерРаздел 4.2.8
PJPurge-JobsЧистка ЗаданийПринтерРаздел 4.2.9

Таблица операций Принтера в IPP 1.1

Операции задания, определенные в этом документе:

Send-Document (Раздел 4.3.1)
Send-URI (Раздел 4.3.2)
Cancel-Job (Раздел 4.3.3)
Get-Job-Attributes (Раздел 4.3.4)
Hold-Job (Раздел 4.3.5)
Release-Job (Раздел 4.3.6)
Restart-Job (Раздел 4.3.7)

Значение кода состоянияОперация протокола IPPОписаниеОбъект IPPОпределено в RFC 8011
SDSend-DocumentОтправить документЗаданиеРаздел 4.3.1
SUSend-URIОтправить URIЗаданиеРаздел 4.3.2
CCancel-JobОтменить заданиеЗаданиеРаздел 4.3.3
GA (для задания и принтера)Get-Job-AttributesПолучить атрибуты заданияЗаданиеРаздел 4.3.4
HJHold-JobЗадержать заданиеЗаданиеРаздел 4.3.5
RJRelease-JobВыпустить заданиеЗаданиеРаздел 4.3.6
RSRestart-JobПерезагрузить заданиеЗаданиеРаздел 4.3.7

Таблица операций Задания в IPP 1.1

Операции задания Send-Document (Отправить документ) и Send-URI (Отправить URI) используются для добавления Documents (документов) в существующее задание, созданное с помощью операции Create-Job (Создать задание).

4.1. Общая семантика

Все операции IPP требуют некоторых общих параметров и атрибутов операций. Эти общие элементы и их семантические характеристики определены и описаны более подробно в следующих разделах.

4.1.1. Обязательные параметры

Каждый запрос операции содержит следующие ТРЕБУЕМЫЕ параметры:

  • «номер версии» — «version-number«
  • «идентификатор операции» — «operation-id«
  • «идентификатор запроса» — «request-id«
  • атрибуты, ТРЕБУЕМЫЕ для этого типа запроса.

Каждый ответ операции содержит следующие ОБЯЗАТЕЛЬНЫЕ параметры:

  • «номер версии» — «version-number«
  • «код состояния» — «status-code«
  • «идентификатор запроса» — «request-id«, который был предоставлен в соответствующем запросе,
  • атрибуты, которые ОБЯЗАТЕЛЬНЫ для этого типа ответа.

Документ кодирования и транспорта [RFC8010] определяет специальные правила для кодирования этих параметров. Все остальные элементы операций представлены с использованием более общих правил кодирования для атрибутов и групп атрибутов.

4.1.2. Идентификаторы операций и идентификаторы запросов

Каждый запрос операции IPP включает в себя идентифицирующее значение «идентификатор операции». Допустимые значения определены в разделе «Поддерживаемые операции» атрибута принтера (см. Раздел 5.4.15). Клиент указывает, какая операция запрашивается, указав правильное значение «идентификатор операции».

Кроме того, каждый вызов операции идентифицируется значением «request-id». Для каждого запроса Клиент выбирает «идентификатор запроса», который ДОЛЖЕН быть целым числом (возможно, уникальным, в зависимости от требований Клиента) в диапазоне от 1 до 2 ** 31 — 1 (включительно). Этот «идентификатор запроса» позволяет клиентам управлять несколькими невыполненными запросами. Принимающий объект IPP (принтер, задание и т. Д.) Копирует все 32 бита предоставленного клиентом атрибута «request-id» в ответ, чтобы клиент мог сопоставить ответ с правильным невыполненным запросом, даже если «request- id «вне диапазона. Если запрос завершается до получения полного «идентификатора запроса», объект IPP отклоняет запрос и возвращает ответ с «идентификатором запроса», равным 0.

Примечание. В некоторых случаях транспортный протокол под IPP может быть протоколом, ориентированным на установление соединения, который делает невозможным для Клиента получение ответов в любом порядке, отличном от порядка, в котором были отправлены соответствующие запросы. В таких случаях атрибут «request-id» не был бы необходим для правильной работы протокола. Однако в других транспортных сопоставлениях ответы на операции могут возвращаться в любом порядке, и в этом случае «идентификатор запроса» является существенным.

4.1.3. Атрибуты

Операционные запросы и ответы состоят из групп атрибутов и / или данных документа. Группы атрибутов:

  • Атрибуты операции: эти атрибуты передаются в операции и влияют на поведение объекта IPP при обработке запроса операции, а также могут влиять на другие атрибуты или группы атрибутов. Некоторые атрибуты операций описывают данные документа, связанные с заданием на печать, и связаны с новыми объектами задания; однако большинство атрибутов операции не сохраняются после срока действия операции. Описание каждого атрибута операции включает в себя операторы соответствия, указывающие, какие атрибуты операции ТРЕБУЮТСЯ, а какие НЕОБЯЗАТЕЛЬНЫ для поддержки объекта IPP, а также какие атрибуты Клиент ДОЛЖЕН предоставлять в запросе, а объект IPP ДОЛЖЕН предоставлять в ответе.
  • Атрибуты шаблона задания: эти атрибуты влияют на обработку задания. Клиент МОЖЕТ предоставлять атрибуты шаблона задания в запросе на создание задания, и принимающий объект ДОЛЖЕН быть готов к приему всех поддерживаемых атрибутов. Позже к объекту задания можно будет обратиться, чтобы выяснить, какие атрибуты шаблона задания были изначально запрошены в запросе на создание задания, и такие атрибуты возвращаются в ответе как атрибуты объекта задания. К объекту «Принтер» можно обратиться с запросом к его атрибутам «Шаблон работы», чтобы выяснить, какие типы возможностей обработки задания поддерживаются и / или каковы способы обработки задания по умолчанию, хотя такие атрибуты возвращаются в ответе как атрибуты объекта «Принтер». Атрибут операции «ipp-attribute-fidelity» влияет на обработку всех предоставленных клиентом атрибутов шаблона работы — полное описание «ipp-attribute-fidelity» и его связь с другими атрибутами смотри в разделе 4.2.1.1 и приложении C.
  • Атрибуты объекта задания: эти атрибуты возвращаются в ответ на операцию запроса, направленную на объект задания.
  • Атрибуты объекта принтера: эти атрибуты возвращаются в ответ на операцию запроса, направленную на объект принтера.
  • Неподдерживаемые атрибуты: в запросе на создание задания клиент предоставляет набор атрибутов операции и шаблона задания. Если какой-либо из этих атрибутов или их значения не поддерживаются объектом «Принтер», объект «Принтер» ДОЛЖЕН возвратить набор неподдерживаемых атрибутов в ответе. Раздел 4.1.7, Раздел 4.2.1.2 и Приложение C дают полное описание того, как атрибуты шаблона задания, предоставленные Клиентом в запросе на создание задания, обрабатываются объектом Printer и как неподдерживаемые атрибуты возвращаются клиенту. Из-за расширяемости любой объект IPP может получить запрос, содержащий новые или неизвестные атрибуты или значения, для которых он не поддерживается. В таких случаях объект IPP обрабатывает все, что может, и возвращает неподдерживаемые атрибуты в ответе. Группа «Неподдерживаемые атрибуты» определяется для всех ответов на операции для возврата неподдерживаемых атрибутов, которые Клиент указал в запросе.

Далее в этом разделе каждая операция формально определяется путем определения допустимых и ожидаемых групп атрибутов для каждого запроса и ответа. Модель определяет конкретный порядок для каждой группы в каждом запросе или ответе, но атрибуты в каждой группе могут быть в любом порядке, если не указано иное.

Атрибуты в группе ДОЛЖНЫ быть уникальными; если атрибут с одним и тем же именем встречается более одного раза, группа деформируется. Клиенты НЕ ДОЛЖНЫ отправлять такие некорректные запросы, а принтеры НЕ ДОЛЖНЫ возвращать такие некорректные ответы. Если такой искаженный запрос передается на принтер, принтер ДОЛЖЕН (1) отклонить запрос с кодом состояния «client-error-bad-request» (РЕКОМЕНДУЕТСЯ — см. Приложение B.1.4.1) или (2) обычно обрабатывать запрос после выбора только одного из экземпляров атрибута, в зависимости от реализации. Какой атрибут выбирается при наличии дублированных атрибутов, зависит от реализации. Принтер IPP НЕ ДОЛЖЕН использовать значения из более чем одного такого дублированного экземпляра атрибута.

Каждое определение атрибута включает имя атрибута, за которым следует имя его синтаксиса (ов) атрибута в скобках. Кроме того, за каждым атрибутом ‘integer’ может следовать допустимый диапазон в скобках (m: n) для значений этого атрибута. За каждым атрибутом «текст» или «имя» может следовать максимальный размер в октетах в скобках (размер) для значений этого атрибута. Для получения более подробной информации о синтаксической нотации атрибутов см. Описания этих синтаксисов атрибутов в Разделе 5.1.

Примечание. Данные документа, включенные в операцию, не являются строго атрибутом, но для упорядочивания они рассматриваются как специальная группа атрибутов. Единственными операциями, определенными в этом документе, которые поддерживают предоставление данных документа в запросе операции, являются Print-Job и Send-Document. В этом документе не определены операции, ответы которых включают данные документа.

Некоторые операции ТРЕБУЮТСЯ для поддержки объектов IPP; остальные НЕОБЯЗАТЕЛЬНЫ (см. раздел 6.2.2). Поэтому, прежде чем использовать ДОПОЛНИТЕЛЬНУЮ операцию, Клиент ДОЛЖЕН сначала использовать НЕОБХОДИМУЮ операцию Get-Printer-Attributes, чтобы запросить у атрибута принтера «операции-поддерживаемые», чтобы определить, какие ОПЦИОНАЛЬНЫЕ операции действительно поддерживаются. Клиент НЕ ДОЛЖЕН использовать ДОПОЛНИТЕЛЬНУЮ операцию, которая не поддерживается. Когда объект IPP получает запрос на выполнение операции, которую он не поддерживает, он ДОЛЖЕН вернуть код состояния «серверная ошибка, операция не поддерживается» (см. Приложение B.1.5.2). Объект IPP не соответствует требованиям, если он не поддерживает операцию REQUIRED.

4.1.4. Набор символов и атрибуты задания на естественном языке

Некоторые атрибуты Job и Printer имеют значения, которые являются текстовыми строками и именами, предназначенными для понимания человеком, а не машинным пониманием (см. Описания синтаксиса атрибутов ‘text’ и ‘name’ в Разделе 5.1). В следующих разделах описываются два специальных атрибута операции, называемые «attribute-charset» и «attribute-natural-language», значения которых используются при интерпретации других атрибутов с использованием синтаксисов атрибутов «text» и «name». Для операций создания задания реализация IPP Printer также сохраняет эти два атрибута с новым объектом задания в качестве атрибутов состояния задания.

Атрибуты «attribute-charset» и «attribute-natural-language» ДОЛЖНЫ быть первыми двумя атрибутами в каждом запросе и ответе IPP, как часть начальной группы «Атрибуты операции» сообщения IPP. Атрибут «attribute-charset» ДОЛЖЕН быть первым атрибутом в группе, а атрибут «attribute-natural-language» ДОЛЖЕН быть вторым атрибутом в группе.

Для краткости в этом документе эти описания атрибутов операций не повторяются с каждым запросом операции и ответом, а вместо этого имеют ссылку на этот раздел.

4.1.4.1. Атрибуты операции Запроса

Клиент ДОЛЖЕН предоставить, а объект Printer ДОЛЖЕН поддерживать следующие ОБЯЗАТЕЛЬНЫЕ атрибуты операции в каждом запросе операции IPP:

«attributes-charset» (charset):

Этот атрибут операции идентифицирует набор символов (набор кодированных символов и метод кодирования), используемый любыми атрибутами text и name, которые Клиент указывает в этом запросе. Он также идентифицирует кодировку, которую объект «Принтер» ДОЛЖЕН использовать (если поддерживается) для всех атрибутов «текст» и «имя» и сообщений о состоянии, которые объект «Принтер» возвращает в ответ на этот запрос. См. Разделы 5.1.2 и 5.1.3 для определения синтаксиса атрибутов «текст» и «имя».

Все клиенты и объекты IPP ДОЛЖНЫ поддерживать кодировку utf-8 [RFC3629] и МОГУТ поддерживать дополнительные кодировки при условии, что они зарегистрированы в IANA [RFC2978] [IANA-CS]. Если объект Printer не поддерживает предоставленное клиентом значение кодировки, объект Printer ДОЛЖЕН отклонить запрос, установить в атрибуте «charset» значение «utf-8» и вернуть «client-error-charset-not» -поддерживаемый ‘status-code’ и любые атрибуты ‘text’ или ‘name’ с использованием кодировки ‘utf-8’. Принтер МОЖЕТ вернуть любые атрибуты в группу «Неподдерживаемые атрибуты» (см. Разделы 4.1.7 и 4.2.1.2). Объект «Принтер» ДОЛЖЕН указывать поддерживаемые наборы символов в качестве значений атрибута «поддерживается набор символов» (см. Раздел 5.4.18), чтобы Клиент мог запрашивать, какие наборы символов поддерживаются.

Примечание для разработчиков клиента: поскольку объекты IPP требуются только для поддержки кодировки utf-8, чтобы максимизировать взаимодействие с несколькими реализациями объектов IPP, клиент ДОЛЖЕН предоставить utf-8 в атрибуте операции attribute-charset даже если Клиент только передает и может представить более простую кодировку, такую как US-ASCII [RFC20] или ISO-8859-1 [ISO8859-1]. Затем клиент должен будет отфильтровать, выполнить преобразование кодировки или заменить те символы, которые возвращаются в ответе, который он не может представить своему пользователю. С другой стороны, если и объект Client, и объекты IPP также поддерживают общую кодировку помимо utf-8, клиент может использовать эту кодировку, чтобы избежать преобразования кодировки или потери данных.

См. Описание синтаксиса атрибута «charset» в разделе 5.1.8 для синтаксической и семантической интерпретации значений этого атрибута и, например, значений.

«attributes-natural-language» (naturalLanguage):

Этот атрибут операции идентифицирует естественный язык [RFC5646], используемый любыми атрибутами «text» и «name», которые Клиент предоставляет в этом запросе. Этот атрибут также определяет естественный язык, который объект «принтер» ДОЛЖЕН использовать для всех атрибутов «текст» и «имя» и сообщений о состоянии, которые объект «Принтер» возвращает в ответ на этот запрос. См. Описание синтаксиса атрибута «NaturalLanguage» в Разделе 5.1.9 для синтаксической и семантической интерпретации значений этого атрибута и, например, значений.

Для поддержки объекта Printer не требуется ТРЕБУЕМЫХ естественных языков. Тем не менее атрибут «созданный-поддерживаемый-поддерживаемый-язык» принтера определяет естественные языки, поддерживаемые объектом «Принтер» и любые содержащиеся в нем задания для всех текстовых строк, созданных объектом IPP. Клиент МОЖЕТ запросить этот атрибут, чтобы определить, какой естественный язык (языки) поддерживается для сгенерированных сообщений.

Для любого из атрибутов, для которых объект «Принтер» генерирует текст, т. Е. Для «сообщения о состоянии задания», «сообщения о состоянии принтера» и сообщений о состоянии (см. Раздел 4.1.6), объект «Принтер» ДОЛЖЕН быть в состоянии генерировать эти текстовые строки на любом из поддерживаемых им естественных языков. Если Клиент запрашивает естественный язык, который не поддерживается, объект «Принтер» ДОЛЖЕН возвращать эти сгенерированные сообщения на сконфигурированном естественном языке Принтера, как указано атрибутом «Конфигурируемый естественный язык» Принтера (см. Раздел 5.4.19).

Для других атрибутов «текст» и «имя», предоставленных клиентом, системой аутентификации, оператором, администратором или производителем (т. Е. Для «имя-пользователя-задания», «имя-принтера» (имя), «принтер-имя» location «(текст),» printer-info «(текст) и» printer-make-and-model «(текст)), объект Printer требуется только для поддержки настроенного естественного языка принтера, идентифицируемого принтером» «настроенный на естественном языке», хотя разрешена поддержка дополнительных естественных языков для этих атрибутов.

Для любого атрибута «текст» или «имя» в запросе, который отличается от естественного языка, отличного от значения, указанного в атрибуте операции «атрибуты-естественный язык», Клиент ДОЛЖЕН использовать механизм переопределения естественного языка (см. Разделы 5.1. 2.2 и 5.1.3.2) для каждого указанного значения атрибута. Клиент МОЖЕТ избыточно использовать механизм переопределения естественного языка, то есть использовать его, даже если значение находится на том же естественном языке, что и значение, указанное в атрибуте операции «атрибуты-естественный язык» запроса.

Объект IPP ДОЛЖЕН принимать любой естественный язык и любое переопределение естественного языка, независимо от того, поддерживает ли объект IPP этот естественный язык или нет (и не зависит от значения атрибута операции «ipp-attribute-fidelity»). Таким образом, объект IPP принимает все предоставленные Клиентом значения, независимо от того, какие значения содержатся в атрибуте принтера «сгенерированный естественный язык поддерживается». Этот атрибут «сгенерированный на естественном языке поддерживается» применяется только к сгенерированным сообщениям, а не к предоставленным Клиентом сообщениям. Объект IPP ДОЛЖЕН помнить этот естественный язык для всех предоставленных Клиентом атрибутов, и при возврате этих атрибутов в ответ на запрос объект IPP ДОЛЖЕН указывать этот естественный язык.

Каждое значение, тип синтаксиса атрибута которого — «текст» или «имя» (см. Разделы 5.1.2 и 5.1.3), имеет ассоциированный естественный язык. В этом документе не указано, как эта связь хранится в объекте «Принтер» или «Задание». Когда такое значение кодируется в запросе или ответе, естественный язык является неявным или явным:

  • В неявном случае значение содержит только значение text / name, а язык указывается атрибутом операции «attribute-natural-language» в запросе или ответе (см. Разделы 5.1.2.1 и 5.1.3.1).
  • В явном случае (также известном как случай переопределения естественного языка) значение содержит как язык, так и значение текста / имени (см. Разделы 5.1.2.2 и 5.1.3.2).

Например, атрибут «имя-задания» МОЖЕТ быть предоставлен клиентом в запросе на создание задания. Текстовое значение для этого атрибута будет на естественном языке, определяемом атрибутом attribute-natural-language, или, если он отличается, как определено механизмом переопределения естественного языка. При наличии объект IPP будет использовать значение атрибута «имя-задания», чтобы заполнить атрибут «Имя-задания» задания. Всякий раз, когда какой-либо Клиент запрашивает атрибут задания «имя-задания», объект IPP возвращает атрибут как сохраненный и использует механизм переопределения естественного языка для указания естественного языка, если он отличается от того, который указан в «атрибутах-естественном языке» Атрибут операции ответа. Объект IPP МОЖЕТ избыточно использовать механизм переопределения естественного языка, то есть использовать его, даже если значение находится на том же естественном языке, что и значение, указанное в атрибуте операции «атрибуты-естественный язык» ответа.

Объект IPP НЕ ДОЛЖЕН отклонять запрос на основе предоставленного естественного языка в атрибуте операции «attribute-natural-language» или в любом атрибуте, который использует переопределение естественного языка.

Примечание. Добавление атрибутов «текст» или «имя» с несовместимой комбинацией естественного языка и кодировки может привести к нежелательному поведению. Например, предположим, что принтер поддерживает наборы символов «utf-8», «iso-8859-1» и «iso-8859-7». Предположим также, что он поддерживает естественные языки «en» (английский), «fr» (французский) и «el» (греческий). Хотя принтер поддерживает кодировку iso-8859-1 и естественный язык el, он, вероятно, не поддерживает сочетание строк греческого текста с использованием кодировки iso-8859-1. Принтер обрабатывает эту кажущуюся несовместимость по-разному, в зависимости от контекста, в котором она возникает:

  • В запросе на создание задания: если Клиент предоставляет атрибут «текст» или «имя» (например, атрибут операции «имя-задания»), который использует явно несовместимую комбинацию, это выбор Клиента, который не влияет на Принтер или его правильная работа. Следовательно, принтер просто принимает значение, предоставленное клиентом, сохраняет его вместе с заданием и отвечает той же комбинацией, когда клиент (или любой клиент) запрашивает этот атрибут.
  • В операции типа запроса, такой как Get-Printer-Attributes: если Клиент запрашивает явно несовместимую комбинацию, Принтер отвечает (как описано в Разделе 4.1.4.2), используя настроенный для принтера естественный язык, а не естественный язык, запрошенный Клиент.

В любом случае принтер не отклоняет запрос из-за явной несовместимости. Потенциально несовместимая комбинация кодировки и естественного языка может возникать либо на глобальном уровне операций, либо на уровне атрибута за атрибутом переопределения естественного языка. Кроме того, поскольку ответ всегда включает в себя явную информацию о кодировке и на естественном языке, никогда не возникает вопроса или двусмысленности в том, как Клиент интерпретирует ответ.

4.1.4.2. Атрибуты операции ответа

Принтер ДОЛЖЕН предоставить, а Клиент ДОЛЖЕН поддерживать следующие ТРЕБУЕМЫЕ атрибуты операции в каждом ответе операции IPP / 1.1:

«attributes-charset» (charset):

Этот атрибут операции идентифицирует набор символов, используемый любыми атрибутами text и name, которые объект Printer возвращает в этом ответе. Значение в этом ответе ДОЛЖНО быть тем же, что и атрибут операции «attribute-charset», предоставленный клиентом в запросе. Если это невозможно (т. Е. Запрошенная кодировка не поддерживается), запрос был бы отклонен. Смотрите «attribute-charset», описанный в Разделе 4.1.4.1 выше.

Если объект Printer поддерживает больше, чем просто кодировку utf-8, объект Printer ДОЛЖЕН быть в состоянии выполнить преобразование кода между каждой из поддерживаемых кодировок на основе «максимально возможной точности», чтобы вернуть «текст» и « атрибуты name в кодировке, запрошенные клиентом. Тем не менее, некоторая потеря информации может произойти во время преобразования набора символов, в зависимости от используемых наборов символов. Например, в зависимости от реализации объект Printer может конвертировать из UTF-8 ’a’ в US-ASCII ’a’ (без потери информации); от ISO LATI 1 КАПИТАЛЬНОЙ ПИСЬМО А с ОСТРЫМ АКЦЕНТОМ до US-ASCII ’A’ (потеря акцента); или от японского символа кандзи UTF-8 до некоторой символьной ошибки ISO латинского 1, такой как ‘?’, эквивалент десятичного кода или отсутствие символа.

Сохраняет ли реализация, которая поддерживает более одной кодировки, данные в кодировке, предоставленной Клиентом, или выполняет преобразование кода в одну из других поддерживаемых кодировок, зависит от реализации. Стратегия должна пытаться свести к минимуму потерю информации во время преобразования кода. При каждом ответе такая реализация конвертирует из своей внутренней кодировки в запрошенную.

«attributes-natural-language» (naturalLanguage):

Этот атрибут операции идентифицирует естественный язык, используемый любыми атрибутами «text» и «name», которые объект IPP возвращает в этом ответе. В отличие от атрибута операции «attribute-charset», объект IPP МОЖЕТ вернуть естественный язык объекта Job или настроенный естественный язык Принтера, как определено атрибутом «сконфигурированного естественного языка» Принтера, а не естественный язык, предоставленный Клиент. Для любого атрибута «текст» или «имя» или сообщения о состоянии в ответе, который отличается от естественного языка, отличного от значения, возвращаемого в атрибуте операции «атрибуты-естественный язык», объект IPP ДОЛЖЕН использовать механизм переопределения естественного языка ( см. разделы 5.1.2.2 и 5.1.3.2) для каждого возвращаемого значения атрибута. Объект IPP МОЖЕТ избыточно использовать механизм переопределения естественного языка, то есть использовать его, даже если значение находится на том же естественном языке, что и значение, указанное в атрибуте операции «атрибуты-естественный язык» ответа.

4.1.5. Операционные цели

Все операции IPP направлены на объекты IPP. Для операций с принтером операция всегда направлена на объект «Принтер» с использованием одного из его URI, то есть одного из значений в атрибуте «Printer-uri-Поддерживаемый» принтера. Даже если объект Printer поддерживает более одного URI, Клиент предоставляет только один URI в качестве цели операции. Клиент идентифицирует целевой объект, указав правильный URI в атрибуте операции «printer-uri».

Для операций Job операция направлена на:

  • Объект Printer, который создал объект Job, используя URI объекта Printer и числовой идентификатор задания (ID задания). Поскольку объект Printer, создавший объект Job, сгенерировал идентификатор задания, он ДОЛЖЕН иметь возможность правильно связать предоставленный клиентом идентификатор задания с правильным объектом задания. Клиент предоставляет URI принтера в атрибуте операции «printer-uri» и идентификатор задания в атрибуте операции «идентификатор задачи».
  • Сам объект задания, используя URI задания. В этом случае Клиент идентифицирует целевой объект, указав правильный URI в атрибуте операции «job-uri» (uri) (раздел 5.3.2).

Клиенты ДОЛЖНЫ отправлять атрибуты операции printer-uri и job-id в операциях Job.

Если операция направлена на объект Job напрямую с использованием URI задания, клиент НЕ ДОЛЖЕН включать избыточный атрибут операции «идентификатор задания».

Атрибуты цели операции — это ОБЯЗАТЕЛЬНЫЕ атрибуты операции, которые включены в каждый запрос операции. Подобно атрибутам charset и естественного языка (см. Раздел 4.1.4), целевые атрибуты операции являются специально упорядоченными атрибутами операции. Во всех случаях целевые атрибуты операции сразу же следуют за атрибутами «attribute-charset» и «attribute-natural-language» в группе «Атрибуты операции»; Тем не менее, конкретные правила заказа следующие:

  • В случае, когда существует только один целевой атрибут операции (т. е. только атрибут «printer-uri» или только атрибут «job-uri»), этот атрибут ДОЛЖЕН быть третьим атрибутом в группе «Атрибуты операции».
  • В случае, когда в операциях Job используются два атрибута цели операции (т. е. атрибуты «printer-uri» и «job-id»), атрибут «printer-uri» ДОЛЖЕН быть третьим атрибутом и атрибутом «job-id» ДОЛЖЕН быть четвертым атрибутом.

Во всех случаях целевые URI, содержащиеся в теле запросов и ответов операции IPP, ДОЛЖНЫ быть в абсолютном формате, а не в относительном формате (относительный URL-адрес идентифицирует ресурс в области действия HTTP-сервера, но не включает схему, хост или порт).

Следующие правила применяются к использованию номеров портов в URI, которые идентифицируют объекты IPP:

  1. Если схема URI позволяет явно включить номер порта в строку URI, а номер порта указан в URI, то этот номер порта ДОЛЖЕН использоваться Клиентом для связи с объектом IPP.
  2. Если схема URI позволяет явно включить номер порта в строку URI, а номер порта не указан в URI, то номер порта по умолчанию, подразумеваемый этой схемой URI, ДОЛЖЕН использоваться Клиентом для связи с IPP. объект.
  3. Если схема URI не позволяет указывать явный номер порта в URI, то номер порта по умолчанию, подразумеваемый этим URI, ДОЛЖЕН использоваться Клиентом для связи с объектом IPP.

Примечание. «Протокол интернет-печати / 1.1: схема URL-адреса IPP» [RFC3510] и «Протокол интернет-печати (IPP) через транспортную привязку HTTPS и схему URI« ipps »[RFC7472] определяют отображение IPP на HTTP и HTTPS соответственно. и определить и зарегистрировать номер порта по умолчанию.

4.1.6. Значения кода состояния ответа операции и сообщения о состоянии

Каждый ответ операции включает в себя ОБЯЗАТЕЛЬНЫЙ параметр «код состояния», ДОЛЖЕН включать атрибут операции «статус-сообщение» и МОЖЕТ включать атрибут операции «подробный статус-сообщение». Ответ Print-URI и Send-URI МОЖЕТ также включать атрибут операции «document-access-error».

4.1.6.1. «status-code» (type2 enum) — код состояния

ТРЕБУЕМЫЙ параметр «код состояния» предоставляет информацию об обработке запроса.

Код статуса предназначен для использования автоматами. Клиентская реализация IPP ДОЛЖНА преобразовывать значения кода состояния в любое локализованное сообщение, которое имеет семантическое значение для конечного пользователя.

Значение «код состояния» — это числовое значение, которое имеет семантическое значение. Синтаксис «код состояния» аналогичен «перечислению type2» (см. Раздел 5.1 («Синтаксис атрибутов»)), за исключением того, что значения могут находиться в диапазоне от 0x0000 до 0x7fff. Приложение B описывает и назначает значения кодов состояния и предлагает соответствующее сообщение о статусе для каждого кода состояния для использования Клиентом, когда естественным языком пользователя является английский.

Если принтер выполняет операцию без ошибок и не сталкивается с какими-либо проблемами, он ДОЛЖЕН возвратить в ответе код состояния «success-ok». Смотри Приложение Б.

Если Клиент предоставляет неподдерживаемые значения для следующих параметров или атрибутов операции, объект Printer ДОЛЖЕН отклонить операцию, МОЖЕТ вернуть значение неподдерживаемого атрибута в группе Unsupported Attributes и ДОЛЖЕН вернуть указанный код состояния:

Таблица 1 - Значения кода состояния для всех запросов
Таблица 1 — Значения кода состояния для всех запросов

Если Клиент предоставляет неподдерживаемые значения для других атрибутов или неподдерживаемые атрибуты, Принтер возвращает код состояния, определенный в Разделе 4.1.7 («Неподдерживаемые атрибуты»).

4.1.6.2. «status-message» (text(255)) — статус-сообщение

РЕКОМЕНДУЕМЫЙ атрибут операции «статус-сообщение» предоставляет краткое текстовое описание статуса операции. Синтаксис атрибута «status-message» — «text (255)», поэтому максимальная длина составляет 255 октетов (см. Раздел 5.1.2). Сообщение о статусе предназначено для конечного пользователя. Если ответ содержит атрибут «статус-сообщение», клиент IPP может просматривать или отображать сообщения некоторым образом, зависящим от реализации. Атрибут «status-message» особенно полезен для более поздней версии Принтера для возврата в качестве дополнительной информации для пользователя-пользователя, чтобы сопровождать код состояния, который более ранняя версия Клиента может не понять.

Если принтер поддерживает атрибут операции «статус-сообщение», он ДОЛЖЕН иметь возможность генерировать это сообщение на любом из естественных языков, определенных атрибутом «генерируемого-естественного языка-поддерживаемого» принтера, и ДОЛЖЕН учитывать любое поддерживаемое значение для « attribute-natural-language «атрибут операции (раздел 4.1.4.1) клиентского запроса. В приложении B предлагается текст сообщения о состоянии, возвращенного принтером для использования на естественном английском языке.

Как описано в Разделе 4.1.4.1, для любого возвращенного атрибута ‘text’, если есть возможность генерировать это сообщение, Принтер использует естественный язык, указанный значением «attribute-natural-language» в запросе Клиента, если поддерживается; в противном случае принтер использует значение в собственном атрибуте принтера, настроенном на естественном языке.

Если принтер поддерживает атрибут операции «status-message», он ДОЛЖЕН использовать ОБЯЗАТЕЛЬНУЮ кодировку «utf-8» для возврата сообщения о состоянии для следующих значений кода состояния ошибки (см. Приложение B): «client-error-bad- request ‘,’ client-error-charset-not-Поддерживается ‘,’ server-error-internal-error ‘,’ server-error-operation-not-Поддерживается ‘и’ Server-Error-Version-Not-Supported ‘. В этом случае он ДОЛЖЕН установить значение атрибута операции «attribute-charset» равным «utf-8» в ответе об ошибке.

4.1.6.3. «detailed-status-message» (text(MAX)) — подробное статус-сообщение

НЕОБЯЗАТЕЛЬНЫЙ атрибут операции «подробное состояние-сообщение» предоставляет дополнительную более подробную техническую и специфичную для реализации информацию об операции для администраторов или других опытных технических специалистов. Синтаксис атрибута «подробное-статус-сообщение» — «текст (MAX)», поэтому максимальная длина составляет 1023 октета (см. Раздел 5.1.2). Если принтер поддерживает атрибут операции «подробное сообщение о состоянии», он ДОЛЖЕН локализовать сообщение, если только такая локализация не затеняет технический смысл сообщения. Клиенты НЕ ДОЛЖНЫ пытаться проанализировать значение этого атрибута. См. Атрибут операции «document-access-error» (раздел 4.1.6.4) для дополнительных ошибок, которые может обработать программа.

4.1.6.4. «document-access-error» (text(MAX)) — ошибка доступа к документу

Этот необязательный атрибут операции предоставляет дополнительную информацию о любых ошибках доступа к документу, с которыми столкнулся принтер до того, как он возвратил ответ на операцию Print-URI (раздел 4.2.2) или Send-URI (раздел 4.3.2). Для ошибок в протоколе, определенных схемой URI в атрибуте операции «document-uri», таких как «http:» или «ftp:», код ошибки возвращается в скобках, за которым следует URI. Например:

(404) http://www.example.com/filename.pdf

Большинство интернет-протоколов используют десятичные коды ошибок (в отличие от IPP), поэтому представление кодов ошибок ASCII является десятичным.

4.1.7. Неподдерживаемые атрибуты

Группа «Неподдерживаемые атрибуты» содержит атрибуты, которые не поддерживаются операцией. Эта группа в первую очередь предназначена для операций создания задания, но все операции могут возвращать эту группу. Принтер ДОЛЖЕН включить в ответ группу «Неподдерживаемые атрибуты», если код состояния является одним из следующих:

  • ’successful-ok-ignored-or-substituted-attributes’ (Успешно-ок-игнорировали или-замещенные-атрибуты)
  • ’successful-ok-conflicting-attributes’ (Успешно-ок-конфликтующие-атрибуты)
  • ’client-error-attributes-or-values-not-supported’ (Ошибка клиента атрибут не поддерживается)
  • ’client-error-conflicting-attributes’ (Клиент-ошибка конфликтующей-атрибуты)

Если код состояния является одним из четырех, указанных в предыдущем абзаце, группа «Неподдерживаемые атрибуты» ДОЛЖНА содержать все эти атрибуты и только те атрибуты, которые:

  • а. атрибут операции или шаблона задания, указанный в запросе
  • б. не поддерживается принтером. Ниже приведены подробные сведения о трех категориях «неподдерживаемых» атрибутов.

Если код состояния является одним из тех, которые указаны в таблице 1 в разделе 4.1.6.1, группа НЕОБЯЗАТЕЛЬНЫХ неподдерживаемых атрибутов содержит неподдерживаемый параметр или атрибут, указанный в этой таблице.

Если принтер не возвращает какие-либо неподдерживаемые атрибуты в ответе, принтер ДОЛЖЕН опустить группу «Неподдерживаемые атрибуты», а не отправлять пустую группу. Однако Клиент ДОЛЖЕН иметь возможность принять пустую группу.

Неподдерживаемые атрибуты делятся на три категории:

  1. Принтер не поддерживает предоставленный атрибут (независимо от его синтаксиса или значения).
  2. Принтер поддерживает этот атрибут, но он не поддерживает некоторые или все конкретные синтаксисы атрибутов или значения, предоставленные Клиентом, т. е. Принтер не имеет синтаксисов или значений этих атрибутов в своем соответствующем атрибуте «xxx-support»
  3. Принтер поддерживает предоставленные атрибуты и значения, но конкретные значения конфликтуют друг с другом, потому что они нарушают ограничение, например, неспособность сшивать прозрачные пленки.

В случае неподдерживаемого имени атрибута принтер возвращает предоставленный клиентом атрибут с подставленным значением «неподдерживаемый». Тип синтаксиса этого значения — «out-of-band», и его кодировка определяется специальными правилами для «out-of-band» значений в документе «Кодирование и транспорт» [RFC8010]. Его значение указывает на отсутствие поддержки самого атрибута — см. Начало Раздела 5.1 в этом документе.

В случае поддерживаемого атрибута с одним или несколькими неподдерживаемыми синтаксисами или значениями атрибутов Принтер просто возвращает предоставленный Клиентом атрибут с неподдерживаемыми синтаксисами или значениями атрибута, предоставленными Клиентом. Это указывает на поддержку атрибута, но не на поддержку этого конкретного синтаксиса или значения атрибута. Если Клиент предоставляет многозначный атрибут с более чем одним значением, и Принтер поддерживает атрибут, но поддерживает только подмножество предоставленных Клиентом синтаксисов или значений атрибута, Принтер ДОЛЖЕН возвращать только те синтаксисы или значения атрибута, которые не поддерживаются.

В случае двух (или более) поддерживаемых значений атрибутов, которые конфликтуют друг с другом (хотя каждое из них поддерживается независимо, значения конфликтуют при совместном запросе в одном и том же задании), принтер ДОЛЖЕН вернуть все значения, которые он игнорирует или заменяет разрешить конфликт, но не любые значения, которые он все еще использует. Выбор именно того, как разрешить конфликт, зависит от реализации. См. Раздел 4.2.1.2 и Приложение C. См. Руководства разработчика [RFC3196] [PWG5100.19] для примеров.

4.1.8. Версии

Каждый запрос и ответ операции содержит параметр «номер версии». Каждое значение параметра «номер версии» имеет вид «X.Y», где X — это номер основной версии, а Y — номер вспомогательной версии. Включая номер версии в запрос клиента, он позволяет клиенту определить, какую версию IPP он заинтересован в использовании, т. Е. Версию, требования соответствия которой клиент может зависеть от выполнения принтера.

Если объект IPP не поддерживает этот основной номер версии, предоставленный Клиентом, т. Е. Часть «основного номера версии» параметра «номер-версии» не соответствует ни одному из значений «Принтер-поддерживаемых версий ipp» принтера. атрибут (см. раздел 5.4.14), объект ДОЛЖЕН ответить кодом состояния «server-error-version-not-Поддерживается» вместе с ближайшим номером версии, который поддерживается (см. Приложение B.1.5.4). Если основной номер версии поддерживается, но вспомогательный номер версии не поддерживается, объект IPP ДОЛЖЕН принять запрос и попытаться его выполнить (или отклонить запрос, если операция не поддерживается); в противном случае он отклоняет запрос и возвращает код состояния «ошибка сервера версии не поддерживается». Во всех случаях объект IPP ДОЛЖЕН возвращать поддерживаемое им значение «номер версии», наиболее близкое к номеру версии, указанному клиентом в запросе.

Там нет согласования версий как таковых. Однако, если Клиент получил код состояния «ошибка сервера версии не поддерживается» от объекта IPP, Клиент ДОЛЖЕН повторить попытку с другим номером версии. Клиент МОЖЕТ также определить поддерживаемые версии либо из каталога, соответствующего Приложению D, либо путем запроса атрибута принтера «ipp-version-support» (см. Раздел 5.4.14), чтобы определить, какие версии поддерживаются.

Реализация объекта IPP / 1.1 ДОЛЖНА поддерживать версию 1.1, то есть соответствовать требованиям соответствия IPP / 1.1, указанным в этом документе и [RFC8010]. Реализации IPP ДОЛЖНЫ принимать любой запрос с основной версией ‘1’ или ‘2’ или отклонять запрос, если операция не поддерживается.

Существует только одно понятие «номер версии», которое охватывает как изменения модели IPP, так и изменения протокола IPP. Изменения в основном номере версии документа «Модель и семантика» могут указывать на структурные или синтаксические изменения, которые делают невозможными для более старых версий клиентов и принтеров IPP правильный анализ и правильную обработку новых или измененных атрибутов, операций и ответов. Если основной номер версии изменяется, дополнительный номер версии устанавливается на ноль. Например, добавление ОБЯЗАТЕЛЬНОГО атрибута «ipp-attribute-fidelity» к версии «1.1» (если бы он не был частью версии «1.0») потребовало бы изменения основного номера версии, поскольку принтер IPP / 1.0 не обработал бы запрос с правильной семантикой, содержащей атрибут «ipp-attribute-fidelity», о котором он не знал. Элементы, которые могут повлиять на изменение основного номера версии, включают любые изменения в документе «Модель и семантика» (этот документ) или в самом документе «Кодирование и транспорт» [RFC8010], например:

  • изменение порядка упорядоченных атрибутов или наборов атрибутов
  • изменения в синтаксисе существующих атрибутов
  • добавление REQUIRED (для поддержки объекта IPP) групп атрибутов операций.
  • добавление значений к существующим НЕОБХОДИМЫМ атрибутам операции
  • добавление ТРЕБУЕМЫХ операций

Изменения в дополнительном номере версии указывают на добавление новых функций, атрибутов и значений атрибутов, которые могут быть не поняты всеми объектами IPP, но которые могут быть проигнорированы, если не поняты. Элементы, которые могут повлиять на изменение вспомогательного номера версии, включают любые изменения объектов и атрибутов модели, но не правила кодирования и транспорта [RFC8010] (кроме добавления синтаксиса атрибутов). Примеры таких изменений:

  • группировка всех расширений, не включенных в предыдущую версию, в новую версию
  • добавление новых значений атрибутов
  • добавление новых атрибутов объекта
  • добавление необязательных (для поддержки объекта IPP) атрибутов операции (т. е. тех атрибутов, которые объект IPP может игнорировать, не путая клиентов)
  • добавление OPTIONAL (для поддержки объекта IPP) групп атрибутов операций (т. е. тех атрибутов, которые объект IPP может игнорировать, не путая клиентов)
  • добавление новых синтаксисов атрибутов
  • добавление необязательных операций
  • изменение атрибутов задания или атрибутов принтера с НЕОБЯЗАТЕЛЬНОГО на ОБЯЗАТЕЛЬНОЕ или наоборот
  • добавление синтаксиса необязательных атрибутов к существующему атрибуту

Кодировка [RFC8010] параметра «номер версии» НЕ ДОЛЖНА изменяться в зависимости от номера версии (основной или вспомогательной). Это правило гарантирует, что все будущие версии будут обратно совместимы со всеми предыдущими версиями (по крайней мере, для проверки параметра «номер версии»). Кроме того, любые элементы протокола (атрибуты, коды ошибок, теги и т. Д.), Которые не переносятся из одной версии в другую, УСТАРЕЛИ, поэтому их никогда нельзя использовать с новой семантикой.

Реализации, которые поддерживают определенную версию, ДОЛЖНЫ поддерживать все предыдущие версии отслеживания стандартов. Поскольку каждая новая версия определяется (посредством выпуска нового документа спецификации IPP), эта версия будет указывать, какие предыдущие версии ДОЛЖНЫ и какие версии ДОЛЖНЫ поддерживаться в совместимых реализациях.

4.1.9. Операции по созданию задания — Job Creation Operations

Чтобы «отправить задание на печать» и создать новое задание, клиент выдает запрос на создание задания. Запрос на создание задания — это любой из следующих трех запросов:

  • Запрос задания на печать: Клиент, который хочет отправить задание на печать только с одним документом, может использовать операцию задания на печать. Операция позволяет Клиенту «проталкивать» данные Документа на Принтер путем включения данных Документа в сам запрос. Обратите внимание, что клиенты ДОЛЖНЫ вместо этого использовать запросы Create-Job и Send-Document, если они поддерживаются принтером, поскольку они позволяют осуществлять мониторинг и контроль работ во время представления данных документа.
  • Запрос Print-URI: клиент, который хочет отправить задание на печать только с одним документом (где принтер «вытягивает» данные документа вместо клиента, «отправляющего» данные на принтер), использует операцию Print-URI , В этом случае Клиент включает в запрос только URI-ссылку на данные документа (но не сами данные документа).
  • Запрос создания задания: клиент, который хочет отправить задание на печать с нулевым или большим количеством документов, использует операцию создания задания. За этой операцией следует произвольное количество операций Send-Document и / или Send-URI, каждая из которых создает новый Document для вновь созданного Job. Операция Send-Document включает в себя данные документа в запросе (клиент «выталкивает» данные документа на принтер), а операция Send-URI включает только ссылку URI на данные документа в запросе (принтер «вытягивает»). Данные документа из указанного местоположения). Последний запрос Send-Document или Send-URI для данного задания включает в себя атрибут операции «last-document», установленный в «true», указывающий, что это последний запрос.

В этом документе термин «запрос на создание задания» (Job Creation request) используется для обозначения любого из этих трех запросов на операцию.

Операция Create-Job, за которой следует только одна операция Send-Document, семантически эквивалентна операции Print-Job; однако Клиент ДОЛЖЕН использовать операции Create-Job и Send-Document (если они поддерживаются) для всех заданий с одним документом, чтобы обеспечить надежный контроль и мониторинг заданий. Print-Job — это ОБЯЗАТЕЛЬНАЯ операция (все реализации ДОЛЖНЫ ее поддерживать), тогда как Create-Job — РЕКОМЕНДУЕМАЯ операция, и, следовательно, некоторые реализации могут ее не поддерживать.

Время отправки работы — это момент времени, когда Клиент отправляет запрос на создание вакансии. Начальным состоянием каждой работы является состояние «в ожидании», «в ожидании» или «обработка» (см. Раздел 5.3.7). Когда принтер начинает обрабатывать задание на печать, состояние задания переходит к «обработке». Это называется временем обработки задания.

Во время отправки задания и во время получения операции проверки задания принтер ДОЛЖЕН сделать следующее:

  1. Обработайте предоставленные Клиентом атрибуты и либо примите, либо отклоните запрос
  2. Проверьте синтаксис и поддержку схемы любого предоставленного клиентом URI.

Во время отправки задания принтер ДОЛЖЕН проверять, поддерживаются ли предоставленные атрибуты, синтаксисы атрибутов и значения, сопоставляя их с соответствующими атрибутами «xxx-поддерживаемых» принтера. См. Раздел 4.1.7 для деталей. См. Руководства разработчика [RFC3196] [PWG5100.19] для получения инструкций по обработке запросов на создание заданий.

Во время отправки Работы Принтер МОЖЕТ выполнить проверки, зарезервированные для времени обработки Работы, например:

  1. Проверка формата данных документа
  2. Проверка фактического содержимого любого предоставленного Клиентом URI (разрешите ссылку и перейдите по ссылке на данные Документа)

Во время отправки Работы эти дополнительные проверки проверки времени обработки Работы по существу бесполезны, поскольку они требуют фактического анализа и интерпретации данных Документа, не гарантируют точности на 100% и ДОЛЖНЫ выполняться снова во время обработки Работы. Кроме того, в случае URI проверка доступности во время отправки Работы не гарантирует доступность во время обработки Работы. Кроме того, во время обработки задания принтер может обнаружить любое из следующих условий, которые не были обнаружены во время отправки задания:

  • ошибки времени выполнения в данных документа
  • вложенные данные документа в неподдерживаемом формате
  • ссылка на URI больше не действительна (т. е. сервер, на котором размещен документ, может быть недоступен)
  • любая другая ошибка обработки задания

Во время отправки задания принтер, особенно принтер без спулинга, МОЖЕТ принимать задания, для которых на нем недостаточно места. В такой ситуации Принтер МОЖЕТ прекратить чтение данных с Клиента на неопределенный период времени. Клиент ДОЛЖЕН быть готов к блокировке операции записи на неопределенный период времени (см. Раздел 6.1 («Требования к соответствию клиента»)).

Если у принтера слишком мало места для запуска нового задания, он МОЖЕТ отклонить новый запрос на создание задания. В этом случае принтер ДОЛЖЕН вернуть ответ (в ответ на отклоненный запрос) с кодом состояния «server-error-busy» (см. Приложение B.1.5.8), и он МОЖЕТ закрыть соединение до получения всех байты операции. Принтер ДОЛЖЕН указать, что он временно не может принимать задания, установив значение «spool-space-full» в его атрибуте «printer-state-reason» и удалив значение, когда он может принять другое задание (см. Раздел 5.4.12).

При получении кода состояния «server-error-busy» в ответе на операцию Клиент ДОЛЖЕН быть готов к тому, что Принтер закроет соединение до того, как Клиент отправит все данные (особенно для операции Print-Job). Клиент ДОЛЖЕН быть готов продолжать отправлять запрос на создание задания, пока принтер не примет запрос на создание задания.

Во время обработки задания, поскольку принтер уже ответил успешным кодом состояния в ответе на запрос на создание задания, если принтер обнаруживает ошибку, принтер не может сообщить конечному пользователю об ошибке с состоянием операции. код. В этом случае принтер, в зависимости от ошибки, может установить для атрибутов «Задание-состояние», «Причины-состояния-задания» и / или «Задание-состояния-сообщения» задания соответствующие значения (ий) так, чтобы последующие запросы могут сообщать правильный статус задания.

Примечание. Асинхронное уведомление о событиях определяется в «Протоколе печати через Интернет (IPP): уведомления о событиях и подписки» [RFC3995].

4.2. Операции Принтера (Printer Operations)

Все операции Принтера (Printer) направлены на Принтеры (Printers). Клиент (Client) ДОЛЖЕН всегда указывать атрибут операции «printer-uri«, чтобы определить правильную цель операции.

4.2.1. Операция Print-Job (Задание на печать)

Эта ТРЕБУЕМАЯ операция позволяет Клиенту (Client) отправить задание на печать (Print Job) только с одним документом (Document) и предоставить данные документа (Document data) (а не просто ссылку на данные). В Приложении C приведены предлагаемые шаги для обработки запросов на «создание заданий» (Job Creation) и их «операции«, а также «атрибуты шаблонов заданий» (Job Template attributes).

4.2.1.1. Запрос задания на печать

Следующие группы атрибутов предоставляются как часть запроса задания на печать:

Группа 1: Атрибуты операции

Natural Language and Character Set (Естественный язык и набор символов): атрибуты «attributes-charset» и «attributes-natural-language«, как описано в Разделе 4.1.4.1. Принтер (Printer) ДОЛЖЕН копировать эти значения в соответствующие атрибуты статуса работы, описанные в разделах 5.3.19 и 5.3.20.

Target (Цель): атрибут операции «printer-uri» (uri), который является целью этой операции, как описано в разделе 4.1.5.

Requesting User Name (Запрос имени пользователя): атрибут «requesting-user-name» (name(MAX)) ДОЛЖЕН быть предоставлен клиентом, как описано в разделе 9.3.

«job-name» (name (MAX)): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Он содержит предоставленное клиентом имя задания. Если этот атрибут предоставляется клиентом, его значение используется для атрибута «job-name» (имя-задания) вновь созданного задания. Клиент МОЖЕТ автоматически включать любую информацию, которая поможет Конечному Пользователю (End User) различать его/её Задания (Jobs), например, название прикладной программы, а также информацию из Документа (Document), такую как имя документа, тема документа или имя исходного файла. Если этот атрибут не предоставлен Клиентом, Принтер (Printer) генерирует имя для использования в атрибуте «job-name» вновь созданного Задания (смотри Раздел 5.3.5).

«ipp-attribute-fidelity» (boolean — логическое значение): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Значение ‘true‘ указывает, что требуется полная точность предоставленных клиентом атрибутов и значений шаблона задания (Job Template); в противном случае принтер ДОЛЖЕН отклонить запрос Print-Job (задания на печать). Значение ‘false‘ указывает, что разумная попытка распечатать задание является приемлемой, и принтер ДОЛЖЕН принять запрос Print-Job (задание на печать). Если принтер не указан, предполагается, что это значение равно ’false’. Все принтеры ДОЛЖНЫ поддерживать оба типа обработки заданий. Смотри Приложение C для полного описания «ipp-attribute-fidelity» и его связи с другими атрибутами, особенно атрибутом принтера «pdl-override-supported«.

«document-name» (name(MAX)): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Он содержит предоставленное клиентом название документа (Document name). Название документа МОЖЕТ отличаться от названия задания (Job name). Как правило, клиентское программное обеспечение автоматически предоставляет имя документа от имени конечного пользователя (End User), используя имя файла или имя, созданное приложением. Если этот атрибут указан, его значение может использоваться способом, определяемым каждой реализацией. Примеры включают следующее: распечатывается вместе с заданием (стартовый лист задания, украшения страниц и т. д.), Используется инструментами управления учетными записями или отслеживания ресурсов или даже сохраняется вместе с Документом в качестве атрибута уровня документа (Document-level).

«compression» (type2 keyword): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Предоставленный клиентом атрибут операции «compression» идентифицирует алгоритм сжатия, используемый для данных документа. Существуют следующие случаи:

  • Если Клиент пропускает этот атрибут, Принтер ДОЛЖЕН предположить, что данные не сжаты, то есть Принтер следует приведенным ниже правилам, как если бы Клиент предоставил атрибут «compression» со значением ’none’.
  • Если Клиент предоставляет этот атрибут, но значение не поддерживается принтером, т. е. Это значение не является одним из значений атрибута «compression-supported» принтера, принтер ДОЛЖЕН отклонить запрос и вернуть сообщение где код- состояния ’client-error-compression-not-supported’. Смотри Раздел 4.1.7 для получения подробной информации о возврате неподдерживаемых атрибутов и значений.
  • Если Клиент предоставляет атрибут, а Принтер поддерживает значение атрибута, Принтер использует соответствующий алгоритм распаковки для данных Документа.
  • Если алгоритм декомпрессии (распаковки) завершается неудачно до того, как принтер возвращает ответ об операции, принтер ДОЛЖЕН отклонить запрос и вернуть код состояния ’client-error-compression-error’.
  • Если алгоритм декомпрессии (распаковки) завершается неудачно после того, как Принтер возвращает ответ операции, Принтер ДОЛЖЕН прервать работу и добавить значение ’compression-error’ в атрибут «job-state-reasons«.
  • Если алгоритм декомпрессии (распаковки) завершается успешно, данные документа ДОЛЖНЫ иметь формат, заданный атрибутом «document-format» задания, если он указан (см. Определение атрибута операции «document-format» ниже).

«document-format» (mimeMediaType): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Значение определяет формат предоставленных данных документа. Существуют следующие случаи:

  • Если Клиент не предоставляет этот атрибут, Принтер предполагает, что данные Документа имеют формат, определенный атрибутом «document-format-default» Принтера (т. е. Принтер следует приведенным ниже правилам, как если бы Клиент предоставил «document-format» со значением, равным значению принтера по умолчанию).
  • Если Клиент предоставляет этот атрибут, но это значение не поддерживается принтером, т. е. это значение не является одним из значений атрибута «document-format-supported» Принтера, Принтер ДОЛЖЕН отклонить запрос и вернуть код состояния ’client-error-document-format-not-supported’.
  • Если Клиент предоставляет этот атрибут и его значение равно «application/octet-stream» (т. е. для автоматического определения; смотри Раздел 5.1.10.1), и этот формат не является одним из форматов документа, которые принтер может автоматически определять и эта проверка происходит до того, как принтер возвращает ответ об операции, затем принтер ДОЛЖЕН отклонить запрос и вернуть код состояния ’client-error-document-format-not-supported’.
  • Если Клиент предоставляет этот атрибут и значение поддерживается Принтером, Принтер может интерпретировать данные Документа.
  • Если интерпретация данных документа не удалась до того, как принтер вернет ответ об операции, принтер ДОЛЖЕН отклонить запрос и вернуть код состояния ’client-error-document-format-error’.
  • Если интерпретация данных документа не удалась после того, как принтер вернул ответ операции, принтер ДОЛЖЕН прервать задание и добавить значение ’document-format-error’ в атрибут Задания «job-state-reasons«.

«document-natural-language» (naturalLanguage): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Значение задает естественный язык содержимого документа для тех форматов документа, которые требуют указания естественного языка для правильного отображения документа.

«job-k-octets» (integer(0:MAX)): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Предоставленный клиентом атрибут операции «job-k-octets» идентифицирует общий размер документа (ов) в представляемых K-октетах (полную семантику смотри в  разделе 5.3.17.1). Если Клиент предоставляет атрибут, а Принтер поддерживает атрибут, значение атрибута используется для заполнения атрибута «job-k-octets» Job Description (Описание задания).

Для этого атрибута и следующих двух атрибутов («job-impressions» и «job-media-sheets«), если клиент предоставляет атрибут, но Принтер не поддерживает атрибут, Принтер игнорирует предоставленное Клиентом значение. Если Клиент предоставляет атрибут, а Принтер поддерживает атрибут, и значение находится в пределах диапазона соответствующего атрибута «xxx-supported» Принтера, Принтер (Printer) ДОЛЖЕН использовать это значение для заполнения атрибута «xxx» Задания. Если Клиент предоставляет атрибут, а Принтер поддерживает атрибут, но значение выходит за пределы диапазона соответствующего атрибута «xxx-supported» Принтера, Принтер ДОЛЖЕН скопировать атрибут и его значение в группу Unsupported
Attributes (Неподдерживаемые атрибуты), отклонить запрос, и вернуть код состояния ’client-error-attributes-or-values-not-supported’. Если клиент не предоставляет атрибут, принтер ДОЛЖЕН заполнить соответствующий атрибут задания, если он поддерживает атрибут и способен рассчитать или распознать правильное значение.

«job-impressions» (integer(0:MAX)): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Предоставленный клиентом атрибут операции «job-impressions» определяет общий размер числа показов отправляемых документов (смотри Раздел 5.3.17.2 для полной семантики).

Смотрите последний абзац под «job-k-octets«.

«job-media-sheets» (integer(1:MAX)): Клиент (Client) МОЖЕТ предоставить, а Принтер (Printer) ДОЛЖЕН поддерживать этот атрибут. Предоставленный клиентом атрибут операции «job-media-sheets» идентифицирует общее количество медиа-листов, которые будут созданы для этого задания (смотри Раздел 5.3.17.3 для полной семантики).

Смотрите последний абзац под «job-k-octets«.

Группа 2: Атрибуты шаблона задания

Клиент (Client) МОЖЕТ предоставить набор Job Template attributes (атрибутов шаблона задания), как это определено в разделе 5.2. Если Клиент не предоставляет никаких атрибутов шаблона задания в запросе, Клиент ДОЛЖЕН опустить Группу 2, а не отправлять пустую группу. Однако принтер ДОЛЖЕН быть в состоянии принять пустую группу.

Группа 3: Данные документа

Клиент (Client) ДОЛЖЕН предоставить данные Документа для обработки.

Самый простой запрос Print-Job состоит только из атрибутов операции «attributes-charset» и «attributes-natural-language«, целевого атрибута операции «printer-uri» и данных документа. В этом простом случае Принтер:

  • создает новое задание, содержащее один документ
  • сохраняет сгенерированное имя задания в атрибуте «job-name» на запрашиваемом естественном языке и кодировке (смотри Раздел 4.1.4.1) (если они поддерживаются; в противном случае используется стандартный язык и кодировка принтера по умолчанию)
  • во время обработки задания использует соответствующие атрибуты значений по умолчанию для поддерживаемых атрибутов шаблона задания (Job Template attributes), которые не были предоставлены клиентом в качестве атрибута IPP или встроенных инструкций в данных документа.
4.2.1.2. Ответ задания на печать

Принтер (Printer) ДОЛЖЕН вернуть Клиенту (Client) следующие наборы атрибутов, как часть ответа операции Print-Job:

Группа 1: Атрибуты операции
  • Natural Language and Character Set
  • Status Message

Natural Language and Character Set (Естественный язык и набор символов): атрибуты «attributes-charset» и «attributes-natural-language«, как описано в Разделе 4.1.4.2.

Status Message (Сообщение о статусе): В дополнение к ТРЕБУЕМОМУ коду состояния, возвращаемому в каждом ответе, ответ МОЖЕТ включать в себя операцию «status-message» (text(255)) и/или «detailed-status-message» (text(MAX)) атрибут, как описано в Приложении B и Разделе 4.1.6. Если Клиент предоставляет неподдерживаемые или конфликтующие атрибуты или значения шаблона задания, Принтер ДОЛЖЕН отклонить или принять запрос Print-Job (задания на печать) в зависимости от того, предоставил ли клиент значение ’true’ или ’false’ для операции «ipp-attribute-fidelity» приписывать. Смотри Руководства разработчика [RFC3196] [PWG5100.19] для получения инструкций по обработке запросов на создание заданий.

Группа 2: Неподдерживаемые атрибуты

Смотри Раздел 4.1.7 для получения подробной информации о возврате неподдерживаемых атрибутов.

Значение «ipp-attribute-fidelity«, предоставленное клиентом, не влияет на то, какие атрибуты принтер возвращает в этой группе. Значение «ipp-attribute-fidelity» влияет только на то, принята или отклонена операция Print-Job (задание на печать). Если задание принято, клиент может запросить задание, используя операцию Get-Job-Attributes, запрашивая неподдерживаемые атрибуты, которые были возвращены в ответе Print-Job, чтобы увидеть, какие атрибуты были проигнорированы (не сохранены в задании) и какие атрибуты хранились с другими (замещенными) значениями.

Группа 3: Атрибуты задания

«job-id» (integer(1:MAX)) (идентификатор задания): принтер ДОЛЖЕН вернуть идентификатор задания в ТРЕБУЕМОМ атрибуте задания «job-id«. Клиент использует этот атрибут «job-id» в сочетании с атрибутом «printer-uri«, который используется в запросе Print-Job (Задание на печать) при управлении операциями Job (Задание) на Принтере.

«job-uri» (uri): принтер ДОЛЖЕН вернуть URI Задания, возвращая содержимое ОБЯЗАТЕЛЬНОГО атрибута задания «job-uri«.

«job-state» (type1 enum) (задание-состояние): Принтер ДОЛЖЕН возвращать ТРЕБОВАННЫЙ атрибут задания «job-state«. Значение этого атрибута вместе со значением атрибута «job-state-reasons» является «snapshot» (моментальным снимком) состояния нового задания, когда принтер возвращает ответ.

«job-state-reasons» (1setOf type2 keyword): Принтер ДОЛЖЕН возвратить ОБЯЗАТЕЛЬНЫЙ для задания атрибут «job-state-reasons» (причины-состояния-задания).

«job-state-message» (text(MAX)): Принтер ДОЛЖЕН вернуть РЕКОМЕНДУЕМЫЙ заданием атрибут «job-state-message«. Если принтер поддерживает этот атрибут, он ДОЛЖЕН быть возвращен в ответе. Если этот атрибут не возвращается в ответе, клиент может предположить, что атрибут «job-state-message» не поддерживается и не будет возвращен в последующем запросе Задания.

«number-of-intervening-jobs» (integer(0:MAX)): Принтер ДОЛЖЕН вернуть РЕКОМЕНДУЕМЫЙ заданием атрибут «number-of-intervening-jobs«. Если Принтер поддерживает этот атрибут, он ДОЛЖЕН быть возвращен в ответе. Если этот атрибут не возвращается в ответе, Клиент может предположить, что атрибут «number-of-intervening-jobs» не поддерживается и не будет возвращен в последующем запросе задания.


 

Примечание! Поскольку любая информация о состоянии Принтера, которая влияет на состояние Задания, отражается в атрибутах «job-state» и «job-state-reasons«, достаточно вернуть только эти атрибуты и никаких дополнительных атрибутов состояния Принтера.

Примечание! Самый простой ответ состоит только из атрибутов операции «attributes-charset» и «attributes-natural-language«, а также атрибутов Задания: «job-uri«, «job-id» и «job-state«. В этом простейшем случае код состояния ’successful-ok’ и отсутствует атрибут операции «status-message» или «detailed-status-message«.

4.2.2. Операция Print-URI (URI на данные Документа для Принтера)

Эта НЕОБЯЗАТЕЛЬНАЯ операция идентична операции Принтера Print-Job (раздел 4.2.1), за исключением того, что Клиент (Client) предоставляет ссылку URI на данные Документа, используя атрибут операции «document-uri» (uri) (в Группе 1), а не включает Данные самого документа. Перед возвратом ответа Принтер ДОЛЖЕН проверить, что Принтер поддерживает метод поиска (например, «http», «ftp» и т. д.), подразумеваемый URI, и ДОЛЖЕН проверять действительный синтаксис URI. Если предоставленная клиентом схема URI не поддерживается, т. е. это значение отсутствует в атрибуте принтера «referenced-uri-scheme-supported«, принтер ДОЛЖЕН отклонить запрос и вернуть код состояния ’client-error-uri-scheme-not-supported’.

Принтер МОЖЕТ проверять доступность Документа как часть операции или впоследствии. Если Принтер обнаруживает проблему доступности, прежде чем вернуть ответ об операции, он ДОЛЖЕН отклонить запрос и вернуть код состояния ’client-error-document-access-error’. Принтер МОЖЕТ также возвращать определенный код ошибки доступа к документу, используя атрибут операции «document-access-error» (смотри Раздел 4.1.6.4).

Если Принтер обнаруживает эту проблему доступности Документа после принятия запроса и возврата ответа операции с одним из «успешных» (successful) значений кода состояния, Принтер ДОЛЖЕН добавить значение «document-access-error» к атрибуту Задания  «job-state-reasons» и МОЖЕТ заполнять атрибут Статуса Задания «job-document-access-errors»  (смотри Раздел 5.3.11). Смотри Руководства разработчика [RFC3196] [PWG5100.19] для получения инструкций по обработке запросов на создание заданий (Job Creation).

Если принтер поддерживает эту операцию, он ДОЛЖЕН поддерживать атрибут принтера «reference-uri-schemes-supported» (смотри Раздел 5.4.27).

Принтер должен интерпретировать URI и затем «pull» (извлечь) данные документа из источника, на который ссылается строка URI.

4.2.3. Операция Validate-Job (Проверка Задания)

Эта ТРЕБУЕМАЯ операция аналогична операции Print-Job (Задание на печать) (раздел 4.2.1), за исключением того, что Клиент не предоставляет данные Документа, а Принтер не выделяет никаких ресурсов, т. е. он не создает новое задание. Эта операция используется только для проверки возможностей принтера по любым атрибутам, предоставленным клиентом в запросе Validate-Job (проверки задания). Используя операцию Validate-Job, клиент может подтвердить, что будет принят идентичный запрос на создание задания (с данными Документа). Операция Validate-Job также выполняет то же согласование безопасности, что и операции Print-Job, Print-URI и Create-Job (смотри Раздел 9), так что клиент может проверить, что требования безопасности клиента и принтера могут быть выполнены до выполнения Запроса Job Creation (Создания Задания).

Операция Validate-Job не принимает атрибут «document-uri«, чтобы позволить Клиенту проверить, будет ли принята та же операция Print-URI, поскольку Клиент не отправляет данные с помощью операции Print-URI. Клиент ДОЛЖЕН просто выполнить запрос Print-URI.

Принтер возвращает те же значения кода состояния, Operation Attributes (атрибуты операции) (Группа 1) и Unsupported Attributes (неподдерживаемые атрибуты) (Группа 2), что и операция Print-Job (Задание на печать). Однако Job Attributes (атрибуты Заданий) (Группа 3) не возвращаются, поскольку задание не создается.

4.2.4. Операция Create-Job (Создать Задание)

Эта РЕКОМЕНДУЕМАЯ операция аналогична операции Print-Job (раздел 4.2.1), за исключением того, что в запросе Create-Job клиент не предоставляет данные Документа или какие-либо ссылки на данные Документа. Кроме того, Клиент не предоставляет никаких атрибутов операции «document-name«, «document-format«, «compression» или «document-natural-language«. За этой операцией следует одна или несколько операций Send-Document или Send-URI. В каждом из этих запросов операции Клиент МОЖЕТ предоставить атрибуты «document-name«, «document-format» и «document-natural-language» для каждого Документа в Задании.

Если Принтер поддерживает операцию Create-Job (создания задания), он ДОЛЖЕН также поддерживать операцию Send-Document (отправки документа). Если принтер поддерживает операции Create-Job и Print-URI, он ДОЛЖЕН также поддерживать операцию Send-URI.

Если принтер поддерживает эту операцию, он ДОЛЖЕН поддерживать атрибут принтера «multiple-operation-time-out» (смотри Раздел 5.4.31).

Если принтер поддерживает эту операцию, он ДОЛЖЕН поддерживать атрибут «multiple-document-jobs-supported«, поддерживаемый принтером (смотри Раздел 5.4.16), и указывать, поддерживает ли он несколько Документов в Задании.

Если принтер поддерживает эту операцию и поддерживает несколько документов в задании, то он ДОЛЖЕН поддерживать атрибут шаблона Задания «multiple-document-handling«, по крайней мере, с одним значением (смотри Раздел 5.2.4) и связанный с ним «multiple-document-handling-default»   и атрибут Принтера «multiple-document-handling-supported» (смотри Раздел 5.2).

После завершения операции Create-Job (Создать задание) значение атрибута «job-state» после операции Print-Job аналогично значению «job-state«, хотя данные документа не поступили. Принтер МОЖЕТ установить значение ’job-data-insufficient’ для атрибута Задания «job-state-reasons«, чтобы указать, что обработка не может начаться, пока не будет получено достаточное количество данных, и установить для «job-state» либо ’pending’ (ожидание), либо ’pending-held’ (в ожидании удерживаемых). Принтер без спулинга (non-spooling), который не реализует ’pending’ состояние задания, может установить для «job-state» значение ’processing’ (обработка), даже если для обработки еще нет данных. Смотри Раздел 5.3.7 и Раздел 5.3.8.

4.2.5. Операция получения атрибутов принтера

Эта ТРЕБУЕМАЯ операция позволяет Клиенту запрашивать значения атрибутов Принтера. В запросе Клиент предоставляет набор имен атрибутов принтера и / или имен групп атрибутов, в которых заинтересован запросчик. В ответе принтер возвращает соответствующий набор атрибутов с заполненными значениями соответствующих атрибутов.

Для принтеров возможные имена групп атрибутов:

  • ’job-template’: подмножество атрибутов Job Template, которые применяются к принтеру (последние два столбца таблицы 8 в разделе 5.2), которые реализация поддерживает для принтеров.
  • ’printer-description’: подмножество атрибутов, указанных в разделе 5.4, которые реализация поддерживает для принтеров.
  • » all ‘: специальная группа’ all ‘, включающая все атрибуты, которые реализация поддерживает для принтеров.

Поскольку Клиент МОЖЕТ запрашивать определенные атрибуты или именованные группы, существует вероятность некоторого перекрытия. Например, если клиент запрашивает «имя-принтера» и «все», он фактически запрашивает атрибут «имя-принтера» дважды: один раз, явно назвав его, и один раз включив в группу «все». В таких случаях принтер возвращает каждый атрибут только один раз в ответе, даже если он запрашивается несколько раз. Клиент НЕ ДОЛЖЕН запрашивать один и тот же атрибут несколькими способами.

Принтеры ДОЛЖНЫ поддерживать все имена групп и ДОЛЖНЫ возвращать все поддерживаемые атрибуты, принадлежащие этой группе.

4.2.5.1. Запрос на получение атрибутов принтера

Следующие наборы атрибутов являются частью запроса Get-Printer-Attributes:

Группа 1: Атрибуты операции

Естественный язык и набор символов: атрибуты «attribute-charset» и «attribute-natural-language», как описано в Разделе 4.1.4.1.

Цель: атрибут операции «printer-uri» (uri), который является целью этой операции, как описано в разделе 4.1.5.

Запрашивающее имя пользователя: атрибут «запрашивающее имя пользователя» (имя (MAX)) ДОЛЖЕН быть предоставлен клиентом, как описано в разделе 9.3.

«requested-attributes» (1setOf keyword) (запрашиваемые атрибуты): клиент МОЖЕТ предоставить набор имен атрибутов и / или имен групп атрибутов, в значениях которых заинтересованный запросчик заинтересован. Принтер ДОЛЖЕН поддерживать этот атрибут. Если Клиент пропускает этот атрибут, Принтер ДОЛЖЕН ответить, как если бы этот атрибут был указан со значением «all».

«document-format» (mimeMediaType) (формат документа): клиент МОЖЕТ предоставить, а принтер ДОЛЖЕН поддерживать этот атрибут. Клиенту полезно определить набор поддерживаемых значений атрибутов, которые относятся к запрошенному формату документа. Принтер ДОЛЖЕН возвращать атрибуты и значения, которые он использует для проверки работы в операции создания работы или проверки работы, в которой указан этот формат документа. Принтер ДОЛЖЕН возвратить только (1) те атрибуты, которые поддерживаются для указанного формата, и (2) значения атрибутов, которые поддерживаются для указанного формата документа. Указав формат документа, клиент может заставить принтер удалить атрибуты и значения, которые не поддерживаются для определенного формата документа. Например, принтер может иметь несколько интерпретаторов для поддержки документов application / postscript (для PostScript) и text / plain (для текста). Однако только один из этих переводчиков может поддерживать атрибут «Количество номеров» с заданными значениями «1», «2» и «4». Другой интерпретатор может поддерживать только атрибут «Шаблон номера задания» со значением «1». Таким образом, Клиент может использовать операцию Get-Printer-Attributes для получения атрибутов и значений, которые будут использоваться для принятия / отклонения запроса на создание задания.

Если принтер не различает различные наборы поддерживаемых значений для каждого отдельного формата документа при проверке заданий в операциях Create-Job, Print-Job, Print-URI и Validate-Job, он НЕ ДОЛЖЕН различать разные форматы документа в Операция Get-Printer-Attributes. Если принтер различает различные наборы поддерживаемых значений для каждого другого формата документа, указанного клиентом, эта специализация применяется только к следующим атрибутам принтера:

  • + Атрибуты принтера, которые являются атрибутами шаблона задания («xxx-default», «xxx-support» и «xxx-ready») (см. Таблицу 8 в разделе 5.2)
  • + «pdl-override-supported»,
  • + «compression-supported»,
  • + «job-k-octets-supported»,
  • + «job-impressions-supported,
  • + «job-media-sheets-supported»,
  • + «printer-driver-installer»,
  • + «color-supported», and
  • + «reference-uri-schemes-supported»

Значения всех других атрибутов принтера (включая «формат документа поддерживается») остаются неизменными относительно предоставленного клиентом формата документа (за исключением новых атрибутов описания принтера, зарегистрированных в соответствии с разделом 7.2).

Если Клиент пропускает этот атрибут операции «формат документа», принтер ДОЛЖЕН ответить так, как если бы атрибут был указан со значением атрибута «документ-формат-по умолчанию» принтера. Клиенты ДОЛЖНЫ всегда указывать значение для «формата документа», поскольку значением «document-format-default» по умолчанию для принтера может быть «application / octet-stream», и в этом случае возвращаемые атрибуты и значения предназначены для объединения форматов документа. что принтер может автоматически определять Для получения дополнительной информации см. Описание синтаксиса атрибута mimeMediaType в разделе 5.1.10.

Если Клиент предоставляет значение для атрибута операции «формат документа», которое не поддерживается Принтером, т. Е. Не входит в число значений атрибута «Формат документа поддерживается», Принтер ДОЛЖЕН отклонить операцию и вернуться код состояния «клиент-ошибка-документ-формат-не поддерживается».

4.2.5.2. Ответ на получение атрибутов принтера

Принтер возвращает следующие наборы атрибутов как часть ответа Get-Printer-Attributes:

Группа 1: Атрибуты операции

Естественный язык и набор символов: атрибуты «attribute-charset» и «attribute-natural-language», как описано в разделе 4.1.4.2.

Сообщение о статусе: В дополнение к ТРЕБУЕМОМУ коду состояния, возвращаемому в каждом ответе, ответ МОЖЕТ включать в себя операцию «статус-сообщение» (текст (255)) и / или «подробное сообщение-статус» (текст (МАКС)). атрибут, как описано в Приложении B и Разделе 4.1.6.

Группа 2: неподдерживаемые атрибуты

См. Раздел 4.1.7 для получения подробной информации о возврате неподдерживаемых атрибутов.

Ответ МОЖЕТ содержать атрибут операции «требуемые атрибуты» с любыми предоставленными значениями (ключевыми словами атрибута), которые были запрошены клиентом, но не поддерживаются принтером. Если принтер возвращает неподдерживаемые атрибуты, указанные в атрибуте операции «требуемые атрибуты», и этот атрибут включает имена групп, такие как «все», неподдерживаемые атрибуты НЕ ДОЛЖНЫ включать атрибуты, описанные в этом документе, но не поддерживаемые реализацией.

Группа 3: Атрибуты принтера

Это набор запрашиваемых атрибутов и их текущих значений. Принтер игнорирует (не отвечает) любой запрошенный атрибут, который не поддерживается. Принтер МОЖЕТ ответить подмножеством поддерживаемых атрибутов и значений в зависимости от действующей политики безопасности. Однако Принтер ДОЛЖЕН ответить значением «неизвестно» для любого поддерживаемого атрибута (включая все ОБЯЗАТЕЛЬНЫЕ атрибуты), для которого Принтер не знает этого значения. Кроме того, принтер ДОЛЖЕН ответить «нет значения» для любого поддерживаемого атрибута (включая все ОБЯЗАТЕЛЬНЫЕ атрибуты), для которого администратор не настроил значение. См. Описание «внеполосных» значений в начале раздела 5.1.

4.2.6. Операция на получение задания

Эта ТРЕБУЕМАЯ операция позволяет Клиенту получить список заданий, принадлежащих целевому Принтеру. Клиент также может предоставить список имен атрибутов заданий и / или имен групп атрибутов. Группа атрибутов заданий будет возвращена для каждого возвращаемого задания.

Эта операция аналогична операции Get-Job-Attributes, за исключением того, что эта операция Get-Jobs возвращает атрибуты, возможно, из нескольких заданий.

4.2.6.1. Запрос на получение задания

Клиент отправляет запрос Get-Jobs на принтер.

Следующие группы атрибутов являются частью запроса Get-Jobs:

Группа 1: Атрибуты операции

Естественный язык и набор символов: атрибуты «attribute-charset» и «attribute-natural-language», как описано в Разделе 4.1.4.1.

Цель: атрибут операции «printer-uri» (uri), который является целью этой операции, как описано в разделе 4.1.5.

Запрашивающее имя пользователя: атрибут «запрашивающее имя пользователя» (имя (MAX)) ДОЛЖЕН быть предоставлен клиентом, как описано в разделе 9.3.

«limit» (integer(1:MAX)): клиент МОЖЕТ предоставить, а принтер ДОЛЖЕН поддерживать этот атрибут. Это целочисленное значение, которое определяет максимальное количество заданий, которое клиент получит от принтера, даже если «which-jobs» или «my-jobs» (описанные ниже) ограничивают возврат заданий. Предел является «пределом без сохранения состояния» в том смысле, что если значение, предоставленное Клиентом, равно «N», то в ответе «Get-Jobs» возвращаются только первые «N» Задания. Если Клиент не предоставляет этот атрибут, Принтер отвечает всеми применимыми Заданиями.

«requested-attributes» (1setOf type2 keyword) (запрашиваемые атрибуты): клиент МОЖЕТ предоставлять, а принтер ДОЛЖЕН поддерживать этот атрибут. Это набор имен атрибутов Job и / или имен групп атрибутов, в значениях которых заинтересован запросчик. Этот набор атрибутов возвращается для каждого возвращаемого задания. Допустимые имена групп атрибутов такие же, как те, которые определены в операции Get-Job-Attributes в Разделе 4.3.4. Если Клиент не предоставляет этот атрибут, Принтер ДОЛЖЕН ответить, как если бы Клиент предоставил этот атрибут с двумя значениями: «job-uri» и «job-id».

«which-jobs» (type2 keyword): Клиент МОЖЕТ предоставить, а принтер ДОЛЖЕН поддерживать этот атрибут. Он указывает, какие работы ДОЛЖНЫ быть возвращены принтером. Значения этого атрибута включают в себя:

+ «Завершен»: любая работа, состояние которой «завершено», «отменено» или «прервано».
+ «Не выполнено»: любое задание, состояние которого «ожидает рассмотрения», «обработка», «остановка обработки» или «ожидание удержания».

Принтер ДОЛЖЕН поддерживать оба значения. Однако если реализация не удерживает задания в состоянии «завершено», «отменено» и «прервано», то при отсутствии значения «завершено» выполнение заданий не возвращается.

Если Клиент предоставляет другое значение, которое не поддерживается Принтером, Принтер ДОЛЖЕН скопировать атрибут и неподдерживаемое значение в группу «Неподдерживаемые атрибуты», отклонить запрос и вернуть «client-error-attribute-or-values-not» -поддерживаемый ‘код состояния.

Если Клиент не предоставляет этот атрибут, Принтер ДОЛЖЕН ответить, как если бы Клиент предоставил этому атрибуту значение «not-completed — не завершено».

«my-jobs» (boolean): клиент МОЖЕТ предоставить, а принтер ДОЛЖЕН поддерживать этот атрибут. Он указывает, ДОЛЖНЫ ли РАБОТЫ от всех пользователей или только задания, представленные запрашивающим пользова