Статус документа
Этот документ содержит информацию для сообщества 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:
- базовый лексикон DDDS;
- алгоритм работы;
- требования к приложениям, использующим алгоритм;
- требования к базам данных для хранения правил DDDS.
RFC 3402 является актуальной спецификацией алгоритма DDDS. Однако спецификация сама по себе бесполезна без дополнительных документов, определяющих где и как используется алгоритм. Эти документы называются Приложениями (Application) и не являются частью основной спецификации DDDS. Приложения требуют баз данных для хранения их правил. Такие базы данных обозначаются термином DDDS Database и спецификации для них обычно указываются в отдельных документах. Эти документы также не являются частью основной спецификации DDDS.
4. Приложения DDDS
Ни одна реализация не может начаться без спецификации Приложения, поскольку именно эта спецификация обеспечивает конкретные детали для алгоритма DDDS. Без этого DDDS не представляет собой ничего, кроме общего алгоритма. Документы для Приложений определяют следующее:
- Уникальная строка приложения (Application Unique String).
- Первое общеизвестное правило (First Well Known Rule) — правило, говорящее где начинается процесс.
- Список корректных баз данных (вы не можете просто использовать любую базу данных).
- Ожидаемый в результате вывод данных.
Примерами документированных Приложений могут служить:
"E.164 number and DNS" (RFC 2916) [7]. Это Приложение использует DDDS для отображения телефонных номеров на конечные точки сервиса типа SIP или электронной почты.
"Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application" (RFC 3404) [3]. Это Приложение использует DDDS для преобразования любого URI в набор конечных точек или «преобразователей» (resolver), которые дают дополнительную информацию об URI независимо от конкретной схемы URI.
5. Стандартизованные базы данных
Любое Приложение DDDS должно использовать тот или иной тип базы данных (DDDS Database). Документы для баз данных определяют следующее:
- общие спецификации работы базы данных;
- форматы для ключей (Key);
- форматы для правил (Rule);
- процесс поиска ключей;
- процедуры вставки правил;
- методы предотвращения конфликтов.
База данных не может использоваться сама по себе — должно существовать хотя бы одно Приложение, которое ею пользуется. Определено множество Баз данных и Приложений и некоторые Базы будут поддерживать множество Приложений. Однако не каждое Приложение использует каждую Базу данных (и наоборот). Таким образом, соответствие спецификациям определяется для пары Приложение — База данных.
Одним из примеров спецификации Базы данных является:
- "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database" (RFC 3402) [1]. (этот документ содержит официальную спецификацию записи NAPTR в DNS).
6. Вопросы безопасности
Любые проблемы безопасности, которые могут быть связаны с использованием алгоритмов и баз данных, должны быть описаны в соответствующих спецификациях. Проблемы должны быть описаны полностью. Не требуется, чтобы база данных или алгоритм были защищенными, или свободными от риска, но все известные проблемы и риски должны быть указаны. Публикация нового типа базы данных или алгоритма требует обзора безопасности и тема безопасности должна быть предметом постоянного изучения. Дополнительные вопросы безопасности следует решать путем публикации пересмотренной версии спецификации алгоритма или базы данных.
7. Согласование с IANA
Хотя сам этот документ не создает каких-либо новых требований для IANA, другие документы этой серии порождают множество требований. Разделы Согласование с IANA (IANA Considerations) в этих документах должны просматриваться агентством IANA для определения полного набора новых реестров и требований. Любым новым алгоритмам, базам данных и приложениям следует аккуратно учитывать, что они могут требовать от IANA в будущем.
Литература
| [1] | Mealling, M., «Система DDDS. Часть 2 - Алгоритм», RFC 3402, Октябрь 2002. |
| [2] | Mealling, M., «Система DDDS. Часть 3 - База данных DNS», RFC 3403, Октябрь 2002. |
| [3] | Mealling, M., «Система DDDS. Часть 4 - Приложение для преобразования URI», RFC 3404, Октябрь 2002. |
| [4] | Mealling, M., «Система DDDS. Часть 5 - Процедуры присваивания URI.ARPA», RFC 3405, Октябрь 2002. |
| [5] | Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, Январь 1998. |
| [6] | Mealling, M. и R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, Август 2000. |
| [7] | Faltstrom, P., «E.164 number and DNS», RFC 2916, Сентябрь 2000. |
| [8] | Daniel, R. и M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, Июнь 1997. |
Адрес автора
Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166 US
URI: http://www.verisignlabs.com
EMail: ten.mynoen@leahcim