Литература
| [1] | Mealling, M., «Система DDDS. Часть 1 - DDDS в целом», RFC 3401, Октябрь 2002. |
| [2] | Mealling, M., «Система DDDS. Часть 2 - Алгоритм», RFC 3402, Октябрь 2002. |
| [3] | Mealling, M., «Система DDDS. Часть 3 - База данных DNS», RFC 3403, Октябрь 2002. |
| [4] | Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application», RFC 3404, Октябрь 2002. |
| [5] | Mealling, M., «Система DDDS. Часть 5 - Процедуры присваивания URI.ARPA», RFC 3405, Октябрь 2002. |
| [6] | Sollins, K. и L. Masinter, «Functional Requirements for Uniform Resource Names», RFC 1737, Декабрь 1994. |
| [7] | Arms, B., «The URN Implementors, Uniform Resource Names: A Progress Report», D-Lib Magazine, Февраль 1996. |
| [8] | Moats, R., «URN Syntax», RFC 2141, Май 1997. |
| [9] | Gulbrandsen, A., Vixie, P. и L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, Февраль 2000. |
| [10] | Daniel, R., «A Trivial Convention for using HTTP in URN Resolution», RFC 2169, Июнь 1997. |
| [11] | Mealling, M., «URI Resolution Services Necessary for URN Resolution», RFC 2483, Январь 1999. |
| [12] | Moore, K., Browne, S., Cox, J. и J. Gettler, «Resource Cataloging and Distribution System», Technical Report CS-97-346, Декабрь 1996. |
| [13] | Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, Январь 1998. |
| [14] | Daniel, R. и M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, Июнь 1997. |
| [15] | Berners-Lee, T., Fielding, R. и L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396, Август 1998. |
| [16] | Daigle, L., van Gulik, D., Iannella, R. и P. Falstrom, «URN Namespace Definition Mechanisms», RFC 2611, BCP 33, Июнь 1999. |
| [17] | Petke, R. и I. King, «Registration Procedures for URL Scheme Names», RFC 2717, BCP 35, Ноябрь 1999. |
| [18] | Mealling, M. и R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, Август 2000. |
Приложение A. Псевдо-код
В помощь разработчикам ниже приводится псевдо-код клиентской программы, использующей записи NAPTR. Этот код не задает стандартного способа обработки записей NAPTR. Кроме того, как всякий псевдо-код, он не может быть выполнен непосредственно и не исключена возможность наличия в нем логических ошибок. Мы вас предупредили.
//
// findResolver(URN)
// По данному значению URN найдем хост,
// который может преобразовать это значение.
//
findResolver(string URN) {
// добавляем префикс к ".urn.arpa."
sprintf(key, "%s.urn.arpa.", extractNS(URN));
do {
rewrite_flag = false;
terminal = false;
if (key has been seen) {
завершаем цикл при обнаружении ошибки
}
добавляем ключ key к списку значений seen
records = lookup(type=NAPTR, key); // получаем все записи NAPTR RR
// для ключа key
отбрасываем все записи с неизвестным значением поля flags.
сортируем записи NAPTR по значениям полей orderи preference
(сначала по order, а потом по preference).
n_naptrs = число записей NAPTR в отклике.
curr_order = records[0].order;
max_order = records[n_naptrs-1].order;
// обработка текущего пакета записей NAPTR в соответствии
// со значением поля order.
for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
if (unknown_flag) // пропускаем запись и переходим к следующей
continue;
newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
if (!newkey) // переходим к следующей записи если перезаписи
// не происходит
match continue;
// мы не делаем перезаписи и усекаем max_order до текущего значения,
// следовательно передача полномочий работает корректно
max_order = naptr[j].order;
// Если неизвестно, что делать с протоколом и службами
// из записи NAPTR, пытаемся работать со следующей записью.
if(!isKnownProto(naptr[j].services)) {
continue;
}
if(!isKnownService(naptr[j].services)) {
continue;
}
// К этому моменту перезапись успешно завершена и мы знаем,
// как сделать запрос к известной службе преобразования.
// Перед следующим просмотром проверяются флаги для определения
// дальнейших действий. Примечание: эту часть можно переписать
// так, чтобы корректная запись помечалась и процесс продолжался
// с целью поиска «лучшей» записи. Однако этот код достаточно
// велик, а наше приложение является лишь иллюстрацией.
if (strcasecmp(flags, "S")
|| strcasecmp(flags, "P"))
|| strcasecmp(flags, "A")) {
terminal = true;
services = naptr[j].services;
addnl = все записи SRV и/или A, возвращенные
как дополнение к naptr[j].
}
key = newkey;
rewriteflag = true;
break;
}
} while (rewriteflag && !terminal);
// Путь к преобразователю найден?
if (!rewrite_flag) {
сообщить об ошибке;
return NULL;
}
// Оставить дальнейшее другому протоколу?
if (strcasecmp(flags, "P")) {
возвратить ключ key, как хост для обращения;
}
// если нет, продолжаем
if (!addnl) { // В дополнительной информации нет записей SRV, ищем их
srvs = lookup(type=SRV, key);
}
сортируем записи SRV по полям preference, weight, ...
for each (SRV record) { // в порядке значений preference
пытаемся соединиться с srv[j].target, используя протокол и одну
из служб преобразования, в поле services последней записи NAPTR.
if (successful)
return (target, protocol, service);
// Возможно, мы будем в реальности возвращать результат,
// но этот код предполагает, что просто найден хороший
// хост для ссоединения с ним.
}
завершение с ошибкой "не удалось найти хост";
}
Адрес автора
Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166 US
URI: http://www.verisignlabs.com
EMail: ten.mynoen@leahcim