IPP (Internet Printing Protocol — протокол печати через Internet) является удачным, широко распространенным стандартом для управления принтерами, доступными через сеть. Указатели на RFC, реализации и многие другие связанные материалы доступны на сайте рабочей группы "Printer Working Group", подразделения IETF <http://www.pwg.org/ipp/>.

В протоколе IPP в качестве транспортного уровня используется HTTP 1.1. Все IPP-запросы проходят через вызов POST-метода HTTP, а ответы являются обычными HTTP-ответами. (В разделе 4.2. RFC 2568, "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol" данный выбор превосходно обосновывается. Указанный раздел заслуживает изучения разработчиками новых протоколов прикладного уровня.)

Что же касается программного обеспечения, то широко распространен протокол HTTP 1.1. Он уже решает множество проблем транспортного уровня, которые в противном случае отвлекали бы конструкторов и создателей протоколов от семантики печати. Существует возможность простого расширения данного протокола, поэтому вполне реальной представляется перспектива роста IPP. Модель CGI-программирования для обработки POST-запросов понятна, а инструменты для разработки широко доступны.

Большинство сетевых принтеров уже имеют встроенный Web-сервер, поскольку в этом состоит естественный путь предоставления пользователям возможности удаленно запрашивать сведения о состоянии принтера. Таким образом, инкрементная стоимость добавления IPP-службы в программно-аппаратное обеспечение принтера невысока. (Данный аргумент применим к чрезвычайно широкому диапазону другого сетевого аппаратного обеспечения, включая торговые автоматы и кофеварки [56] .)

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

BEEP (ранее BXXP), протокол для расширяемого обмена блоками информации является общим протокольным аппаратом, который конкурирует с HTTP в качестве универсального нижнего уровня для протоколов прикладного уровня. Существует открытая ниша, поскольку до сих пор нет другого, заслуживающего большего доверия, метапротокола, пригодного для действительно одноранговых приложений, как противоположности клиент-серверным приложениям, с которыми хорошо справляется HTTP. На сайте проекта <http://www.beepcore.org/beepcore/docs/sl-beep.jsp> предоставляется доступ к стандартам и реализациям с открытым исходным кодом на нескольких языках.

Протокол ВЕЕР обладает функциями для поддержки как клиент-серверного, так и однорангового режимов. Создатели ВЕЕР спроектировали протокол и библиотеку поддержки таким образом, что выбор верных параметров избавляет от запутанных проблем, таких как кодировка данных, управление потоком, обработка перегрузок, поддержка сквозного шифрования и компоновка большого ответа, составленного из множества передач.

BEEP-узлы обмениваются между собой последовательностями самоописательных двоичных пакетов, которые подобны типам блоков в PNG. Данная конструкция более приспособлена к экономии и менее к прозрачности, чем классические Internet-протоколы или HTTP, и может быть наилучшим выбором при необходимости передавать большие объемы данных. Протокол ВЕЕР также позволяет избежать проблемы HTTP, которая заключается в том, что все запросы должны быть инициированы клиентом. Это преимущество проявляется в ситуациях, когда серверу необходимо отправлять асинхронные извещения о состоянии обратно клиенту.

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

В проектировании прикладных протоколов усиливается тенденция к использованию XML внутри MIME для структурирования запросов и блоков полезной нагрузки. BEEP-узлы используют данный формат для согласования каналов. По пути развития XML движутся три основных протокола: XML-RPC и SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) для реализации удаленного вызова процедур и Jabber для обмена мгновенными сообщениями. Все три протокола представляют собой типы XML-документов.

XML-RPC весьма выдержан в духе Unix (его автор отмечает, что он начал изучать программирование в 1970-х годах, читая оригинальный исходный код Unix). Подход к разработке данного протокола был осознанно минималистским. И тем не менее, протокол является весьма мощным. Он предоставляет способ для значительного большинства RPC-приложений, которые могут работать, распространяя скалярные булевы/целые/плавающие/строковые типы данных, выполнять их функции способом, простым для понимания и мониторинга. Онтология типов XML-RPC богаче онтологии текстовых потоков, однако остается простой и достаточно переносимой, для того чтобы функционировать в качестве ценной проверки сложности интерфейса. Существуют реализации данного протокола с открытым исходным кодом. Ссылки на них, а также на соответствующие спецификации доступны на домашней странице XML-RPC <http://www.xmlrpc.com/>.

SOAP является более тяжеловесным RPC-протоколом с более развитой онтологией типов, которая включает в себя массивы и C-подобные структуры. Его создателей вдохновил XML-RPC, однако он заслуженно был назван "перепроектированной жертвой эффекта второй системы". К середине 2003 года работы по стандарту SOAP еще велись, однако пробная реализация в Apache остается черновой. Клиентские модули с открытыми исходными кодами на языках Perl, Python, Tcl и Java можно быстро найти с помощью Web-поиска. Проектная спецификация консорциума W3C доступна на странице <http://www.w3.org/TR/SOAP>.