RFC: 3404
Оригинал: Dynamic Delegation Discovery System - Part Four: The Uniform Resource Identifiers (URI) Resolution Application
Предыдущие версии: RFC 2168, RFC 2915
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3404, Страница 12 из 12

Литература

[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

Страница 12 из 12

2007 - 2017 © Русские переводы RFC, IETF, ISOC.