Кратко

  • RFC 1107 описал три этапа создания справочника White Pages для Интернета и National Research Network, но прямо уточнил, что речь не шла о принятой сообществом исследовательской программе.
  • Сначала предлагалось сравнить несколько решений в ограниченных испытаниях, затем разработать службу по их итогам и подготовить широкое развёртывание. Достоверность записей, права на пространство имён, доступ и клиентские программы оставались частью задачи.

Телефонный справочник полезен лишь тогда, когда кто-то собирает сведения, исправляет ошибки и обновляет контакты. В RFC 1107 «White Pages» означали службу, которая поможет найти человека в исследовательской сети и сведения для связи с ним: электронный почтовый ящик, календарь или файловый сервер. Отдельные «Yellow Pages» должны были помогать искать сетевые ресурсы по их атрибутам. Это не сводилось к добавлению имён людей в службу имён узлов.

Опубликованный в июле 1989 года документ Карен Соллинс «A Plan for Internet Directory Services» подводил итоги двухдневной встречи в феврале. Небольшая группа представляла академические, коммерческие и государственные интересы. Участники сочли, что полезную службу можно создать за три года при сильной поддержке и финансировании. Однако статусная часть RFC называет текст предложением для комментариев и подчёркивает отсутствие принятого обязательства со стороны интернет-сообщества. Календарь описывал возможный план, а не утверждённый проект или состоявшееся развёртывание.

Первый этап должен был сохранить выбор архитектуры открытым. X.500 казался наиболее вероятной основой благодаря богатой семантике и ожидавшемуся статусу международного стандарта. Но спецификация оставляла пробелы, а строгая иерархия вызывала сомнения. Поэтому предлагалось испытать как минимум одну реализацию X.500 — наиболее готовым кандидатом тогда считался Quipu — вместе с Profile и DNANS, службой именования DEC. Profile поддерживал описательные имена без обязательного единого дерева; DNANS проектировался с механизмами контроля доступа, репликации и кэширования.

Вторая реализация X.500 помогла бы понять, связана ли проблема с самим стандартом или с конкретной программой.

Сравнивать службы на разных записях было бы трудно. RFC 1107 предлагал единый формат входных данных и общие инструменты управления ими, чтобы несколько реализаций могли работать рядом. Испытания должны были проверить сбор и обновление информации, распределение и репликацию, права чтения и записи, целостность записей, клиентские интерфейсы, производительность и поддержку нескольких протокольных стеков. Для первого эксперимента предлагалась ограниченная и достаточно подготовленная аудитория; для DNANS называлось сообщество, которому предстоял переход на DECnet.

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

Оценки масштаба объясняют, почему демонстрации было недостаточно. Документ предполагал около десяти миллионов пользователей в науке и исследованиях и примерно десять поисков в неделю на человека. Это давало 10^8 запросов в неделю, около 170 в секунду в среднем и существенно более высокие пики. Требовалось поддерживать как минимум 10^7 записей; автор считал распределённую службу с несколькими серверами единственным разумным направлением. Это расчётные предположения, а не данные работающей системы. RFC предупреждал, что широкие поиски могли дорожать по мере роста всего каталога.

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

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

Это превращало управление данными в часть архитектуры. Кто вправе создать ветвь для организации, выбрать авторитетный сервер, исправить запись или ограничить просмотр сведений о сотрудниках? RFC 1107 признавал, что организации могут не захотеть передавать контроль над своими именами другой стороне, а люди и работодатели — ограничивать чтение кадровой информации. В то же время смысл общего справочника заключался в поиске людей за пределами своей организации. Совместимость требовала общих правил, а доверие — актуальных записей и контроля доступа, учитывающего местные потребности.

RFC 1107 фиксирует серьёзный план и перечень проверок, а не доказательство его выполнения. Его вклад — разбить архитектурное решение на этапы и поставить сбор данных, интерфейсы и распределение полномочий рядом с выбором стандарта. Трёхлетняя цель могла быть правдоподобной только при наличии ответственных, ресурсов и результатов каждого этапа. Сам RFC не содержит такой истории исполнения.

Источники