3. Спецификация Базы данных DDDS
- General Description — общее описание
Эта база данных использует систему DNS, описанную в [8] и [7].
Набором символов, используемых для задания различных значений записей NAPTR является UTF-8 [17]. Следует соблюдать осторожность в тех случаях, когда ввод или вывод выражений для замены содержит коды, выходящие за пределы эквивалентности ASCII/Unicode в UTF-8 — любые символы UTF-8 интерпретируются как последовательности кодовых точек (code-point), а не байтов. Это сделано для поддержки других языков в расширенных регулярных выражениях POSIX, чтобы обеспечить возможность соответствия предназначенным кодовым точкам. Недопустимо писать выражения для замены так, чтобы они зависели от локальных установок POSIX, поскольку это приведет к потере выражениями для замены их универсальности в применении.
Все записи о ресурсах DNS имеют связанное с ними значение времени жизни TTL. По истечении с момента отыскания записи соответствующего числа секунд корректность записи теряется м нужно сделать новый запрос для получения новых записей. Таким образом, как указано в Алгоритме DDDS, могут возникать ситуации, когда срок действия данного Правила истекает. В тех случаях, когда приложение пытается вернуться к ранее найденным наборам Правил (в случае неподходящего пути передачи полномочий или при отказе сервера) приложение должно обеспечить гарантию того, что ни одна из записей, к которым происходит возврат, не перестала быть корректной по времени жизни. Если истек срок действия хотя бы одной записи приложение должно вернуть процесс на первый шаг алгоритма.
- Key Format — формат ключей
- Ключ представляет собой корректно сформированное доменное имя DNS.
- Lookup Request — поисковый запрос
- Чтобы запросить набор правил для данного Ключа, клиент вводит запрос, соответствующий стандартным правилам DNS, для записис NAPTR RR, соответствующей данному доменному имени.
- Lookup Response — отклик при поиске
- Отклик на запрос для данного Ключа (доменное имя) будет серией записей NAPTR. Формат записи NAPTR описан в главе 4.
- Rule Insertion Procedure — процедура вставки правил
- Правила вставляются путем добавления новых записей в соответствующую зону DNS. Если Правило производит Ключ, который существует в конкретной зоне, тогда только объект, имеющий административный контроль над этой зоной, может задавать Правило, связанное с таким Ключом.
- Collision Avoidance — предотвращение конфликтов
В том случае, когда два Приложения могут использовать эту Базу данных (на практике это случай использования базы приложениями ENUM и URI Resolution, описанный в параграфе 6.2), возможно возникновение конфликта между правилами, когда в домене появляются две записи NAPTR, применимые более, чем к одному Приложению. Существуют три способа предотвращения конфликтов.
Создание в домене новой зоны, которая содержит только записи NAPTR, которые подходят для Приложения. Например, все записи URI Resolution могут размещаться в зоне urires.example.com, а все записи ENUM — в зоне enum.example.com. В том случае, когда такое решение невозможно по причине отсутствия контроля над восходящим делегированием, следует использовать второй метод.
Создание регулярного выражения, содержащего часть строки AUS, достаточную для однозначной идентификации приложения. Например, URI Resolution может использовать имя схемы слева для привязки регулярного выражения к соответствию этой схеме. Связанные с ENUM записи в той же зоне могут привязываться слева к соответствию символу "+", который определен в ENUM как начало каждой строки AUS. В результате данной строке AUS может соответствовать лишь одна из записей, а не две.
Если два приложения используют различные значения Flags или Services, тогда записи другого Приложения можно игнорировать, поскольку они не будут соответствовать значению Services/Flags.