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

Аннотация

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

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

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

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

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

Приложение А. Форматы для заявок на регистрацию 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.

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

На данный документ распространяется действие ПП 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:

Принтер (Раздел 3.1)
Работа (Раздел 3.2)
Документ (см. [PWG5100.5])
Подписка (см. [RFC3995])

Каждый тип объекта имеет связанный набор операций (см. Раздел 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. Клиент МОЖЕТ быть:

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

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

(встроенный) компонент устройства, который принимает IPP-запросы и контролирует устройство, или
компонент сервера печати, который принимает запросы 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
PJ	Print-Job	Задание на печать	Принтер	Раздел 4.2.1
PU	Print-URI	Печать URI	Принтер	Раздел 4.2.2
V	Validate-Job	Подтвердить задание	Принтер	Раздел 4.2.3
CJ	Create-Job	Создать задание	Принтер	Раздел 4.2.4
GA (для принтера и задания)	Get-Printer-Attributes	Получить атрибуты принтера	Принтер	Раздел 4.2.5
GJ	Get-Jobs	Получить задание	Принтер	Раздел 4.2.6
PP	Pause-Printer	Приостановить Принтер	Принтер	Раздел 4.2.7
RP	Resume-Printer	Возобновить принтер	Принтер	Раздел 4.2.8
PJ	Purge-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
SD	Send-Document	Отправить документ	Задание	Раздел 4.3.1
SU	Send-URI	Отправить URI	Задание	Раздел 4.3.2
C	Cancel-Job	Отменить задание	Задание	Раздел 4.3.3
GA (для задания и принтера)	Get-Job-Attributes	Получить атрибуты задания	Задание	Раздел 4.3.4
HJ	Hold-Job	Задержать задание	Задание	Раздел 4.3.5
RJ	Release-Job	Выпустить задание	Задание	Раздел 4.3.6
RS	Restart-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:

Если схема URI позволяет явно включить номер порта в строку URI, а номер порта указан в URI, то этот номер порта ДОЛЖЕН использоваться Клиентом для связи с объектом IPP.
Если схема URI позволяет явно включить номер порта в строку URI, а номер порта не указан в URI, то номер порта по умолчанию, подразумеваемый этой схемой URI, ДОЛЖЕН использоваться Клиентом для связи с IPP. объект.
Если схема 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, группа НЕОБЯЗАТЕЛЬНЫХ неподдерживаемых атрибутов содержит неподдерживаемый параметр или атрибут, указанный в этой таблице.

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

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

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

В случае неподдерживаемого имени атрибута принтер возвращает предоставленный клиентом атрибут с подставленным значением «неподдерживаемый». Тип синтаксиса этого значения — «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). Когда принтер начинает обрабатывать задание на печать, состояние задания переходит к «обработке». Это называется временем обработки задания.

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

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

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

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

Проверка формата данных документа
Проверка фактического содержимого любого предоставленного Клиентом 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

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.

«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): клиент МОЖЕТ предоставить, а принтер ДОЛЖЕН поддерживать этот атрибут. Он указывает, ДОЛЖНЫ ли РАБОТЫ от всех пользователей или только задания, представленные запрашивающим пользователем этого запроса, ДОЛЖНЫ рассматриваться как кандидатские задания, которые должны быть возвращены Принтером. Если Клиент не предоставляет этот атрибут, Принтер ДОЛЖЕН ответить так, как если бы Клиент предоставил этому атрибуту значение «ложь», то есть Задания от всех пользователей. Средства аутентификации запрашивающего пользователя и сопоставления заданий описаны в разделе 9.

4.2.6.2. Ответ на получение задания

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

Принтер не возвращает 0 заданий. Если ответ возвращает 0 заданий, поскольку нет заданий, соответствующих критериям, и запрос возвратил бы одно или несколько заданий с кодом состояния «success-ok», если бы были задания, соответствующие критериям, то код состояния для 0 Вакансии ДОЛЖНЫ быть ‘успешными-хорошо’.

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

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

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

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

Группы от 3 до N: атрибуты работы

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

Задания возвращаются в следующем порядке:

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

4.2.7. Операция паузы принтера

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

Если поддерживается операция Pause-Printer, то ДОЛЖНА поддерживаться операция Resume-Printer, и наоборот.

Принтер IPP останавливает текущее задание на своем устройстве или устройствах, которые находились в состоянии «обработка» или «остановка обработки», как только позволяет реализация. Если реализация займет значительное время, чтобы остановить, IPP-принтер добавляет значение «переходит в режим паузы» к атрибуту «Printer-State-reason» принтера (см. Раздел 5.4.12). Когда все устройство или устройства остановлены, принтер IPP переводит принтер в состояние «остановлен»; удаляет значение «переход к паузе», если оно присутствует; и добавляет значение «paused» в атрибут «Printer-state-reason» принтера.

Когда текущее задание или задания завершены, находящиеся в состоянии «обработка», принтер IPP переводит их в состояние «завершено». Когда текущее задание или задания останавливаются в середине обработки, которые находились в состоянии «обработка», принтер IPP переводит их в состояние «обработка остановлена» и добавляет значение «остановлен принтер» в «job-state-reasons»

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

Принтер IPP ДОЛЖЕН принять запрос в любом состоянии и перевести принтер в указанное новое «состояние принтера» перед возвратом, как показано в таблице 2.

Права доступа: аутентифицированный пользователь (см. Раздел 9.3), выполняющий эту операцию, ДОЛЖЕН быть оператором или администратором принтера (см. Разделы 1 и 9.5). В противном случае принтер IPP ДОЛЖЕН отклонить операцию и вернуть «клиент-ошибка-запрещен», «клиент-ошибка-не-аутентифицирован» или «клиент-ошибка-не авторизован» в зависимости от ситуации.

Таблица 2 - Переходы состояния Пауза-Принтер — Таблица 2 — Переходы состояния Пауза-Принтер

4.2.7.1. Запрос паузы принтера

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

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

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

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

4.2.7.2. Ответ паузы принтера

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

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

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

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

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

4.2.8. Операция возобновления работы принтера

Эта ФАКУЛЬТАТИВНАЯ операция позволяет Клиенту возобновлять работы по планированию принтера на всех своих устройствах. Принтер ДОЛЖЕН удалить значения «paused» и «moving to paused» из атрибута «Printer-State-reason» принтера, если таковой имеется. Если нет других причин держать устройство в режиме паузы (например, застревание носителя), принтер IPP может самостоятельно перейти в состояние «обработка» или «ожидание», в зависимости от того, есть ли задания для обработки или нет, соответственно, и устройство (а) возобновляет обработку заданий.

Если поддерживается операция Pause-Printer, то ДОЛЖНА поддерживаться операция Resume-Printer, и наоборот.

Принтер IPP удаляет значение «принтер остановлен» из атрибутов «Задания состояния задания» любого задания, содержащихся в этом принтере.

Принтер IPP ДОЛЖЕН принять запрос в любом состоянии и перевести принтер в указанное новое состояние, как показано в таблице 3.

Запрос Resume-Printer и Resume-Printer имеют те же группы атрибутов и атрибуты, что и операция Pause-Printer (см. Разделы 4.2.7.1 и 4.2.7.2).

Таблица 3 - Переходы состояния Возобновление-Принтер — Таблица 3 — Переходы состояния Возобновление-Принтер

4.2.9. Операция очистки заданий — Purge-Jobs Operation

Эта УСТАРЕВШАЯ операция позволяет Клиенту удалить все Задания с Принтера, независимо от их состояний Заданий, включая Задания в Журнале заданий Принтера (см. Раздел 5.3.7.2). После выполнения операции Purge-Jobs принтер ДОЛЖЕН не возвращать никаких заданий в последующих ответах Get-Job-Attributes и Get-Jobs (до тех пор, пока не будут отправлены новые задания).

Примечание. Эту операцию НЕ СЛЕДУЕТ поддерживать в новых реализациях, поскольку она уничтожает учетную информацию принтера.

Влияет ли операция Purge-Jobs (и Get-Jobs) на задания, которые были отправлены на устройство из источников, отличных от принтера IPP, так же, как операция Purge-Jobs влияет на задания, которые были отправлены на принтер IPP с использованием IPP, зависит от реализации, т. е. о том, используется ли IPP в качестве универсального протокола управления или просто для управления заданиями IPP, соответственно.

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

Если эта ДОПОЛНИТЕЛЬНАЯ операция поддерживается, Принтер ДОЛЖЕН принять эту операцию в любом состоянии и перевести Принтер в состояние «ожидания».

Права доступа: аутентифицированный пользователь (см. Раздел 9.3), выполняющий эту операцию, ДОЛЖЕН быть оператором или администратором принтера (см. Разделы 1 и 9.5). В противном случае принтер ДОЛЖЕН отклонить операцию и вернуть «клиент-ошибка-запрещен», «клиент-ошибка-не-аутентифицирован» и «клиент-ошибка-не авторизован» в зависимости от ситуации.

Запрос Purge-Jobs и ответ Purge-Jobs имеют те же группы атрибутов и атрибуты, что и операция Pause-Printer (см. Разделы 4.2.7.1 и 4.2.7.2).

4.3. Операции Задания

Все работы Job направлены на работу. Клиент ДОЛЖЕН всегда предоставлять некоторые средства идентификации объекта Job для определения правильной цели операции. Этот идентификатор задания ДОЛЖЕН быть комбинацией URI принтера и идентификатора задания, но МОЖЕТ быть (единственным) URI задания. Реализация IPP ДОЛЖНА поддерживать обе формы идентификации для каждого задания.

4.3.1. Операция отправки документа

Эта РЕКОМЕНДУЕМАЯ операция позволяет Клиенту добавить документ в задание, созданное с помощью операции создания задания. В ответе Create-Job принтер возвращает URI задания (атрибут «job-uri») и 32-битный идентификатор задания (атрибут «идентификатор задания»). Для каждого нового документа, который клиент желает добавить, он использует операцию отправки документа. Каждый запрос отправки документа содержит весь поток данных документа для одного документа.

Если принтер поддерживает эту операцию, но не поддерживает несколько документов на одно задание, он ДОЛЖЕН отклонить последующие операции отправки документа, снабженные данными, и вернуть код состояния «ошибка сервера — несколько заданий — не поддерживается». Однако принтер ДОЛЖЕН принять первый документ со значением «истина» или «ложь» для атрибута операции «последний документ» (см. Ниже), поэтому клиенты МОГУТ всегда отправлять одно задание документа со значением «ложь» для « last-document «в первом Send-Document и значение true для» last-document «во втором Send-Document (без данных).

Поскольку последующие операции Create-Job и send (операции Send-Document или Send-URI) могут происходить в течение произвольно длительного периода времени для конкретного задания, клиент ДОЛЖЕН отправить другую операцию отправки в течение минимального интервала времени, как определено принтером IPP, после получения предыдущего запроса на задание. Если принтер поддерживает операции «Создать задание» и «Отправить документ», он ДОЛЖЕН поддерживать атрибут «многократное превышение времени ожидания» (см. Раздел 5.4.31). Этот атрибут указывает минимальное количество секунд, в течение которых принтер будет ожидать следующей операции отправки, прежде чем предпринимать какие-либо действия по восстановлению.

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

Предположим, что задание является недопустимым заданием, запустите процесс изменения состояния задания на «прервано», добавьте значение «прервано по системе» в атрибут задания «задание состояния задания» (см. Раздел 5.3. 8) и очистить все ресурсы, связанные с заданием. В этом случае, если другая операция отправки наконец получена, Принтер отвечает кодом состояния «ошибка клиента не возможна» или «ошибка клиента не найдена», в зависимости от того, работает ли еще Задание, когда Операция отправки наконец прибывает.
Предположим, что последняя полученная операция отправки была на самом деле последним документом (как если бы флаг «last-document» был установлен в «true»), закройте задание и приступите к его обработке (т. Е. Переместите состояние задания в ожидании).
Предположим, что последняя полученная операция отправки была на самом деле последним документом, и закройте задание, но переведите его в состояние «ожидание удерживается» и добавьте значение «отправка-прерывание» к «причинам состояния задания» задания. атрибут (см. раздел 5.3.8). Это действие позволяет пользователю или оператору определить, следует ли продолжить обработку задания, переместив его обратно в состояние «ожидание» с помощью операции Release-Job (см. Раздел 4.3.6), или отменить задание с помощью операции Cancel-Job. (см. раздел 4.3.3).

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

Права доступа: аутентифицированный пользователь (см. Раздел 9.3), выполняющий эту операцию, должен быть либо владельцем задания (как определено в операции создания задания), либо оператором или администратором принтера (см. Разделы 1 и 9.5). В противном случае принтер ДОЛЖЕН отклонить операцию и вернуть «клиент-ошибка-запрещен», «клиент-ошибка-не-аутентифицирован» или «клиент-ошибка-не авторизован» в зависимости от ситуации.

4.3.1.1. Запрос отправки документа

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

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

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

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

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

«compression» (type2 keyword) (сжатие): см. описание «сжатия» для операции «Задание на печать» в разделе 4.2.1.1.

«document-format» (mimeMediaType) (формат документа): см. описание «формата документа» для операции «Задание на печать» в разделе 4.2.1.1.

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

«last-document» (boolean): клиент ДОЛЖЕН предоставить, а принтер ДОЛЖЕН поддерживать этот атрибут. Это логический флаг, который имеет значение «true», если это последний документ для задания; в противном случае он имеет значение «false».

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

Клиент ДОЛЖЕН предоставить данные документа, если для флага «последний документ» установлено значение «ложь». Однако, поскольку Клиент может не знать, что предыдущий Документ, отправленный с помощью операции Send-Document (или Send-URI), был последним Документом (т. Е. Атрибуту «last-document» было присвоено значение «false»), это допустимо отправить запрос на отправку документа без данных документа, где для флага «последний документ» установлено значение «истина». Такой запрос НЕ ДОЛЖЕН увеличивать значение атрибута «количество документов» в задании, поскольку в задание не был добавлен настоящий документ. Клиент не ошибается при отправке работы без фактических данных документа, т. Е. Только с одним запросом Create-Job и Send-Document с атрибутом операции «последний документ», установленным в «true», без данных документа.

4.3.1.2. Ответ отправки документа

Следующие наборы атрибутов являются частью ответа Send-Document:

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

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

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

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

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

Это тот же набор атрибутов, который описан в ответе «Задание на печать» (см. Раздел 4.2.1.2).

4.3.2. Операция отправки URI

Эта РЕКОМЕНДУЕМАЯ операция идентична операции Send-Document (см. Раздел 4.3.1), за исключением того, что Клиент ДОЛЖЕН предоставить ссылку на URI (атрибут операции document-uri), а не сами данные документа. Если принтер поддерживает эту операцию, клиенты могут использовать операции Send-URI и Send-Document для добавления новых документов в существующее задание. Однако, если Клиенту необходимо указать, что предыдущий Send-URI или Send-Document был последним Документом, Клиент ДОЛЖЕН использовать операцию Send-Document без данных Document, а для флага «last-document» установлено значение «true» ( вместо использования операции Send-URI без атрибута операции «document-uri»).

Если принтер поддерживает эту операцию, он ДОЛЖЕН также поддерживать операцию Print-URI (см. Раздел 4.2.2).

Принтер ДОЛЖЕН проверить синтаксис и схему URI предоставленного URI, прежде чем возвращать ответ, как в операции Print-URI. Принтер МОЖЕТ проверять доступность Документа как часть операции или впоследствии (см. Раздел 4.2.2).

4.3.3. Операция отмены задания

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

Принтер ДОЛЖЕН принять или отклонить запрос на основе текущего состояния задания и перевести задание в указанное новое состояние, как показано в таблице 4.

Права доступа: аутентифицированный пользователь (см. Раздел 9.3), выполняющий эту операцию, должен быть либо владельцем задания, либо оператором или администратором принтера (см. Разделы 1 и 9.5). В противном случае принтер ДОЛЖЕН отклонить операцию и вернуть «клиент-ошибка-запрещен», «клиент-ошибка-не-аутентифицирован» или «клиент-ошибка-не авторизован» в зависимости от ситуации.

Таблица 4 - Переходы состояния отмены задания — Таблица 4 — Переходы состояния отмены задания

Примечание 1: Если реализации требуется некоторое измеримое время для отмены задания в состоянии «обработка» или «остановленная обработка», принтер ДОЛЖЕН добавить значение «обработка до остановки» в состояние «задания» -reasons «и затем переводит задание в состояние» отменено «, когда обработка прекращается (см. раздел 5.3.8).

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

4.3.3.1. Запрос отмены задания

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

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

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

«message» (text(127)): Клиент МОЖЕТ предоставить, а принтер МОЖЕТ поддерживать этот атрибут. Это сообщение для Оператора. Этот атрибут «message» не совпадает с атрибутом «job-message-from-operator». Этот атрибут используется для сообщения сообщения от оператора конечному пользователю, который запрашивает этот атрибут. Этот атрибут операции «сообщение» используется для отправки сообщения от Клиента Оператору вместе с запросом операции. Как или где отобразить это сообщение для Оператора (если оно вообще есть), это решение о реализации.

4.3.3.2. Ответ отмены задания

Следующие наборы атрибутов являются частью ответа Cancel-Job:

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

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

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

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

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

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

Эта операция REQUIRED позволяет клиенту запрашивать значения атрибутов задания, и она практически идентична операции Get-Printer-Attributes (см. Раздел 4.2.5). Единственное отличие состоит в том, что операция направлена на задание, а не на принтер, при запросе задания не используется атрибут операции «формат документа», а возвращаемая группа атрибутов представляет собой набор атрибутов задания, а не набор принтеров. атрибутов.

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

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

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

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

4.3.4.1. Запрос на получение атрибутов задания

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

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

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

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

4.3.4.2. Ответ на получение атрибутов задания

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

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

Естественный язык и набор символов:

Атрибуты «attribute-charset» и «attribute-natural-language» описаны в разделе 4.1.4.2. «attribute-natural-language» МОЖЕТ быть естественным языком задания, а не тем, который запрашивается.

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

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

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

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

4.3.5. Операция задержки задания

Эта НЕОБЯЗАТЕЛЬНАЯ операция позволяет Клиенту удерживать ожидающее задание в очереди, чтобы оно не подходило для планирования. Если операция Hold-Job поддерживается, то операция Release-Job ДОЛЖНА поддерживаться, и наоборот. НЕОБЯЗАТЕЛЬНЫЙ атрибут операции «удержание задания» позволяет клиенту указать, следует ли удерживать задание на неопределенный срок или до указанного периода времени, если это поддерживается.

Принтер ДОЛЖЕН принять или отклонить запрос на основе текущего состояния задания и перевести задание в указанное новое состояние, как показано в таблице 5.

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

Таблица 5 - Переходы состояния Удержание-Работа — Таблица 5 — Переходы состояния Удержание-Работа

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

Примечание 2. Если принтер поддерживает атрибут операции «работа-удержание до», но указанный период времени уже начался (или является значением «не удерживать»), и нет других причин для удержания работы, принтер НЕОБХОДИМО, чтобы Задание сразу же стало кандидатом на обработку (см. Раздел 5.2.2), переведя Задание в состояние ожидания.

4.3.5.1. Запрос удержания задания

Группы и атрибуты операций такие же, как те, которые определены для запроса отмены задания (см. Раздел 4.3.3.1), с добавлением следующего атрибута операции группы 1:

«job-hold-till» (ключевое слово type2 | имя (MAX)):

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

Если он предоставлен и поддерживается в соответствии с указанными в атрибуте «Задание удержания до тех пор» принтера, принтер копирует предоставленный атрибут операции в задание, заменяя предыдущий атрибут задания заданий до удержания, если он присутствует, и создает Работа кандидата на планирование в течение указанного периода времени.

Если он указан, но сам атрибут операции «job-hold-till» или предоставленное значение не поддерживаются, принтер принимает запрос, возвращает неподдерживаемый атрибут или значение в группе Unsupported Attributes в соответствии с разделом 4.1.7 и возвращает ‘ код состояния успешно-нормально-игнорируемых-или-замещенных-атрибутов и удерживает задание на неопределенное время, пока клиент не выполнит последующую операцию освобождения-задания.

Если (1) Клиент предоставляет либо значение, которое указывает период времени, который уже начался, либо значение «без удержания» (имеется в виду не удерживать задание) и (2) принтер поддерживает «задание удержания до «Атрибут операции и нет других причин удерживать задание, принтер ДОЛЖЕН принять операцию и сделать задание незамедлительным кандидатом для обработки (см. раздел 5.2.2).

Если Клиент не предоставляет в запросе атрибут операции «удержание задания», принтер ДОЛЖЕН заполнить задание атрибутом «задание удержания» значением «неопределенное» (если принтер поддерживает задание -hold-till «) и удерживайте Задание на неопределенное время, пока Клиент не выполнит операцию Release-Job.

4.3.5.2. Ответ задержки задания

Группы и атрибуты такие же, как те, которые определены для ответа «Отмена задания» (см. Раздел 4.3.3.2).

4.3.6. Операция выпуска задания

Эта НЕОБЯЗАТЕЛЬНАЯ операция позволяет Клиенту освободить ранее выполненное Задание, чтобы оно снова имело право на планирование. Если операция Hold-Job поддерживается, то операция Release-Job ДОЛЖНА поддерживаться, и наоборот.

Эта операция удаляет атрибут «Задание-удержание задания», если таковой имеется, из Задания, которое было предоставлено в операции «Создать задание» или в самой последней операции Задержка-задание или Рестарт-задание, и удаляет его влияние на задание. Принтер ДОЛЖЕН удалить значение «задание-удержание до задания» из атрибута «Задание-состояние-задание» задания, если оно имеется. См. Раздел 5.3.8.

Принтер ДОЛЖЕН принять или отклонить запрос на основе текущего состояния задания и перевести задание в указанное новое состояние, как показано в таблице 6.

Запрос Release-Job и ответ Release-Job имеют те же группы атрибутов и атрибуты, что и операция Cancel-Job (см. Разделы 4.3.3.1 и 4.3.3.2).

Таблица 6 - Переходные состояния Выпуск-Работа — Таблица 6 — Переходные состояния Выпуск-Работа

Примечание 1: Если есть другие причины для сохранения работы в состоянии «отложено», например «ресурсы не готовы», работа остается в состоянии «отложено». Таким образом, состояние «отложено удерживается» не только для заданий, к которым применен атрибут «задание удержано», но также используется по любой причине, которая помешает заданию быть кандидатом на планирование и обработку, например как «ресурсы не готовы». См. Атрибут «job-hold-till» (раздел 5.2.2).

4.3.7. Перезапуск задания (Restart-Job Operation)

Эта операция УСТАРЕЛА позволяет клиенту перезапустить задание, которое сохраняется в очереди после завершения обработки (см. Раздел 5.3.7.2).

Примечание. Эту операцию НЕ СЛЕДУЕТ поддерживать в новых реализациях, поскольку она уничтожает учетную информацию принтера. Операция Resubmit-Job [PWG5100.11] является безопасной заменой для этой операции и создает копию задания, назначает для копии новые «job-uri» и «job-id» и сбрасывает атрибуты хода выполнения задания в только новая копия.

Операция «Перезапустить задание» переводит задание в состояние «ожидание» или «ожидание удерживается» и перезапускается в начале на том же принтере с теми же значениями атрибута. Если какой-либо из Документов в Задании был передан по ссылке (Print-URI или Send-URI), Принтер ДОЛЖЕН повторно выполнить данные, поскольку семантика Restart-Job должна повторять всю обработку Задания. Атрибуты Статус работы, которые накапливают прогресс Работы, такие как «работа-показы завершены», «работа-медиа-листы завершены» и «работа-k-октеты-обработаны», ДОЛЖНЫ быть сброшены в 0, чтобы они давали точная запись задания с точки его перезапуска. В задании ДОЛЖНЫ по-прежнему использоваться одни и те же значения атрибутов «job-uri» и «job-id».

Принтер ДОЛЖЕН принять или отклонить запрос на основе текущего состояния задания и перевести задание в указанное новое состояние, как показано в таблице 7.

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

Таблица 7 - Изменения состояния Перезапуск-Работа — Таблица 7 — Изменения состояния Перезапуск-Работа

Правило 1: Если срок хранения задания истек для задания в этом состоянии, то принтер отклоняет операцию. См. Раздел 5.3.7.2.

4.3.7.1. Запрос перезапуска задания

Группы и атрибуты такие же, как те, которые определены для запроса отмены задания (см. Раздел 4.3.3.1), с добавлением следующего атрибута операции группы 1:

«job-hold-until» (type2 keyword | name(MAX)) (задание-удержание): Клиент МОЖЕТ предоставить и принтер ДОЛЖЕН поддерживать этот атрибут операции в запросе «Перезапуск-задание», если он поддерживает атрибут «Задание-задание» в Запросы на создание рабочих мест. Смотри раздел 5.2.2.

Если он указан, но значение не поддерживается, принтер принимает запрос, возвращает неподдерживаемый атрибут или значение в группе «Неподдерживаемые атрибуты» в соответствии с разделом 4.1.7, возвращает статус «success-ok-ignore-or-replace-attribute». код и хранит Задание на неопределенное время, пока Клиент не выполнит последующую операцию Release-Job.

Если он указан, но сам атрибут операции «hold-hold-till» не поддерживается, принтер принимает запрос, возвращает неподдерживаемый атрибут со значением «unsupported», находящимся вне диапазона, в группе «Unsupported Attributes» в соответствии с разделом 4.1.7. возвращает код состояния «success-ok-ignore-or-replace-attribute» и перезапускает задание, т. е. игнорирует атрибут «job-hold-till».

Если (1) Клиент предоставляет либо значение, которое указывает период времени, который уже начался, либо значение «без удержания» (имеется в виду не удерживать задание) и (2) принтер поддерживает «задание удержания до «Атрибут операции и других причин удерживать задание нет, принтер сразу же назначает его для обработки (см. раздел 5.2.2).

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

4.3.7.2. Ответ перезапуска задания

Группы и атрибуты такие же, как те, которые определены для ответа «Отмена задания» (см. Раздел 4.3.3.2).

5. Атрибуты объекта

В этом разделе описываются атрибуты с соответствующими синтаксисами и значениями атрибутов, которые являются частью модели IPP. В разделах ниже показаны объекты и связанные с ними атрибуты, которые включены в объем этого протокола. Многие из этих атрибутов получены из других соответствующих документов:

Приложение для печати документов (DPA) [ISO10175]
Принтер MIB v2 [RFC3805]

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

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

5.1. Синтаксис атрибутов

В этом разделе определяются основные типы синтаксиса атрибутов, которые ДОЛЖНЫ быть в состоянии принимать все клиенты и объекты IPP в ответах и принимать в запросах соответственно. Каждое описание атрибута в разделах 4 и 5 включает в заголовок раздела имя атрибута с его синтаксисом (ами) в скобках. Соответствующая реализация атрибута ДОЛЖНА включать семантику синтаксиса (ов) атрибута, идентифицированных таким образом. Раздел 7.7 описывает, как протокол может быть расширен с помощью новых синтаксисов атрибутов.

Синтаксис атрибутов указан в следующих подразделах, где заголовок подраздела — это ключевое слово синтаксиса атрибута в одинарных кавычках. В запросах и ответах на операции каждое значение атрибута ДОЛЖНО быть представлено как один из синтаксисов атрибута, указанных в заголовке подраздела для атрибута. Кроме того, значение атрибута в ответе (но не в запросе) МОЖЕТ быть одним из «внеполосных» значений (раздел 5.1.1), специальные правила кодирования которых определены в документе «Кодирование и транспорт» [ RFC8010].

Все атрибуты в запросе ДОЛЖНЫ иметь одно или несколько значений, определенных в разделах 5.2, 5.3 и 5.4. Все атрибуты в ответе ДОЛЖНЫ иметь (1) одно или несколько значений, как определено в разделах 5.2, 5.3 и 5.4, или (2) одно внеполосное значение.

У большинства атрибутов определен синтаксис с одним атрибутом. Однако некоторые атрибуты (например, «лист задания», «носитель», «задание удержания до тех пор») определены, чтобы иметь несколько синтаксисов атрибутов, в зависимости от значения. Эти множественные атрибуты синтаксиса разделены «|» символ в названии подраздела для обозначения выбора. Поскольку каждое значение ДОЛЖНО быть помечено в соответствии с синтаксисом его атрибута в протоколе, экземпляр однозначного атрибута может иметь любой из его синтаксисов атрибута, а экземпляр многозначного атрибута может иметь смесь своих определенных синтаксисов атрибута.

5.1.1. Значения вне диапазона — ’unknown’, ’unsupported’, ’no-value’ — «неизвестно», «не поддерживается» и «нет значения»

Этот документ определяет три «внеполосных» значения, которые используются вместо определенного синтаксиса атрибута:

’unknown’: атрибут поддерживается объектом IPP, но по какой-то причине это значение неизвестно объекту IPP. Это внеполосное значение используется для атрибутов, которые имеют внутреннее физическое значение, которое не может быть определено объектом IPP в данный момент времени, например, количество листов, географическое положение и т. Д.
’unsupported’: атрибут не поддерживается объектом IPP. Это значение ДОЛЖНО быть возвращено только как значение атрибута в группе «Неподдерживаемые атрибуты».
’no-value’: атрибут поддерживается принтером, но администратор еще не настроил значение.

5.1.2. ’text’ — текст

Атрибут «текст» — это атрибут, значение которого представляет собой последовательность из нуля или более символов, закодированных максимум в 1023 («МАКС») октетов. MAX — это максимальная длина для каждого значения любого атрибута text. Однако, если атрибут всегда будет содержать значения, максимальная длина которых намного меньше, чем MAX, определение этого атрибута будет включать определитель, который определяет максимальную длину для значений этого атрибута. Например, атрибут «printer-location» указан как «printer-location (text (127))». В этом случае текстовые значения для «местоположения принтера» НЕ ДОЛЖНЫ превышать 127 октетов; если предоставляется более длинная текстовая строка через некоторый внешний интерфейс (кроме протокола), реализации могут урезать это более короткое ограничение длины.

В этом документе все атрибуты ‘text’ определены с использованием синтаксиса ‘text’. Тем не менее, «текст» используется только для краткости; формальное толкование текста — это textWithoutLanguage | textWithLanguage. То есть для любого атрибута, определенного в этом документе с использованием синтаксиса атрибута «текст», все объекты IPP и клиенты ДОЛЖНЫ поддерживать синтаксисы атрибутов «textWithoutLanguage» и «textWithLanguage». Однако при фактическом использовании и выполнении протокола объекты IPP и клиенты принимают и возвращают только один из двух синтаксисов для каждого атрибута. Синтаксис «текст» никогда не появляется «на проводе».

Оба «textWithoutLanguage» и «textWithLanguage» необходимы для удовлетворения реальных потребностей в совместимости между сайтами и системами, которые используют разные естественные языки в качестве основы для человеческого общения. Как правило, один естественный язык применяется ко всем атрибутам текста в данном запросе или ответе. Язык указывается атрибутом операции «attribute-natural-language», определенным в Разделе 4.1.4, или атрибутом Job «attribute-natural-language», определенным в Разделе 5.3.20, и нет необходимости определять естественный язык для каждая текстовая строка на основе значения по значению. В этих случаях синтаксис атрибута «textWithoutLanguage» используется для «текстовых» атрибутов. В других случаях Клиент должен предоставить или Принтер должен вернуть текстовое значение на естественном языке, который отличается от остальных текстовых значений в запросе или ответе. В этих случаях клиент или принтер использует синтаксис атрибута «textWithLanguage» для атрибутов «текст» (это механизм переопределения естественного языка, описанный в разделе 4.1.4).

Синтаксис атрибутов textWithoutLanguage и textWithLanguage более подробно описан в следующих разделах.

5.1.2.1. ’textWithoutLanguage’ — текст без языка

Синтаксис textWithoutLanguage указывает значение, представляющее собой последовательность из нуля или более символов, закодированных максимум в 1023 (MAX) октетов. Текстовые строки кодируются с использованием правил некоторой кодировки. Принтер ДОЛЖЕН поддерживать набор символов UTF-8 [RFC3629] и МОЖЕТ поддерживать дополнительные наборы символов для представления «текстовых» значений при условии, что наборы символов зарегистрированы в IANA [IANA-CS]. См. Раздел 5.1.8 для определения синтаксиса атрибута «charset», включая ограниченную семантику и примеры наборов символов.

5.1.2.2. ’textWithLanguage’ — текст с языком

Синтаксис атрибута ‘textWithLanguage’ является составным синтаксисом атрибута, состоящим из двух частей: часть ‘textWithoutLanguage’, закодированная максимум в 1023 (MAX) октетов, плюс дополнительная часть «naturalLanguage» (см. Раздел 5.1.9), которая переопределяет естественный язык действующий. Часть «NaturalLanguage» явно определяет естественный язык, который применяется к текстовой части этого значения и только этого значения. Для любого заданного атрибута ‘text’ часть ‘textWithoutLanguage’ ограничена максимальной длиной, определенной для этого атрибута ‘text’, а часть ‘naturalLanguage’ всегда ограничена 63 (дополнительными) октетами. Использование синтаксиса атрибута «textWithLanguage» вместо обычного синтаксиса «textWithoutLanguage» является так называемым «механизмом переопределения естественного языка» и ДОЛЖЕН поддерживаться всеми объектами IPP и клиентами.

Если атрибут является многозначным (1setOf text), то синтаксис атрибута textWithLanguage ДОЛЖЕН использоваться для явного указания значения каждого атрибута, чей естественный язык необходимо переопределить. Другие значения в многозначном атрибуте text в запросе или ответе возвращаются к естественному языку атрибута операции.

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

Пример: если Клиент предоставляет атрибут операции «attribute-natural-language» со значением «en», указывающим на английский, но значение атрибута «job-name» на французском языке, Клиент ДОЛЖЕН использовать синтаксис атрибута «textWithLanguage» с следующие два значения:

’Fr’: переопределение естественного языка с указанием французского
’Rapport Mensuel’: название работы на французском языке

Информацию о кодировке двух частей и подробном примере синтаксиса атрибута ‘textWithLanguage’ см. В документе [RFC8010].

5.1.3. ’name’ — имя

Этот тип синтаксиса используется для удобных для пользователя строк, таких как имя принтера, которые для людей более значимы, чем идентификаторы. Имена никогда не переводятся с одного естественного языка на другой. Синтаксис атрибута «name» по сути такой же, как и «text», включая ТРЕБУЕМУЮ поддержку UTF-8, за исключением того, что последовательность символов ограничена, поэтому его кодированная форма НЕ ДОЛЖНА превышать 255 (MAX) октетов.

Также, как и «текст», «имя» на самом деле является сокращенной нотацией для «nameWithoutLanguage» или «nameWithLanguage». То есть все объекты IPP и клиенты ДОЛЖНЫ поддерживать синтаксисы атрибутов «nameWithoutLanguage» и «nameWithLanguage». Однако при фактическом использовании и выполнении протокола объекты IPP и клиенты принимают и возвращают только один из двух синтаксисов для каждого атрибута. Синтаксис «имя» никогда не появляется «на проводе».

Только синтаксисы атрибутов «текст» и «имя» разрешают механизм переопределения естественного языка.

Некоторые атрибуты определены как ключевое слово type2 | название’. Эти атрибуты поддерживают значения, которые являются ключевыми словами или именами type2. Этот механизм с двойным синтаксисом позволяет администратору сайта расширять эти атрибуты, чтобы юридически включать значения, которые локально определяются администратором сайта. Такие имена не зарегистрированы в IANA.

5.1.3.1. ’nameWithoutLanguage’ — имя без языка

Синтаксис nameWithoutLanguage указывает значение, представляющее собой последовательность из нуля или более символов, закодированных максимум в 255 (MAX) октетов.

5.1.3.2. ’nameWithLanguage’ — имя с языком

Синтаксис атрибута «nameWithLanguage» — это составной синтаксис атрибута, состоящий из двух частей: части «nameWithoutLanguage» (см. Раздел 5.1.3.1) и дополнительной части «NaturalLanguage» (см. Раздел 5.1.9), которая переопределяет действующий естественный язык. Часть «NaturalLanguage» явно определяет естественный язык, который применяется к этому значению имени и только к этому значению имени. Для любого заданного атрибута name часть ‘nameWithoutLanguage’ ограничена максимальной длиной, определенной для этого атрибута name, а часть naturalLanguage всегда ограничена 63 (дополнительными) октетами. Использование синтаксиса атрибута «nameWithLanguage» вместо обычного синтаксиса «nameWithoutLanguage» является механизмом переопределения естественного языка и ДОЛЖЕН поддерживаться всеми объектами IPP и клиентами.

Синтаксис атрибута nameWithLanguage ведет себя так же, как синтаксис textWithLanguage. Если имя написано на языке, отличном от остальной части объекта или операции, то используется этот синтаксис «nameWithLanguage», а не общий синтаксис «nameWithoutLanguage».

Если атрибут является многозначным (1setOf name), то Синтаксис атрибута nameWithLanguage ДОЛЖЕН использоваться для явного указания значения каждого атрибута, чей естественный язык необходимо переопределить. Другие значения в многозначном атрибуте name в запросе или ответе возвращаются к естественному языку атрибута операции.

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

Пример: если Клиент предоставляет атрибут операции «attribute-natural-language» со значением «en», указывающим на английский, но атрибут «printer-name» на немецком языке, Клиент ДОЛЖЕН использовать синтаксис атрибута «nameWithLanguage» следующим образом:

«De»: переопределение естественного языка с указанием немецкого языка
«Farbdrucker»: название принтера на немецком языке

Информацию о кодировке двух частей см. В документе «Кодирование и транспорт» [RFC8010] и подробном примере синтаксиса атрибута «nameWithLanguage».

5.1.3.3. Соответствующие значения атрибутов ’name’

В целях сопоставления двух значений атрибута «name» на равенство, например, при проверке задания (где проверяется значение, предоставленное клиентом для атрибута «xxx», чтобы увидеть, находится ли значение среди значений соответствующего «Принтера, поддерживаемого xxx»). атрибут), применяются следующие правила соответствия:

1. «ключевые» значения никогда не совпадают с «именными» значениями.

2. Значения «name» («nameWithoutLanguage» и «nameWithLanguage») совпадают, если (1) совпадают части имени и (2)
Части естественного языка (смотри Раздел 4.1.4.1) совпадают. Правила соответствия следующие:

2а. Части имен совпадают, если два имени идентичны символ за символом, за исключением того, что РЕКОМЕНДУЕТСЯ игнорировать регистр, как определено в «i; unicode-casemap — Простой алгоритм сортировки Unicode» [RFC5051]. Например, «Ajax-letter-head-white» ДОЛЖЕН соответствовать «Ajax-letter-head-white» и ДОЛЖЕН соответствовать «ajax-letter-head-white» и «AJAX-LETTER-HEAD-WHITE».

2b. Связанные части естественного языка совпадают, если более короткая из двух соответствует синтаксическим требованиям, определенным в разделе 2.1 RFC 5646 [RFC5646], и сопоставляется (байт за байтом, поскольку языковые теги IPP являются строчными) с более длинной. Например, «en» соответствует «en», «en-us» и «en-gb», но не соответствует ни «fr», ни «e».

5.1.4. ’keyword’ — ключевое слово

Синтаксис атрибута «ключевое слово» представляет собой последовательность символов длиной от 1 до 255, содержащую только значения в кодировке US-ASCII [RFC20] для строчных букв («a» — «z»), цифр («0» — «9 «), дефис (» — «), точка («. «) и подчеркивание (» _ «). Первый символ ДОЛЖЕН быть строчной буквой. Кроме того, ключевые слова ДОЛЖНЫ быть на американском английском.

Этот тип синтаксиса используется для перечисления семантических идентификаторов объектов в абстрактном протоколе, то есть объектов, идентифицированных в этом документе. Ключевые слова используются как имена атрибутов или значения атрибутов. В отличие от значений атрибутов «текст» и «имя», значения «ключевое слово» НЕ ДОЛЖНЫ использовать механизм переопределения естественного языка, поскольку они всегда ДОЛЖНЫ быть US-ASCII и американским английским.

Ключевые слова для использования в протоколе. Пользовательский интерфейс, скорее всего, обеспечит отображение между ключевыми словами протокола и отображаемыми понятными для пользователя словами и фразами, которые локализованы на естественном языке пользователя. Хотя ключевые слова, указанные в этом документе, МОГУТ отображаться пользователям, чей естественный язык — американский английский, они МОГУТ быть сопоставлены с другими словами английского языка для пользователей английского языка США, поскольку пользовательский интерфейс выходит за рамки этого документа.

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

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

«job-name»
«attributes-charset»

Примечание. В этом документе используются префиксы «type1» и «type2» к базовому синтаксису «ключевого слова» для указания различных уровней проверки расширений (см. Раздел 7.3).

5.1.5. ’enum’ — перечисление

Синтаксис атрибута enum — это перечисляемое целочисленное значение в диапазоне от 1 до 2 ** 31 — 1 (MAX). Каждое значение имеет ассоциированное с ним ключевое слово. В определении для каждого атрибута этого синтаксического типа указан полный набор возможных значений для этого атрибута. Этот тип синтаксиса используется для атрибутов, для которых есть значения перечисления, назначенные другими стандартами, такими как MIB SNMP. Ряд значений перечисления атрибутов в этом документе также используется для соответствующих атрибутов в других стандартах [RFC3805]. Этот тип синтаксиса не используется для атрибутов, которым администратор может назначать значения. Раздел 7.4 описывает, как протокол может быть расширен новыми значениями перечисления.

Перечисленные значения предназначены для использования в протоколе. Пользовательский интерфейс обеспечит отображение между значениями перечисления протокола и отображаемыми удобными для пользователя словами и фразами, которые локализованы на естественном языке пользователя. Хотя символы перечисления, указанные в этом документе, МОГУТ отображаться пользователям, чей естественный язык — американский английский, они МОГУТ быть сопоставлены с другими словами английского языка для пользователей английского языка США, поскольку пользовательский интерфейс выходит за рамки этого документа.

Примечание. Некоторые SNMP MIB используют «2» для «неизвестного», что соответствует значению «вне диапазона» IPP «неизвестно». См. Описание «внеполосных» значений в начале раздела 5.1. Поэтому атрибуты типа «enum» обычно начинаются с «3».

Примечание. В этом документе используются префиксы «type1» и «type2» к базовому синтаксису «enum» для указания различных уровней просмотра расширений (см. Раздел 7.4).

5.1.6. ’uri’

Синтаксис атрибута ‘uri’ — это любой допустимый универсальный идентификатор ресурса (URI) [RFC3986]. Чаще всего URI представляют собой просто унифицированные указатели ресурсов (URL). Максимальная длина URI, используемых в качестве значений атрибутов IPP, составляет 1023 октета. Хотя большинство других типов синтаксиса атрибутов IPP допускают только строчные значения, этот тип синтаксиса атрибута соответствует правилам с учетом регистра и без учета регистра, указанным в [RFC3986]. См. Также [RFC3196] для обсуждения случая в URI.

5.1.7. ’uriScheme’ — схема URI

Синтаксис атрибута «uriScheme» представляет собой последовательность символов, представляющих схему URI в соответствии с RFC 3986 [RFC3986]. Хотя в RFC 3986 требуется, чтобы значения не учитывали регистр, для IPP требуются все строчные значения в атрибутах IPP, чтобы упростить сравнение по клиентам и принтерам IPP.

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

’ipp’: for IPP schemed URIs, e.g., «ipp://example.com/ipp/…»
[RFC3510]
’ipps’: for IPPS schemed URIs, e.g., «ipps://example.com/ipp/…»
[RFC7472]
’http’: for HTTP schemed URIs, e.g., «http://example.com/path/to/
filename» [RFC7230]
’https’: for HTTPS schemed URIs, e.g.,
«https://example.com/path/to/filename» [RFC7230]
’ftp’: for FTP schemed URIs, e.g., «ftp://example.com/path/to/
filename» [RFC1738]
’mailto’: for SMTP schemed URIs, e.g., «mailto:user@example.com»
[RFC6068]
’file’: for file schemed URIs, e.g., «file:///path/to/filename»
[RFC1738]
’urn’: for Uniform Resource Name schemed URIs, e.g.,
«urn:uuid:01234567-89ab-cdef-fedc-ba9876543210» [RFC4122]

Принтер МОЖЕТ поддерживать любую схему URI, зарегистрированную в IANA [IANA-MT]. Максимальная длина значений схемы URI, используемых для представления значений атрибута IPP, составляет 63 октета.

5.1.8. ’charset’ — кодировка

Синтаксис атрибута «charset» является стандартным идентификатором для charset. Кодировка — это кодированный набор символов и схема кодирования. Наборы символов используются для маркировки определенного содержимого документа, значений атрибутов «текст» и значений атрибутов «имя». Синтаксис и семантика этого синтаксиса атрибута определены в RFC 2046 [RFC2046] и содержатся в реестре «Наборов символов» IANA [IANA-CS] в соответствии с процедурами IANA [RFC2978]. Хотя RFC 2046 требует, чтобы значения не учитывали регистр US-ASCII [RFC20], для IPP требуются все строчные значения в атрибутах IPP, чтобы упростить сравнение клиентами и принтерами IPP. Когда набор символов в реестре IANA имеет более одного имени (псевдоним), ДОЛЖНО использоваться имя, помеченное как «(предпочтительное имя MIME)», если оно присутствует.

Максимальная длина значений «charset», используемых для представления значений атрибутов IPP, составляет 63 октета.

Вот некоторые примеры:

’utf-8’: Универсальный многооктетный набор кодированных символов (UCS) ISO 10646 [ISO10646], представленный в виде схемы кодирования передачи UTF-8 [RFC3629], в которой US-ASCII [RFC20] является подмножеством кодировки.
» us-ascii »: 7-битный американский стандартный код для обмена информацией (ASCII) [RFC20].
‘iso-8859-1’: 8-битный однобайтовый набор кодированных символов, латинский алфавит № 1 [ISO8859-1]. Этот стандарт определяет набор кодированных символов, который используется латинскими языками в Западном полушарии и Западной Европе. US-ASCII является подмножеством кодировки.

Некоторые описания атрибутов МОГУТ предъявлять дополнительные требования к значениям набора символов, которые могут использоваться, такие как ТРЕБУЕМЫЕ значения, которые ДОЛЖНЫ поддерживаться, или дополнительные ограничения, такие как требование, чтобы набор символов в кодировке US-ASCII был подмножеством.

5.1.9. ’naturalLanguage’ — естественный язык

Синтаксис атрибута «NaturalLanguage» является стандартным идентификатором для естественного языка и, необязательно, страны или региона. Значения для этого типа синтаксиса определены в RFC 5646 [RFC5646]. Хотя RFC 5646 требует, чтобы значения не учитывали регистр US-ASCII, для IPP требуются все строчные значения в атрибутах IPP, чтобы упростить сравнение с помощью клиентов и принтеров IPP. Примеры включают в себя:

’en’: для английского языка
‘en-us’: для американского английского
‘фр’: для французского
‘де’: для немецкого

Максимальная длина значений «naturalLanguage», используемых для представления значений атрибута IPP, составляет 63 октета.

Примечание. Хотя можно использовать любой стандартный идентификатор естественного языка, определенный в RFC 5646, клиенты обычно поддерживают только подмножество этих идентификаторов. При сравнении двух идентификаторов или выполнении поиска принтеры ДОЛЖНЫ быть готовы сопоставить устаревшие идентификаторы с их соответствующими современными эквивалентами и наоборот.

5.1.10. ’mimeMediaType’ — медиа типы MIME

Синтаксис атрибута «mimeMediaType» — это тип интернет-медиа (иногда называемый «тип MIME»), определенный в RFC 2046 [RFC2046] и зарегистрированный в соответствии с процедурами RFC 6838 [RFC6838] для идентификации формата документа. Значение МОЖЕТ включать параметр charset или какой-либо другой параметр, в зависимости от спецификации типа носителя в реестре IANA «Типы носителя» [IANA-MT]. Хотя большинство других типов синтаксиса IPP допускают только строчные значения, этот тип синтаксиса допускает значения со смешанным регистром без учета регистра.

Примеры:

o’’ text / html ’: HTML-документ
o » text / plain »: простой текстовый документ в US-ASCII (RFC 2046 указывает, что при отсутствии параметра charset ДОЛЖЕН означать US-ASCII, а не просто не указываться) [RFC2046]
o ’text / plain; charset = US-ASCII ’: простой текстовый документ в US-ASCII
o ’text / plain; charset = ISO-8859-1 ’: простой текстовый документ в ISO 8859-1 (лат. 1) [ISO8859-1]
o ’text / plain; charset = utf-8 ’: простой текстовый документ в ISO 10646, представленный как UTF-8 [RFC3629]
o ‘application / postscript’: документ PostScript [RFC2046]
o ’application / vnd.hp-PCL’: документ PCL [IANA-MT] (escape-последовательность кодировки, встроенная в данные документа)
o ’application / pdf’: формат переносимого документа [ISO32000]
o ‘application / octet-stream’: автоматическое распознавание — см. раздел 5.1.10.1

Максимальная длина значения mimeMediaType для представления значений атрибута IPP составляет 255 октетов.

5.1.10.1. ’application/octet-stream’ — автоматическое определение формата документа

Одним из специальных типов является application / octet-stream. Если принтер поддерживает это значение, он ДОЛЖЕН быть способен автоматически определять формат данных документа, используя метод, зависящий от реализации, который проверяет некоторое количество октетов данных документа, как часть запроса на создание задания и / или во время обработки документов. Во время автоматического определения принтер может определить, что данные документа имеют формат, который принтер не может распознать. Если принтер определяет эту проблему перед возвратом ответа операции, он отклоняет запрос и возвращает код состояния «клиент-ошибка-формат-документа-не-поддерживается». Если Принтер определяет эту проблему после принятия запроса и возврата ответа операции с одним из успешных значений кода состояния, Принтер добавляет значение «unsupported-document-format» в атрибут «Задание-состояние-задания» задания.

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

1. Если Клиент не предоставляет значение формата документа, принтер ДОЛЖЕН полагаться на настройку значения по умолчанию (это может быть «application / octet-stream», указывающий механизм автоматического определения).

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

3. Если Клиент предоставляет значение «application / octet-stream», Клиент указывает, что Принтер ДОЛЖЕН использовать свой механизм автоматического определения для данных Документа, предоставленных Клиентом, независимо от того, является ли автоматическое определение по умолчанию для Принтера или нет.

Примечание. Поскольку алгоритм автоматического определения является вероятностным, если Клиент запрашивает как автоматическое определение («формат документа», установленный в «application / octet-stream»), так и истинную точность («ipp-attribute-fidelity», установленный в «true» ‘), Принтер может быть не в состоянии точно гарантировать, что задумал Конечный пользователь (алгоритм автоматического определения может принять один формат документа за другой), но он может гарантировать, что будет использоваться его механизм автоматического определения.

5.1.11. ’octetString’ — строка октетов

Синтаксис атрибута «octetString» представляет собой последовательность октетов, закодированных максимум в 1023 октета, которая указывается в определениях синтаксиса с использованием нотации «octetString (MAX)». Этот тип синтаксиса используется для непрозрачных данных.

5.1.12. ’boolean’ — логическое

Синтаксис атрибута «логический» имеет только два значения: «истина» и «ложь».

5.1.13. ’integer’ — целое число

Синтаксис атрибута ‘integer’ представляет собой целочисленное значение в диапазоне от -2 ** 31 (MIN) до 2 ** 31 — 1 (MAX). Каждый отдельный атрибут может явно указывать ограничение диапазона, если диапазон отличается от полного диапазона возможных целочисленных значений — например, приоритет задания (целое число (1: 100)) для атрибута «приоритет задания», как показано в название раздела 5.2.1. Однако принудительное применение этого дополнительного ограничения зависит от объектов IPP, а не от протокола.

5.1.14. ’rangeOfInteger’ — диапазон целых чисел

Синтаксис атрибута «rangeOfInteger» — это упорядоченная пара целых чисел, которая определяет включающий диапазон целочисленных значений. Первое целое число определяет нижнюю границу, а второе — верхнюю границу. Если в определении атрибута указано ограничение диапазона, т. Е. ‘RangeOfInteger (X: Y)’, указывающее X как минимальное значение и Y как максимальное значение, то ограничение применяется к обоим целым числам.

5.1.15. ’dateTime’ — дата время

Синтаксис атрибута dateTime является стандартным 11-октетным представлением фиксированной длины синтаксиса DateAndTime, как определено в RFC 2579 [RFC2579]. RFC 2579 также идентифицирует 8-октетное представление значения «DateAndTime», но объекты IPP ДОЛЖНЫ использовать 11-октетное представление. Пользовательский интерфейс обеспечит отображение между значениями протокола dateTime и отображаемыми понятными для пользователя словами или значениями и фразами представления, которые локализованы на естественном языке и формате даты пользователя, включая часовой пояс.

5.1.16. ’resolution’ — разрешающая способность

Синтаксис атрибута ‘resolution’ определяет двумерное разрешение в указанных единицах. Он состоит из трех значений: разрешение в направлении поперечной подачи (положительное целое значение), разрешение в направлении подачи (положительное целое значение) и единица измерения. Семантика этих трех компонентов взята из предложенных значений в Printer MIB [RFC3805]. То есть компонент разрешения направления поперечной подачи такой же, как объект prtMarkerAddressabilityXFeedDir в MIB принтера, компонент разрешения направления подачи такой же, как prtMarkerAddressabilityFeedDir в MIB принтера, а компонент единиц такой же, как объект prtMarkerAddressabilityUnit в Printer MIB (а именно «3» обозначает количество точек на дюйм, а «4» обозначает число точек на сантиметр). Все три значения ДОЛЖНЫ присутствовать, даже если первые два значения одинаковы. Например, ’300’, ’600’, ’3’ обозначает разрешение направления поперечной подачи 300 т / д и разрешение направления подачи 600 т / д, поскольку ’3’ указывает число точек на дюйм (т / д).

5.1.17. ’collection’ — коллекция

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

Ценность коллекции состоит из трех отдельных компонентов:

значение ‘begCollection’ с необязательным значением строки октета, начинающим сбор,
Ноль или более атрибутов-членов, определенных с использованием ряда неназванных значений, начинающихся со значения «memberAttrName», которое задает имя атрибута-члена
Значение endCollection с необязательным именем плюс строковое значение октета, заканчивающее коллекцию.

5.1.18. ’1setOf X’

Синтаксис атрибута «1setOf X» — это одно или несколько значений типа синтаксиса атрибута X. Этот тип синтаксиса используется для многозначных атрибутов. Тип синтаксиса называется «1setOf», а не просто «setOf», как напоминание о том, что набор значений НЕ ДОЛЖЕН быть пустым (т. Е. Набор с размером 0). Наборы обычно неупорядочены; однако каждое описание атрибута этого типа может указывать, что значения ДОЛЖНЫ быть в определенном порядке для этого атрибута.

5.2. Атрибуты шаблона задания

Атрибуты шаблона задания описывают цель обработки задания. Клиенты МОГУТ предоставлять (в запросах на создание заданий), а принтеры ДОЛЖНЫ поддерживать атрибуты шаблонов заданий. См. Раздел 2.3.11 для описания поддержки необязательных атрибутов.

Атрибуты шаблона работы соответствуют следующим правилам. Для каждого атрибута шаблона работы с именем «xxx»:

1. Если принтер поддерживает «xxx», то он ДОЛЖЕН поддерживать как атрибут «xxx-default» (если в таблице 8 ниже нет «атрибута»), так и атрибут «xxx-support». Если принтер не поддерживает «xxx», то он НЕ ДОЛЖЕН поддерживать ни атрибут «xxx-default», ни атрибут «xxx-support», и он ДОЛЖЕН трактовать атрибут «xxx», предоставленный клиентом, как неподдерживаемый. Атрибут «xxx» может поддерживаться для некоторых форматов документа и не поддерживаться для других форматов документа. Например, ожидается, что принтер будет поддерживать «запрашиваемую ориентацию» только для некоторых форматов документов (таких как «text / plain» или «text / html»), но не для других (таких как «application / postscript»).

2. Клиенты МОГУТ предоставить «xxx» в запросе на создание вакансии. Если указано «xxx», Клиент указывает желаемое поведение обработки задания для этого задания. Если «xxx» не указано, Клиент указывает, что принтер применяет свое поведение по умолчанию для Обработки заданий во время обработки заданий, если содержимое документа не содержит встроенную инструкцию, указывающую поведение, связанное с ххх.

Поскольку администратор МОЖЕТ изменить атрибут значения по умолчанию после отправки задания, но до его обработки, значение по умолчанию, используемое принтером во время обработки задания, может отличаться от значения по умолчанию, действующего во время отправки задания.

3. Атрибут «ххх-поддерживаемый» — это атрибут принтера, который описывает, какие режимы обработки заданий поддерживаются этим принтером. Клиент может запросить принтер, чтобы выяснить, какие поведения, связанные с xxx, поддерживаются, проверив возвращенные значения атрибута «xxx-support».

Примечание. «Xxx» в каждом имени атрибута «xxx-support» является единичным, хотя атрибут «xxx-support» обычно имеет более одного значения, например «print-quality-Поддерживается», если только не задание «xxx» Атрибут шаблона является множественным, например «отделка» или «сторона». В таких случаях имена атрибутов «с поддержкой xxx» являются «поддерживаемыми окончаниями» и «поддерживаемыми сторонами».

4. Атрибут значения по умолчанию «xxx-default» описывает, что будет сделано во время обработки задания, когда клиент не предоставит никакой другой информации об обработке задания (явно как атрибут IPP в запросе на создание задания или неявно как встроенная инструкция внутри Данные документа).

Если приложение желает предоставить Конечному пользователю список поддерживаемых значений, из которых можно выбирать, приложение ДОЛЖНО запросить у принтера атрибуты поддерживаемых значений. Приложение ДОЛЖНО также запрашивать атрибуты значений по умолчанию. Если приложение затем ограничивает выбираемые значения только теми значениями, которые поддерживаются, приложение может гарантировать, что все значения, предоставленные Клиентом в запросе на создание задания, попадают в набор поддерживаемых значений на принтере. При запросе принтера клиент МОЖЕТ перечислить каждый атрибут по имени в запросе Get-Printer-Attributes, или клиент МОЖЕТ просто назвать группу «job-template», чтобы получить полный набор поддерживаемых атрибутов (как поддерживаемых, так и используемых по умолчанию). атрибуты).

Таблица 8 - Атрибуты шаблона работы — Таблица 8 — Атрибуты шаблона работы

5.2.1. job-priority (integer(1:100)) — приоритет работы (целое число (1: 100))

Этот атрибут определяет приоритет для планирования работы. Более высокое значение указывает более высокий приоритет. Значение 1 указывает наименьший возможный приоритет. Значение 100 указывает на максимально возможный приоритет. Среди тех заданий, которые готовы к печати, принтер ДОЛЖЕН распечатать все задания со значением приоритета n, прежде чем печатать задания со значением приоритета n — 1 для всех n.

Если принтер поддерживает этот атрибут, он ДОЛЖЕН всегда поддерживать полный диапазон от 1 до 100. Административные ограничения не допускаются. Таким образом, Конечный пользователь всегда может в полной мере использовать весь диапазон с любым принтером. Если привилегированные задания реализованы за пределами IPP, они ДОЛЖНЫ иметь приоритеты выше 100, а не ограничивать диапазон, доступный конечным пользователям.

Если Клиент не предоставляет этот атрибут, и этот атрибут поддерживается принтером, принтер ДОЛЖЕН использовать значение атрибута «job-priority-default» принтера во время отправки задания (в отличие от большинства атрибутов шаблона задания, которые используются при необходимости при Время обработки задания).

Синтаксис для атрибута «приоритет работы поддерживается» также целочисленный (1: 100). Это одно целочисленное значение указывает количество поддерживаемых уровней приоритета. Принтер ДОЛЖЕН принять значение, предоставленное Клиентом, и сопоставить его с ближайшим целым числом в последовательности из n целых значений, которые равномерно распределены в диапазоне от 1 до 100, используя формулу:

roundToNearestInt((100x + 50) / n)

где n — это значение «job-priority-supported» (поддерживается приоритет работы), а x находится в диапазоне от 0 до (n — 1).

Например, если n = 1, последовательность значений равна 50; если n = 2, последовательность значений составляет 25 и 75; если n = 3, последовательность значений равна 17, 50 и 83; если n = 10, последовательность значений составляет 5, 15, 25, 35, 45, 55, 65, 75, 85 и 95; если n = 100, последовательность значений составляет 1, 2, 3, … 100.

В таблице 9 показано, как принтер отображает предоставленные клиентом значения «приоритет работы», например, значения n.

Таблица 9 - Последовательные значения Работа-Приоритет — Таблица 9 — Последовательные значения Работа-Приоритет

5.2.2. job-hold-until (type2 keyword | name(MAX)) — удержание задания

Этот атрибут указывает именованный период времени, в течение которого задание ДОЛЖНО стать кандидатом на печать.
Стандартные значения ключевых слов для именованных периодов времени:

’no-hold’: немедленно, если нет других причин удерживать работу
’indefinite’ — неопределенный: задание удерживается неопределенное время до тех пор, пока клиент не выполнит повторное задание (раздел 4.3.6)
’day-time’: в течение дня
’evening’: вечер
’night’: ночь
’weekend’: выходные
’second-shift’: вторая смена (после закрытия бизнеса)
’third-shift’: третья смена (после полуночи)

Администратор ДОЛЖЕН связать допустимое время печати с указанным периодом времени (с помощью средств, выходящих за рамки этого документа IPP / 1.1). Администратору рекомендуется выбирать имена, которые предлагают тип периода времени. Администратор МОЖЕТ определять дополнительные значения, используя синтаксис атрибута «name» или «keyword», в зависимости от реализации.

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

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

Если это значение атрибута Задания является именованным значением «no-hold» или указанный период времени уже начался, Задание ДОЛЖНО быть кандидатом на немедленную обработку.

Если Клиент не предоставляет этот атрибут, и этот атрибут поддерживается Принтером, Принтер ДОЛЖЕН использовать значение «Задержание задания по умолчанию» для принтера во время отправки задания (в отличие от большинства атрибутов шаблона задания, которые используются при необходимости). во время обработки задания).

5.2.3. job-sheets (type2 keyword | name(MAX)) — Рабочие листы

Этот атрибут определяет, какой начальный / конечный лист (ы) Задания, если таковые имеются, ДОЛЖНЫ быть напечатаны вместе с Заданием.
Стандартные значения ключевых слов:

‘none‘: лист работы не печатается
’standard’: печатается один или несколько стандартных листов заданий для конкретного сайта, например, один начальный лист или оба начальных и конечных листа. Администратор МОЖЕТ определить дополнительные значения, используя синтаксис атрибута «name» или «keyword», в зависимости от реализации.

Влияние этого атрибута на задания с несколькими документами МОЖЕТ зависеть от атрибута задания «обработка нескольких документов» (раздел 5.2.4), в зависимости от семантики листа заданий.

5.2.4. multiple-document-handling (type2 keyword) — Обработка нескольких документов

Этот РЕКОМЕНДУЕМЫЙ атрибут управляет тем, какие показы и листы мультимедиа составляют набор для процессов создания и завершения копирования. Когда значение атрибута «копии» превышает «1», оно также контролирует порядок, в котором создаются копии, полученные в результате обработки Документов. В целях этого объяснения, если «а» представляет экземпляр данных документа, то результатом обработки данных в документе «а» является последовательность листов медиафайлов, представленная «а (*)». Этот атрибут ДОЛЖЕН поддерживаться хотя бы одним значением, если принтер поддерживает несколько документов на одно задание (см. Разделы 4.2.4 и 4.3.1).

Стандартные значения ключевых слов:

’single-document’ (один документ): если задание имеет несколько документов, скажем, данные документа называются «a» и «b», то результат обработки всех данных документа (a и затем b) ДОЛЖЕН рассматриваться как один последовательность медиа-листов для отделочных процессов; то есть окончание выполняется при конкатенации последовательностей a (*), b (*). Принтер НЕ ДОЛЖЕН принудительно форматировать данные в каждом экземпляре документа на новом Impression или запускать новое Impression на новом листе носителя. Если сделано более одной копии, порядок следования наборов листов бумаги, полученных в результате обработки данных документа, ДОЛЖЕН быть a (*), b (*), a (*), b (*), … и Принтер ДОЛЖЕН принудительно запускать каждую копию (a (*), b (*)) на новом листе бумаги.
’separate-documents-uncollated-copies’ (отдельные-документы-несократированные-копии): если в задании есть несколько документов, скажем, данные документа называются «а» и «b», то результат обработки данных в каждом экземпляре документа ДОЛЖЕН рассматриваться как одна последовательность Медиа Листов для отделочных процессов; то есть наборы a (*) и b (*) будут завершены отдельно. Принтер ДОЛЖЕН принудительно запускать каждую копию результата обработки данных в одном документе на новом листе носителя. Если сделано более одной копии, порядок наборов листов носителей, полученных в результате обработки данных документа, ДОЛЖЕН быть a (*), a (*), …, b (*), b (*), .. …
’separate-documents-collated-copies’ (отдельные документы-разборные копии): если в задании имеется несколько документов, скажем, данные документа называются «а» и «b», то результат обработки данных в каждом экземпляре документа ДОЛЖЕН рассматриваться как одна последовательность Медиа Листов для отделочных процессов; то есть наборы a (*) и b (*) будут завершены отдельно. Принтер ДОЛЖЕН принудительно запускать каждую копию результата обработки данных в одном документе на новом листе носителя. Если сделано более одной копии, порядок следования наборов листов бумаги, полученных в результате обработки данных документа, ДОЛЖЕН быть a (*), b (*), a (*), b (*), ….
’single-document-new-sheet’ (один документ новый лист): то же самое, что и ‘single-document’, за исключением того, что принтер ДОЛЖЕН гарантировать, что первое впечатление от каждого экземпляра документа в задании будет размещено на новом листе носителя. Это значение позволяет сшивать несколько документов вместе с одним сшивателем, где каждый документ начинается на новом листе бумаги.

Значение ‘single-document’ такое же, как ‘Отдельные-Document-Collated-копии’ в отношении упорядочения входных страниц, но не генерации медиа-листа, так как ‘Single-Document’ будет помещать первую страницу следующего документа на обратной стороне листа бумаги, если на данный момент для работы было создано нечетное количество страниц, в то время как «Отдельные документы-сопоставления-копии» всегда вынуждают следующий документ или копию документа на новый лист бумаги. Кроме того, если в атрибуте «отделки» указано «сшивание», то в случае «одного документа» документы А и В сшиваются вместе в виде одного набора, безотносительно к новому листу носителя, в то время как с «единственным документом-новым» -sheet ‘, документы a и b сшиваются вместе как один комплект, но документ b начинается на новом листе носителя. При использовании «отдельных документов-копий-копий» и «отдельных документов-копий-копий» документы А и В сшиваются отдельно.

Примечание. Значение ‘Отдельные-документы-несократированные-копии’ создает несократированные листы мультимедиа в наборе, например, когда «копии» равны «2», задание с двумя документами будет напечатано как листы мультимедиа a (1), a (1). ), a (2), a (2), … a (n), a (n), b (1), b (1), …, b (n), b (n). Все остальные значения создают сопоставленные листы мультимедиа в наборе.

Взаимосвязь этого атрибута и других атрибутов, управляющих обработкой Документа, описана в Приложении C.3.

5.2.5. copies (integer(1:MAX)) — копии

Этот РЕКОМЕНДУЕМЫЙ атрибут определяет количество копий для печати.

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

Примечание. Эффект этого атрибута для заданий с несколькими документами контролируется атрибутом задания «обработка нескольких документов» (раздел 5.2.4). Взаимосвязь этого атрибута и других атрибутов, управляющих обработкой Документа, описана в Приложении C.3.

5.2.6. finishings (1setOf type2 enum) — завершения

Этот РЕКОМЕНДУЕМЫЙ атрибут определяет завершающие процессы, которые принтер использует для каждой копии каждого распечатанного документа в задании. Для заданий с несколькими документами атрибут «обработка нескольких документов» определяет, что является «копией» в целях завершения.

Стандартные значения перечисления, определенные в этом документе, перечислены в Таблице 10. Значения «staple-xxx» указываются относительно Документа, как если бы Документ был в книжной ориентации с исходным положением каждого Листа мультимедиа в верхнем левом углу. Если Документ фактически находится в горизонтальной или обратной горизонтальной ориентации, Клиент предоставляет соответствующее преобразованное значение. Например, чтобы расположить скрепку в верхнем левом углу документа с альбомной ориентацией, когда он удерживается для чтения, Клиент предоставляет значение «скрепка-нижний левый», поскольку альбомная ориентация определяется как поворот изображения на +90 градусов с помощью уважение к носителю из портрета, т. е. против часовой стрелки. С другой стороны, чтобы расположить скрепку в верхнем левом углу Документа с обратным ландшафтом, когда она удерживается для чтения, Клиент предоставляет значение «сшивание-верхний правый», поскольку обратный пейзаж определяется как -90 Степень поворота изображения относительно носителя из портрета, т. е. по часовой стрелке.

Угол (вертикальный, горизонтальный, угловой) каждой скобки относительно документа зависит от реализации, которая, в свою очередь, может зависеть от значения атрибута.

Примечание. Значение «3» («нет») не влияет на любые другие значения.

Примечание. Атрибут «finishings-col» (отделочные материалы) [PWG5100.1] является альтернативой атрибуту «отделочные материалы», который позволяет клиенту более подробно определять намерение завершить.

Таблица 10 - Перечисляемые значения finishings — Таблица 10 — Перечисляемые значения finishings

Значение «3»

Символьное имя ’none’ (ничего): не выполнять отделку.

Значение «4»

Символьное имя ’staple’ (скрепка): связать документ (ы) одним или несколькими скрепками. Точное количество и расположение скрепок определяются на месте.

Значение «5»

Символьное имя ’punch’ (удар): это значение указывает, что в готовом документе требуются отверстия. Точное количество и расположение отверстий определяются на месте. Спецификация перфорации МОЖЕТ быть удовлетворена (в зависимости от конкретной площадки и конкретной реализации) либо путем сверления / перфорации, либо путем замены предварительно просверленной среды.

Значение «6»

Символьное имя ’cover’ (обложка): это значение указывается, когда необходимо выбрать непечатную (или предварительно напечатанную) обложку для документа. Это не заменяет спецификацию печатной обложки (на материале обложки) самим Документом.

Значение «7»

Символьное имя ’bind’ (связать): это значение указывает, что привязка должна применяться к документу; тип и размещение привязки определяются сайтом.

Значение «8»

Символьное имя ’saddle-stitch’ (седельная строчка): связывайте документ (ы) одним или несколькими скрепками (проволочными стежками) вдоль средней складки. Точное количество и расположение скрепок и средней складки определяются реализацией и / или местом расположения.

Значение «9»

Символьное имя ’edge-stitch’ (кромочный стежок): связывайте документ (ы) одной или несколькими скобками (проволочными стежками) вдоль одного края. Точное количество и расположение скрепок определяются реализацией и / или местом расположения.

Значение «10» — «19»

Зарезервировано для будущих общих значений enum.

Значение «20»

Символьное имя ’staple-top-left’ (скрепка-верхний левый): связать документ (-ы) с одним или несколькими скрепками в верхнем левом углу.

Значение «21»

Символьное имя ’staple-bottom-left’ (скрепка-нижний левый): связать документ (-ы) с одним или несколькими скрепками в левом нижнем углу.

Значение «22»

Символьное имя ’staple-top-right’ (скрепка-верх-правая): связать документ (-ы) с одним или несколькими скрепками в верхнем правом углу.

Значение «23»

Символьное имя ’staple-bottom-right’ (скрепка-нижний правый): связать документ (-ы) с одним или несколькими скрепками в правом нижнем углу.

Значение «24»

Символьное имя ’edge-stitch-left’: связать документ (-ы) одной или несколькими скобками (проволочными стежками) вдоль левого края. Точное количество и расположение скрепок определяются реализацией и / или местом расположения.

Значение «25»

Символьное имя ’edge-stitch-top’: связывайте документ (-ы) одним или несколькими скрепками (проволочными стежками) вдоль верхнего края. Точное количество и расположение скрепок определяются реализацией и / или местом расположения.

Значение «26»

Символьное имя ’edge-stitch-right’: связать документ (-ы) одной или несколькими скобками (проволочными стежками) вдоль правого края. Точное количество и расположение скрепок определяются реализацией и / или местом расположения.

Значение «27»

Символьное имя ’edge-stitch-bottom’: связывайте документ (-ы) одной или несколькими скобками (проволочными стежками) вдоль нижнего края. Точное количество и расположение скрепок определяются реализацией и / или местом расположения.

Значение «28»

Символьное имя ’staple-dual-left’: связать документ (ы) двумя скрепками (проволочными стежками) вдоль левого края, предполагая, что это портретный документ (см. Выше).

Значение «29»

Символьное имя ’staple-dual-top’: связать документ (ы) двумя скрепками (проволочными стежками) вдоль верхнего края, предполагая, что это портретный документ (см. Выше).

Значение «30»

Символьное имя ’staple-dual-right’: связать документ (ы) двумя скрепками (проволочными стежками) вдоль правого края, предположив, что это портретный документ (см. Выше).

Значение «31»

Символьное имя ’staple-dual-bottom’: связать документ (ы) двумя скрепками (проволочными стежками) вдоль нижнего края, предполагая, что это портретный документ (см. Выше).

5.2.7. page-ranges (1setOf rangeOfInteger(1:MAX)) — диапазоны страниц

Этот РЕКОМЕНДУЕМЫЙ атрибут определяет диапазон (ы) входных страниц, которые принтер использует для каждого набора, который должен быть напечатан до наложения этих страниц на показы. Ничего не печатается для любых идентифицированных страниц, которые не существуют в наборе / документе (ах). Диапазоны ДОЛЖНЫ быть в порядке возрастания (1-3, 5-7, 15-19 и т. д.) И НЕ ДОЛЖНЫ перекрываться, чтобы не спулинговый принтер мог обрабатывать задание за один проход. Если диапазоны не возрастают или перекрываются, принтер ДОЛЖЕН отклонить запрос и вернуть код состояния «client-error-bad-request». Атрибут связан с входными страницами, а не с номерами приложений, такими как номера страниц, найденные в верхних и / или нижних колонтитулах для определенных приложений для обработки текста.

Для заданий с несколькими документами атрибут «обработка нескольких документов» определяет, что составляет набор для целей указанного диапазона страниц. Когда «обработка нескольких документов» является «одним документом», принтер ДОЛЖЕН применять каждый предоставленный диапазон страниц один раз для объединения входных страниц. Например, если имеется 8 документов по 10 страниц каждый, диапазон страниц «41-60» печатает страницы в 5-м и 6-м документах как один документ, и ни одна из страниц других документов не печатается. Когда «обработка нескольких документов» представляет собой «отдельные документы-несвязанные копии» или «отдельные документы-разборные копии», принтер ДОЛЖЕН неоднократно применять каждый предоставленный диапазон страниц к каждой копии документа. Для той же работы диапазон страниц «1-3, 10-10» будет печатать первые 3 страницы и 10-ю страницу каждого из 8 документов в задании в виде 8 отдельных комплектов.

«page-ranges-supported» (поддерживаемые диапазоны страниц) — это логическое значение, указывающее, способен ли принтер поддерживать печать диапазонов страниц. Эта возможность может отличаться от одного PDL к другому. Нет атрибута «page-range-default». Если атрибут «диапазоны страниц» не предоставлен Клиентом, печатаются все страницы документа.

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

5.2.8. sides (type2 keyword) — стороны

Этот РЕКОМЕНДУЕМЫЙ атрибут указывает, как показы размещаются по бокам листа носителя.

Стандартные значения ключевых слов:

’one-sided’ (односторонний): накладывает каждое последующее впечатление на одну и ту же сторону последовательных листов СМИ.
’two-sided-long-edge’ (двухсторонний длинный край): накладывает каждую последовательную пару впечатлений на лицевую и заднюю стороны последовательных листов носителя, так что ориентация каждой пары впечатлений на носителе будет правильной для читателя, как если бы она была привязана к длинный край Такое наложение иногда называют ’duplex’ (дуплексом) или ’head-to-head’ (лицом к лицу).
’two-sided-short-edge’ (двухсторонний-короткий-край): накладывает каждую последовательную пару впечатлений на лицевую и заднюю стороны последовательных листов носителя, так что ориентация каждой пары впечатлений на носителе будет правильной для читателя, как если бы она была привязана к короткий край. Такое наложение иногда называют ’tumble’ (падением) или ’head-to-toe’ (с ног до головы).

5.2.9. number-up (integer(1:MAX)) — число вверх

Этот атрибут задает количество входных страниц для наложения на одно впечатление. Например, если значение:

’1’: принтер ДОЛЖЕН размещать одну входную страницу на одном показе.
’2’: принтер ДОЛЖЕН размещать две входные страницы на одном отпечатке.
’4’: принтер ДОЛЖЕН размещать четыре входных страницы на одном отпечатке.

Во всех случаях Принтер МОЖЕТ добавить некоторый вид перевода, масштабирования или поворота входных страниц при наложении их.

5.2.10. orientation-requested (type2 enum) — запрашиваемая ориентация

Этот РЕКОМЕНДУЕМЫЙ атрибут указывает желаемую ориентацию для печатных входных страниц; он не описывает ориентацию предоставленных клиентом входных страниц.

Для некоторых форматов документа (таких как «application / postscript») желаемая ориентация страниц ввода иногда указывается в данных документа. Эта информация генерируется драйвером принтера до отправки задания на печать. Другие форматы документа, такие как «текст / обычный», не включают в себя понятие желаемой ориентации в данных документа. В последнем случае принтер может связать желаемую ориентацию с данными документа после его отправки. Принтеры МОГУТ поддерживать «запрашиваемую ориентацию» только для некоторых форматов документов (например, «text / plain» или «text / html»), но не для других (например, «application / postscript»). Это ничем не отличается от любого другого атрибута шаблона работы, поскольку в разделе 5.2, пункт 1, указывается, что принтер может поддерживать или не поддерживать любой атрибут шаблона работы на основе формата документа, предоставленного клиентом. Однако здесь следует особо упомянуть, поскольку весьма вероятно, что принтер будет поддерживать «запрошенную ориентацию» только для подмножества поддерживаемых форматов документов.

Стандартные значения перечисления приведены в таблице 11.

Примечание. Эффект этого атрибута для заданий с несколькими документами контролируется атрибутом задания «обработка нескольких документов» (раздел 5.2.4).

Взаимосвязь этого атрибута и других атрибутов, управляющих обработкой Документа, описана в Приложении C.3.

Таблица 11 - Перечисление значений orientation-requested — Таблица 11 — Перечисление значений orientation-requested

Значение «3».

Символьное имя ’portrait’ (портрет): содержимое будет отображаться по короткому краю носителя.

Значение «4».

Символьное имя ’landscape’ (пейзаж): контент будет отображаться по длинному краю носителя. Пейзаж определяется как поворот входной страницы, которая должна отображаться на +90 градусов относительно носителя (то есть против часовой стрелки) от книжной ориентации. Примечание. Направление +90 было выбрано, потому что простая обработка по длинному краю — это одно и то же ребро, независимо от того, портретное или альбомное.

Значение «5».

Символьное имя ’reverse-landscape’ (обратный пейзаж): контент будет отображаться по всей длине носителя. Обратный ландшафт определяется как поворот входной страницы, которая должна отображаться на -90 градусов относительно носителя (то есть по часовой стрелке) от книжной ориентации. Примечание. Значение ‘reverse-landscape’ было добавлено, потому что некоторые приложения поворачивают альбомную ориентацию на -90 градусов, а не на +90 градусов.

Значение «6».

Символьное имя ’reverse-portrait’ (обратный портрет): контент будет отображаться по короткому краю носителя. Обратный портрет определяется как поворот входной страницы, которая должна отображаться на 180 градусов относительно носителя относительно книжной ориентации. Примечание. Значение «реверс-портрет» было добавлено для использования с атрибутом «финишная обработка» в тех случаях, когда для завершения работы с портретным документом на простых финишных устройствах, имеющих только одну финишную позицию, требуется противоположный край. Таким образом, «текстовый» / простой »портретный документ может быть сшит« справа »с помощью простого финишного устройства, как это обычно используется в некоторых ближневосточных языках, таких как иврит.

5.2.11. media (ключевое слово type2 | name (MAX))

Этот РЕКОМЕНДУЕМЫЙ атрибут определяет носитель, который принтер использует для всех показов задания.

Исторически значения «мультимедиа» включали в себя имена носителей, размеры носителей, входные лотки и электронные формы, так что один атрибут определяет носитель. Однако Клиент ДОЛЖЕН использовать атрибут медиа только для указания средних размеров с использованием стандартных имен PWG Media [PWG5101.1].

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

СЛЕДУЕТ использовать стандартные имена PWG Media [PWG5101.1]. Устаревшие значения «ключевых слов» взяты из ISO DPA [ISO10175], MIB принтера [RFC3805] и ASME-Y14.1M [ASME-Y14.1M]. Администратор МОЖЕТ определять дополнительные значения, используя синтаксис атрибута «name» или «keyword», в зависимости от реализации.

Существует также дополнительный атрибут Printer с именем «media-ready», который отличается от «media-support» тем, что допустимые значения включают только подмножество «media-ready» значений, которые физически загружены и готовы к печати без вмешательства оператора. ,

Взаимосвязь этого атрибута и других атрибутов, управляющих обработкой Документа, описана в Приложении C.3.

Примечание. Если это поддерживается принтером, клиенты МОГУТ использовать альтернативный атрибут «media-col» [PWG5100.3] [PWG5100.13] для более подробного определения требований к среде.

5.2.12. printer-resolution (resolution) — разрешение принтера (разрешение)

Этот РЕКОМЕНДУЕМЫЙ атрибут определяет выходное разрешение, которое принтер использует для работы.

Примечание. Этот атрибут и атрибут «качество печати» (раздел 5.2.13) используются для указания общего выходного качества работы. Если Клиент указывает конфликтующие значения «разрешение принтера» и «качество печати», Принтеры ДОЛЖНЫ использовать значение «качество печати».

5.2.13. print-quality (type2 enum) — качество печати (перечисление type2)

Этот атрибут РЕКОМЕНДУЕТСЯ определяет качество печати, которое принтер использует для работы.

Стандартные значения перечисления перечислены в таблице 12.

Примечание. Этот атрибут и атрибут «printer-resolution» (раздел 5.2.12) используются для указания общего качества вывода работы. Если Клиент указывает конфликтующие значения «разрешение принтера» и «качество печати», Принтеры ДОЛЖНЫ использовать значение «качество печати».

Таблица 12 - Перечисления значений качество печати — Таблица 12 — Перечисления значений качество печати

Значение «3». Символьное имя ’draft’ (черновик): самое низкое качество, доступное на принтере

Значение «4». Символьное имя ’normal’ (нормальное): нормальное или промежуточное качество на принтере

Значение «5». Символьное имя ’high’ (высокий): высочайшее качество, доступное на принтере

5.3. Описание задания и атрибуты статуса

Атрибуты в этом разделе образуют группу атрибутов, которая называется «описание работы». Таблицы 13 и 14 суммируют эти атрибуты. Третий столбец каждой таблицы указывает, является ли атрибут ОБЯЗАТЕЛЬНЫМ атрибутом, который ДОЛЖЕН поддерживаться Принтерами. Если он не указан как ТРЕБУЕМЫЙ, то он НЕОБЯЗАТЕЛЬНЫЙ. Максимальный размер в октетах для атрибутов «текст» и «имя» указан в скобках.

Таблица 13 - Атрибуты описания задания (READ-WRITE) — Таблица 13 — Атрибуты описания задания (READ-WRITE)

Таблица 14 - Атрибуты статуса задания (ТОЛЬКО ДЛЯ ЧТЕНИЯ) — Таблица 14 — Атрибуты статуса задания (ТОЛЬКО ДЛЯ ЧТЕНИЯ)

5.3.1. job-id (integer(1:MAX)) — идентификатор задания

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

Описание этого атрибута и его связь с атрибутами «job-uri» и «job-printer-uri» см. В разделе 3.4 («Идентификация объекта»).

5.3.2. job-uri (uri) — URI задания

Этот атрибут REQUIRED содержит URI для задания. Принтер при получении нового задания генерирует URI, который идентифицирует новое задание. Принтер возвращает значение атрибута «job-uri» как часть ответа на запрос «Создание задания». Точный формат URI задания зависит от реализации [RFC3510] [RFC7472]. Если принтер поддерживает более одного URI и существует некоторая связь между вновь сформированным URI задания и URI принтера, принтер использует URI принтера, предоставленный клиентом в запросе на создание задания. Например, если запрос создания задания поступает по безопасному каналу, новый URI задания ДОЛЖЕН использовать тот же защищенный канал. Это может быть гарантировано, поскольку принтер отвечает за генерацию URI задания, а принтер знает о своей конфигурации и политике безопасности, а также URI принтера, который используется в запросе на создание задания.

Описание этого атрибута и его взаимосвязи с атрибутами «job-id» и «job-printer-uri» см. В разделе 3.4 («Идентификация объекта»).

5.3.3. job-printer-uri (uri) — URI принтера задания

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

Описание этого атрибута и его связь с атрибутами «job-uri» и «job-id» см. В разделе 3.4 («Идентификация объекта»).

5.3.4. job-more-info (uri) — больше информации о задании

Подобно «printer-more-info», этот атрибут содержит URI, ссылающийся на некоторый ресурс с дополнительной информацией об этом задании, возможно, HTML-страницу, содержащую информацию о состоянии задания.

5.3.5. job-name (name(MAX)) — название задания

Этот НЕОБХОДИМЫЙ атрибут является названием работы. Это имя более удобное для пользователя, чем значения атрибутов «job-uri» или «job-id». Это не должно быть уникальным между Джобсом. Атрибут «Job-name» задания устанавливается равным значению, указанному Клиентом в атрибуте операции «job-name» в запросе на создание задания (см. Раздел 4.2.1.1). Если, однако, атрибут операции «имя-задания» не предоставлен Клиентом в запросе на создание задания, принтер при создании задания ДОЛЖЕН сгенерировать имя. Принтер ДОЛЖЕН сгенерировать значение атрибута Job-name задания из первого из следующих источников, которые создают значение: (1) атрибут операции «document-name» первого (или единственного) документа, (2) атрибут «document-URI» первого (или единственного) документа или (3) любой другой фрагмент специфичных для задания и / или данных документа.

5.3.6. job-originating-user-name (name(MAX)) — имя пользователя происходящего задания

Этот атрибут REQUIRED содержит имя конечного пользователя, отправившего задание на печать. Принтер устанавливает для этого атрибута наиболее аутентифицированное имя для печати, которое он может получить от службы аутентификации, для которой была получена операция IPP. Только если такое имя недоступно, принтер использует значение, предоставленное клиентом в операционном атрибуте «requesting-user-name» запроса на создание задания (см. Разделы 5.4.2, 5.4.3 и 9).

Примечание. Принтеру необходимо сохранить внутренний идентификатор пользователя какой-либо формы, обычно в качестве учетных данных принципала, вместе с заданием. Поскольку такой внутренний атрибут зависит от реализации и не представляет интереса для клиентов, он не указывается в качестве атрибута задания. Этот исходный идентификатор пользователя используется для проверки полномочий (если таковые имеются) для всех последующих операций.

5.3.7. job-state (type1 enum) — состояние задания

Этот атрибут REQUIRED определяет текущее состояние работы. Несмотря на то, что IPP определяет семь значений для состояний заданий (плюс «неизвестное» значение вне диапазона — см. Раздел 5.1), реализации должны поддерживать только те состояния, которые подходят для конкретной реализации. Другими словами, принтер поддерживает только те состояния заданий, которые реализованы устройством вывода и доступны для реализации принтера.

Стандартные значения перечисления приведены в таблице 15.

Окончательное значение этого атрибута ДОЛЖНО быть одним из следующих — «завершено», «отменено» или «прервано» — прежде чем принтер полностью удалит задание. Время, в течение которого Задание остается в состоянии «отменено», «прервано» и «завершено», зависит от реализации. См. Раздел 5.3.7.2.

На рисунке 3 показаны обычные переходы состояний задания. Как правило, задание прогрессирует слева направо. Другие изменения состояния маловероятны, но не запрещены. Не показаны переходы в состояние «отменено» из состояний «в ожидании», «в ожидании» и «остановлена обработка».

Рисунок 3 - Жизненный цикл задания протокола IPP — Рисунок 3 — Жизненный цикл задания протокола IPP

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

Таблица 15 - Перечисление значений job-state — Таблица 15 — Перечисление значений job-state

Значение «3». Символьное имя ’pending’ (в ожидании): задание является кандидатом для начала обработки, но еще не обрабатывает.

Значение «4». Символьное имя ’pending-held’ (ожидающий): задание не является кандидатом на обработку по ряду причин, но вернется в состояние «ожидающий», как только причины исчезнут. Атрибут «Задание-состояние-задания» в задании ДОЛЖЕН указывать, почему задание больше не является кандидатом на обработку.

Значение «5». Символьное имя ’processing’ (обработка): одно или несколько из следующего: (1) Задание использует или пытается использовать один или несколько чисто программных процессов, которые анализируют, создают или интерпретируют PDL и т. Д .; (2) Задание использует или пытается использовать одно или несколько аппаратных устройств, которые интерпретируют PDL; делать отметки на носителе; и / или выполнение отделки, такой как сшивание и т.д .; (3) Принтер подготовил задание к печати, но устройство вывода еще не печатает его, либо потому, что задание не достигло устройства вывода, либо потому, что задание находится в очереди в устройстве вывода или каком-либо другом диспетчере очереди печати, ожидая для устройства вывода, чтобы распечатать его. Когда задание находится в состоянии «обработки», все состояние задания включает подробный статус, представленный в атрибутах «Состояние принтера», «Причины состояния принтера» и «Сообщение о состоянии принтера». Реализации МОГУТ включать дополнительные значения в атрибут «Задание-состояние-задания» задания, чтобы указать ход выполнения задания, например, добавив значение «печать задания», чтобы указать, когда устройство вывода фактически делает отметки на бумаге и / или значение ‘обработки до остановки’, указывающее, что принтер находится в процессе отмены или отмены задания.

Значение «6». Символьное имя ’processing-stopped’ (обработка остановлена): задание было остановлено во время обработки по любому числу причин и вернется в состояние «Обработка», как только причины исчезнут. Атрибут «Задания-состояния-задания» МОЖЕТ указывать, почему работа была остановлена. Например, если устройство вывода остановлено, значение «принтер остановлен» МОЖЕТ быть включено в атрибут задания «состояние задания». Примечание. Когда устройство вывода остановлено, устройство обычно указывает его состояние в удобочитаемой форме локально на устройстве. Клиент может получить более полное состояние устройства удаленно, запросив атрибуты «Состояние принтера», «Причины состояния принтера» и «Сообщение о состоянии принтера» принтера.

Значение «7». Символьное имя ’canceled’ (отменен): задание было отменено операцией отмены задания, и принтер завершил отмену задания. Все атрибуты статуса работы достигли своих окончательных значений для работы. Пока принтер отменяет задание, задание остается в его текущем состоянии, но атрибут «причины-состояния-задания» задания ДОЛЖЕН содержать значение «обработка до остановки» и одно из «отмененных пользователем». ‘,’ отменено оператором ‘или’ отменено на устройстве ‘значения. Когда задание переходит в состояние «отменено», значение «обработка до точки остановки», если оно присутствует, ДОЛЖНО быть удалено, но «отменено до ххх», если оно присутствует, ДОЛЖНО оставаться.

Значение «8». Символьное имя ’aborted’ (прервано): задание было прервано системой, обычно, когда задание находилось в состоянии «обработка» или «остановка обработки», и принтер завершил прерывание задания; все атрибуты статуса работы достигли своих окончательных значений для работы. Пока принтер прерывает работу, задание остается в его текущем состоянии, но атрибут «причины-состояния-задания» работы ДОЛЖЕН содержать значения «обработка до остановки» и «прерывание по системе». Когда задание переходит в состояние «прервано», значение «обработка до остановки», если оно присутствует, ДОЛЖНО быть удалено, но значение «прервано по системе», если оно присутствует, ДОЛЖНО оставаться.

Значение «9». Символьное имя ’completed’ (завершено): задание завершено успешно или с предупреждениями или ошибками после обработки, все листы носителя задания успешно сложены в соответствующие выходные лотки, и все атрибуты состояния задания достигли своих окончательных значений для задания. Атрибут «Задание-состояние-задания» задания ДОЛЖЕН содержать одно из значений «завершено успешно», «завершено с предупреждениями» или «завершено с ошибками».

5.3.7.1. Серверы пересылки

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

5.3.7.2. Разделение состояний задания

В этом разделе описывается разбиение семи состояний заданий на этапы: задание не выполнено, сохранение задания, история задания и удаление задания. В этом разделе также объясняется значение «job-restartable» атрибута «Статус-состояния-задания» атрибута «Статус работы» для использования с операциями Restart-Job и Resubmit-Job [PWG5100.11].

Задание не завершено: если задание находится в состоянии «ожидание», «ожидание удерживается», «обработка» или «остановка обработки», задание не завершается.

Сохранение задания. Когда задание входит в одно из трех состояний задания терминала — «завершено», «отменено» или «прервано», принтер IPP МОЖЕТ «сохранить» задание в состоянии перезапуска в течение определенного периода реализации. Этот период времени МОЖЕТ составлять ноль секунд и МОЖЕТ зависеть от состояния задания терминала. Этот этап называется «Удержание работы». На этапе сохранения задания данные документа задания сохраняются, и клиент может перезапустить задание, используя операцию перезапуска задания. Если принтер поддерживает операцию Restart-Job или Resubmit-Job, то он ДОЛЖЕН указать, что задание можно перезапустить, добавив значение «job-restartable» в атрибут задания «job-state-reason» (см. Раздел 5.3.8) на этапе сохранения работы.

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

Удаление задания: после того, как задание остается в истории заданий в течение времени, определенного реализацией, например, когда число заданий превышает фиксированное число или после фиксированного периода времени (который МОЖЕТ быть равным нулю секунд), принтер IPP удаляет задание из системы.

Используя операцию Get-Jobs и указав значение «не завершено» для атрибута операции «what-jobs», Клиент запрашивает задания на этапе «Не выполнено». Используя операцию Get-Jobs и предоставляя значение «complete» для атрибута операции «which-jobs», Клиент запрашивает задания на этапах «Задание на удержание» и «Журнал заданий». Используя операцию Get-Job-Attributes, Клиент запрашивает задание на любом этапе, кроме удаления задания. После удаления задания операции Get-Job-Attributes и Get-Jobs больше не могут возвращать какую-либо информацию о задании.

5.3.8. job-state-reasons (1setOf type2 keyword) — причины состояния задания

Этот атрибут REQUIRED предоставляет дополнительную информацию о текущем состоянии задания, то есть информацию, которая увеличивает значение атрибута Job-state задания.

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

Примечание. Хотя значения нельзя добавить в атрибут «состояние-задания» без влияния на развернутых клиентов, которые предпринимают действия после получения значений «состояние-задания», предполагается, что дополнительные значения «причины-состояния-задания» могут быть определены и зарегистрированы без влияния на таких развернутых клиентов. Другими словами, атрибут «задание состояния задания» предназначен для расширения.

Определены следующие стандартные значения ключевых слов. Для простоты понимания значения представлены в том порядке, в котором вероятны причины (если они будут реализованы):

’none’ (ничего): нет причин для текущего состояния работы. Эта причина состояния семантически эквивалентна «причинам состояния задания» без какого-либо значения и ДОЛЖНА использоваться при отсутствии другого значения, поскольку синтаксис атрибута «1setOf» требует как минимум одно значение.
’job-incoming’ (задание на поступление): либо (1) принтер принял операцию «Создать задание» и ожидает дополнительных операций отправки-документа и / или отправки-URI, либо (2) принтер извлекает / принимает данные документа в результате операции Print-Job, Print-URI, Send-Document или Send-URI.
’job-data-insufficient’: операция создания задания была принята принтером, но принтер ожидает дополнительных данных документа, прежде чем он сможет перевести задание в состояние «обработка». Если принтер начинает обработку до того, как получит все данные, он устраняет причину «задания-данных-недостаточно», но причина «поступления-задания» остается. Если принтер начинает обрабатывать после получения всех данных, он одновременно устраняет причину «задания-данных-недостаточно» и причину-поступления работы.
’document-access-error’ (ошибка доступа к документу): после принятия запроса Print-URI или Send-URI Принтер не смог получить доступ к одному или нескольким Документам, переданным по ссылке. Эта причина предназначена для решения любой проблемы с доступом к файлу, в том числе «файл не существует» и «доступ запрещен» из-за проблемы контроля доступа. Принтер МОЖЕТ также указывать на ошибку доступа к документу с помощью атрибута «Статус работы» «job-document-access-errors» (см. Раздел 5.3.11). Принтер может (1) отменить задание и переместить задание в «отмененное» состояние задания или (2) распечатать все доступные документы и переместить задание в состояние «завершено» с сообщением «выполнено с ошибками». значение в атрибуте Job-state-reason. Это значение ДОЛЖНО поддерживаться, если поддерживаются операции Print-URI или Send-URI.
’submission-interrupted’ (прерывание отправки): задание не было полностью отправлено по какой-то непредвиденной причине, например (1) произошел сбой принтера до закрытия задания клиентом, (2) в некоторых случаях произошел сбой принтера или способа передачи документа невосстановимым способом до полной передачи данных Документа на Принтер или (3) Клиент потерпел крах или не смог закрыть Задание до истечения времени ожидания. Смотрите Раздел 5.4.31.
’job-outgoing’: принтер передает работу на устройство вывода.
’job-hold-until-specified’: значение атрибута Задание-задание задание задано с периодом времени, который все еще находится в будущем. Задание НЕ ДОЛЖНО быть кандидатом на обработку до тех пор, пока не будет устранена эта причина и нет других причин удерживать Задание. Это значение ДОЛЖНО поддерживаться, если поддерживается атрибут «Job-hold-till» шаблона работы.
’resources-are-not-ready’ (ресурсы не готовы): по крайней мере один из ресурсов, необходимых для работы, таких как носители, шрифты, объекты ресурсов и т. д., не готов ни на одном из физических устройств вывода, для которых задание является кандидат. Это условие МОЖЕТ быть обнаружено, когда задание принято, или впоследствии, когда задание ожидает или обрабатывает, в зависимости от реализации. Задание может оставаться в своем текущем состоянии или быть переведено в состояние ожидания, в зависимости от реализации и / или политики планирования заданий.
’printer-stopped-partly’: значение атрибута «Printer-State-reason» принтера содержит значение «остановлено-частично».
’printer-stopped’: значение атрибута «Printer-State» принтера «остановлено».
’job-interpreting’ (перевод задания): задание находится в состоянии «обработки», но, более конкретно, принтер интерпретирует данные документа.
’job-queued’ (задание в очереди): задание находится в состоянии «обработки», но, более конкретно, принтер поставил в очередь данные документа.
’job-transforming’ (преобразование задания): задание находится в состоянии «обработки», но, более конкретно, принтер интерпретирует данные документа и создает другое электронное представление.
’job-queued-for-marker’ (задание поставлено в очередь для маркера): задание находится в любом из состояний «ожидание отложено», «ожидание» или «обработка», но, более конкретно, принтер завершил достаточно обработки документа, чтобы в состоянии начать маркировку, и задание ждет маркера. Системы, требующие вмешательства человека для освобождения заданий с помощью операции Release-Job, переводят задание в состояние отложенного выполнения. Системы, которые автоматически выбирают задание для использования маркера, переводят задание в состояние «ожидающих» или сохраняют задание в состоянии «обработки» во время ожидания маркера, в зависимости от реализации. Все реализации переводят задание в состояние «обработки», когда маркировка начинается.
’job-printing’: устройство вывода маркирует носитель. Это значение полезно для принтеров, которые тратят много времени на обработку (1), когда маркировка не выполняется, и хотят показать, что маркировка выполняется, или (2) когда работа находится в процессе отмены или отмены, пока Задание остается в состоянии «обработка», но разметка еще не остановлена, поэтому количество показов или количество листов для задания все еще увеличивается.
’job-canceled-by-user’ (задание отменено пользователем): задание было отменено владельцем задания с помощью запроса «Отмена задания», т. е. пользователем, чья аутентифицированная личность совпадает со значением исходного пользователя, создавшего задание. или каким-либо другим уполномоченным конечным пользователем, например членом группы безопасности владельца задания. Это значение ДОЛЖНО поддерживаться.
’job-canceled-by-operator’ (задание отменено оператором): задание было отменено оператором с помощью запроса на отмену задания, т. е. пользователем, который был аутентифицирован как имеющий права оператора (локальный или удаленный). Если политика безопасности разрешает кому-либо отменять чью-либо работу, то это значение можно использовать, когда работа отменяется кем-либо, кроме владельца работы. По сути, для такой политики безопасности каждый является Оператором в том, что касается отмены Заданий с IPP. Это значение ДОЛЖНО поддерживаться, если реализация разрешает отмену кем-либо, кроме владельца задания.
’job-canceled-at-device’ (задание отменено на устройстве): задание было отменено неизвестным локальным пользователем, т. е. пользователем на консоли устройства. Это значение ДОЛЖНО поддерживаться, если реализация поддерживает отмену заданий на консоли.
’aborted-by-system’: задание (1) находится в процессе отмены, (2) было прервано системой и переведено в состояние «aborted», или (3) было прервано системой и переведен в состояние ожидания, так что пользователь или оператор могут снова вручную выполнить задание. Это значение ДОЛЖНО поддерживаться.
’unsupported-compression’ (неподдерживаемое сжатие): задание было прервано системой, поскольку принтер при попытке распаковать данные документа определил, что алгоритм сжатия фактически не входит в число поддерживаемых принтером. Это значение ДОЛЖНО поддерживаться, поскольку «сжатие» является ОБЯЗАТЕЛЬНЫМ атрибутом операции.
’compression-error’: задание было прервано системой, потому что принтер обнаружил ошибку в данных документа при распаковке. Если принтер отправляет эту причину, данные документа уже прошли любые тесты, которые привели бы к значению «unsupported-сжатие» «причины-состояния-задания».
’unsupported-document-format’ (неподдерживаемый формат документа): задание было прервано системой, поскольку атрибут «формат документа» данных документа не входит в число поддерживаемых принтером. Если Клиент указывает «формат документа» как «application / octet-stream», Принтер МОЖЕТ прервать Задание и опубликовать эту причину, даже если значение «формат документа» является одним из значений в «Принтере», поддерживаемом форматом документа. Msgstr «Атрибут принтера, но не среди автоматически определяемых форматов документов. Это значение ДОЛЖНО поддерживаться, так как «формат документа» является НЕОБХОДИМЫМ атрибутом операции.
’document-format-error’: задание было прервано системой, поскольку принтер обнаружил ошибку в данных документа при обработке. Если принтер отправляет эту причину, данные документа уже прошли любые тесты, которые привели бы к значению «unsupported-document-format» «job-state-reason».
’processing-to-stop-point’ (обработка до остановки): запрашивающая сторона выполнила операцию отмены задания или принтер прервал задание, но принтер все еще выполняет некоторые действия над заданием до тех пор, пока не будет достигнута указанная точка остановки или не завершится / не завершится задание. выполнен.
Если для реализации требуется некоторое измеримое время для отмены задания в состоянии «обработка» или «остановленная обработка», принтер ДОЛЖЕН использовать это значение, чтобы указать, что принтер все еще выполняет некоторые действия над заданием, пока задание остается в состояние «обработка» или «остановка обработки». Оказавшись в точке остановки, принтер переводит задание из состояния «обработка» в состояние «отменено» или «прервано».
’service-off-line’ (автономный сервис): принтер не подключен и не принимает задания. Все «ожидающие» вакансии переводятся в «ожидающие». Эта ситуация может быть верной, если ввод службы или преобразования документа нарушен или поврежден.
’job-completed-successfully’ (задание выполнено успешно): задание выполнено успешно. Это значение ДОЛЖНО поддерживаться.
’job-completed-with-warnings’ (задание выполнено с предупреждениями): задание выполнено с предупреждениями. Это значение ДОЛЖНО поддерживаться, если реализация обнаруживает предупреждения.
’job-completed-with-errors’ (задание выполнено с ошибками): задание выполнено с ошибками (и, возможно, с предупреждениями). Это значение ДОЛЖНО поддерживаться, если реализация обнаруживает ошибки.
’job-restartable’: это задание сохраняется (см. раздел 5.3.7.2) и в настоящее время может быть перезапущено с помощью операции Restart-Job (см. раздел 4.3.7) или Resubmit-Job [PWG5100.11]. Если «задание перезапуска» является значением атрибута «Задание состояния задания» задания, то принтер ДОЛЖЕН принять операцию перезапуска задания для этого задания. Это значение ДОЛЖНО поддерживаться, если поддерживается операция Restart-Job.
’queued-in-device’ (в очереди в устройстве): задание было перенаправлено на устройство или систему печати, которые не могут вернуть статус. Принтер устанавливает для атрибута «состояние-задания» задания значение «завершено» и добавляет значение «в очереди в устройстве» к атрибуту «Задания-состояния-задания» задания, чтобы указать, что у принтера нет дополнительной информации о задании и никогда не будет никакой лучшей информации. См. Раздел 5.3.7.1.

5.3.9. job-state-message (text(MAX)) — сообщение о состоянии задания

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

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

5.3.10. job-detailed-status-messages (1setOf text(MAX)) — сообщения о статусе задания

Этот атрибут определяет дополнительную подробную и техническую информацию о Работе. Принтер ДОЛЖЕН локализовать сообщение, если только такая локализация не затеняет технический смысл сообщения. Клиенты НЕ ДОЛЖНЫ пытаться проанализировать значение этого атрибута. См. «Job-document-access-errors» (Раздел 5.3.11) для дополнительных ошибок, которые может обработать программа.

5.3.11. job-document-access-errors (1setOf text(MAX)) — ошибки доступа к документу задания

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

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

5.3.12. number-of-documents (integer(0:MAX)) — количество документов

Этот атрибут указывает количество документов в задании, т. Е. Количество операций Send-Document, Send-URI, Print-Job или Print-URI, которые принтер принял для этого задания, независимо от того, были ли достигнуты данные документа. принтер.

Реализации, поддерживающие РЕКОМЕНДУЕМЫЕ операции Create-Job / Send-Document / Send-URI, ДОЛЖНЫ поддерживать этот атрибут, чтобы клиенты могли запрашивать количество документов в каждом задании.

5.3.13. output-device-assigned (name(127)) — назначенное устройство вывода

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

5.3.14. Атрибуты статуса задания времени события

В этом разделе определяются атрибуты статуса работы, которые указывают время, когда происходят определенные события для работы. Если событие Job еще не произошло, то принтер ДОЛЖЕН вернуть внеполосное значение «no-value» (см. Начало раздела 5.1). Атрибуты «time-at-xxx (integer)» представляют время как «целое число», представляющее количество секунд, прошедших с момента включения устройства (неофициально называемые «временными метками»). Атрибуты «date-time-at-xxx (dateTime)» представляют время как «dateTime», представляющее дату и время (включая смещение от UTC).

Чтобы заполнить эти атрибуты, принтер копирует значение (значения) следующих атрибутов состояния принтера в момент возникновения события:

значение в атрибуте Printer-up-time принтера для атрибутов time-at-xxx (integer).
значение в атрибуте «Printer-current-time» принтера для атрибутов «date-time-at-xxx (dateTime)».

Если принтер сбрасывает свой атрибут «времени работы принтера» на 1 при включении питания (см. Раздел 5.4.29) и имеет постоянные задания, то он ДОЛЖЕН изменить все эти задания «time-at-xxx (integer)» (отметка времени) Атрибуты задания, события которых произошли либо:

«0», чтобы указать, что событие произошло до последнего включения питания, или
Отрицательное число секунд до последнего включения питания, когда произошло событие, если Принтер знает точное количество секунд.

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

Примечание. Принтер не изменяет значения атрибутов задания «date-time-at-xxx (dateTime)» при включении питания.

5.3.14.1. time-at-creation (integer(MIN:MAX)) — время создания

Этот ОБЯЗАТЕЛЬНЫЙ атрибут указывает время, когда было создано задание.

5.3.14.2. time-at-processing (integer(MIN:MAX)) — время обработки

Этот ОБЯЗАТЕЛЬНЫЙ атрибут указывает время, когда задание впервые начало обрабатываться после запроса на создание задания или самой последней операции перезапуска задания. Внешнее значение ‘no-value’ возвращается, если Задание еще не было в состоянии ‘processing’ (см. Начало Раздела 5.1).

5.3.14.3. time-at-completed (integer(MIN:MAX)) — время завершения

Этот ОБЯЗАТЕЛЬНЫЙ атрибут указывает время, когда задание вошло в состояние завершения («завершено», «отменено» или «прервано»). Внешнее значение ‘no-value’ возвращается, если Задание еще не завершено, отменено или прервано (см. Начало Раздела 5.1).

5.3.14.4. job-printer-up-time (integer(1:MAX)) — время работы задания принтера

Этот ОБЯЗАТЕЛЬНЫЙ атрибут Job Status указывает количество времени (в секундах), в течение которого реализация принтера была запущена и запущена. Этот атрибут является псевдонимом для атрибута «Состояние принтера» (см. Раздел 5.4.29).

Клиент МОЖЕТ запросить этот атрибут в запросе Get-Job-Attributes или Get-Jobs и использовать возвращаемое значение в сочетании с другими запрошенными атрибутами Event Time Статус работы, чтобы отобразить атрибуты времени для пользователя. Разница между этим атрибутом и целочисленным значением атрибута «time-at-xxx» заключается в количестве секунд назад, когда произошло событие «time-at-xxx». Клиент может вычислить время настенных часов, в которое произошло событие «time-at-xxx», вычитая эту разницу из времени настенных часов Клиента.

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-октеты

Этот атрибут определяет общий размер документа (ов) в K-октетах, то есть в единицах по 1024 октета, запрошенных для обработки в задании. Значение ДОЛЖНО быть округлено, так что задание от 1 до 1024 октетов ДОЛЖНО быть указано как 1, от 1025 до 2048 ДОЛЖНО быть 2 и т. Д.

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

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

5.3.17.2. job-impressions (integer(0:MAX)) — задание отпечатка

Этот РЕКОМЕНДУЕМЫЙ атрибут указывает общий размер числа показов отправляемых документов (см. Определение «Показы» в разделе 2.3.4).

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

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

5.3.17.3. job-media-sheets (integer(1:MAX)) — задание медиа листы

Этот РЕКОМЕНДУЕМЫЙ атрибут указывает общее количество листов бумаги, которые будут созданы для этого задания.

В отличие от атрибутов «job-k-octets» и «job-впечатлений», это значение ДОЛЖНО включать мультипликативные факторы, определяемые количеством копий, указанных в атрибуте «копий», и инструкцией «количество копий», встроенной в документ. данные, если таковые имеются. Это различие позволяет администратору контролировать нижнюю и верхнюю границы как (1) размера документа (ов) с помощью «заданий, поддерживаемых заданиями», так и «заданий, поддерживаемых заданиями», и (2) размера Работа с «Job-Media-Sheets-Поддерживается».

5.3.18. Атрибуты прогресса задания

В этом подразделе определяются атрибуты задания, которые описывают ход выполнения задания. Эти атрибуты предназначены для счетчиков. То есть значения для Задания, которое не начало обработку, ДОЛЖНЫ быть 0. Когда «задание» для Задания находится в состоянии «Обработка» или «Обработка остановлена», это значение должно содержать количество Задания, которое было обрабатывается до времени, когда запрашиваются атрибуты. Когда Задание входит в состояние «завершено», «отменено» или «прервано», эти значения являются окончательными значениями Задания.

5.3.18.1. job-k-octets-processed (integer(0:MAX)) — обработка задания с к-октетами

Этот атрибут указывает общее количество октетов, обработанных в K октетах, то есть в единицах по 1024 октета. Значение ДОЛЖНО быть округлено, так что задание от 1 до 1024 октетов включительно ДОЛЖНО быть указано как 1, от 1025 до 2048 включительно ДОЛЖНО быть 2 и т. Д.

Для реализаций, где интерпретатор создает несколько копий с одним проходом данных, окончательное значение ДОЛЖНО быть равно значению атрибута «job-k-octets». Для реализаций, в которых интерпретатор создает несколько копий путем обработки данных для каждой копии, окончательное значение ДОЛЖНО быть кратным значению атрибута «job-k-octets».

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) — кодировка атрибутов

Этот атрибут REQUIRED заполняется с использованием значения в предоставленном клиентом атрибуте «attribute-charset» в запросе на создание задания. Он идентифицирует набор символов (набор кодированных символов и метод кодирования), используемый любыми атрибутами задания с синтаксисом атрибута «текст» и «имя», которые были предоставлены клиентом в запросе на создание задания. См. Раздел 4.1.4 для полного описания атрибута операции «attribute-charset».

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

5.3.20. attributes-natural-language (naturalLanguage) — атрибуты естественного языка

Этот атрибут REQUIRED заполняется с использованием значения в предоставленном клиентом атрибуте «attribute-natural-language» в запросе на создание задания. Он идентифицирует естественный язык, используемый для любых атрибутов задания с синтаксисом атрибута «текст» и «имя», которые были предоставлены клиентом в запросе на создание задания. См. Раздел 4.1.4 для полного описания атрибута операции «attribute-natural-language». См. Разделы 5.1.2.2 и 5.1.3.2 о том, как переопределение естественного языка может быть предоставлено явно для каждого значения атрибута «текст» и «имя», которое отличается от значения, указанного атрибутом «атрибуты-естественного языка».

5.4. Описание принтера и атрибуты состояния

Эти атрибуты образуют группу атрибутов, которая называется «принтер-описание». Таблицы 16 и 17 суммируют эти атрибуты, их синтаксис и необходимость их поддержки принтером. Если они не указаны как НЕОБХОДИМЫЕ, они НЕОБЯЗАТЕЛЬНЫ. Максимальный размер в октетах для атрибутов «текст» и «имя» указан в скобках.

Примечание. То, как эти атрибуты устанавливаются администратором, выходит за рамки этого документа.

Таблица 16 - Атрибуты описания принтера (READ-WRITE) — Таблица 16 — Атрибуты описания принтера (READ-WRITE)

Таблица 17 - Атрибуты состояния принтера (только для чтения) — Таблица 17 — Атрибуты состояния принтера (только для чтения)

5.4.1. printer-uri-supported (1setOf uri) — поддержка URI принтера

Этот НЕОБХОДИМЫЙ атрибут принтера содержит один или несколько URI для принтера. МОЖЕТ содержать более одного URI для принтера. Администратор определяет URI принтера и настраивает этот атрибут так, чтобы он содержал эти URI некоторыми способами, выходящими за рамки этого документа IPP / 1.1. Точный формат URI зависит от реализации и зависит от протокола. См. Разделы 5.4.2 и 5.4.3 для описания атрибутов «uri-authentication-Поддерживается» и «URI-Безопасность-поддерживается», оба из которых являются обязательными сопутствующими атрибутами для этого атрибута «Printer-Uri-Supported». См. Разделы 3.4 («Идентификация объекта») и 9.2 («URI в атрибутах операции, задания и принтера») для получения дополнительной информации.

5.4.2. uri-authentication-supported (1setOf type2 keyword) — поддерживается URI-аутентификация

Этот ОБЯЗАТЕЛЬНЫЙ атрибут принтера ДОЛЖЕН иметь ту же мощность (содержать то же количество значений), что и атрибут «printer-uri-support». Этот атрибут определяет механизм аутентификации клиента, связанный с каждым URI, указанным в атрибуте «printer-uri-support». Принтер использует указанный механизм для идентификации аутентифицированного пользователя (см. Раздел 9.3). Значение «i-й» в «uri-authentication-поддержано» соответствует значению «i-й» в «printer-uri-Поддерживается», и оно описывает механизмы аутентификации, используемые принтером при доступе через этот URI. См. [RFC8010] для более подробной информации об аутентификации клиента.

Определены следующие стандартные значения ключевых слов:

’none’: механизм аутентификации, связанный с URI, отсутствует. Принтер предполагает, что аутентифицированный пользователь является «анонимным».
’requesting-user-name’: когда Клиент выполняет операцию, целью которой является связанный URI, Принтер предполагает, что аутентифицированный пользователь указан атрибутом операции «requesting-user-name» (см. Раздел 9.3). Если в запросе отсутствует атрибут «запрашивающее имя пользователя», Принтер предполагает, что аутентифицированный пользователь является «анонимным».
’basic’: когда клиент выполняет операцию, целью которой является связанный URI, принтер вызывает у клиента базовую аутентификацию HTTP [RFC7617]. Принтер предполагает, что аутентифицированным пользователем является имя, полученное с помощью базового механизма аутентификации.
’digest’: когда Клиент выполняет операцию, целью которой является связанный URI, Принтер запрашивает у клиента аутентификацию по дайджесту HTTP [RFC7616]. Принтер предполагает, что аутентифицированным пользователем является имя, полученное с помощью механизма дайджест-аутентификации.
’certificate’: когда Клиент выполняет операцию, целью которой является связанный URI, Принтер ожидает, что Клиент предоставит сертификат X.509. Принтер предполагает, что аутентифицированный пользователь является одним из текстовых имен (общее имя или альтернативные имена субъекта), содержащихся в сертификате.

5.4.3. uri-security-supported (1setOf type2 keyword) — поддержка uri-безопасности

Этот ОБЯЗАТЕЛЬНЫЙ атрибут принтера ДОЛЖЕН иметь ту же мощность (содержать то же количество значений), что и атрибут «printer-uri-support». Этот атрибут определяет механизмы безопасности, используемые для каждого URI, указанного в атрибуте «printer-uri-support». Значение «i-й» в «uri-security-Поддерживается» соответствует значению «i-й» в «Принтер-URI-поддерживается», и оно описывает механизмы безопасности, используемые для доступа к принтеру через этот URI. См. [RFC8010] для более подробной информации о механизмах безопасности.

Определены следующие стандартные значения ключевых слов:

’none’: для данного URI не используются протоколы безопасного канала связи.
’tls’: TLS [RFC5246] [RFC7525] — это протокол безопасного канала связи, используемый для данного URI.

Этот атрибут ортогонален определению механизма аутентификации клиента. В частности, «никто» не исключает аутентификацию клиента. Смотрите раздел 5.4.2.

Рассмотрим следующий пример. Для одного принтера администратор настраивает атрибуты «printer-uri-Поддерживаемые», «URI-аутентификация-поддерживаемые» и «URI-Безопасность-поддерживаемые» следующим образом:

«printer-uri-supported»: ’ipp://printer.example.com/ipp/print/open-use-printer’, ’ipp://printer.example.com/ipp/print/restricted-use-printer’, ’ipps://printer.example.com/ipp/print/private-printer’
«uri-authentication-supported»: ’none’, ’digest’, ’basic’
«uri-security-supported»: ’none’, ’none’, ’tls’

В этом случае один принтер имеет три URI.

Для первого URI, «ipp: //printer.example.com/ipp/print/open-use-printer», значение «none» в «uri-security-support» указывает, что не настроен протокол защищенного канала работать по HTTP. Значение «none» в «uri-аутентификации-поддерживается» указывает, что все пользователи являются «анонимными». Там не будет никаких проблем, и принтер будет игнорировать «запрос имени пользователя».

Для второго URI, «ipp: //printer.example.com/ipp/print/restricted-use-printer», значение «none» в «uri-security-support» указывает, что не настроен протокол защищенного канала работать по HTTP. Значение «дайджест» в «uri-authenticating-Поддерживается» указывает, что Принтер вызовет вызов и что Принтер будет использовать имя, предоставленное механизмом дайджеста, для определения аутентифицированного пользователя (см. Раздел 9.3).

Для третьего URI ’ipps: //printer.example.com/ipp/print/private-printer’ значение tls в «uri-security-support» указывает, что TLS используется для защиты канала. Клиент ДОЛЖЕН быть готов использовать кадрирование TLS для согласования приемлемого набора шифров, который будет использоваться при обмене данными с принтером. В этом случае имя подразумевает использование безопасного канала связи, но этот факт становится явным из-за присутствия значения «tls» в «uri-security-Поддерживается». Клиенту не нужно прибегать к пониманию того, какие механизмы безопасности он должен использовать, следуя соглашениям об именах или анализируя URI, чтобы определить, какие механизмы безопасности подразумеваются. Значение «basic» в «uri-аутентификации-поддерживается» указывает, что принтер вызовет вызов и что принтер будет использовать имя, предоставленное базовым механизмом, для определения аутентифицированного пользователя (см. Раздел 9.3). Поскольку эта проблема возникает в сеансе TLS, канал является безопасным.

Некоторые принтеры будут настроены на поддержку только одного канала (настроен ли на использование доступа TLS или нет) и только одного механизма аутентификации. Такие принтеры имеют только один URI, указанный в атрибуте «printer-uri-support». Независимо от конфигурации Принтера (независимо от того, имеет ли он только один URI или несколько URI), Клиент ДОЛЖЕН предоставить только один URI в целевом атрибуте операции «printer-uri».

5.4.4. printer-name (name(127)) — имя принтера

Этот НЕОБХОДИМЫЙ атрибут принтера содержит имя принтера. Это имя является более удобным для конечного пользователя, чем URI. Администратор определяет имя принтера и устанавливает для этого атрибута это имя. Это имя может быть последней частью URI принтера или может не иметь отношения. В локалях не на американском и английском языках имя может содержать символы, которые не допускаются в URI.

5.4.5. printer-location (text(127)) — местоположение принтера

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера определяет местоположение устройства. Это может включать такие вещи, как «в комнате 123A, на втором этаже здания XYZ».

5.4.6. printer-info (text(127)) — информация о принтере

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера предоставляет описательную информацию об этом принтере. Сюда могут входить такие вещи, как «Этот принтер может использоваться для печати на прозрачных пленках для презентаций HR» или «Из вежливости по отношению к другим, печатайте только небольшие (1-5 стр.) Задания на этом принтере», или даже «Этот принтер уходя 1 июля; пожалуйста, найдите новый принтер ».

5.4.7. printer-more-info (uri) — больше информации о принтере

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера содержит URI, используемый для получения дополнительной информации об этом конкретном принтере. Например, это может быть HTTP-URI, ссылающийся на HTML-страницу, доступную для веб-браузера. Информация, полученная из этого URI, предназначена для конечного пользователя. Функции, выходящие за рамки IPP, могут быть доступны из этого URI. Предполагается, что информация должна быть специфичной для данного экземпляра принтера и услуг, специфичных для конкретного сайта, например, цены на работу, предлагаемые услуги и помощь конечного пользователя. Производитель устройства может изначально заполнить этот атрибут.

5.4.8. printer-driver-installer (uri) — установщик драйвера принтера

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

5.4.9. printer-make-and-model (text(127)) — изготовитель и модель принтера

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера определяет марку и модель устройства. Производитель устройства может изначально заполнить этот атрибут.

5.4.10. printer-more-info-manufacturer (uri) — больше информации о производителе принтера

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

5.4.11. printer-state (type1 enum) — состояние принтера

Этот НЕОБХОДИМЫЙ атрибут принтера определяет текущее состояние устройства. Атрибут «причины состояния принтера» дополняет атрибут «состояние принтера», чтобы предоставить более подробную информацию о принтере в указанном состоянии принтера.

Принтер постоянно обновляет этот атрибут, если поддерживается асинхронное уведомление о событии [RFC3995].

Стандартные значения перечисления определены в таблице 18. Значения «причин-состояний принтера», таких как «спул-область-заполнен» и «остановлен-частично», МОГУТ использоваться для предоставления дополнительной информации.

Таблица 18 - Перечисление значений состояние принтера — Таблица 18 — Перечисление значений состояние принтера

5.4.12. printer-state-reasons (1setOf type2 keyword) — причины состояния принтера

Этот НЕОБХОДИМЫЙ атрибут принтера предоставляет дополнительную информацию о состоянии устройства. Некоторые определения значений указывают на соответствие требованиям; Остальные НЕОБЯЗАТЕЛЬНЫ.

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

’-report’: этот суффикс указывает, что причиной является «отчет». Реализация может выбрать пропустить некоторые или все отчеты. В некоторых отчетах указывается более высокая степень детализации состояния принтера; другие служат предвестником предупреждения. Отчет НЕ ДОЛЖЕН содержать ничего, что могло бы повлиять на вывод на печать. Отчеты соответствуют «другому» значению свойства prtAlertSeverityLevel в MIB принтера [RFC3805].
’-warning’: этот суффикс указывает, что причиной является «предупреждение». Реализация может предпочесть пропустить некоторые или все предупреждения. Предупреждения служат предвестником ошибки. Предупреждение НЕ ДОЛЖНО содержать ничего, что мешало бы завершению задания, хотя в некоторых случаях выходные данные могут быть более низкого качества. Предупреждения соответствуют значению предупреждения для свойства prtAlertSeverityLevel в MIB принтера [RFC3805].
’-error’: этот суффикс указывает, что причиной является «ошибка». Реализация ДОЛЖНА включать все ошибки. Если этот атрибут содержит одну или несколько ошибок, принтер ДОЛЖЕН быть в состоянии «остановлен». Ошибки соответствуют «критическому» значению свойства prtAlertSeverityLevel в MIB принтера [RFC3805].

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

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

Определены следующие стандартные значения ключевых слов:

’none’: причин нет. Эта причина состояния семантически эквивалентна «причинам состояния принтера» без какого-либо значения и ДОЛЖНА использоваться, поскольку синтаксис атрибута «1setOf» требует как минимум одно значение.
’other’: устройство обнаружило состояние, отличное от указанного в этом документе.
’connecting-to-device’ (подключение к устройству): принтер запланировал задание на устройстве вывода и находится в процессе подключения к общему сетевому устройству вывода (и может не иметь возможности фактически начать печать задания в течение сколь угодно длительного времени, в зависимости от использования устройства вывода другими серверами в сети).
’cover-open’: одна или несколько обложек на устройстве открыты, что эквивалентно prtCoverStatus [RFC3805] из 3 (coverOpen).
’developer-empty’: на устройстве нет разработчика.
’developer-low’: на устройстве мало разработчиков.
’door-open’ (дверь открыта): одна или несколько дверей на устройстве открыты, что эквивалентно prtCoverStatus [RFC3805] из 3 (coverOpen).
’fuser-over-temp’: температура фьюзера выше нормальной, что эквивалентно prtMarkerStatus [RFC3805] из 19 (сумма «Недоступно из-за поломки» (3) и «Критических предупреждений» (16)).
’fuser-under-temp’: температура фьюзера ниже нормальной, эквивалентная prtMarkerStatus [RFC3805] из 19 (сумма «Недоступно из-за поломки» (3) и «Критических предупреждений» (16)).
’input-tray-missing’ (входной лоток отсутствует): один или несколько входных лотков отсутствуют в устройстве, что эквивалентно prtInputStatus [RFC3805] из 19 (сумма «недоступен из-за поломки» (3) и «критических предупреждений» (16))
’interlock-open’: одно или несколько устройств блокировки на принтере разблокированы, что эквивалентно prtCoverStatus [RFC3805], равному 5 (interlockOpen).
’interpreter-resource-unavailable’: ресурс-интерпретатор недоступен (т. е. шрифт, форма).
’marker-supply-empty’: на устройстве отсутствует хотя бы один источник маркеров, например, тонер, чернила или лента.
’marker-supply-low’: на устройстве не хватает хотя бы одного маркера, например тонера, чернил или ленты.
’marker-waste-almost-full’ (маркер-отходы-почти-полные): емкость для сбора маркера устройства почти заполнена.
’marker-waste-full’: емкость для сбора маркера устройства заполнена.
’media-empty’: по крайней мере один входной лоток пуст, что эквивалентно prtInputStatus [RFC3805] из 19 (сумма «Недоступно из-за поломки» (3) и «Критических оповещений» (16)).
’media-jam’ (застревание носителя): устройство имеет застревание носителя, эквивалентное значению prtInputStatus [RFC3805], равному 19 (сумма «Недоступно из-за поломки» (3) и «Критических оповещений» (16)).
’media-low’: по крайней мере в одном входном лотке недостаточно носителя, что эквивалентно prtInputStatus [RFC3805] из 8 (некритические оповещения).
’media-needed’: в лотке закончились носители, что эквивалентно значению prtInputStatus [RFC3805], равному 17 (сумма «Unavailable and OnRequest» (1) и «Critical Alerts» (16)).
’moving-to-paused’ (переходит в режим паузы): кто-то приостановил работу принтера с помощью операции «Пауза-принтер» (см. раздел 4.2.7) или другими способами, но для остановки устройства требуется значительное время. Позже, когда весь вывод остановился, «состояние принтера» становится «остановленным», а значение «приостановлено» заменяет значение «переход в паузу» в атрибуте «принтер-состояние-причины». Это значение ДОЛЖНО поддерживаться, если поддерживается операция «Пауза-принтер», и реализация в определенных обстоятельствах требует значительного времени для приостановки работы устройства.
’opc-life-over’: оптический фотопроводник больше не функционирует, что эквивалентно prtMarkerStatus [RFC3805] из 19 (сумма «Недоступно из-за поломки» (3) и «Критических оповещений» (16)).
’opc-near-eol’: срок годности оптического фотопроводника близок к концу, что эквивалентно prtMarkerStatus [RFC3805] из 8 (некритические оповещения).
’output-area-almost-full’: одна или несколько областей вывода почти заполнены, например, лоток, укладчик, сборщик, эквивалентный prtOutputStatus [RFC3805] из 8 (некритические предупреждения).
’output-area-full’: одна или несколько областей вывода заполнены, например, лоток, укладчик, сборщик, эквивалентный prtInputStatus [RFC3805] из 19 (сумма «Недоступно из-за поломки» (3) и «Критических предупреждений»). «(16)).
’output-tray-missing’: один или несколько выходных лотков отсутствуют в устройстве, что эквивалентно prtOutputStatus [RFC3805] из 19 (сумма «недоступен из-за поломки» (3) и «критических предупреждений» (16)) ,
’paused’: кто-то приостановил работу принтера с помощью операции Pause-Printer (см. раздел 4.2.7) или другими способами, и «состояние принтера» принтера «остановлено». В этом состоянии принтер НЕ ДОЛЖЕН печатать вывод, но он ДОЛЖЕН выполнять другие операции, запрошенные клиентом. Если принтер печатал задание, когда принтер был поставлен на паузу, принтер ДОЛЖЕН возобновить печать этого задания, когда принтер больше не находится в режиме паузы, и не оставит никаких доказательств в выводе такой паузы. Это значение ДОЛЖНО поддерживаться, если поддерживается операция Pause-Printer.
’shutdown’: кто-то удалил принтер из обслуживания, и устройство может быть отключено или физически удалено. В этом состоянии Принтер НЕ ДОЛЖЕН выдавать вывод на печать, и если Принтер не реализован сервером печати, который все еще активен, Принтер НЕ ДОЛЖЕН выполнять никаких других операций, запрошенных Клиентом, включая возврат этого значения. Если принтер выключал задание, когда он был выключен, принтер МОЖЕТ возобновить печать этого задания после перезапуска принтера. Если принтер возобновляет печать такого задания, он может оставить свидетельство на распечатанном выходе такого выключения, например, часть, напечатанная до выключения, может быть напечатана во второй раз после выключения.
’spool-area-full’: достигнут предел постоянного хранилища, выделенного для буферизации. Принтер временно не может принимать больше заданий. Принтер удалит это значение, когда сможет принимать больше заданий. Это значение СЛЕДУЕТ использовать не спулинговому принтеру, который принимает только одно или небольшое количество заданий за раз, или спулинговому принтеру, который заполнил пространство спулинга.
’stopped-partly’ (остановлено частично): когда принтер управляет более чем одним устройством вывода, эта причина означает, что одно или несколько устройств вывода остановлены. Если причиной является отчет, останавливается менее половины выходных устройств. Если причиной является предупреждение, останавливается меньше, чем все выходные устройства.
’stopping’ (остановка): принтер находится в процессе остановки устройства и через некоторое время будет остановлен. Когда устройство остановлено, принтер изменит его состояние на «остановлено». Причина «остановки-предупреждения» никогда не бывает ошибкой даже для принтера с одним устройством вывода. Когда устройство вывода прекращает прием заданий, принтер будет иметь эту причину, пока устройство вывода завершит печать.
’timed-out’: сервер смог подключиться к устройству вывода (или всегда подключен), но не смог получить ответ от устройства вывода.
’toner-empty’: на устройстве закончился тонер.
’toner-low’: на устройстве мало тонера.

5.4.13. printer-state-message (text(MAX)) — сообщение о состоянии принтера

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

5.4.14. ipp-versions-supported (1setOf type2 keyword) — поддержка ipp-версий

Этот атрибут REQUIRED определяет версию (версии) IPP, поддерживаемые этим принтером, включая основные и вспомогательные версии, то есть номера версий, для которых данная реализация принтера соответствует требованиям соответствия. Для проверки номера версии принтер сопоставляет (2-октетный двоичный) параметр «номер версии», предоставленный клиентом в каждом запросе (см. Разделы 4.1.1 и 4.1.8), со значениями (US-ASCII) «ключевое слово» этого атрибута.

В этом документе определены следующие стандартные значения ключевых слов:

o ‘1.0’: соответствует требованиям соответствия IPP версии 1.0, как указано в RFC 2566 [RFC2566] и RFC 2565 [RFC2565], включая любые расширения, зарегистрированные в соответствии с разделом 7, и любые расширения, определенные в этой версии или любой будущей версии IPP. Документ «Модель и семантика» (настоящий документ) или документ «Кодирование и транспорт IPP» [RFC8010] в соответствии с правилами, если таковые имеются, когда параметр «номер версии» равен «1,0».

o «1.1»: соответствует требованиям соответствия версии 1.1 IPP, как указано в этом документе и [RFC8010], включая любые расширения, зарегистрированные в соответствии с разделом 7, и любые расширения, определенные в любых будущих версиях этого документа или [RFC8010], следуя правилам, если таковой имеется, когда параметр «номер версии» равен «1.1».

Дополнительные значения определены в «IPP версии 2.0, 2.1 и 2.2» [PWG5100.12].

5.4.15. operations-supported (1setOf type2 enum) — поддерживаемые операции

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

Этот атрибут кодируется как любой другой синтаксис атрибута перечисления в соответствии с [RFC8010] как 32 бита. Однако все 32-битные значения перечисления для этого атрибута НЕ ДОЛЖНЫ превышать 0x00007fff, поскольку эти же значения также передаются в двух октетах в поле «идентификатор операции» (см. Раздел 4.1.1) в каждом запросе протокола с двумя высокими значениями. октеты порядка опущены, чтобы указать выполняемую операцию [RFC8010].

В Таблице 19 перечислены значения атрибута «поддерживаемые операции» и параметр «идентификатор операции» (см. Раздел 4.1.2), которые определены в этом документе.

Таблица 19 - Перечисляемые значения «Поддерживаемых операций» — Таблица 19 — Перечисляемые значения «Поддерживаемых операций»

5.4.16. multiple-document-jobs-supported (boolean) — поддерживается работа с несколькими документами (логическое значение)

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера указывает, поддерживает ли принтер более одного документа на задание, т.е. более одной операции отправки документа с данными документа и / или операциями отправки URI. Если принтер поддерживает операции Create-Job и Send-Document (см. Разделы 4.2.4 и 4.3.1), он ДОЛЖЕН поддерживать этот атрибут.

5.4.17. charset-configured (charset) — настроенная кодировка

Этот НЕОБХОДИМЫЙ атрибут принтера определяет кодировку, которую принтер настроил для представления атрибутов принтера «текст» и «имя», которые устанавливаются оператором, администратором или производителем, т. Е. Для «имя-принтера» (имя), «принтер» -location «(текст),» printer-info «(текст) и» printer-make-and-model «(текст). Следовательно, значение атрибута «сконфигурированного в charset» Принтера ДОЛЖНО также быть в числе значений атрибута «поддерживаемого charset» в Принтере.

5.4.18. charset-supported (1setOf charset) — поддержка кодировки

Этот НЕОБХОДИМЫЙ атрибут принтера определяет набор кодировок, которые поддерживаются Принтером и содержащимися в них заданиями, в атрибутах с синтаксисом атрибутов «текст» и «имя». ДОЛЖНО присутствовать хотя бы значение ut-8, поскольку объекты IPP ДОЛЖНЫ поддерживать кодировку UTF-8 [RFC3629]. Если принтер поддерживает кодировку, это означает, что для всех атрибутов синтаксиса «текст» и «имя» принтер ДОЛЖЕН (1) принимать кодировку в запросах и (2) возвращать кодировку в ответах по мере необходимости.

Если поддерживается больше кодировок, чем UTF-8, принтер ДОЛЖЕН выполнить преобразование кодировок между кодировками, как описано в разделе 4.1.4.2.

5.4.19. natural-language-configured (naturalLanguage) — настроенный на естественном языке

Этот НЕОБХОДИМЫЙ атрибут принтера определяет естественный язык, который принтер настроил для представления атрибутов принтера «текст» и «имя», которые устанавливаются оператором, администратором или производителем, т. Е. Для «имя принтера» (имя), « местоположение принтера «(текст),» информация о принтере «(текст) и» модель и модель принтера «(текст). При возврате этих атрибутов принтера, принтер МОЖЕТ вернуть их на настроенном естественном языке, указанном в этом атрибуте, вместо естественного языка, запрошенного клиентом в атрибуте операции «attribute-natural-language». Смотри Раздел 4.1.4.1 для спецификации ОПЦИОННОЙ поддержки нескольких естественных языков. Следовательно, значение атрибута «сконфигурированного на естественном языке» Принтера ДОЛЖНО также быть одним из значений атрибута «генерируемого на натуральном языке» Принтера.

5.4.20. generated-natural-language-supported (1setOf naturalLanguage) — сгенерированный естественный язык поддерживается

Этот НЕОБХОДИМЫЙ атрибут принтера определяет естественный язык (языки), которые принтер и содержащиеся в нем задания поддерживают в атрибутах с синтаксисом атрибутов «текст» и «имя». Поддерживаемый естественный язык (языки) зависит от реализации и / или конфигурации. В отличие от кодировок, принтеры ДОЛЖНЫ принимать запросы на любом естественном языке или с любым изменением естественного языка, независимо от того, поддерживается естественный язык или нет.

Если принтер поддерживает естественный язык, это означает, что для любого из атрибутов, для которых принтер или задание генерирует сообщения, т. Е. Для атрибутов «job-state-message» и «printer-state-message» и рабочих сообщений (см. Раздел 4.1.5) в ответах на операции принтер и задание ДОЛЖНЫ иметь возможность генерировать сообщения на любом из поддерживаемых принтером естественных языков. См. Разделы 4.1.4, 5.1.2 и 5.1.3 для определения атрибутов ‘text’ и ‘name’ в запросах и ответах на операции.

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

5.4.21. document-format-default (mimeMediaType) — формат документа по-умолчанию

Этот НЕОБХОДИМЫЙ атрибут принтера идентифицирует формат документа, который был настроен для принтера, если клиент не предоставляет атрибут операции «формат документа» ни в одном из запросов операции, которые предоставляют данные документа. Стандартными значениями для этого атрибута являются типы мультимедиа в Интернете (иногда называемые «типами мультимедиа MIME»). Дополнительные сведения см. В описании синтаксиса атрибута «mimeMediaType» в разделе 5.1.10.

5.4.22. document-format-supported (1setOf mimeMediaType) — поддерживаемый формат документа

Этот НЕОБХОДИМЫЙ атрибут принтера определяет набор форматов документов, которые может поддерживать принтер и содержащиеся в нем задания. Дополнительные сведения см. В описании синтаксиса атрибута «mimeMediaType» в разделе 5.1.10.

5.4.23. printer-is-accepting-jobs (boolean) — принтер принимает задание

Этот атрибут REQUIRED Printer указывает, может ли принтер в настоящее время принимать задания, т. Е. Принимает запросы Print-Job, Print-URI и Create-Job. Если значение равно «true», принтер принимает задания. Если значение равно «false», Принтер в настоящее время отклоняет любые предоставленные ему Задания. В этом случае принтер возвращает код состояния «ошибка сервера не принимает».

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

5.4.24. queued-job-count (integer(0:MAX)) — количество заданий в очереди

Этот атрибут REQUIRED Printer содержит количество заданий, которые «ожидают», «обрабатывают», «ожидают» или «остановлены» и устанавливаются принтером.

5.4.25. printer-message-from-operator (text(127)) — сообщение от оператора принтера

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

5.4.26. color-supported (boolean) — с поддержкой цвета

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера определяет, способно ли устройство вообще к какой-либо цветной печати, включая выделение цветом. Все инструкции документа, связанные с цветом, встроены в Document PDL, хотя атрибуты IPP могут влиять на отображение этих цветов.

Примечание. Конечные пользователи могут определять характер и детали поддержки цвета, запрашивая атрибут принтера «printer-more-info-Manufacturer».

5.4.27. reference-uri-schemes-supported (1setOf uriScheme) — поддержка опорных схем uri

Этот атрибут принтера указывает, какие схемы URI поддерживаются для использования в атрибуте операции «document-uri» операций Print-URI или Send-URI. Если принтер поддерживает эти НЕОБЯЗАТЕЛЬНЫЕ операции, он ДОЛЖЕН поддерживать атрибут принтера «reference-uri -grams-support» как минимум со следующим значением схемы URI:

» ftp »: принтер будет использовать операцию FTP ‘get’, как определено в [RFC959], с использованием URL-адресов FTP, как определено в [RFC3986].

Принтер МОЖЕТ поддерживать другие схемы URI (см. Раздел 5.1.7).

5.4.28. pdl-override-supported (type2 keyword) — поддерживается pdl-переопределение

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

’attempted’ (предпринято): это значение указывает на то, что Принтер пытается сделать так, чтобы значения атрибута IPP имели приоритет над встроенными инструкциями в данных документа; однако, нет никакой гарантии.
’not-attempted’ (не-предпринято): это значение означает, что Принтер не предпринимает попыток сделать так, чтобы значения атрибута IPP имели приоритет над встроенными инструкциями в данных документа.

Приложение C содержит полное описание того, как этот атрибут взаимодействует и влияет на другие атрибуты IPP, особенно атрибут «ipp-attribute-fidelity».

5.4.29. printer-up-time (integer(1:MAX)) — время работы принтера

Этот атрибут REQUIRED Printer указывает количество времени (в секундах), в течение которого этот экземпляр принтера работал и работал. Это монотонно увеличивающееся значение, начинающееся с 1, когда принтер запускается (инициализируется, загружается и т. Д.). Это значение используется для заполнения атрибутов статуса задания времени события «время создания», «время обработки» и «время завершения» (см. Раздел 5.3.14).

Если принтер выходит из строя с некоторым значением ‘n’ и возвращается обратно, реализация МОЖЕТ:

1. знать, как долго он был недоступен, и возобновить его при некотором значении, большем, чем «n», или
2. перезапустите с «1».

Другими словами, если устройство или устройства, которые представляет Принтер, перезапускаются или выключаются, Принтер МОЖЕТ продолжать считать это значение или МОЖЕТ сбросить это значение до 1, в зависимости от реализации. Однако, если программное обеспечение принтера прекращает работу и перезапускается, не зная последнего значения для «времени работы принтера», реализация ДОЛЖНА сбросить это значение до 1. Если это значение сброшено и принтер имеет постоянные задания, принтер ДОЛЖЕН сбросить «time-at-xxx (integer)» Атрибуты «Статус рабочего времени времени события» в соответствии с разделом 5.3.14. Реализация МОЖЕТ использовать обе альтернативы реализации, в зависимости от «горячего» и «холодного» запуска соответственно.

5.4.30. printer-current-time (dateTime|unknown) — текущее время принтера

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера указывает текущую дату и время. Это значение используется для заполнения атрибутов состояния задания времени события «дата-время при создании», «дата-время при обработке» и «дата-время при завершении» (см. Раздел 5.3.14).

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

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

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

Примечание. В предыдущих версиях этого документа неправильно указывалось использование внеполосного значения «no-value», если текущая дата и время не были установлены. Правильное внеполосное значение — «неизвестно», поскольку всегда существуют внутренние текущие дата и время.

5.4.31. multiple-operation-time-out (integer(1:MAX)) — время ожидания нескольких операций

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера определяет минимальное время (в секундах), в течение которого принтер ожидает дополнительных операций Send-Document или Send-URI, чтобы выполнить все еще открытое задание, прежде чем предпринимать какие-либо действия по восстановлению, такие как те, которые указаны в разделе 4.3.1. Если принтер поддерживает операции Create-Job и Send-Document (см. Разделы 4.2.4 и 4.3.1), он ДОЛЖЕН поддерживать этот атрибут.

Принтеры ДОЛЖНЫ использовать значение от 60 до 240 секунд. Реализация МОЖЕТ позволять Администратору устанавливать этот атрибут средствами, не определенными в этом документе. Если это так, администратор МОЖЕТ установить значения за пределами этого диапазона.

5.4.32. compression-supported (1setOf type2 keyword) — поддерживается сжатие

Этот НЕОБХОДИМЫЙ атрибут принтера определяет набор поддерживаемых алгоритмов сжатия для данных документа. Сжатие применяется только к данным документа; сжатие не применяется к кодированию самой операции IPP. Поддерживаемые значения используются для проверки предоставленных клиентом атрибутов операции «сжатия» в запросах Print-Job и Send-Document.

Стандартные значения ключевых слов, определенные в этом документе:

’none’: сжатие не используется.
’deflate’: технология сжатия ZIP-раздувания / раздувания, описанная в RFC 1951 [RFC1951].
’gzip’: технология сжатия zip в формате GNU, описанная в RFC 1952 [RFC1952].
’compress’: технология сжатия UNIX, описанная в RFC 1977 [RFC1977].

5.4.33. job-k-octets-supported (rangeOfInteger(0:MAX)) — поддерживаются задания k-октетов

Этот атрибут Printer определяет верхнюю и нижнюю границы общих размеров заданий в K октетах, то есть в единицах по 1024 октета. Поддерживаемые значения используются для проверки предоставленного клиентом атрибута операции «job-k-octets» в запросах на создание задания. Соответствующий атрибут описания задания «job-k-octets» определен в разделе 5.3.17.1.

5.4.34. job-impressions-supported (rangeOfInteger(0:MAX)) — поддержка заданий отпечатков

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера определяет верхнюю и нижнюю границы для числа показов в задании. Поддерживаемые значения используются для проверки предоставленного клиентом атрибута операции «впечатления от работы» в запросах на создание работы. Соответствующий атрибут описания работы «работа-показы» определен в разделе 5.3.17.2.

5.4.35. job-media-sheets-supported (rangeOfInteger(1:MAX)) — поддерживаются листы заданий носителя

Этот атрибут принтера определяет верхнюю и нижнюю границы для количества листов носителя на задание. Поддерживаемые значения используются для проверки предоставленного клиентом атрибута работы «job-media-sheet» в запросах на создание заданий. Соответствующий атрибут Job «job-media-sheet» определен в разделе 5.3.17.3.

5.4.36. pages-per-minute (integer(0:MAX)) — страниц в минуту

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера указывает номинальное количество страниц в минуту до ближайшего целого числа, которое может быть сгенерировано этим принтером (например, симплекс, черно-белый). Этот атрибут является информативным, а не гарантией обслуживания. Как правило, это значение, используемое в маркетинговой литературе для описания скорости устройства.

Значение 0 указывает устройство, которое обрабатывает страницу более двух минут.

5.4.37. pages-per-minute-color (integer(0:MAX)) — цвет страниц в минуту

Этот РЕКОМЕНДУЕМЫЙ атрибут принтера указывает номинальное количество страниц в минуту до ближайшего целого числа, которое может быть сгенерировано этим принтером при цветной печати (например, симплекс, цветной). Для целей этого атрибута значение «цвет» такое же, как и для атрибута «цвет поддерживается»; а именно, устройство способно к любому типу цветной печати вообще, включая цветную подсветку. Этот атрибут является информативным, а не гарантией обслуживания. Как правило, это значение, используемое в маркетинговой литературе для описания цветовых возможностей этого устройства.

Значение 0 указывает на то, что устройству требуется более двух минут для обработки цветной страницы.

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

Черно-белые принтеры НЕ ДОЛЖНЫ поддерживать этот атрибут. Если этот атрибут присутствует, то атрибут «Описание цвета» принтера ДОЛЖЕН присутствовать и иметь значение «истина».

На значения атрибутов «pages-per-minute» и «pages-per-minute-color», возвращаемых операцией Get-Printer-Attributes, МОЖЕТ влиять атрибут «document-format», предоставленный клиентом в Get- Запрос атрибутов принтера. Другими словами, реализация МОЖЕТ иметь разные скорости в зависимости от формата обрабатываемого документа. См. Раздел 4.2.5.1 («Запрос Get-Printer-Attributes»).

6. Соответствие

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

6.1. Требования к клиенту

В этом разделе описаны требования соответствия для Клиента (см. Раздел 3.1), будь то:

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

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

Соответствующий Клиент поддерживает все ТРЕБУЕМЫЕ операции, как определено в этом документе. Для каждого атрибута, включенного в запрос операции, соответствующий клиент ДОЛЖЕН предоставить значение, тип и синтаксис которого соответствуют требованиям, указанным в разделах 4 и 5 этого документа. Соответствующий клиент МОЖЕТ предоставлять любые расширения стандартов и / или расширения поставщиков в запросе на выполнение операций, если расширения соответствуют требованиям раздела 7.

Хотя в этом документе не определены требования соответствия для пользовательских интерфейсов, предоставляемых Клиентами IPP или их приложениями, передовые методы для пользовательских интерфейсов определены в [PWG5100.19].

Клиент ДОЛЖЕН быть в состоянии принять любой из синтаксисов атрибутов, определенных в Разделе 5.1, включая их полный диапазон, которые могут быть ему возвращены в ответе от Принтера. В частности, для каждого атрибута, который поддерживает Клиент, чей синтаксис атрибута — «текст», Клиент ДОЛЖЕН принимать и обрабатывать формы «textWithoutLanguage» и «textWithLanguage». Аналогичным образом, для каждого атрибута, который поддерживает Клиент, чей синтаксис атрибута равен «name», Клиент ДОЛЖЕН принимать и обрабатывать формы «nameWithoutLanguage» и «nameWithLanguage». В целях представления усечение длинных значений атрибута не рекомендуется. Рекомендованный подход для реализации клиента — позволить пользователю прокручивать длинные значения атрибутов.

Ответ МОЖЕТ содержать группы атрибутов, атрибуты, синтаксисы атрибутов, значения и значения кода состояния, которые Клиент не ожидает. Поэтому реализация клиента ДОЛЖНА изящно обрабатывать такие ответы и не отказываться взаимодействовать с соответствующим принтером, который возвращает расширения отслеживания стандартов или расширения поставщиков, включая группы атрибутов, атрибуты, синтаксис атрибутов, значения атрибутов, значения кодов состояния и вне -диапазонные значения атрибутов, которые соответствуют Разделу 7. Клиенты могут игнорировать любые параметры, группы атрибутов, атрибуты, синтаксисы атрибутов или значения, которые они не понимают.

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

Клиент ДОЛЖЕН поддерживать аутентификацию клиента, как определено в [RFC8010]. Клиент ДОЛЖЕН поддерживать конфиденциальность операций и аутентификацию сервера, как определено в [RFC8010]. Смотрите также Раздел 9 этого документа.

6.2. Требования соответствия объекта IPP

Этот раздел определяет требования соответствия для соответствующих реализаций объектов IPP (см. Раздел 3). Эти требования применяются к объекту IPP независимо от того, является ли он:

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

6.2.1. Объекты

Соответствующие реализации ДОЛЖНЫ реализовывать все объекты модели, как определено в этом документе в указанных разделах:

Раздел 3.1 — Объект принтера
Раздел 3.2 — Объект задания

6.2.2. Операции

Соответствующие реализации объекта IPP ДОЛЖНЫ реализовывать все необходимые операции модели, включая требуемые ответы, как определено в этом документе в указанных разделах. В таблице 20 перечислены операции для принтера, а в таблице 21 перечислены операции для задания.

Таблица 20 - Требования соответствия для операций принтера — Таблица 20 — Требования соответствия для операций принтера

Таблица 21 - Требования соответствия для рабочих заданий — Таблица 21 — Требования соответствия для рабочих заданий

Соответствующие объекты IPP ДОЛЖНЫ поддерживать все ТРЕБУЕМЫЕ атрибуты операции и все значения таких атрибутов, если это указано в описании. Соответствующие объекты IPP ДОЛЖНЫ игнорировать все неподдерживаемые или неизвестные атрибуты операции или группы атрибутов операции, полученные в запросе, но ДОЛЖНЫ отклонять запрос, который содержит поддерживаемый атрибут операции, который содержит неподдерживаемое значение.

Соответствующие объекты IPP МОГУТ возвращать ответы операций, которые содержат группы атрибутов, имена атрибутов, синтаксисы атрибутов, значения атрибутов и значения кодов состояния, которые являются расширениями данной спецификации. Дополнительные группы атрибутов МОГУТ появляться в любом порядке.

В следующем разделе об атрибутах объекта указана поддержка, необходимая для атрибутов объекта.

6.2.3. Атрибуты объекта IPP

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

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

6.2.4. Версии

Клиенты IPP / 1.1 ДОЛЖНЫ соответствовать требованиям соответствия для Клиентов, указанных в этом документе и [RFC8010]. Клиенты IPP / 1.1 ДОЛЖНЫ иметь возможность отправлять запросы, содержащие параметр «номер версии» со значением «1,1».

Объекты принтера и задания IPP / 1.1 ДОЛЖНЫ соответствовать требованиям соответствия для объектов IPP, указанных в этом документе и [RFC8010]. Объекты IPP / 1.1 ДОЛЖНЫ принимать запросы, содержащие параметр «номер версии» со значением «1.1», или отклонять запрос, если операция не поддерживается.

В сферу действия данной спецификации не входит обязательное соответствие с другими версиями IPP. Тем не менее, IPP был специально разработан, чтобы облегчить поддержку различных версий. Реализации принтера IPP / 1.1 ДОЛЖНЫ:

декодировать и обрабатывать любой правильно сформированный запрос IPP / 1.1, и
отвечать соответствующим образом ответом, содержащим то же значение параметра «номер версии», которое использовалось клиентом в запросе.

Реализации клиента IPP / 1.1 ДОЛЖНЫ:

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

6.2.5. Расширения

Соответствующий объект IPP МОЖЕТ поддерживать расширения для отслеживания стандартов и поставщиков, если расширения соответствуют требованиям, указанным в разделе 7.

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

6.2.6. Синтаксис атрибутов

Объект IPP ДОЛЖЕН иметь возможность принимать любой из синтаксисов атрибутов, определенных в Разделе 5.1, включая их полный диапазон, в любой операции, в которой Клиент может предоставлять атрибуты или Администратор может настраивать атрибуты (с помощью средств, выходящих за рамки этого IPP / 1.1. документ). В частности, для каждого атрибута, который поддерживает объект IPP, чей синтаксис атрибута равен «text», объект IPP ДОЛЖЕН принимать и обрабатывать формы «textWithoutLanguage» и «textWithLanguage». Аналогично, для каждого атрибута, который поддерживает объект IPP, синтаксис атрибута которого равен «name», объект IPP ДОЛЖЕН принимать и обрабатывать формы «nameWithoutLanguage» и «nameWithLanguage». Кроме того, объект IPP ДОЛЖЕН возвращать клиенту атрибуты в ответах на операции, которые соответствуют синтаксисам, указанным в разделе 5.1, включая их полный диапазон, если он был предоставлен ранее клиентом.

6.2.7. Безопасность

Реализация принтера IPP ДОЛЖНА содержать поддержку аутентификации клиента, как это определено в документе «Кодирование и транспорт IPP / 1.1» [RFC8010]. Реализация Принтера МОЖЕТ позволить Администратору настроить Принтер так, чтобы все, некоторые или ни один из пользователей не проходили аутентификацию. Смотрите также Раздел 9 этого документа.

Реализация принтера IPP ДОЛЖНА содержать поддержку конфиденциальности операций и аутентификации сервера, как определено в [RFC8010]. Реализация принтера МОЖЕТ позволять администратору настраивать степень поддержки конфиденциальности операций и аутентификации сервера. Смотрите также Раздел 9 этого документа.

Безопасность НЕ ДОЛЖНА подвергаться риску, когда Клиент указывает в запросе меньший параметр «номер версии». Например, если принтер, соответствующий IPP / 1.1, принимает запросы версии 1.0 и настроен на принудительную дайджест-аутентификацию, он ДОЛЖЕН сделать то же самое для запроса версии 1.0.

6.3. Требования к кодировке и естественному языку

Все клиенты и объекты IPP ДОЛЖНЫ поддерживать кодировку utf-8, как определено в разделе 5.1.8.

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

7. Соображения IANA

В этом разделе описываются процедуры определения отслеживания стандартов и расширений поставщиков для этого документа. Это влияет на следующие подрегистры реестра IPP IANA:

Объекты
Атрибуты
Значения атрибута ключевого слова
Перечислите значения атрибутов
Теги группы атрибутов
Внешние теги значений атрибутов
Синтаксис атрибутов
Операции
Значения кода состояния

Расширения, зарегистрированные для использования с IPP, являются ФАКУЛЬТАТИВНЫМИ для соответствия Клиента и объекта IPP документу Модели и Семантики IPP / 1.1 (этот документ).

Эти процедуры расширения приведены в соответствие с рекомендациями, изложенными в «Руководстве по написанию Раздела рассмотрения IANA в RFC» [RFC5226]. Приложение A описывает, как предлагать новые регистрации для рассмотрения. IANA отклонит предложения о регистрации, в которых пропущена необходимая информация или которые не соответствуют соответствующему формату, описанному в Приложении A. Документ модели и семантики IPP / 1.1 также может быть расширен соответствующим документом отслеживания стандартов, в котором указано любое из вышеуказанных расширений.

Политика IANA (с использованием терминов, определенных в [RFC5226]) для всех расширений: «Требуется спецификация», «Экспертная проверка» или «Первым прибыл — первым обслужен», как описано в следующих подразделах. Регистрации, представленные в IANA, направляются назначенному эксперту (-ам) IPP, который просматривает предложение в списке рассылки, который назначенный эксперт ведет для этой цели. Первоначально этот список является списком рассылки, используемым рабочей группой PWG IPP:

ipp@pwg.org

Назначенный эксперт (ы) IPP назначается региональным директором IESG, ответственным за IPP, в соответствии с [RFC5226].

Кроме того, IANA-PRINTER-MIB [RFC3805] был обновлен для ссылки на этот документ; текущая версия доступна на <http://www.iana.org>.

7.1. Расширяемость объектов

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений объектов ранее была экспертной проверкой; этот документ изменяет политику на «Требуется спецификация».

7.2. Расширяемость атрибутов

Поскольку имена атрибутов являются ключевыми словами типа 2 (см. Раздел 5.1.4), политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений атрибутов — это экспертная проверка.

Для расширений атрибутов поставщиков разработчикам СЛЕДУЕТ использовать ключевые слова с подходящим отличительным префиксом, таким как ‘smiNNN-‘, где NNN — номер частного предприятия SMI (PEN) [IANA-PEN]. Например, если компания Example Corp. получила SMI PEN 32473, то атрибутом поставщика «foo» будет «smi32473-foo».

Примечание. В предыдущих версиях этого документа рекомендовалось использовать в качестве префикса полное доменное имя [RFC1035] (например, «example.com-foo»), а во многих реализациях IPP также использовались обратные доменные имена (например, «com.example-»). Foo ‘). Доменные имена оказались проблематичными из-за длины некоторых доменных имен, параллельного использования доменных имен для конкретной страны (например, «example.co.jp-foo») и изменений в владении доменными именами.

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

«Значение этого атрибута, возвращаемого в ответе Get-Printer-Attributes, МОЖЕТ зависеть от предоставленного атрибута« format-format »(см. Раздел 4.2.5.1) документа« Модель и семантика IPP / 1.1 ».»

Если спецификация этого не делает, то ее значение в ответе Get-Printer-Attributes НЕ ДОЛЖНО зависеть от атрибута «document-format», предоставленного в запросе.

При регистрации нового атрибута шаблона задания значение атрибутов принтера МОЖЕТ изменяться в зависимости от «формата документа», указанного в запросе, без указания спецификации.

7.3. Расширяемость ключевых слов

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений ключевых слов type1: Требуется спецификация. Политика IANA для расширений ключевых слов type2 — экспертная проверка. Политика IANA в отношении расширений ключевых слов поставщика — «Сначала пришел, первым обслужен». В реестре IANA IPP могут быть зарегистрированы только атрибуты, использующие синтаксис ключевых слов type1 и type2.

Примечание. Префикс type1 или type2 в синтаксисе базовых атрибутов предоставляется только для передачи политики IANA, необходимой для регистрации, и не представлен в сообщениях IPP. Значения «ключевого слова» type1 и type2 представлены с использованием одного и того же тега значения ключевого слова.

Для ключевых слов type1 и type2 заявитель включает имя ключевого слова в заявку на регистрацию, и это имя является частью технического обзора.

Для расширений ключевых слов вендора разработчики ДОЛЖНЫ либо:

а. следуйте указаниям, относящимся к атрибутам, таким как указания, определенные в [PWG5101.1], или
б. используйте ключевые слова с подходящим отличительным префиксом, например, «smiNNN-», где NNN — номер частного предприятия SMI (PEN) [IANA-PEN].

Например, если компания Example Corp. получила SMI PEN 32473, тогда ключевое слово поставщика «foo» будет «smi32473-foo».

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

7.4. Расширяемость Enum

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений перечисления type1: Требуется спецификация. Политика IANA для расширений перечислений type2 — экспертная проверка. Политика IANA в отношении расширений перечислений поставщиков — «Сначала пришел первым обслужен». В реестре IANA IPP могут быть зарегистрированы только атрибуты, использующие синтаксис перечислений type1 и type2.

Примечание. Префикс type1 или type2 в синтаксисе базовых атрибутов предоставляется только для передачи политики IANA, необходимой для регистрации, и не представлен в сообщениях IPP. Значения перечисления как type1, так и type2 представлены с использованием одного и того же тега перечисления.

Для расширений перечисления поставщиков разработчики ДОЛЖНЫ использовать значения в зарезервированном целочисленном диапазоне, который составляет от 0x40000000 до 0x7fffffff. Разработчикам СЛЕДУЕТ проконсультироваться с назначенным экспертом (экспертами) IPP, чтобы зарезервировать дополнительные значения поставщика для их использования.

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

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

7.5. Расширяемость группы атрибутов

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений группы атрибутов ранее была экспертной проверкой; этот документ изменяет политику на «Требуется спецификация».

Для групп атрибутов назначенный эксперт (ы) IPP в консультации с IANA назначает следующий код тега группы атрибутов в соответствующем диапазоне, как указано в [RFC8010].

7.6. Расширяемость значения атрибута вне диапазона

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений значений атрибутов вне полосы ранее была экспертной проверкой; этот документ изменяет политику на «Требуется спецификация».

Для тегов значений атрибутов вне диапазона назначенный эксперт (ы) IPP, консультируясь с IANA, назначает следующий код тега значений атрибутов вне диапазона в соответствующем диапазоне, как указано в [RFC8010].

7.7. Расширяемость синтаксиса атрибута

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений синтаксиса атрибутов ранее была экспертной проверкой; этот документ изменяет политику на «Требуется спецификация». Политика IANA для расширений синтаксиса атрибутов поставщиков (теги от 0x40000000 до 0x7fffffff) — «Первым прибыл — первым обслужен». В реестре IANA IPP могут быть зарегистрированы только синтаксисы атрибутов в диапазоне от 0x00000000 до 0x3fffffff.

Для расширений синтаксиса атрибутов поставщиков разработчики ДОЛЖНЫ использовать значения в зарезервированном целочисленном диапазоне, который составляет от 0x40000000 до 0x7fffffff. Разработчикам СЛЕДУЕТ проконсультироваться с назначенным экспертом (экспертами) IPP, чтобы зарезервировать дополнительные значения поставщика для их использования.

Для зарегистрированных синтаксисов атрибутов назначенный эксперт (ы) IPP, консультируясь с IANA, назначает тег синтаксиса следующего атрибута в соответствующем диапазоне, как указано в [RFC8010].

7.8. Расширяемость операций

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений операций — это экспертная проверка. Политика IANA для расширений операций поставщика (значения от 0x4000 до 0x7fff) — «Первым прибыл — первым обслужен». В реестре IANA IPP могут быть зарегистрированы только коды операций в диапазоне от 0x0000 до 0x3fff.

Для расширений операций поставщика разработчики ДОЛЖНЫ использовать значения в зарезервированном целочисленном диапазоне, который составляет от 0x4000 до 0x7fff. Разработчикам СЛЕДУЕТ проконсультироваться с назначенным экспертом (экспертами) IPP, чтобы зарезервировать дополнительные значения поставщика для их использования.

Для зарегистрированных расширений операций назначенный эксперт (ы) IPP, консультируясь с IANA, присваивает следующий код «идентификатор операции», как указано в разделе 5.4.15.

7.9. Расширяемость кода состояния

Политика IANA (с использованием терминов, определенных в [RFC5226]) для расширений кода статуса — это экспертная проверка. Политика IANA для расширений кодов статуса поставщика (коды от 0x0n80 до 0x0nff, для n = от 0 до 5) — «первым пришел — первым обслужен». Только значения кода состояния в диапазоне от 0x0n00 до 0x0n7f могут быть зарегистрированы в реестре IANA IPP.

Значения кода состояния распределяются в диапазонах, как указано в Приложении B для каждого класса кода состояния:

«informational» — информационный — запрос получен, продолжение процесса
«successful» — успешно — акция была успешно принята, понята и принята
«redirection» — перенаправление — для выполнения запроса предпринимаются дальнейшие действия
«client-error» — ошибка клиента — запрос содержит неверный синтаксис или не может быть выполнен
«server-error» ошибка сервера — объекту IPP не удалось выполнить явно допустимый запрос

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

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

8. Вопросы интернационализации

Некоторые из атрибутов имеют значения, которые являются текстовыми строками и именами, которые предназначены для понимания человеком, а не машинным пониманием (см. Синтаксисы атрибутов «текст» и «имя» в разделах 5.1.2 и 5.1.3).

В каждом запросе операции Клиент

идентифицирует набор символов и естественный язык запроса, который влияет на каждое предоставленное значение атрибута ‘text’ и ‘name’, и
запрашивает набор символов и естественный язык для атрибутов, возвращаемых объектом IPP в ответах операции (как описано в Разделе 4.1.4.1).

Кроме того, Клиент МОЖЕТ отдельно и индивидуально идентифицировать переопределение естественного языка для предоставленного атрибута ‘text’ или ‘name’, используя методы ‘textWithLanguage’ и ‘nameWithLanguage’, описанные в разделах 5.1.2.2 и 5.1.3.2, соответственно.

Все объекты IPP ДОЛЖНЫ поддерживать кодировку UTF-8 [RFC3629] во всех поддерживаемых атрибутах ‘text’ и ‘name’. Если объект IPP поддерживает больше, чем набор символов UTF-8, этот объект ДОЛЖЕН преобразовываться между ними, чтобы вернуть запрошенный набор символов клиенту в соответствии с разделом 4.1.4.2. Если объект IPP поддерживает более одного естественного языка, объект ДОЛЖЕН возвращать значения «текст» и «имя» на запрашиваемом естественном языке, где эти значения создаются принтером (смотри Раздел 4.1.4.1).

Для принтеров, которые поддерживают несколько кодировок и / или несколько естественных языков в атрибутах «текст» и «имя», различные задания могли быть представлены на разных кодировках и / или на естественных языках. Все ответы ДОЛЖНЫ быть возвращены в кодировке, запрошенной Клиентом. Однако операция Get-Jobs использует механизмы textWithLanguage и nameWithLanguage для определения различных естественных языков с каждым возвращаемым атрибутом Job.

Принтер также настроил атрибуты набора символов и естественного языка. Клиент может запросить Принтер, чтобы определить список кодировок и естественных языков, поддерживаемых Принтером, и узнать, какие параметры принтера настроены. Дополнительные сведения см. В атрибутах «Описание набора символов», «Поддержка набора символов», «Настройка на естественном языке» и «Сгенерированный на естественном языке».

Атрибут «charset-support» определяет поддерживаемые наборы символов. Если поддерживается набор символов, объект IPP ДОЛЖЕН быть способен преобразовывать этот набор символов и обратно в любой другой поддерживаемый набор символов. Во многих случаях объект IPP будет поддерживать только одну кодировку, и он ДОЛЖЕН быть кодировкой UTF-8.

Атрибут «charset-сконфигурированный» идентифицирует тот поддерживаемый набор символов, который является собственным набором символов, учитывая текущую конфигурацию объекта IPP (определено администратором).

Атрибут «генерируемый естественный язык поддерживается» идентифицирует набор поддерживаемых естественных языков для сгенерированных сообщений; он не связан с набором естественных языков, которые ДОЛЖНЫ быть приняты для предоставленных Клиентом атрибутов ‘text’ и ‘name’. Для предоставленных Клиентом атрибутов ‘text’ и ‘name’ объект IPP ДОЛЖЕН принимать ВСЕ предоставленные естественные языки. Например, если Клиент предоставляет имя задания, которое находится в «fr-ca», но принтер генерирует только «en-us», объект Printer ДОЛЖЕН по-прежнему принимать значение имени задания.

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

Атрибуты типов ‘text’ и ‘name’ заполняются из разных источников. Эти атрибуты можно разделить на следующие группы (в зависимости от источника атрибута):

Некоторые атрибуты предоставляются клиентом (например, предоставленные клиентом атрибуты операции «имя-задания», «имя-документа» и «запрашивающее-имя-пользователя» вместе с соответствующими «заданиями-именами» и «соответствующим заданием»). атрибуты «job-originating-user-name»). Объект IPP ДОЛЖЕН принимать эти атрибуты на любом естественном языке независимо от набора поддерживаемых языков для сгенерированных сообщений.
Некоторые атрибуты предоставляются администратором (например, атрибуты принтера «имя принтера» и «местоположение принтера»). Они также могут быть на любом естественном языке. Если естественный язык для этих атрибутов отличается от того, что запрашивает Клиент, то они ДОЛЖНЫ быть представлены с использованием механизма переопределения естественного языка.
Некоторые атрибуты предоставляются производителем устройства (например, атрибут «Принтер-изготовитель-модель»). Они также могут быть на любом естественном языке. Если естественный язык для этих атрибутов отличается от того, что запрашивает Клиент, то они ДОЛЖНЫ быть представлены с использованием механизма переопределения естественного языка.
Некоторые атрибуты предоставляются Оператором (например, атрибут задания Job-message-from-operator). Они также могут быть на любом естественном языке. Если естественный язык для этих атрибутов отличается от того, что запрашивает Клиент, то они ДОЛЖНЫ быть представлены с использованием механизма переопределения естественного языка.
Некоторые атрибуты генерируются объектом IPP (например, атрибут Job-state-message-Job, атрибут Printer-state-message принтера и атрибут операции-status-message). Эти атрибуты могут быть только на одном из естественных языков «сгенерированных естественным языком». Если Клиент запрашивает некоторый естественный язык для этих атрибутов, отличный от одного из поддерживаемых значений, объект IPP ДОЛЖЕН ответить, используя значение атрибута «сконфигурированный на естественном языке» (при необходимости используя механизм переопределения естественного языка).

Атрибуты «text» и «name», указанные в этой версии этого документа (дополнительные будут зарегистрированы в соответствии с процедурами в разделе 7), показаны в таблице 22.

Примечание 1: ни Принтер, ни Клиент не локализуют эти атрибуты сообщения, поскольку они предназначены для использования Администратором или другими опытными техническими специалистами.

9. Вопросы безопасности

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

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

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

Во время запроса на создание задания личность клиента записывается в объекте задания в атрибуте, определяемом реализацией. Эта информация может использоваться для проверки личности Клиента для последующих операций с этим объектом Job для обеспечения применения любой политики контроля доступа, которая может быть в силе. См. Раздел 9.3 ниже для более подробной информации. Эта и другая информация, хранящаяся в объекте Job, также может считаться личной или конфиденциальной по своему характеру и может быть отфильтрована как часть настроенной политики конфиденциальности (Раздел 9.4).

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

9.1. Сценарии безопасности

В следующих разделах описываются конкретные атаки безопасности для сред IPP. Там, где приведены примеры, они иллюстрируют среду, а не являются исчерпывающим набором.

9.1.1. Клиент и сервер в одном домене безопасности

Эта среда типична для внутренних сетей, где традиционные офисные работники печатают выходные данные приложений для повышения производительности на общих принтерах рабочих групп, или когда пакетные приложения печатают свои результаты на больших производственных принтерах. Хотя личность пользователя была аутентифицирована и ей можно доверять в этой среде, пользователь может захотеть защитить содержимое документа от таких атак, как подслушивание, воспроизведение или подделка, с помощью безопасного транспорта, такого как TLS [RFC5246].

9.1.2. Клиент и сервер в разных доменах безопасности

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

9.1.3. Печать по ссылке

Когда Документ не хранится на Клиенте, печать может быть сделана по ссылке. То есть запрос на печать может содержать ссылку или указатель на документ вместо самого документа — см. Разделы 4.2.2 и 4.3.2. В настоящее время не существует стандартных методов, позволяющих удаленным объектам «принимать» учетные данные клиента для пересылки запросов третьей стороне. Предполагается, что печать по ссылке будет использоваться для доступа к «общедоступным» документам. Обратите внимание, что сложные методы аутентификации «прокси» выходят за рамки этого документа IPP / 1.1. Поскольку принтеры обычно обрабатывают задания последовательно, печать по ссылке не рассматривается как серьезная угроза отказа в обслуживании для указанных серверов.

9.2. URI в атрибутах операции, задания и принтера

Атрибут «printer-uri-support» содержит URI принтера. Его сопутствующий атрибут «uri-security-Поддерживается» идентифицирует механизм безопасности, используемый для каждого URI, указанного в атрибуте «printer-uri-support». Для каждого запроса операции принтера Клиент ДОЛЖЕН предоставить только один URI в атрибуте операции printer-uri. Другими словами, даже если принтер поддерживает более одного URI, клиент взаимодействует только с принтером, используя один из его URI. Эта двойственность не требуется для объектов Job, поскольку принтеры будут действовать как «фабрика» для объектов Job, и данный принтер, в зависимости от конфигурации безопасности принтера, будет генерировать правильный URI для новых объектов Job.

9.3. URI для каждого механизма аутентификации

Каждый URI имеет связанный с ним механизм аутентификации. Если URI является «i-тым» элементом «printer-uri-Поддерживаемый», то механизм аутентификации является «i-тым» элементом «URI-аутентификация-поддерживаемый». Список возможных механизмов аутентификации см. В разделе 5.4.2.

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

Во время запросов на создание задания принтер инициализирует значение атрибута «job-originating-user-name» (см. Раздел 5.3.6) для аутентифицированного пользователя. Аутентифицированный пользователь в этом случае называется «Владелец работы».

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

Клиент может определить механизм аутентификации, используемый для создания задания. Это «i-е» значение атрибута «uri-authentication-support» принтера (см. Раздел 5.4.2), где «i» — это индекс элемента атрибута «printer-uri-support» принтера ( см. раздел 5.4.1), равный атрибуту Job-printer-uri задания (см. раздел 5.3.3).

9.4. Запрещенные Запросы

Во многих операциях IPP Клиент предоставляет список атрибутов, которые должны быть возвращены в ответе. В целях безопасности объект IPP можно настроить так, чтобы он не возвращал все атрибуты (или все значения), которые запрашивает клиент. Возвращаемые атрибуты задания МОГУТ зависеть от того, совпадает ли запрашивающий пользователь с пользователем, отправившим задание. Объект IPP МОЖЕТ даже не возвращать ни один из запрошенных атрибутов. В таких случаях возвращаемый статус такой же, как если бы объект возвратил все запрошенные атрибуты. Клиент не может определить таким ответом, был ли запрошенный атрибут в объекте или отсутствует.

9.5. Операции, выполняемые операторами и администраторами

Для трех операций «Принтер» — «Пауза-принтер», «Возобновление-принтер» и «Очистка-задание» (см. Разделы 4.2.7, 4.2.8 и 4.2.9) запрашивающий пользователь должен быть оператором или администратором принтера (см. Секция 1). В противном случае принтер IPP ДОЛЖЕН отклонить операцию и вернуть «клиент-ошибка-запрещен», «клиент-ошибка-не-аутентифицирован» или «клиент-ошибка-не авторизован» в зависимости от ситуации. Для работы с заданиями запрашивающий пользователь должен быть владельцем задания или может быть оператором или администратором принтера. Средства для авторизации Оператора или Администратора Принтера в этом документе не указаны.

9.6. Запросы о заданиях, отправленных с использованием протоколов, отличных от IPP

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

IPP-принтерам СЛЕДУЕТ также генерировать значения «идентификатор-задания» и «задание-задание» для таких внешних заданий, если это возможно, чтобы они могли быть объектами других операций IPP, таких как Get-Job-Attributes и Cancel-Job. Такая реализация также должна иметь дело с проблемой аутентификации таких иностранных рабочих мест. Один из подходов состоит в том, чтобы рассматривать все такие внешние задания как принадлежащие пользователям, отличным от пользователя Клиента IPP. Другой подход заключается в том, чтобы иностранное задание принадлежало «анонимному» — тогда только аутентифицированные операторы или администраторы принтера IPP могли запрашивать иностранные задания с помощью запроса IPP. В качестве альтернативы, если политика безопасности разрешает пользователям запрашивать задания других пользователей, то внешние задания также будут видны клиенту IPP конечного пользователя, использующему Get-Jobs и Get-Job-Attributes.

10. Изменения с RFC 2911

Следующие изменения были внесены после RFC 2911:

Ошибка ID 364: фиксированный диапазон значений кода состояния «перенаправление» (до 0x03xx).
Ошибка с кодом 694: фиксированный диапазон значений кода состояния поставщика (от 0x0n80 до 0x0nff).
Ошибка ID 3072: переопределено определение обработки нескольких документов, поскольку оно также применяется к заданиям с одним документом и является единственным совместимым способом запроса неколлированных копий.
Ошибка 3365: исправлена неверная максимальная длина nameWithLanguage путем ссылки на раздел nameWithoutLanguage (т. е. раздел 5.1.3.1).
Ошибка ID 4173: фиксированный диапазон кодов работы поставщика (от 0x4000 до 0x7fff).
Обновлены устаревшие ссылки RFC.
Изменена ссылка на Руководство по реализации IPP / 1.1 для RFC 3196.
Обновлены Create-Job, Send-Document и Send-URI для РЕКОМЕНДУЕМЫХ.
Содержимое атрибута ‘collection’ из RFC 3382.
Устарели все атрибуты и значения, определенные в RFC 3381, так как они плохо взаимодействуют с атрибутом «отделки» и никогда широко не применялись.
Устаревшие операции Purge-Jobs и Restart-Job, которые уничтожают учетную информацию.
Отброшены процедуры регистрации типа 3.
Изменены атрибуты поставщика и рекомендации по именованию ключевых слов, чтобы использовать SMI Private Enterprise Numbers («smiNNN-foo») вместо доменных имен.
Разделить атрибуты «Описание работы» и «Описание принтера» на атрибуты «Статус работы» и «Состояние принтера» в соответствии с текущей организацией реестра IANA IPP.
Ссылка на все стандарты IETF и PWG IPP.
Обновлены ДОПОЛНИТЕЛЬНЫЕ операции, атрибуты и значения, чтобы РЕКОМЕНДУЕТСЯ для согласованности с IPP 2.0, IPP Everywhere и Руководством для разработчика IPP v2.0.
Удалено приложение на названиях носителей. Читатели направляются на «Стандартные имена PWG Media 2.0 (MSN2)» [PWG5101.1].

11. Ссылки

11.1. Нормативные ссылки

[ASME-Y14.1M]
ASME Y14.1M-2012, «Metric Drawing Sheet Size and Format»,
March 2013.

[ISO10175] ISO/IEC 10175, «Information technology — Text and office systems — Document Printing Application (DPA) — Part 1: Abstract service definition and procedures», September 1996.

[ISO10646] ISO/IEC 10646:2014, JTC1/SC2, «Information technology — Universal Coded Character Set (UCS)», September 2014.

[ISO8859-1]
ISO/IEC 8859-1:1998, «Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1», April 1998.

[PWG5100.1]
Sweet, M., «IPP Finishings 2.0 (FIN)», December 2014, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippfinishings20-20141219-5100.1.pdf>.

[PWG5100.11]
Hastings, T. and D. Fullman, «Internet Printing Protocol (IPP): Job and Printer Extensions — Set 2 (JPS2)», October 2010, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext10-20101030-5100.11.pdf>.

[PWG5100.12]
Sweet, M. and I. McDonald, «IPP Version 2.0, 2.1, and 2.2», October 2015, <http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf>.

[PWG5100.13]
Sweet, M., McDonald, I., and P. Zehler, «IPP: Job and Printer Extensions — Set 3 (JPS3)», July 2012, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf>.

[PWG5100.14]
Sweet, M., McDonald, I., Mitchell, A., and J. Hutchings, «IPP Everywhere», January 2013, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf>.

[PWG5100.15]
Sweet, M., «IPP FaxOut Service», June 2014, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf>.

[PWG5100.16]
Sweet, M., «IPP Transaction-Based Printing Extensions», November 2013, <http://ftp.pwg.org/pub/pwg/candidates/cs-ipptrans10-20131108-5100.16.pdf>.

[PWG5100.17]
Zehler, P. and M. Sweet, «IPP Scan Service (SCAN)», September 2014, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippscan10-20140918-5100.17.pdf>.

[PWG5100.18]
Sweet, M. and I. McDonald, «IPP Shared Infrastructure Extensions (INFRA)», June 2015, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippinfra10-20150619-5100.18.pdf>.

[PWG5100.19] Kennedy, S., «IPP Implementor’s Guide v2.0 (IG)», August 2015, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf>.

[PWG5100.2]
Hastings, T. and R. Bergman, «Internet Printing Protocol (IPP): «output-bin» attribute extension», February 2001, <http://ftp.pwg.org/pub/pwg/candidates/
cs-ippoutputbin10-20010207-5100.2.pdf>.

[PWG5100.3]
Ocke, K. and T. Hastings, «Internet Printing Protocol (IPP): Production Printing Attributes — Set1», February 2001, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf>.

[PWG5100.5]
Carney, D., Hastings, T., and P. Zehler, «Standard for The Internet Printing Protocol (IPP): Document Object», October 2003, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippdocobject10-20031031-5100.5.pdf>.

[PWG5100.6]
Zehler, P., Herriot, R., and K. Ocke, «Standard for The Internet Printing Protocol (IPP): Page Overrides», October 2003, <http://ftp.pwg.org/pub/pwg/candidates/cs-ipppageoverride10-20031031-5100.6.pdf>.

[PWG5100.7]
Hastings, T. and P. Zehler, «Standard for The Internet Printing Protocol (IPP): Job Extensions», October 2003, <http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobext10-20031031-5100.7.pdf>.

[PWG5100.8]
Carney, D. and H. Lewis, «Standard for Internet Printing Protocol (IPP): «-actual» attributes», March 2003,
<http://ftp.pwg.org/pub/pwg/candidates/cs-ippactuals10-20030313-5100.8.pdf>.

[PWG5100.9]
McDonald, I. and C. Whittle, «Internet Printing Protocol (IPP): Printer State Extensions v1.0», July 2009,
<http://ftp.pwg.org/pub/pwg/candidates/cs-ippstate10-20090731-5100.9.pdf>.

[PWG5101.1]
Sweet, M., Bergman, R., and T. Hastings, «PWG Media Standardized Names 2.0 (MSN2)», March 2013,
<http://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn20-20130328-5101.1.pdf>.

[RFC20] Cerf, V., «ASCII format for network interchange», STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC1951] Deutsch, P., «DEFLATE Compressed Data Format Specification version 1.3», RFC 1951, DOI 10.17487/RFC1951, May 1996,
<http://www.rfc-editor.org/info/rfc1951>.

[RFC1952] Deutsch, P., «GZIP file format specification version 4.3», RFC 1952, DOI 10.17487/RFC1952, May 1996,
<http://www.rfc-editor.org/info/rfc1952>.

[RFC1977] Schryver, V., «PPP BSD Compression Protocol», RFC 1977, DOI 10.17487/RFC1977, August 1996,
<http://www.rfc-editor.org/info/rfc1977>.

[RFC2046] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types», RFC 2046, DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.

[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, «Internet Printing Protocol/1.1: Implementor’s Guide», RFC 3196, DOI 10.17487/RFC3196, November 2001,
<http://www.rfc-editor.org/info/rfc3196>.

[RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis, «Internet Printing Protocol (IPP): Job and Printer Set Operations», RFC 3380, DOI 10.17487/RFC3380,
September 2002, <http://www.rfc-editor.org/info/rfc3380>.

[RFC3510] Herriot, R. and I. McDonald, «Internet Printing Protocol/1.1: IPP URL Scheme», RFC 3510, DOI 10.17487/RFC3510, April 2003,
<http://www.rfc-editor.org/info/rfc3510>.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629,
November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3805] Bergman, R., Lewis, H., and I. McDonald, «Printer MIB v2», RFC 3805, DOI 10.17487/RFC3805, June 2004,
<http://www.rfc-editor.org/info/rfc3805>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.

[RFC3995] Herriot, R. and T. Hastings, «Internet Printing Protocol (IPP): Event Notifications and Subscriptions», RFC 3995, DOI 10.17487/RFC3995, March 2005,
<http://www.rfc-editor.org/info/rfc3995>.

[RFC3996] Herriot, R., Hastings, T., and H. Lewis, «Internet Printing Protocol (IPP): The ’ippget’ Delivery Method for Event Notifications», RFC 3996, DOI 10.17487/RFC3996,
March 2005, <http://www.rfc-editor.org/info/rfc3996>.

[RFC3998] Kugler, C., Lewis, H., and T. Hastings, Ed., «Internet Printing Protocol (IPP): Job and Printer Administrative Operations», RFC 3998, DOI 10.17487/RFC3998, March 2005,
<http://www.rfc-editor.org/info/rfc3998>.

[RFC5051] Crispin, M., «i;unicode-casemap — Simple Unicode Collation Algorithm», RFC 5051, DOI 10.17487/RFC5051, October 2007,
<http://www.rfc-editor.org/info/rfc5051>.

[RFC5234] Crocker, D., Ed., and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.

[RFC5646] Phillips, A., Ed., and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009,
<http://www.rfc-editor.org/info/rfc5646>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.

[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.

[RFC7472] McDonald, I. and M. Sweet, «Internet Printing Protocol (IPP) over HTTPS Transport Binding and the ’ipps’ URI Scheme», RFC 7472, DOI 10.17487/RFC7472, March 2015,
<http://www.rfc-editor.org/info/rfc7472>.

[RFC7612] Fleming, P. and I. McDonald, «Lightweight Directory Access Protocol (LDAP): Schema for Printer Services», RFC 7612, DOI 10.17487/RFC7612, June 2015,
<http://www.rfc-editor.org/info/rfc7612>.

[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, «HTTP Digest Access Authentication», RFC 7616, DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>.

[RFC7617] Reschke, J., «The ’Basic’ HTTP Authentication Scheme», RFC 7617, DOI 10.17487/RFC7617, September 2015,
<http://www.rfc-editor.org/info/rfc7617>.

[RFC8010] Sweet, M. and I. McDonald, «Internet Printing Protocol/1.1: Encoding and Transport», RFC 8010, DOI 10.17487/RFC8010, January 2017,
<http://www.rfc-editor.org/info/rfc8010>.

11.2. Информационные ссылки

[HTPP] Barnett, J., Carter, K., and R. deBry, «Internet Print Protocol Proposal: HTPP — Hypertext Print Protocol (HTPP/1.0 Initial Draft)», October 1996,
<ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz>.

[IANA-CS] IANA, «Registry of Coded Character Sets», <http://www.iana.org/assignments/character-sets/>.

[IANA-MT] IANA, «Media Types», <http://www.iana.org/assignments/media-types/>.

[IANA-PEN] IANA, «Private Enterprise Numbers», <http://www.iana.org/assignments/enterprise-numbers/>.

[ISO32000] «Document management — Portable document format — Part 1: PDF 1.7», July 2008, <http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf>.

[LDPA] Isaacson, S., Taylor, D., MacKay, M., Zehler, P., Hastings, T., and C. Manros, «LDPA — Lightweight Document Printing Application», Proposed Internet-Draft,
October 1996, <ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz>.

[P1387.4] Kirk, M., «POSIX Systems Administration — Part 4: Printing Interfaces, POSIX 1387.4 D8», 1998.

[PSIS] Herriot, R., Ed., «X/Open: A Printing System Interoperability Specification (PSIS)», August 1995.

[PWG-IPP-WG]
IEEE-ISTO Printer Working Group, «Internet Printing Protocol Workgroup», <http://www.pwg.org/ipp>.

[RFC959] Postel, J. and J. Reynolds, «File Transfer Protocol», STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,

<http://www.rfc-editor.org/info/rfc959>.

[RFC1179] McLaughlin, L., «Line printer daemon protocol», RFC 1179, DOI 10.17487/RFC1179, August 1990,
<http://www.rfc-editor.org/info/rfc1179>.

[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, «Uniform Resource Locators (URL)», RFC 1738, DOI 10.17487/RFC1738,
December 1994, <http://www.rfc-editor.org/info/rfc1738>.

[RFC2565] Herriot, R., Ed., Butler, S., Moore, P., and R. Turner, «Internet Printing Protocol/1.0: Encoding and Transport», RFC 2565, DOI 10.17487/RFC2565, April 1999,
<http://www.rfc-editor.org/info/rfc2565>.

[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, «Internet Printing Protocol/1.0: Model and Semantics», RFC 2566, DOI 10.17487/RFC2566, April 1999,
<http://www.rfc-editor.org/info/rfc2566>.

[RFC2567] Wright, F., «Design Goals for an Internet Printing Protocol», RFC 2567, DOI 10.17487/RFC2567, April 1999,
<http://www.rfc-editor.org/info/rfc2567>.

[RFC2568] Zilles, S., «Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol», RFC 2568, DOI 10.17487/RFC2568, April 1999,
<http://www.rfc-editor.org/info/rfc2568>.

[RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. Martin, «Mapping between LPD and IPP Protocols», RFC 2569, DOI 10.17487/RFC2569, April 1999,
<http://www.rfc-editor.org/info/rfc2569>.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>.

[RFC2978] Freed, N. and J. Postel, «IANA Charset Registration Procedures», BCP 19, RFC 2978, DOI 10.17487/RFC2978,
October 2000, <http://www.rfc-editor.org/info/rfc2978>.

[RFC3239] Kugler, C., Lewis, H., and T. Hastings, «Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations», RFC 3239, DOI 10.17487/RFC3239, February 2002,
<http://www.rfc-editor.org/info/rfc3239>.

[RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, «Internet Printing Protocol (IPP): Requirements for IPP Notifications», RFC 3997, DOI 10.17487/RFC3997,
March 2005, <http://www.rfc-editor.org/info/rfc3997>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, «A Universally Unique IDentifier (UUID) URN Namespace», RFC 4122, DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.

[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, «The ’mailto’ URI Scheme», RFC 6068, DOI 10.17487/RFC6068, October 2010,
<http://www.rfc-editor.org/info/rfc6068>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

[SWP] Moore, P. and S. Butler, «Simple Web Printing (SWP/1.0)», May 1997, <ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf>.

Приложение А. Форматы для заявок на регистрацию IPP

Чтобы предложить расширение IPP для регистрации, заявитель должен подать заявку в IANA по электронной почте на «iana@iana.org» или заполнив соответствующую форму на веб-страницах IANA (http://www.iana.org). ). В этом разделе указана необходимая информация и форматы для предложения регистрации расширений IPP, как указано в разделе 7 для:

атрибуты
значения атрибута type2 «ключевое слово»
type2 ’enum’ значения атрибутов
операции
значения кода состояния

A.1. Регистрация атрибутов

Тип регистрации: атрибут

Предлагаемое ключевое слово для этого атрибута:

Типы атрибутов (Описание документа, Статус документа, Шаблон документа, Уведомления о событиях, Описание задания, Состояние задания, Шаблон задания, Операция, Описание принтера, Состояние принтера, Описание подписки, Состояние подписки, Шаблон подписки):

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

Объект (документ, задание, принтер, подписка и т. Д., Если он привязан к объекту):

Синтаксис (ы) атрибутов (включая «1setOf» и диапазон; см. Раздел 5.2):

Если синтаксис атрибута — это «ключевое слово» или «enum», это тип1 или тип2?

Если это атрибут принтера, МОЖЕТ ли возвращаемое значение зависеть от «формата документа»? (См. Раздел 7.2.)

Если это атрибут шаблона задания, как его спецификация зависит от значения атрибута «обработка нескольких документов»?

Спецификация этого атрибута (следуйте стилю раздела 5.2):

Имя заявителя:

Адрес электронной почты заявителя:

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

А.2. Регистрация значения атрибута type2 ’keyword’

Тип регистрации: значение атрибута ключевого слова type2 Имя атрибута, к которому должна быть добавлена эта спецификация ключевого слова:

Предлагаемое имя ключевого слова для этого значения ключевого слова:

Задание значения этого ключевого слова (следуйте стилю раздела 5.1.4):

Имя заявителя:

Адрес электронной почты заявителя:

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

А.3. Регистрация значения атрибута type2 ’enum’

Тип регистрации: значение атрибута перечисления type2 Имя атрибута, к которому должна быть добавлена эта спецификация перечисления:

Ключевое слово символическое имя этого значения перечисления:

Числовое значение (назначается назначенным экспертом IPP по согласованию с IANA):

Спецификация этого значения перечисления (следуйте стилю раздела 5.1.5):

Имя заявителя:

Адрес электронной почты заявителя:

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

А.4. Регистрация операций

Тип регистрации: операция

Предлагаемое название этой операции:

Числовое значение «идентификатор операции» в соответствии с разделом 5.4.15 (назначается назначенным экспертом IPP в консультации с IANA):

Цель объекта (документ, задание, принтер, подписка и т. Д., Над которыми выполняется операция):

Спецификация этой операции (следуйте стилю раздела 4):

Имя заявителя:

Адрес электронной почты заявителя:

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

А.5. Регистрация кода состояния

Тип регистрации: код статуса. Ключевое слово, символическое название этого кода статуса:

Числовое значение (назначается назначенным экспертом IPP по согласованию с IANA):

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

Спецификация этого кода состояния (следуйте стилю Приложения B):

Имя заявителя:

Адрес электронной почты заявителя:

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

Приложение B. Значения кода состояния и рекомендуемые сообщения кода состояния

В этом разделе определяются ключевые слова перечисляемых кодов состояний (status-code enum keywords) и значения, которые используются для предоставления семантической информации о результатах запроса операции. Каждый ответ операции ДОЛЖЕН включать код состояния (status-code). Ответ МОЖЕТ также содержать сообщение о состоянии (status message), которое содержит краткое текстовое описание состояния (description of the status). Код состояния предназначен для использования автоматами, а сообщение о статусе предназначено для конечного пользователя.

Префикс статуса ключевого слова (prefix of the status keyword) определяет класс ответа следующим образом:

«informational» — информационный — запрос получен, продолжение процесса
«successful» — успешный — действие было успешно принято, понято и одобрено
«redirection» — перенаправление — для выполнения запроса предпринимаются дальнейшие действия
«client-error» — ошибка клиента — запрос содержит неверный синтаксис или не может быть выполнен
«server-error» — ошибка сервера — объекту IPP не удалось выполнить явно допустимый запрос

Как и в случае перечислений «type2«, значения кода состояния IPP являются расширяемыми. Независимо от того, распознаны ли все значения кода состояния, Клиенты IPP ДОЛЖНЫ понимать класс любого кода состояния, как указано в префиксе, и рассматривать любой нераспознанный ответ как эквивалент первого кода состояния этого класса, за исключением что нераспознанный ответ НЕ ДОЛЖЕН кэшироваться. Например, если клиент получил нераспознанный код состояния «client-error-xxx-yyy», он может с уверенностью предположить, что с его запросом что-то не так, и обработать ответ так, как если бы он получил статус кода «client-error-bad-request». Имя «enum» (перечисления) — это рекомендуемое сообщение о статусе для английского языка США.

См. [PWG5100.19] для рекомендаций по представлению сообщений о состоянии конечным пользователям.

Значения кода состояния ответа находятся в диапазоне от 0x0000 до 0x7fff. Диапазоны значений для каждого класса кода состояния следующие:

«successful» — «успешно» — от 0x0000 до 0x00ff
«informational» — «информационный» — от 0x0100 до 0x01ff
«redirection» — «перенаправление» — от 0x0300 до 0x03ff
«client-error» — «ошибка клиента» — от 0x0400 до 0x04ff
«server-error» «ошибка сервера» — от 0x0500 до 0x05ff

Верхняя половина (128 значений) каждого диапазона (от 0x0n80 до 0x0nff, для n = 0 до 5) зарезервирована для использования поставщиком в каждом классе кода состояния. Значения от 0x0600 до 0x7fff зарезервированы для последующего присвоения документами стандартов «Standards Track» и НЕ ДОЛЖНЫ использоваться.

B.1. Значения кода состояния (Status-Code)

Каждый код состояния описан ниже. Приложение B.2 содержит таблицу, которая указывает, какие значения кода состояния применяются к каким операциям. Руководства разработчика [RFC3196] [PWG5100.19] содержат руководство по обработке атрибутов IPP для всех операций, включая значения кода состояния.

B.1.1. «Информационные» значения кодов состояния

Этот класс значений кода состояния указывает предварительный ответ и должен использоваться только в информационных целях.

В этом документе не определены значения для этого класса значений кода состояния.

B.1.2. «Успешные» значения кодов состояния

Этот класс значений кода состояния указывает, что запрос Клиента был успешно принят, понят и одобрен.

B.1.2.1. successful-ok (0x0000) — (Успешно-хорошо)

Запрос выполнен успешно, и никакие атрибуты запроса не были заменены или проигнорированы. В случае ответа на запрос на «создание задания» (Job Creation), код состояния «successful-ok» указывает, что запрос был успешно получен и проверен, и что объект задания (Job) был создан; это не означает, что задание было обработано. Переход объекта задания (Job) в состояние «completed» (завершено) является единственным показателем того, что задание было распечатано.

B.1.2.2. successful-ok-ignored-or-substituted-attributes (0x0001) — (Успешно-хорошо-игнорируемые-или-замещенные-атрибуты)

Запрос выполнен успешно, но некоторые предоставленные атрибуты (1) были проигнорированы или (2) неподдерживаемые значения были заменены поддерживаемыми значениями или были проигнорированы, чтобы выполнить операцию, не отклоняя ее. Неподдерживаемые атрибуты, синтаксисы атрибутов или значения ДОЛЖНЫ быть возвращены в группе «Unsupported attributes» (Неподдерживаемые атрибуты) ответа для всех операций. Из этого правила есть исключение для операций запроса Get-Printer-Attributes, Get-Jobs и Get-Job-Attributes только для атрибута операции «requested-attributes» (требуемые-атрибуты). Когда предоставленные значения атрибута операции «requested-attributes» (запрашиваемые атрибуты) запрашивают атрибуты, которые не поддерживаются, объект IPP ДОЛЖЕН вернуть атрибут операции «requested-attributes» (запрашиваемые атрибуты) в группе ответа «Unsupported Attributes» (неподдерживаемые атрибуты) (только с неподдерживаемыми значениями). См. Разделы 4.1.7 и 4.2.1.2.

B.1.2.3. successful-ok-conflicting-attributes (0x0002) — (Успешно-хорошо-конфликтующие-атрибуты)

Запрос выполнен успешно, но некоторые предоставленные значения атрибута конфликтуют со значениями других предоставленных атрибутов. Либо (1) эти конфликтующие значения были заменены (поддерживаемыми) значениями, либо (2) атрибуты были удалены, чтобы обработать задание, не отклоняя его. Атрибуты или значения, которые конфликтуют с другими атрибутами и были заменены или проигнорированы, ДОЛЖНЫ быть возвращены в группу «Unsupported Attributes» (Неподдерживаемые атрибуты) ответа для всех операций, предоставленных Клиентом. См. Разделы 4.1.7 и 4.2.1.2.

B.1.3. «Перенаправленные» значения кодов состояния

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

В этом документе не определены значения для этого класса значений кода состояния.

B.1.4. «Ошибки клиента» значения кодов состояния

Этот класс значений кода состояния предназначен для случаев, когда Клиент, похоже, допустил ошибку. Объекту IPP СЛЕДУЕТ возвращать сообщение, содержащее объяснение ситуации ошибки и является ли это временным или постоянным условием.

B.1.4.1. client-error-bad-request (0x0400) — ошибка клиента плохой запрос

Запрос не может быть понят объектом IPP из-за неправильного синтаксиса (например, значения атрибута фиксированной длины, длина которого не соответствует предписанной длине для этого атрибута — см. Руководства разработчика [RFC3196] [PWG5100.19]) , Приложение IPP НЕ ДОЛЖНО повторять запрос без изменений.

B.1.4.2. client-error-forbidden (0x0401) — ошибка клиента запрещено

Объект IPP понял запрос, но отказывается его выполнить. Дополнительная информация аутентификации или учетные данные авторизации не помогут, и запрос НЕ СЛЕДУЕТ повторять. Этот код состояния обычно используется, когда объект IPP не хочет точно указывать, почему запрос был отклонен или когда другой ответ не применим.

B.1.4.3. client-error-not-authenticated (0x0402) — ошибка клиента не аутентифицировано

Запрос требует аутентификации пользователя. Клиент IPP может повторить запрос с подходящей информацией для аутентификации. Если в запрос уже включена информация об аутентификации, то этот код состояния указывает, что в авторизации было отказано для этих учетных данных. Если этот ответ содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации хотя бы один раз, тогда ответное сообщение может содержать соответствующую диагностическую информацию. Этот код состояния показывает больше информации, чем «client-error-forbidden».

B.1.4.4. client-error-not-authorized (0x0403) — ошибка клиента не авторизовано

Запрашивающая сторона не авторизована для выполнения запроса. Дополнительная информация аутентификации или учетные данные авторизации не помогут, и запрос НЕ СЛЕДУЕТ повторять. Этот код состояния используется, когда объект IPP хочет показать, что информация аутентификации понятна; однако запрашивающая сторона явно не авторизована для выполнения запроса. Этот код состояния показывает больше информации, чем «client-error-forbidden» и «client-error-not-authenticated».

B.1.4.5. client-error-not-possible (0x0404) — ошибка клиента невозможно

Этот код состояния используется, когда осуществляется запрос на то, что не может произойти. Например, может возникнуть запрос на отмену задания (cancel a Job), которое уже было отменено или отменено системой. Клиент IPP НЕ ДОЛЖЕН повторять запрос.

B.1.4.6. client-error-timeout (0x0405) — ошибка клиента перерыв

Клиент не выдал запрос в течение времени, когда объект IPP был готов ждать. Например, Клиент выполнил операцию «Create-Job«, а затем, через длительный период времени, выполнил операцию «Send-Document«; этот код состояния ошибки был возвращен в ответ на запрос «Send-Document» (см. раздел 4.3.1). Возможно, объект IPP был вынужден очистить ресурсы, которые удерживались для ожидающих дополнительных документов. Объект IPP был вынужден закрыть задание, так как клиент занял слишком много времени. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.

B.1.4.7. client-error-not-found (0x0406) — ошибка клиента не найдено

Объект IPP не нашел ничего соответствующего URI запроса. Не указывается, является ли состояние временным или постоянным. Например, клиент со старой ссылкой на задание (URI) пытается отменить задание; тем не менее, тем временем задание могло быть завершено, и вся его запись на принтере была удалена. Этот код состояния «client-error-not-found» возвращается, указывая, что указанное задание не может быть найдено. Этот код состояния ошибки также используется, когда клиент предоставляет URI в качестве ссылки на данные документа в операции «Print-URI» или «Send-URI«, но документ не может быть найден.

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

B.1.4.8. client-error-gone (0x0407) — ошибка клиента ушло израсходовано

Запрашиваемый объект больше не доступен, а адрес пересылки неизвестен. Это условие следует считать постоянным. Клиенты с возможностями редактирования ссылок должны удалять ссылки на URI запроса после одобрения пользователя. Если объект IPP не знает или не имеет возможности определить, является ли условие постоянным, следует использовать код состояния «client-error-not-found».

Этот ответ в первую очередь предназначен для оказания помощи в обслуживании, уведомляя получателя о том, что ресурс намеренно недоступен и что администратор объекта IPP желает удалить удаленные ссылки на этот ресурс. Нет необходимости отмечать все постоянно недоступные ресурсы как «gone» (ушедшие) или сохранять отметку в течение любого промежутка времени — это оставлено на усмотрение Администратора объекта IPP и / или реализации Принтера.

B.1.4.9. client-error-request-entity-too-large (0x0408) — ошибка клиента слишком большой объект запроса

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

B.1.4.10. client-error-request-value-too-long (0x0409) — ошибка клиента значение запроса слишком длинное

Объект IPP отказывается обслуживать запрос, поскольку один или несколько предоставленных Клиентом атрибутов имеют значение переменной длины, которое превышает максимальную длину, указанную для этого атрибута. Объект IPP может не иметь достаточных ресурсов (памяти, буферов и т. д.) Для обработки (даже временно), интерпретации и/или игнорирования значения, превышающего максимальную длину. Другое использование этого кода ошибки — когда объект IPP поддерживает обработку большого значения, которое меньше максимальной длины, но во время обработки запроса в целом объект может передать значение в некоторый другой системный компонент, который является не в состоянии принять большое значение. Для получения дополнительной информации см. Руководства разработчика [RFC3196] [PWG5100.19].

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

B.1.4.11. client-error-document-format-not-supported (0x040a) — ошибка клиента формат документа не поддерживается

Объект IPP отказывается обслуживать запрос, поскольку данные документа имеют формат, указанный в атрибуте операции «document-format» (формат документа), который не поддерживается принтером. Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity«. Принтер ДОЛЖЕН вернуть этот код состояния, даже если есть другие атрибуты шаблона задания, которые также не поддерживаются, поскольку эта ошибка представляет собой большую проблему, чем с атрибутами шаблона задания. См. Разделы 4.1.6.1, 4.1.7 и 4.2.1.1.

B.1.4.12. client-error-attributes-or-values-not-supported (0x040b) — ошибка клиента атрибуты или значения не поддерживаются

В запросе на создание задания (Job Creation), если принтер не поддерживает один или несколько атрибутов, синтаксисов атрибутов или значений атрибутов, предоставленных в запросе, и клиент предоставил атрибут операции «ipp-attribute-fidelity» со значением «true», принтер ДОЛЖЕН вернуть этот код состояния. Принтер ДОЛЖЕН также вернуть в группу Unsupported Attributes (Неподдерживаемые атрибуты) все атрибуты и/или значения, предоставленные Клиентом, которые не поддерживаются. См. Раздел 4.1.7. Например, если в запросе указан носитель «iso-a4«, но этот тип носителя не поддерживается принтером, или если клиент предоставляет атрибут шаблона задания (Job Template), а сам атрибут даже не поддерживается принтером. Если атрибут «ipp-attribute-fidelity» имеет значение «false», принтер ДОЛЖЕН игнорировать или заменять значения для неподдерживаемых атрибутов и значений шаблона задания, а не отклонять запрос и возвращать этот код состояния.

Для любой операции, когда Клиент запрашивает атрибуты (такие как операция Get-Jobs, Get-Printer-Attributes или Get-Job-Attributes), если объект IPP не поддерживает один или несколько запрошенных атрибутов, объект IPP просто игнорирует неподдерживаемые запрошенные атрибуты и обрабатывает запрос, как если бы они не были предоставлены, вместо того, чтобы возвращать этот код состояния. В этом случае объект IPP ДОЛЖЕН возвращать код состояния «success-ok-ignore-or-replace-attribute» и ДОЛЖЕН возвращать неподдерживаемые атрибуты в качестве значений атрибута операции «requested-attributes» (требуемые атрибуты)в группе Unsupported Attributes (Неподдерживаемые атрибуты) (см. Приложение B.1.2.2).

B.1.4.13. client-error-uri-scheme-not-supported (0x040c) — ошибка клиента uri-схема не поддерживается

Схема предоставленного Клиентом URI в операции Print-URI или операции Send-URI не поддерживается. См. Разделы 4.1.6.1 и 4.1.7.

B.1.4.14. client-error-charset-not-supported (0x040d) — ошибка клиента кодировка не поддерживается

Для любой операции, если Принтер IPP не поддерживает кодировку, предоставленную Клиентом в атрибуте операции «attributes-charset», Принтер ДОЛЖЕН отклонить операцию и вернуть этот код состояния и любые атрибуты «text» или «name» используя кодировку utf-8 (Раздел 4.1.4.1). См. Разделы 4.1.6.1 и 4.1.7.

B.1.4.15. client-error-conflicting-attributes (0x040e) — ошибка клиента конфликтующие атрибуты

Запрос отклонен, поскольку некоторые значения атрибутов конфликтуют со значениями других атрибутов, которые этот документ не разрешает заменять или игнорировать. Принтер ДОЛЖЕН также возвращать в группе Unsupported Attributes (Неподдерживаемые атрибуты) конфликтующие атрибуты, предоставленные Клиентом. См. Разделы 4.1.7 и 4.2.1.2.

B.1.4.16. client-error-compression-not-supported (0x040f) — ошибка клиента сжатие не поддерживается

Объект IPP отказывается обслуживать запрос, поскольку данные документа, как указано в атрибуте операции «compression», сжимаются способом, который не поддерживается принтером. Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity». Принтер ДОЛЖЕН вернуть этот код состояния, даже если есть другие атрибуты Job Template (шаблона работы), которые также не поддерживаются, поскольку эта ошибка представляет собой большую проблему, чем с атрибутами Job Template (шаблона работы). Смотри раздел 4.1.6.1, раздел 4.1.7 и раздел 4.2.1.1.

B.1.4.17. client-error-compression-error (0x0410) — ошибка клиента ошибка сжатия

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

B.1.4.18. client-error-document-format-error (0x0411) — ошибка клиента ошибка формата документа

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

B.1.4.19. client-error-document-access-error (0x0412) — ошибка клиента ошибка доступа

Объект IPP отказывается обслуживать запрос «Print-URI» или «Send-URI«, поскольку принтер обнаружил ошибку доступа при попытке проверить доступность или доступ к данным Document (документа), указанным в атрибуте операции «document-uri». Принтер МОЖЕТ также возвращать определенный код ошибки доступа к Document (документу), используя атрибут операции «document-access-error» (см. Раздел 4.1.6.4). Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity». Принтер ДОЛЖЕН вернуть этот код состояния, даже если есть атрибуты Job Template (шаблона работы), которые также не поддерживаются, поскольку эта ошибка представляет собой большую проблему, чем с атрибутами Job Template (шаблона работы). Смотри раздел 4.1.6.1 и раздел 4.1.7.

B.1.5. «Ошибки сервера» значения кодов состояния

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

B.1.5.1. server-error-internal-error (0x0500) — ошибка сервера внутренняя ошибка

Объект IPP обнаружил непредвиденное состояние, которое не позволило ему выполнить запрос. Этот код состояния ошибки отличается от «server-error-temporary-error» тем, что он подразумевает более постоянный тип внутренней ошибки. Он также отличается от «server-error-device-error» тем, что предполагает непредвиденное состояние (в отличие от проблемы с застреванием бумаги или отсутствием тонера, которая нежелательна, но ожидается). Этот код ошибки указывает, что, вероятно, требуется вмешательство знающего человека.

B.1.5.2. server-error-operation-not-supported (0x0501) — ошибка сервера операция не поддерживается

Объект IPP не поддерживает функции, необходимые для выполнения запроса. Это соответствующий ответ, когда объект IPP не распознает операцию или не способен ее поддержать. Смотри раздел 4.1.6.1 и раздел 4.1.7.

B.1.5.3. server-error-service-unavailable (0x0502) — ошибка сервера сервис недоступен

В настоящее время объект IPP не может обработать запрос из-за временной перегрузки или из-за обслуживания объекта IPP. Подразумевается, что это временное состояние, которое будет смягчено после некоторой задержки. Если известно, длительность задержки может быть указана в сообщении. Если задержка не указана, приложение IPP должно обработать ответ так же, как и для ответа «server-error-temporary-error». Если условие является более постоянным, можно использовать код состояния ошибки «client-error-gone» или «client-error-not-found».

B.1.5.4. server-error-version-not-supported (0x0503) — ошибка сервера версии не поддерживается

Объект IPP не поддерживает или отказывается поддерживать версию IPP, указанную в качестве значения параметра операции «version-number» (номер версии) в запросе. Объект IPP указывает, что он не может или не желает завершить запрос, используя тот же основной и младший номер версии, который указан в запросе, за исключением этого сообщения об ошибке. Ответ об ошибке ДОЛЖЕН содержать атрибут «status-message» (статус-сообщение) (см. Раздел 4.1.6.2), описывающий, почему эта версия не поддерживается и какие другие версии поддерживаются этим объектом IPP. Смотри раздел 4.1.6.1, раздел 4.1.7 и раздел 4.1.8.

Ответ об ошибке ДОЛЖЕН идентифицировать в параметре операции «version-number» (номер версии) ближайший номер версии, который поддерживает объект IPP. Например, если Клиент предоставляет версию «1.0», а объект IPP/1.1 поддерживает версию «1.0», то он отвечает версией «1.0» во всех ответах на такой запрос. Если объект IPP/1.1 не поддерживает версию «1.0», он должен принять запрос и ответить версией «1.1» или может отклонить запрос и ответить этим кодом ошибки и версией «1.1». Если Клиент предоставляет версию «1.2», объект IPP/1.1 должен принять запрос и вернуть версию «1.1» или может отклонить запрос и ответить этим кодом ошибки и версией «1.1». Смотри раздел 4.1.8 и раздел 5.3.14.

B.1.5.5. server-error-device-error (0x0504) — ошибка сервера ошибка оборудования

Ошибка принтера, например застревание бумаги, возникает, когда объект IPP обрабатывает операцию печати (Print) или (send) отправки. Ответ содержит истинное состояние задания (значения атрибутов «job-state» (состояние-задания) и «job-state-reasons» (причины-состояния-задания)). Дополнительная информация может быть возвращена в ДОПОЛНИТЕЛЬНОМ значении атрибута «job-state-message» или в ДОПОЛНИТЕЛЬНОМ сообщении о состоянии, которое более подробно описывает ошибку. Этот код состояния ошибки возвращается только в тех случаях, когда Printer (Принтер) не может принять запрос на создание задания из-за такой ошибки устройства. Например, если принтер не может спулировать (spool) и может принимать только одно задание за раз, причина, по которой он может отклонить запрос на создание задания, заключается в том, что в принтере в настоящий момент застряла бумага. Однако во многих случаях, когда принтер может принять запрос, даже если в принтере есть какое-то условие ошибки, будет возвращен код состояния «successful-ok». В таком случае Клиент будет просматривать возвращенные атрибуты объекта Job или позже запрашивать Printer (принтер), чтобы определить его состояние и причины состояния.

B.1.5.6. server-error-temporary-error (0x0505) — ошибка сервера временная ошибка

Временная ошибка, такая как ошибка записи в буфере, переполнение памяти (то есть данные документа превышают память принтера) или состояние переполнения диска, происходит, когда принтер IPP обрабатывает операцию. Клиент МОЖЕТ повторить немодифицированный запрос еще раз в какой-то более поздний момент времени, ожидая, что условие временной внутренней ошибки было очищено. В качестве альтернативы, в качестве варианта реализации, принтер МОЖЕТ отложить ответ до тех пор, пока временное условие не будет очищено, чтобы не было возвращено никакой ошибки.

B.1.5.7. server-error-not-accepting-jobs (0x0506) — ошибка сервера нет принятых заданий

Это временная ошибка, указывающая на то, что Printer (Принтер) в настоящее время не принимает Jobs (Задания), потому что Администратор установил значение атрибута «printer-is-accepting-jobs» в значение «false» (ложь) (что выходит за рамки данного документа IPP/1.1.).

B.1.5.8. server-error-busy (0x0507) — ошибка сервера занято

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

B.1.5.9. server-error-job-canceled (0x0508) — ошибка сервера задание отменено

Это ошибка, указывающая на то, что задание было отменено оператором или системой, когда клиент передавал данные на принтер IPP. Если атрибут «job-id» (идентификатор задания) и атрибут «job-uri» (uri задания) были созданы, то они возвращаются в ответе Print-Job, Send-Document или Send-URI как обычно; в противном случае в ответе не возвращаются атрибуты «job-id» и «job-uri».

B.1.5.10. server-error-multiple-document-jobs-not-supported (0x0509) — ошибка сервера несколько заданий документа не поддерживается

Объект IPP не поддерживает несколько документов на одно задание, и клиент попытался предоставить данные документа с помощью второй операции Send-Document или Send-URI.

B.2. Значения кода состояния для операций IPP

PJ = Print-Job (Задание на печать)
PU = Print-URI (Печать URI)
CJ = Create-Job (Создать задание)
SD = Send-Document (Отправить документ)
SU = Send-URI (Отправить URI)
V = Validate-Job (Подтвердить задание)
GA = Get-Job-Attributes and Get-Printer-Attributes (Получить атрибуты задания и Получить атрибуты принтера)
GJ = Get-Jobs (Получить задание)
C = Cancel-Job (Отменить задание)

Значение кода состояния	Операция протокола IPP	Описание	Определено в …
PJ	Print-Job	Задание на печать	Раздел
PU	Print-URI	Печать URI	Раздел
CJ	Create-Job	Создать задание	Раздел
SD	Send-Document	Отправить документ	Раздел
SU	Send-URI	Отправить URI	Раздел
V	Validate-Job	Подтвердить задание	Раздел
GA	Get-Job-Attributes and Get-Printer-Attributes	Получить атрибуты задания и Получить атрибуты принтера	Раздел
GJ	Get-Jobs	Получить задание	Раздел
C	Cancel-Job	Отменить задание	Раздел

Таблица

Значения кода состояния для операций IPP - набор 1 — Значения кода состояния для операций IPP — набор 1

HJ = Hold-Job (Задержать задание)
RJ = Release-Job (Выпустить задание)
RS = Restart-Job (Перезагрузить задание)
PP = Pause-Printer (Пауза Принтер)
RP = Resume-Printer (Возобновить принтер)
PJ = Purge-Jobs (Чистка Заданий)

Значение кода состояния	Операция протокола IPP	Описание	Определено в …
HJ	Hold-Job	Задержать задание	Раздел
RJ	Release-Job	Выпустить задание	Раздел
RS	Restart-Job	Перезагрузить задание	Раздел
PP	Pause-Printer	Приостановить Принтер	Раздел
RP	Resume-Printer	Возобновить принтер	Раздел
PJ	Purge-Jobs	Чистка Заданий	Раздел

Таблица

Значения кода состояния для операций IPP - набор 2 — Значения кода состояния для операций IPP — набор 2

Приложение C. Обработка атрибутов IPP

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

что реализация способна реализовать (то есть, что поддерживает принтер), или
инструкции, встроенные в сами данные документа.

В следующих разделах описывается, как эти два типа конфликтов обрабатываются в модели IPP.

C.1. Точность

Если существует конфликт между тем, что запрашивает Клиент, и тем, что поддерживает Принтер, Клиент может запросить один из двух возможных механизмов обработки конфликтов:

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

В первом случае Клиент указывает принтеру следующее: «Распечатайте задание точно так, как указано, без каких-либо исключений, и если это невозможно, даже не печатайте задание вообще». Во втором случае Клиент указывает принтеру следующее: «Более важно убедиться, что задание напечатано, а не обработано точно так, как указано; просто убедитесь, что задание напечатано, даже если для некоторых атрибутов, предоставленных клиентом, требуется быть изменены или проигнорированы.

Модель IPP учитывает эту ситуацию, вводя атрибут «ipp-attribute-fidelity».

В запросе на создание задания «ipp-attribute-fidelity» является атрибутом логической операции, который МОЖЕТ быть предоставлен клиентом. Значение «true» указывает, что требуется полная точность предоставленных клиентом атрибутов и значений шаблона работы. Клиент требует, чтобы Задание было распечатано точно так, как указано, и, если это невозможно, то задание ДОЛЖНО быть отклонено, а не обработано неправильно. Значение ‘false’ указывает, что разумная попытка распечатать задание является приемлемой. Если принтер не поддерживает некоторые из предоставленных клиентом атрибутов или значений шаблона работы, принтер ДОЛЖЕН игнорировать или заменять их поддерживаемыми значениями. Принтер может заменить значение по умолчанию, связанное с этим атрибутом, или использовать другое поддерживаемое значение, аналогичное неподдерживаемому запрошенному значению. Например, если клиент предоставляет значение «media» «na_letter_8.5x11in», принтер может заменить «iso_a4_210x297mm» вместо значения по умолчанию «na_personal_3.625×6.5in». Если Клиент не предоставляет атрибут «ipp-attribute-fidelity», Принтер принимает значение «false».

Каждая реализация принтера ДОЛЖНА поддерживать оба типа печати «верности» (то есть, указывает ли клиент значение «true» или «false»):

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

Поскольку клиент всегда может запросить принтер, чтобы выяснить, что именно и что не поддерживается, «ipp-attribute-fidelity» со значением «false» полезен, когда:

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

С.2. Переопределение языка описания страниц (PDL)

Если существует конфликт между значением атрибута шаблона задания IPP и соответствующей инструкцией в данных документа, значение атрибута IPP ДОЛЖНО иметь приоритет над инструкцией документа. Рассмотрим случай, когда ранее отформатированный файл данных документа отправляется на принтер IPP. В этом случае, если Клиент предоставляет какие-либо атрибуты во время отправки Задания, Клиент желает, чтобы эти атрибуты переопределяли встроенные инструкции. Рассмотрим случай, когда ранее отформатированный Документ содержит встроенные команды загрузки медиа-файлов iso-a4. Однако Документ передается Конечному пользователю, который имеет доступ только к принтеру с загруженным носителем. Этот конечный пользователь, скорее всего, захочет отправить этот документ на принтер IPP с атрибутом «шаблон» задания «media», установленным как «na-letter». Атрибуты, предоставляемые во время отправки задания, должны иметь приоритет над встроенными инструкциями PDL. Однако до тех пор, пока компании, которые предоставляют интерпретаторы данных Document, не позволят внешним атрибутам IPP иметь приоритет над встроенными инструкциями по производству заданий, принтер может не поддерживать семантику, согласно которой атрибуты IPP переопределяют встроенные инструкции.

Модель IPP объясняет эту ситуацию, вводя атрибут «pdl-override-support», который описывает возможности принтера по переопределению инструкций, встроенных в поток данных PDL. Значение атрибута «pdl-override-Поддерживается» настраивается средствами, выходящими за рамки этого документа IPP/1.1.

Этот НЕОБХОДИМЫЙ атрибут принтера принимает следующие значения:

’предпринято’: это значение указывает на то, что Принтер пытается сделать так, чтобы значения атрибута IPP имели приоритет над встроенными инструкциями в данных документа; однако, нет никакой гарантии.
‘не-предпринято’: это значение означает, что Принтер не предпринимает попыток сделать так, чтобы значения атрибута IPP имели приоритет над встроенными инструкциями в данных документа.

Во время обработки задания реализация, поддерживающая значение «попытки», может выполнять одно из следующих действий:

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

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

Во время обработки задания реализация, которая поддерживает значение «не предпринято», может выполнить одно из следующих действий:

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

Примечание. Атрибут «ipp-attribute-fidelity» применяется к способности принтера принимать или отклонять другие неподдерживаемые атрибуты шаблона работы. Другими словами, если для «ipp-attribute-fidelity» установлено значение «true», задание принимается тогда и только тогда, когда предоставленные клиентом атрибуты и значения шаблона задания поддерживаются принтером. Фактическое влияние этих атрибутов на обработку задания, когда данные документа содержат встроенные инструкции, зависит от способности принтера переопределять инструкции, встроенные в данные документа, в семантику атрибутов IPP. Если атрибуты данных документа могут быть переопределены (для «pdl-override-support» установлено значение «предпринято»), принтер пытается использовать атрибуты IPP при обработке задания. Если атрибуты данных документа не могут быть переопределены («pdl-override-support» установлено как «not-предпринято»), принтер не пытается переопределить встроенные инструкции данных документа с атрибутами IPP при обработке задания, и, следовательно, Атрибуты IPP могут не повлиять на обработку и вывод задания, когда соответствующая инструкция встроена в данные документа.

С.3. Использование атрибутов шаблона задания при обработке документа

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

1. Используя предоставленный клиентом атрибут «формат документа» или какой-либо другой алгоритм определения формата документа (если значение «формат документа» недостаточно конкретное), определите, были ли данные документа уже отформатированы для печати. Если данные документа были отформатированы, перейдите к шагу 2. В противном случае данные документа ДОЛЖНЫ быть отформатированы. Алгоритм обнаружения форматирования определяется реализацией и не указывается в этом документе. Форматирование данных документа использует атрибут «востребованный ориентации», чтобы определить, как отформатированные данные печати должны быть размещены на странице ввода; см. Раздел 5.2.10 для деталей.

2. Данные документа — это набор входных страниц в известном типе носителя. Атрибут «диапазон страниц» используется для выбора, как указано в разделе 5.2.7, подпоследовательности страниц в потоке печати, которые должны обрабатываться и отображаться.

3. Вход для этого шага представляет собой последовательность страниц ввода. Этот шаг контролируется атрибутом «номер-вверх». Если значение «number-up» равно N, то во время обработки входных страниц каждая N входных страниц позиционируется, как указано в разделе 5.2.9, для создания одного показа. Если данный документ не имеет больше N входных страниц, тогда завершение Impression контролируется атрибутом «обработка нескольких документов», как описано в разделе 5.2.4; когда значение этого атрибута равно «один документ» или «один документ-новый лист», для завершения показа используются входные страницы данных документа из последующих документов.

Размер (масштабирование), положение (перевод) и поворот входных страниц в Impression определяются реализацией. Обратите внимание, что во время этого процесса входные страницы можно отобразить в форме, подходящей для размещения в Impression; этот рендеринг контролируется значениями атрибутов «printer-resolution» и «print-quality», как описано в разделах 5.2.12 и 5.2.13. В случае, когда N = 1, показ почти такой же, как на входной странице; различия будут заключаться только в размере, положении и повороте входной страницы и / или в любом оформлении, таком как рамка для страницы, добавляемой реализацией.

1. Коллекция впечатлений размещается последовательно по сторонам листов материалов. Это размещение контролируется атрибутом сторон и ориентацией страницы ввода, как описано в разделе 5.2.8. Ориентация входных страниц влияет на ориентацию показа; например, если «число» равно 2, то, как правило, две книжные входные страницы становятся одним пейзажным показом. Обратите внимание, что размещение показов на носителях также контролируется атрибутом «обработка нескольких документов», как описано в разделе 5.2.4.

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

3. Когда будет создано правильное количество копий, листы носителя будут заполнены в соответствии со значениями атрибута «отделки», как описано в разделе 5.2.6. Обратите внимание, что иногда процессы завершения могут потребовать ручного вмешательства для выполнения процессов завершения на копиях, особенно на незакрепленных копиях. Этот документ позволяет выполнять любые или все этапы обработки автоматически или вручную по усмотрению принтера.

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

Этот раздел определяет общую схему для записи в службе каталогов. Реализации этой схемы определены в «Облегченном протоколе доступа к каталогам (LDAP): схема для служб печати» [RFC7612] и «IPP Everywhere» [PWG5100.14]. Служба каталогов — это средство, с помощью которого пользователи службы могут находить поставщиков услуг. В средах IPP это означает, что принтеры IPP могут быть зарегистрированы (либо автоматически, либо с помощью администратора) в качестве записей типа «Принтер» в каталоге с использованием механизма реализации, такого как атрибуты записей, поля типов записей, определенные ветви и т. Д. Каталог Клиенты могут искать или просматривать записи типа принтера. Клиенты используют службу каталогов для поиска записей на основе именования, организационных контекстов или фильтрованных поисков по значениям атрибутов записей. Например, Клиент может найти все принтеры в контексте «Локальный отдел». Аутентификация и авторизация также часто являются частью службы каталогов, так что администратор может устанавливать ограничения для конечных пользователей, чтобы они могли только находить записи, к которым у них есть определенные права доступа. Сам IPP не требует какого-либо определенного протокола службы каталогов или поставщика.

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

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

Насколько это возможно, имена атрибутов в схеме каталога и записях ДОЛЖНЫ совпадать с именами атрибутов принтера IPP, как показано.
Чтобы установить связь между службой каталогов и принтером IPP, одним из РЕКОМЕНДУЕМЫХ атрибутов записи каталога является атрибут принтера «printer-uri-support». Клиент каталога запрашивает атрибут «printer-uri-support» (или его эквивалент) в записи каталога, а затем Клиент IPP обращается к принтеру IPP, используя один из его URI. Атрибут «uri-security-Поддерживается» идентифицирует протокол (если таковой имеется), используемый для защиты канала.

Атрибуты в таблице 23 определяют общую схему для записей каталога типа Printer.

Таблица 23 - Атрибуты в записях каталога — Таблица 23 — Атрибуты в записях каталога

Подтверждения

Авторы хотели бы поблагодарить следующих лиц за их вклад в первоначальные спецификации IPP / 1.1:

Роджер де Бри (Roger deBry), Том Гастингс (Tom Hastings — оригинальный редактор RFC 2911), Роберт Херриот (Robert Herriot), Скотт Айзексон (Scott A. Isaacson), Кирк Оке (Kirk Ocke), Патрик Пауэлл (Patrick Powell) и Питер Зелер (Peter Zehler)

Адреса авторов

Michael Sweet
Apple Inc.
1 Infinite Loop
MS 111-HOMC
Cupertino, CA 95014
United States of America

Email: msweet@apple.com

Ira McDonald
High North, Inc.
PO Box 221
Grand Marais, MI 49839
United States of America

Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com

Аннотация

Оглавление

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

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

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. Атрибуты операции Запроса

«attributes-charset» (charset):

«attributes-natural-language» (naturalLanguage):

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

«attributes-charset» (charset):

«attributes-natural-language» (naturalLanguage):

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. Операции по созданию задания — Job Creation Operations

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

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

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

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

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

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

4.2.1.2. Ответ задания на печать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.6.2. Ответ на получение задания

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

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

Группы от 3 до N: атрибуты работы