Кратко

  • RFC 2056 разделил два намерения: z39.50s описывал работу в сеансе поиска, а z39.50r — получение записи по непрозрачному идентификатору с гораздо более жестко заданным поиском.
  • Адрес содержал несколько независимых слоев: узел, базу данных, идентификатор документа, набор логических элементов и синтаксис записи. Совпадение одного слоя не доказывало тождество остальных.
  • Документальный статус схем и их регистрация IANA говорят о спецификации и реестре, а не о нынешнем трафике, поддержке программами или продолжающейся доступности конкретных ресурсов.

RFC 2056 появился в ноябре 1996 года как Proposed Standard в Standards Track. В публично доступных сегодня метаданных RFC Editor и IETF документ относится к историческому наследию стандартизации; в рассмотренных сведениях не указана явная связь, по которой другой RFC обновляет или отменяет RFC 2056. Это описание документального положения, а не свидетельство нынешнего развертывания Z39.50 или практической поддержки этих URL-схем.

Исторический интерес RFC 2056 состоит прежде всего в том, что он помещает в URL не просто сетевой адрес. Обычный запрос Z39.50 был многошаговым и сохранял состояние сеанса: клиент устанавливал соединение с сервером, мог проводить поиск, получать результаты и при необходимости продолжать взаимодействие. Поиск создавал на стороне сервера указатели на записи базы данных. Между шагами могли потребоваться дополнительные параметры, а степень участия пользователя зависела от клиента. Поэтому одна строка URL должна была сообщить интерфейсу достаточно, чтобы тот заранее различил два разных намерения, еще до разбора непрозрачных частей адреса.

Схема z39.50s предназначалась для сеансового варианта. Имя узла обязательно, порт необязателен и по умолчанию равен 210; остальные части необязательны. Клиент должен начать новый сеанс с указанными узлом и портом либо повторно использовать уже существующий сеанс к той же паре. Если присутствует docid, должна быть указана и база данных: тогда клиент выполняет поиск, ориентированный на получение этой записи. Если docid отсутствует, другие параметры не превращаются автоматически в обязательную команду сервера: в зависимости от клиента они могут выступать требованиями, предпочтениями или подсказками, которые клиент вправе не использовать. Существенная деталь этой схемы — после обработки URL сеанс оставляется открытым для дальнейшей работы пользователя.

z39.50r задавал другое поведение. Здесь обязательны и узел, и база данных; порт снова по умолчанию равен 210. Значение URL без docid спецификация не определяет. Сам docid — непрозрачное значение, определяемое сервером. Для его использования RFC задает конкретное построение запроса: один термин в общем формате Type-1 с тегом 45, атрибутом Bib-1 Use=docid и Structure=URx. Результат Search обязан иметь счетчик ровно 1. Иное значение означает неуспех, после которого поведение приложения документом не определено. Если единственная запись уже содержится в Search Response, отдельный шаг не нужен; в противном случае выполняется Present. После получения записи клиент может закрыть соединение либо сохранить его.

Эта жесткость важна. RFC не дает клиенту права приблизительно сопоставлять идентификатор, выбирать произвольную запись среди нескольких или трактовать неоднозначный результат как успех. docid здесь не свободный поисковый текст, а серверный непрозрачный ключ, встроенный в строго определенную конструкцию Search. В этом отношении z39.50r превращает URL в довольно точное описание протокольного действия, тогда как z39.50s сохраняет пространство для интерактивного продолжения сеанса.

Другой слой спецификации касается того, что именно считается записью. RFC различает локальную запись базы данных, общую абстрактную запись базы данных и экспортируемую запись, выдаваемую клиенту. Это не три названия одного и того же объекта. Параметр esn выбирает логический набор элементов, то есть состав сведений, которые требуется представить. Параметр rs задает синтаксис записи — форму, в которой выбранное содержание упаковывается для передачи. Если esn не указан, выбор остается клиенту; если указан, он применяется либо в полях small/medium-set-element-set-names операции Search, либо при последующем Present. При отсутствии rs синтаксис также выбирает клиент. Если перечислены несколько допустимых синтаксисов, предпочтительно использовать первый поддерживаемый как PreferredRecordSyntax.

Грамматика делает эти различия видимыми прямо в адресе. Базы данных разделяются знаком +; затем может следовать ?docid, а после него — ;esn= и один параметр ;rs=. Именно один: если приемлемых синтаксисов записи несколько, их значения внутри этого единственного ;rs= разделяются знаком +. Общая основа синтаксиса URL восходит к RFC 1738. Поэтому форма адреса отражает композицию нескольких решений: куда подключаться, с какой базой работать, какой непрозрачный идентификатор передать, какие логические элементы запросить и в каком представлении получить результат.

На этом фоне полезен RFC 1729, обсуждавший проблемы совместимости представлений информации. Он напоминает, почему выбор логического содержания и способа его кодирования нельзя считать одним решением. Даже если две стороны согласны, какую сущность хотят передать, различия в представлении могут препятствовать корректному обмену. В RFC 2056 это различие получает конкретное выражение через esn и rs: отбор содержания отделен от формы выдаваемой записи.

Еще один близкий по времени документ, RFC 1625, описывал контекст WAIS и использовал иной механизм. Там применялся текстовый запрос Type-3, результаты удалялись ради обработки без сохранения состояния между обращениями, а операция Present не использовалась. Это соседний исторический пример, но не модель, которую следует переносить на RFC 2056. Сходство задач информационного поиска не отменяет различий в протокольном поведении.

RFC 2056 также прямо разрушает представление о URL как о вечном и безобидном имени. Раздел безопасности предупреждает, что со временем указатель может перестать обозначать именно тот объект, для которого был создан. Более того, действие, внешне похожее на безвредное повторяемое получение данных, на удаленной системе способно вызвать операцию с разрушительными последствиями. В середине 1990-х это уже означало: синтаксическая возможность воспроизвести запрос не равна гарантии того, что цель сохранилась, полномочия остались прежними или повторение безопасно.

Сегодня реестр URI Schemes IANA указывает z39.50s и z39.50r как Permanent, а z39.50 — как Historical. Реестровая запись подтверждает закрепление имен схем и их классификацию. Она сама по себе ничего не сообщает об объеме нынешнего трафика, числе работающих серверов, поддержке клиентами или эксплуатационной пригодности конкретного адреса. Точно так же статус RFC — документальное свойство стандарта, а не измерение современной практики.

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

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

Именно поэтому RFC 2056 интересен не как курьез о старых URL, а как компактная карта ответственности. Сервер владеет базами, состоянием поиска и непрозрачными идентификаторами. Клиент интерпретирует схему, решает, как применять необязательные подсказки, выбирает значения по умолчанию и управляет продолжением сеанса. URL связывает эти стороны, но не устраняет различия между ними и не превращает адрес в доказательство всех свойств ресурса.

Источники