Кратко

  • RFC 3510 дал службам и заданиям IPP абсолютный локатор ipp:, но прямо признал: преобразование URL задания обратно в URL создавшего его Printer не было определено.
  • Рекомендация добавить один компонент пути улучшала совместимость, однако не удостоверяла сервер, не делала имя вечным и не доказывала принятие, печать или доставку.

Строка ipp://example.com/printer/123 подталкивает к простому выводу. Число 123 — задание, а родительский путь — принтер. Достаточно удалить последний сегмент, чтобы узнать создателя. Историческая ценность RFC 3510 состоит в том, что он не позволил превратить удобную догадку в правило протокола.

Документ вышел в апреле 2003 года в Standards Track и уточнил раздел об IPP URL в RFC 2910. Он описал применимость схемы ipp:, порт 631 по умолчанию, тип application/ipp, кодирование, синтаксис и сравнение. Новых параметров URL стандарт не добавлял.

URL ipp: указывает на службу печати IPP либо на управляемый ею сетевой ресурс, например Job. Допустима только абсолютная форма. Схема связывает абстрактную модель RFC 2911 с HTTP-транспортом RFC 2910; иному транспорту понадобилась бы иная схема. Это не общее слово «печать», а точная привязка модели к переносу.

Если порт отсутствует, используется 631. При сравнении отсутствие порта эквивалентно явному :631. Без пути Request-URI становится /. Запросы и ответы имеют тип application/ipp. Эти правила устраняют расхождения между эквивалентными написаниями.

Но путь не является схемой оборудования. Несколько URL на одном узле могут обозначать независимые логические Printer. Один — физическое устройство, другой — балансирующий spooler, третий — группу устройств. Даже две очереди для разных получателей на одном аппарате могут вести себя как разные Printer.

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

С Job URL неопределённость стала явной. RFC 2911 оставил точный формат Job URI реализации. Поэтому связь между printer-uri в запросе Print-Job и job-uri в ответе тоже зависит от реализации. RFC 3510 назвал ложным прежнее утверждение, будто одного URI задания достаточно для определения Printer-создателя: обратное преобразование не было специфицировано.

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

Даже при соблюдении соглашения надёжнее сохранить исходный обмен: отправленный printer-uri, полученный job-uri, удостоверенную личность сервера, ответ и время. Позднее удаление части строки — более слабое свидетельство. Путь может быть переписан прокси или повторно использован, а транзакция показывает, кто и когда выдал имя.

У имени есть срок. RFC 3510 считает Job URL действительным и осмысленным до завершения задания и, возможно, в течение необязательного периода хранения, выбранного реализацией. Это не вечный архивный идентификатор. Исчезновение ссылки может означать очистку объекта после завершения, а не отсутствие задания.

Раздел безопасности отделяет синтаксис от личности. Поддельный IPP URL может отправить конфиденциальный документ вредоносной службе; защитой служит аутентификация сервера. Настоящий URL может использовать неуполномоченный клиент; нужны аутентификация и авторизация клиента.

Шлюз IPP–LPD создаёт ещё больший разрыв. RFC предупреждает, что он способен незаметно ослабить безопасность IPP, а практической защиты на клиенте нет. Администраторам предлагается избегать такой конфигурации. Удостоверение ближней стороны не доказывает свойства следующего участка.

Сам URL не содержит параметров требуемого способа аутентификации клиента или механизма безопасности. Их могут сообщить discovery или directory. Рабочая группа рассматривала новые параметры, но сохранила исходный синтаксис ради совместимости с уже поставлявшимися реализациями IPP/1.1.

Полная лестница доказательств идёт от синтаксиса и разрешения адреса к HTTP-связке, application/ipp, личности сервера, правам клиента, принятию операции, созданию Job и выдаче временной ссылки. Затем отдельно следуют состояние завершения, физический вывод и передача получателю. Каждая нижняя ступень может быть истинной, когда следующая ложна.

Настоящая служба может отказать. Принятое задание можно отменить. Программное завершение может наблюдаться раньше выхода листа. Бумага может попасть не в тот лоток или не к тому человеку. RFC 3510 упорядочил локатор, но не объединил эти факты.

Различие Lu Heng между символической и операционной реальностью помогает не переоценивать стандарт. Общая URL создаёт символический маршрут. Работающий код определяет объект, правила имён, хранение и шлюз. RFC доказывает наличие технического договора, а не распространённость и не печать конкретного файла.

RFC 3510 оказался ценен своей сдержанностью. Он сделал адреса совместимее и одновременно отверг лишний вывод. URL мог назвать Job. Без контекста обмена и реализации он не сообщал, какой Printer этот Job создал.

Источники