Кратко

  • RFC 2345 отделила поиск корпоративной веб-информации от администрирования DNS и споров о правах на имя.
  • Толкование названия, сокращений и вариантов написания оставалось на усмотрение сервера; правильность совпадения спецификация не гарантировала.
  • Ответ содержал URL и свободную отображаемую строку без юрисдикции, регистрационного номера, источника, даты проверки и доказательства контроля домена.
  • Демонстрационная система ранжировала кандидатов, обрезала выдачу после десяти и автоматически открывала единственное совпадение, хотя уникальность относилась лишь к одной базе.
  • Идентичность компании, управление доменом, подлинность страницы и результат услуги требовали отдельных подтверждений.

Спецификация отвечала только на вопрос «где искать»

На раннем коммерческом Вебе казалось естественным угадывать адрес по названию: для XYZ Company попробовать www.xyz.com. Рост сети разрушил это удобное допущение. Короткие названия повторялись в разных странах и отраслях, торговые марки отличались от юридических наименований, а сайты размещались не только в .com.

RFC 2345 разделила три темы: политику администрирования доменов, права на названия и поиск информации об организации по известному имени. Эксперимент занимался только третьей.

Это ограничение защищало систему от лишних полномочий. Каталог мог подсказать страницу, но не разрешал спор о товарном знаке, не менял делегирование DNS и не определял владельца прав на название.

WHOIS дал минимальный транспорт

Клиент подключался к TCP-порту 43, отправлял одну строку, получал одну или несколько строк, после чего сервер закрывал соединение. RFC 954 уже описывала такой читаемый человеком цикл WHOIS.

В RFC 2345 запросом было предполагаемое название компании. Обычная строка ответа начиналась с URL; пробелы отделяли его от отображаемого названия. Поскольку URL по принятому синтаксису не содержал пробелов, разбор был прост.

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

Текстовое имя не является ключом юридического лица

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

У разных компаний может быть одно торговое имя. Материнская структура, дочерняя компания и продукт могут использовать один бренд. Старое название живёт после слияния. Транслитерация создаёт несколько форм. Удаление организационно-правового суффикса помогает поиску, но иногда стирает различие между субъектами.

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

Поле «название компании» тоже не было удостоверением

Текст после URL мог быть названием, названием с местоположением или видом деятельности либо иным описанием по выбору сервера. Он помогал человеку выбрать адрес.

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

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

URL указывал место, а не титул

RFC 1738 определяла URL как компактное представление местонахождения и доступа к интернет-ресурсу. Она также предупреждала: нет общей гарантии, что позднее тот же адрес будет указывать на тот же объект.

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

RFC 2345 отдельно рассматривала подмену сервера преобразования, способного вернуть неправильный адрес. В качестве защиты документ предлагал проверять сертификаты, подписи и другие признаки подлинности. Значит, само отображение имени в URL не считалось достаточным.

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

Единственный результат создавал локальную уверенность

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

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

Автоматический переход ускорял действие, но не усиливал доказательство.

Первая десятка не была полной выборкой

Демонстрационный сервер содержал около 209 тысяч записей Dun & Bradstreet. Если совпадений было десять или больше, он возвращал только верхние десять. Клиент показывал от двух до десяти названий в порядке балла.

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

Not found сообщало лишь, что строка не совпала с записью в данной базе. Оно не доказывало отсутствия компании или сайта.

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

Качество создавалось вне протокола

RFC 2345 прямо говорила: результат зависит от базового каталога и от редакционной и исследовательской работы по его созданию. Ни то ни другое протокол не регулировал.

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

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

Выбор сервера входил в происхождение результата

Документ не требовал единственного поставщика или реестра поставщиков. Клиентам рекомендовалось позволять выбирать сервер.

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

Рынок мог поощрить лучший каталог, но не ставил подпись под каждой уже выданной строкой.

Официальная страница ещё не была квитанцией услуги

Даже верная связь не завершала задачу. DNS должен был разрешиться, сеть — доставить запрос, сертификат — соответствовать контексту, перенаправления — оставаться в приемлемой цепочке контроля. Затем продукт, форма, поддержка или транзакция должны были реально сработать.

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

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