Network Working Group Request for Comments: 3401 Updates: 2276 Obsoletes: 2915, 2168 Category: Informational
M. Mealling
VeriSign
October 2002
Система DDDS. Часть 1 - DDDS в целом
Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
Статус документа
Этот документ содержит информацию для сообщества Internet и не содержит каких-либо стандартов Internet. Документ может распространяться свободно.
Авторские права
Copyright (C) The Internet Society (2002). All Rights Reserved.
Тезисы
Этот документ точно определяет документы для полной спецификации системы DDDS1. Система 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 Database2, путем итеративного применения правил преобразования строк, пока не будут достигнуты условия завершения. Этот документ определяет всю систему 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.
1Dynamic Delegation Discovery System 2База данных DDDS.
динамическая система детектирования передачи полномочий.
Перевод RFC 3401
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., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 34023, October 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Doman Name System (DNS) Database", RFC 34033, October 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 34043, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 34053, 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.
3На сайте http://rfc.com.ru имеется перевод этого документа на русский язык. Прим. перев.
rfc.com.ru                                                                                     2                                                            rfc.com.ru
Перевод RFC 3401
[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
Полное заявление авторских прав
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
Перевод на русский язык Николай Малых
BiLiM Systems nmalykh@bilim.com
3