Кратко
- Авторы RFC 1430 считали, что приведение записей разных организаций к единой информационной структуре потребует гораздо больше труда, чем установка серверов и пользовательских программ.
- Крупные организации должны были вести собственные ветви каталога, небольшие — арендовать место у региональных сетей. Корневой узел, имена, сведения о местонахождении ветвей и репликация требовали общих оплачиваемых служб.
Запрос к справочнику может выполниться за секунду. Между фамилией на экране и действительным местом работы человека лежит длинная цепочка: исходная ведомость, перенос в каталог, назначение ответственного, исправление после каждого переезда. В плане февраля 1993 года эту цепочку не считали второстепенной. Пять авторов прямо писали: сопоставление данных с согласованной распределенной структурой по трудозатратам намного превосходит установку серверов и программ для пользователей.
Первыми применениями должны были стать «белые страницы» для поиска людей и поддержка аутентификации X.509. Затем планировались поиск ресурсов, сведения об инфраструктуре и поддержка почты. Несколько пилотных проектов X.500 уже сотрудничали. Для постоянной службы, говорилось в RFC, требовалось достаточное финансирование центральных операций. Испытательный стенд показывал связность, но не оплачивал годы сверки записей.
Распределение работы описано вполне предметно. Крупная организация держит свою часть дерева каталога DIT на собственном сервере DSA. Небольшая арендует место на DSA региональной сети или иного поставщика. Такая схема расширяла круг участников без покупки отдельного сервера каждой организацией. Она сохраняла вопрос о владельце данных: кто имеет право исправлять запись и кто заметит, что она устарела? Плата за размещение и труд редактора — разные строки бюджета.
Общая часть дерева также требовала операторов. Нужно было поддерживать корневой DSA, распределять имена, учитывать, какой сервер хранит ту или иную ветвь, и размножать сведения верхнего уровня. Тогда корневой сервер вел проект Paradise, который авторы предложили взять за начальную основу центральных операций. В каждой участвующей стране следовало создать соответствующие национальные службы. Открытие новой страновой ветви означало новую координацию, а не просто добавление строки в конфигурацию.
Раздел управления данными звучал как предупреждение руководству. Без процедур качества вся инфраструктура имела мало шансов. Записи поддерживали бы сами владельцы, поэтому один порядок для всех не подходил. Нужны были рекомендации, минимальный уровень качества, опыты по подключению существующих баз и инструменты для повторного применения. Авторы даже включили краткое обоснование для руководителей вычислительных центров, чтобы добиться выделения персонала. За работой машины стояло решение о штатном времени.
Публикация сведений о людях добавляла правовую работу. Национальным операторам предлагалось изучить местные нормы о приватности и регистрации; отдельно обсуждалась хартия прав пользователей. Международная доступность записи не отменяла местной ответственности за ее содержание.
В RFC нет переписи сотрудников или отчета о полном развертывании. Его сильная сторона — ясный счет того, что придется делать ежедневно. Сервер может годами отвечать на запросы и одновременно выдавать вчерашний справочник. Исправление следующей записи остается задачей конкретного учреждения и конкретного бюджета.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров





