AAA

RFC 3401 — Система DDDS. Часть 1 — DDDS в целом

Статус документа

Этот документ содержит информацию для сообщества Internet и не содержит каких-либо стандартов Internet. Документ может распространяться свободно.

Тезисы

Этот документ точно определяет документы для полной спецификации системы DDDS (Dynamic Delegation Discovery System — динамическая система детектирования передачи полномочий). Система DDDS представляет собой абстрактный алгоритм применения динамически отыскиваемых правил преобразования строк к уникальным строкам, связанным с приложениям.

Данный документ вместе с RFC 3402, RFC 3403 и RFC 3404 отменяет документы RFC 2168 и RFC 2915, а также обновляет RFC 2276.

1. Аудитория

Этот документ вместе с упоминаемыми в нем документами предназначен для тех, понять и реализовать базовый алгоритм DDDS, преобразование URI Resolution, преобразование телефонных номеров ENUM в URI и DNS-записи NAPTR. Чтение отдельных документов этой серии без прочтения остальных может привести к непониманию и возникновению проблем интероперабельности.

2. Введение

Система DDDS используется для реализации простого связывания строк с данными, обеспечивающего поддержку динамически настраиваемых систем передачи полномочий (делегирования). DDDS отображает некие уникальные строки на данные, хранящиеся в DDDS Database, путем итеративного применения правил преобразования строк, пока не будут достигнуты условия завершения. Этот документ определяет всю систему DDDS, перечисляя документы, образующие полную на данный момент спецификацию.

Этот документ вместе с RFC 3402, RFC 3403 и RFC 3404 отменяет действие RFC 2168 [8] и RFC 2915 [6], а также обновляет RFC 2276 [5]. При изменении спецификации DDDS данный документ будет обновляться или отменяться. Следовательно, читателю настоятельно рекомендуется проверять репозиторий IETF RFC на предмет появления документов, обновляющих или отменяющих данный документ.

3. Алгоритм

Алгоритм DDDS определен в RFC 3402 [1]. Этот документ определяет следующие концепции DDDS:

RFC 3402 является актуальной спецификацией алгоритма DDDS. Однако спецификация сама по себе бесполезна без дополнительных документов, определяющих где и как используется алгоритм. Эти документы называются Приложениями (Application) и не являются частью основной спецификации DDDS. Приложения требуют баз данных для хранения их правил. Такие базы данных обозначаются термином DDDS Database и спецификации для них обычно указываются в отдельных документах. Эти документы также не являются частью основной спецификации DDDS.

4. Приложения DDDS

Ни одна реализация не может начаться без спецификации Приложения, поскольку именно эта спецификация обеспечивает конкретные детали для алгоритма DDDS. Без этого DDDS не представляет собой ничего, кроме общего алгоритма. Документы для Приложений определяют следующее:

Примерами документированных Приложений могут служить:

5. Стандартизованные базы данных

Любое Приложение DDDS должно использовать тот или иной тип базы данных (DDDS Database). Документы для баз данных определяют следующее:

База данных не может использоваться сама по себе — должно существовать хотя бы одно Приложение, которое ею пользуется. Определено множество Баз данных и Приложений и некоторые Базы будут поддерживать множество Приложений. Однако не каждое Приложение использует каждую Базу данных (и наоборот). Таким образом, соответствие спецификациям определяется для пары Приложение — База данных.

Одним из примеров спецификации Базы данных является:

6. Вопросы безопасности

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

7. Согласование с IANA

Хотя сам этот документ не создает каких-либо новых требований для IANA, другие документы этой серии порождают множество требований. Разделы Согласование с IANA (IANA Considerations) в этих документах должны просматриваться агентством IANA для определения полного набора новых реестров и требований. Любым новым алгоритмам, базам данных и приложениям следует аккуратно учитывать, что они могут требовать от IANA в будущем.

Литература

  1. Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
  2. Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Doman Name System (DNS) Database", RFC 3403, October 2002.
  3. Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
  4. Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
  5. Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
  6. Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, August 2000.
  7. Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
  8. Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.

Адрес автора

Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166 US
URI: http://www.verisignlabs.com
EMail: ten.mynoen@leahcim

Перевод на русский язык

Николай Малых, moc.milib@hkylamn