5. Примеры
5.1. Пример использования URN
Рассмотрим URN из гипотетического пространства имен FOO. Номера FOO служат идентификаторами приблизительно для 30 миллионов зарегистрированных компаний по всему миру; идентификаторы распределяет и поддерживает компания Fred, Otto and Orvil, Inc. URN могут иметь вид:
urn:foo:002372413:annual-report-1997
Первым шагом процесса преобразования будет поиск информации о пространстве имен FOO. Идентификатор пространства имен [8] "foo" создается из URN путем добавления к '.urn.arpa.' префикса 'foo', что дает в результате 'foo.urn.arpa.'. Далее делается запрос к DNS для получения записей NAPTR для этого домена. Результат запроса имеет вид:
foo.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "foolink+I2L+I2C" "" foolink.udp.example.com. IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.example.com. IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.example.com.
Поле order содержит одинаковые значения, показывающие отсутствие упорядочения. Поле preference показывает, что провайдер предпочитает, чтобы клиенты использовали специальный протокол foolink, после этого RCDS и в последнюю очередь THTTP. Все записи содержат флаг s, показывающий, что запись является завершающей и следующим шагом является получение от DNS записи SRV для данного доменного имени.
Поле service говорит, что при использовании протокола foolink можно вводить запросы I2L, I2C или I2R для получения URI или задавать некоторые более сложные вопросы о ресурсе. Можно использовать сервис RCDS [12] для получения некоторых метаданных, тогда как THTTP можно использовать для получения URI, соответствующего текущему местоположению ресурса.
Предположим, что клиент не знает протокола foolink, но знает RCDS. Следующим шагом будет поиск записей SRV RR для имени rcds.udp.example.com, котрый даст нам список хостов, способных предоставить требуемые услуги преобразования. Этот список может иметь вид:
;; Pref Weight Port Target
rcds.udp.example.com IN SRV 0 0 1000 deffoo.example.com.
IN SRV 0 0 1000 dbexample.com.au.
IN SRV 0 0 1000 ukexample.com.uk.
Список содержит три хоста, способных выполнить преобразование и указывает номер порта, который следует использовать для связи с сервером RCDS (получить сведения об интерпретации приведенных выше полей можно из спецификации SRV [9]). Здесь существует возможность оптимизации. RFC 3403 определяет возможность использования раздела Additional Information. В этом случае записи SRV могут возвращаться в качестве дополнительной информации при завершающем поиске NAPTR (вместе с записями A для этих SRV). Эти записи обеспечивают возможность существенной оптимизации. При использовании этого в комбинации со большими значениями TTL для записей *.urn.arpa. среднее число обращений к DNS для преобразования большинства URI будет приближаться к 1.
Отметим, что приведенные выше примеры записей NAPTR предназначены для представления результатов поиска NAPTR с использованием некой клиентской программы типа nslookup; администраторам зон следует поддерживать документацию для своих серверов имен с точной информацией о синтаксисе используемых файлов зон.
Отметим также, что может использоваться дополнительный первый шаг, на котором URN преобразуется как базовый вариант URI путем просмотра urn.uri.arpa. Результирующее правило будет задавать, что NID выделяется и URN и суффикс '.urn.arpa.' добавляется для получения первого ключа 'foo.urn.arpa.'.