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

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

4.4.2. Протоколы

Идентификаторы протоколов, которые являются корректными значениями поля Protocol, должны определяться документами, относящимися к преобразованию URI. В настоящий момент единственным таким протоколом является THTTP [10].

Очень важно обеспечить, чтобы простого указания протокола в поле Services было недостаточно, поскольку имеется дополнительная семантика, относящаяся к преобразованию URI, которая не определена в протоколе. Например, если протокол Z39.50 указан в качестве корректного, нужно будет дополнительно определить как этот протокол будет представлять запросы для конкретных служб, как будут представляться идентификаторы URI и какая информация будет возвращаться.

4.4.3. Применимость сервиса

В силу возможности существования сложных наборов возможных протоколов и служб, у приложений часто может возникать необходимость использования более сложного процесса выбора, нежели простой просмотр упорядоченного списка протоколов. Например, при наличии 4 применимых правил в последнем значение поля Service может оказаться более предпочтительным, чем в первом. Но, поскольку клиент может быть удовлетворен первым, он просто не узнает о четвертом, который может оказаться «лучше».

Для упрощения этой задачи у клиента может возникнуть желание несколько изменить алгоритм DDDS (только для данного приложения!), чтобы определять наличие более предпочтительных протоколов и/или служб. Это можно сделать без опасений для данного приложения, используя более сложные итерации между п. 3 и п. 4 алгоритма DDDS для поиска оптимального пути. Например, после того, как клиент нашел правило, в котором Выражение для замены (Substitution Expression) дает результат с подходящим описанием сервиса, клиент может отметить этот факт и продолжить просмотр правил (в порядке, заданном значением Order!) для поиска наилучшего. Если лучшего правила не будет найдено, клиент сможет использовать отмеченное ранее правило.

Следует принимать во внимание, что для безопасной реализации сказанного входные данные п. 3 и выходные данные п. 4 должны быть идентичны базовому алгоритму. Для клиентской программы недопустимы попытки проведения оптимизации за пределами одного набора Правил перезаписи (т. е., со сменой путей передачи полномочий).

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

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