Network Working Group Request for Comments: 4516 Категория: Standards Track Под редакцией M. Smith (Pearl Crescent, LLC), T. Howes (Opsware, Inc.) Июнь 2006 года Отменяет: 2255
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
В этом документе описан формат единого указателя ресурса (Uniform Resource Locator, URL) для протокола Lightweight Directory Access Protocol (LDAP). LDAP URL описывает поисковую операцию LDAP, которая используется для извлечения информации из каталога LDAP, либо, в контексте отсылки или перенаправления LDAP, LDAP URL описывает сервис, где может быть продолжено выполнение операции LDAP.
LDAP — это Lightweight Directory Access Protocol [RFC4510]. В этом документе даётся определение формата LDAP URL для 3-й версии протокола LDAP и разъясняется, каким образом разрешаются LDAP URL. В этом документе также определяется механизм расширения для LDAP URL. Данный механизм может использоваться для предоставления доступа к новым расширениям LDAP.
Имейте ввиду, что не все параметры операции поиска LDAP, описанной в [RFC4511], могут быть выражены с использованием определённого в этом документе формата. Также имейте ввиду, что URL могут быть использованы для представления данных отсылок, в том числе для операций, отличных от операции поиска.
Этот документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей определённую ранее техническую спецификацию LDAP, RFC 3377.
Этот документ заменяет RFC 2255. В приложении A перечислены изменения, внесённые в RFC 2255.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
LDAP URL начинается с префикса протокола "ldap" и определяется следующей грамматикой в нотации ABNF, определённой в RFC 4234:
ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]] ; <host> и <port> определены ; в разделах 3.2.2 и 3.2.3 ; [RFC3986]. ; <filter> определён в разделе 3 ; [RFC4515], при условии ; соблюдения положений ; представленного ниже раздела ; "Процент-кодирование". scheme = "ldap" dn = distinguishedName ; Из раздела 3 RFC 4514, ; при условии соблюдения положений ; представленного ниже раздела ; "Процент-кодирование". attributes = attrdesc *(COMMA attrdesc) attrdesc = selector *(COMMA selector) selector = attributeSelector ; Из раздела 4.5.1 RFC 4511, ; при условии соблюдения положений ; представленного ниже раздела ; "Процент-кодирование". scope = "base" / "one" / "sub" extensions = extension *(COMMA extension) extension = [EXCLAMATION] extype [EQUALS exvalue] extype = oid ; Из раздела 1.4 RFC 4512. exvalue = LDAPString ; Из раздела 4.1.2 RFC 4511, ; при условии соблюдения положений ; представленного ниже раздела ; "Процент-кодирование". EXCLAMATION = %x21 ; восклицательный знак ("!") SLASH = %x2F ; прямой слеш ("/") COLON = %x3A ; двоеточие (":") QUESTION = %x3F ; вопросительный знак ("?")
Префикс "ldap" означает, что запись или записи можно получить с LDAP-сервера, работающего на указанном хосте по указанному номеру порта. Имейте ввиду, что в конструкции <host> могут содержаться буквенные адреса IPv6, как определено в разделе 3.2.2 RFC 3986.
Конструкция <dn> — это уникальное имя LDAP, для которого используется строковый формат, описанный в RFC 4514. Оно идентифицирует базовый объект поиска LDAP или целевой объект для операций, отличных от операции поиска.
Конструкция <attributes> используется для указания того, какие атрибуты записи или записей должны быть возвращены.
Конструкция <scope> используется для указания диапазона поиска, который будет осуществлён на заданном LDAP-сервере. Допустимые диапазоны: "base" — для поиска по базовому объекту, "one" — для поиска на один уровень ниже базового объекта, или "sub" — для поиска по поддереву.
Конструкция <filter> используется для указания поискового фильтра, который будет применён к записям в пределах заданного диапазона при выполнении поиска. Его формат определён в RFC 4515.
Конструкция <extensions> обеспечивает для LDAP URL механизм расширения, позволяющий в будущем расширить возможности этого типа URL. Расширения представляют собой простой список разделённых запятыми пар тип=значение, в которых часть =значение может (MAY) быть опущена для тех параметров, где она не требуется. Каждая пара тип=значение представляет собой отдельное расширение. Расширения LDAP URL не обязательно связаны с каким-либо из механизмов расширения LDAP. Расширения могут как поддерживаться, так и не поддерживаться клиентом, разрешающим данный URL. Расширение, перед которым указан символ '!' (ASCII 0x21), является критичным. Расширение, перед которым не указан символ '!' (ASCII 0x21), является некритичным.
Если расширение LDAP URL реализовано (то есть, если какая-то конкретная реализация распознаёт его и может его использовать), то реализация должна (MUST) использовать это расширение. Если расширение не реализовано и помечено как критичное, то реализация не должна (MUST NOT) обрабатывать этот URL. Если расширение не реализовано и не помечено как критичное, то реализация должна (MUST) проигнорировать это расширение.
Тип расширения (<extype>) может (MAY) быть указан с использованием формы цифрового OID <numericoid> (например, 1.2.3.4) или формы описания <descr> (например, myLDAPURLExtension). При использовании формы <descr>, в качестве дескрипторов следует (SHOULD) использовать только зарегистрированные описательные имена идентификаторов объектов. Подробности по процедуре регистрации и рекомендации по использованию описательных имён можно найти в RFC 4520.
В этом документе не определяется никаких расширений LDAP URL. Расширения могут (MAY) быть определены в других документах или в будущих версиях этого документа.
Сгенерированный LDAP URL должен состоять только из ограниченного набора символов, удовлетворяющих одной из следующих трех ABNF-конструкций, определённых в RFC 3986:
<reserved> <unreserved> <pct-encoded>
Реализациям следует (SHOULD) принимать на вход и другие допустимые строки UTF-8 [RFC3629]. Октет должен (MUST) быть закодирован с помощью механизма процент-кодирования, описанного в разделе 2.1 RFC 3986 в любой из следующих ситуаций:
Этот октет не входит в набор <reserved>, определённый в разделе 2.2 RFC 3986, или в набор <unreserved>, определённый в разделе 2.3 RFC 3986.
Это единичный зарезервированный символ '?', и он встречается внутри компонентов <dn>, <filter>, либо других элементов LDAP URL.
Это символ запятой ',', который встречается внутри элемента <exvalue>.
Обратите внимание, что перед тем как механизм процент-кодирования будет применён, компонент <extensions> LDAP URL может содержать один или несколько null (нулевых) байтов. Никакой другой компонент содержать их не может.
Как указывалось выше, некоторые поля LDAP URL являются опциональными. Если не определено каких-либо иных спецификаций, то при отсутствии поля следует (SHOULD) использовать приведённые ниже общие соображения. Имейте ввиду, что в других документах могут (MAY) быть определены правила формирования значений по умолчанию, отличные от приведённых в этой спецификации; например, в разделе 4.1.10 RFC 4511 установлено альтернативное правило для определения корректного DN, которое нужно использовать при отсутствии DN в LDAP URL, возвращённого в качестве отсылки.
<host>
Если компонент <host> не задан, у клиента должны быть некоторые заранее полученные сведения о сервере LDAP, с которым он будет взаимодействовать.
<port>
Порт LDAP по умолчанию — это TCP-порт 389.
<dn>
Если компонент <dn> не задан, по умолчанию используется DN нулевой длины — "".
<attributes>
Если компонент <attributes> опущен, должны быть запрошены все пользовательские атрибуты записи или записей (как, например, при задании списка атрибутов в поле AttributeDescriptionList поискового запроса LDAP в NULL, или при использовании специальной конструкции <alluserattrs> "*").
<scope>
Если компонент <scope> опущен, подразумевается диапазон "base".
<filter>
Если компонент <filter> опущен, подразумевается фильтр "(objectClass=*)".
<extensions>
Если компонент <extensions> опущен, подразумевается, что никаких расширений нет.
Далее следуют несколько примеров LDAP URL, использующих определённый выше формат. Первый пример — LDAP URL, ссылающийся на запись Мичиганского Университета (University of Michigan), доступную на сервере LDAP, сведения о котором известны клиенту:
ldap:///o=University%20of%20Michigan,c=US
Следующий пример — LDAP URL, ссылающийся на запись Мичиганского Университета на конкретном LDAP-сервере:
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Оба этих URL соответствуют поиску с диапазоном "base", базовой записью "o=University of Michigan,c=US", фильтром "(objectclass=*)", с запросом всех атрибутов.
Следующий пример — LDAP URL, ссылающийся только на атрибут postalAddress записи Мичиганского Университета:
ldap://ldap1.example.net/o=University%20of%20Michigan, c=US?postalAddress
Соответствующая операция поиска LDAP — та же, что и в прошлом примере, за исключением того, что запрашивается только атрибут postalAddress.
Следующий пример — LDAP URL, ссылающийся на набор записей, запрашиваемый с заданного LDAP-сервера с порта 6666, при этом должен быть выполнен поиск любых записей с общепринятым именем (common name) "Babs Jensen" по всему поддереву каталога Мичиганского Университета с получением всех атрибутов:
ldap://ldap1.example.net:6666/o=University%20of%20Michigan, c=US??sub?(cn=Babs%20Jensen)
Следующий пример — LDAP URL, ссылающийся на все записи, дочерние c=GB:
LDAP://ldap1.example.com/c=GB?objectClass?ONE
Для возвращения вместе с записями запрашивается атрибут objectClass. Используется фильтр по умолчанию "(objectclass=*)".
Следующий пример — LDAP URL для получения атрибута mail LDAP-записи с именем "o=Question?,c=US", иллюстрирующий использование механизма процент-кодирования для зарезервированного символа '?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail
Следующий пример (разбит на две строки для повышения читабельности) иллюстрирует взаимодействие между механизмом экранирования строкового представления поискового фильтра LDAP и механизмом экранирования URL.
ldap://ldap3.example.com/o=Babsco,c=US ???(four-octet=%5c00%5c00%5c00%5c04)
В этом примере фильтр использует механизм экранирования LDAP с помощью обратного слеша \ для кодирования null (нулевых) байтов в значении. В LDAP данный фильтр будет записываться как (four-octet=\00\00\00\04). Поскольку в URL символ \ должен быть экранирован, эти символы кодируются в URL-кодировке как %5c (или %5C).
Следующий пример иллюстрирует взаимодействие между механизмом экранирования строкового представления DN в LDAP и механизмом экранирования URL.
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
В этом URL DN кодируется как:
o=An Example\2C Inc.,c=US
То есть первоначальное значение самого левого RDN:
An Example, Inc.
Три следующих URL эквивалентны. Подразумевается, что используются определённые в разделе 3 правила формирования значений по умолчанию:
ldap://ldap.example.net ldap://ldap.example.net/ ldap://ldap.example.net/?
Эти три URL указывают на запись root DSE сервера ldap.example.net.
Последние два примера демонстрируют использование гипотетического, экспериментального расширения для указания записи, от имени которой будет выполняться подсоединение (значение, ассоциируемое с этим расширением, представляет собой LDAP DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
Эти два URL аналогичны, за исключением того, что во втором расширение e-bindname помечено как критичное. Обратите внимание на использование механизма процент-кодирования для кодирования запятых в уникальном имени в значении расширения e-bindname.
Общие соображения по безопасности URL, обсуждаемые в [RFC3986], относятся и к LDAP URL.
Использование механизмов безопасности при обработке LDAP URL требует внимательного подхода в каждом конкретном случае, поскольку клиенты посредством URL могут взаимодействовать с большим количеством разнообразных серверов, а также потому, что URL, скорее всего, будут обрабатываться автоматически, без вмешательства пользователя. На клиенте должна (SHOULD) быть настраиваемая пользователем политика контроля того, с какими серверами этот клиент будет устанавливать LDAP-сеансы и какие механизмы безопасности будут при этом применяться, и клиенту не следует (SHOULD NOT) устанавливать LDAP-сеансы, не входящие в эту политику. Если клиент при разрешении одного или нескольких LDAP URL собирается повторно использовать существующий сеанс LDAP, он должен (MUST) убедиться, что данный сеанс совместим с этими URL и никакие политики безопасности не будут при этом нарушены.
Отправка данных аутентификации, вне зависимости от механизма, может нарушать требования пользователя по обеспечению конфиденциальности. В отсутствии конкретной политики, разрешающей посылать данные аутентификации на сервер, клиенту следует использовать анонимный сеанс LDAP. (Обратите внимание, что клиенты, удовлетворяющие требованиям предыдущей спецификации LDAP URL, в которой все сеансы LDAP являлись анонимными и незащищёнными, также соответствуют и данной спецификации; они просто используют политику безопасности по умолчанию). Простое открытие транспортного соединения с другим сервером может нарушать некоторые пользовательские требования по обеспечению конфиденциальности, поэтому клиентам следует предоставить пользователю возможность контроля за обработкой URL.
Некоторые методы аутентификации, в частности, метод аутентификации, в котором на сервер отправляются многоразовые пароли, могут привести к раскрытию конфиденциальной информации удалённому серверу, либо к прослушке её во время передачи по сети, и не должны использоваться в обработке URL, если только они не были явно разрешены политикой безопасности. В большинстве случаев уместно подтверждение использования данных аутентификации человеком. Гораздо предпочтительнее использовать методы строгой аутентификации, не приводящие к раскрытию конфиденциальной информации. В URL, представляющих собой ссылки на операции обновления каталога, следует (SHOULD) использовать методы строгой аутентификации. Дополнительную информацию можно найти в разделе, посвящённом безопасности, RFC 4513.
Формат LDAP URL позволяет запрашивать выполнение произвольной операции поиска LDAP. Обработка LDAP URL может привести к неожиданным результатам, например, получению большого объёма данных или инициализации продолжительных операций поиска. Соображения безопасности для реализаций разрешения LDAP URL аналогичны соображениям безопасности для обработки поисковых запросов LDAP.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, ноябрь 2003 г.
[RFC3986] Berners-Lee, T., Fielding, R. и L. Masinter, "URI: Generic Syntax", STD 66, RFC 3986, январь 2005 г.
[RFC4234] Crocker, D. и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Путеводитель по технической спецификации", RFC 4510, июнь 2006 г.
[RFC4511] Под редакцией Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.
[RFC4512] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC4512, июнь 2006 г.
[RFC4513] Под редакцией Harrison, R., "Lightweight Directory Access Protocol (LDAP): Методы аутентификации и механизмы обеспечения безопасности", RFC 4513, июнь 2006 г.
[RFC4514] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Строковое представление уникальных имён", RFC 4514, июнь 2006 г.
[RFC4515] Под редакцией Smith, M. и T. Howes, "Lightweight Directory Access Protocol (LDAP): Строковое представление поисковых фильтров", RFC 4515, июнь 2006 г.
[RFC2396] Berners-Lee, T., Fielding, R. и L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, август 1998 г.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, июнь 2006 г.
Первоначально формат LDAP URL был определён в Мичиганском Университете. Данный материал основан на работе, поддержка которой осуществлялась Национальным научным фондом США по гранту № NCR-9416667. Авторы высоко оценивают поддержку Мичиганского Университета и Национального научного фонда.
Этот документ отменяет RFC 2255, авторы Tim Howes и Mark Smith. Изменения, включённые в данную пересмотренную спецификацию, основаны на обсуждениях между авторами, обсуждениях в рабочей группе LDAP (v3) Revision (ldapbis), а также в других рабочих группах IETF. Авторы высоко оценивают вклад, внесённый представителями этих рабочих групп. Особой благодарности за их значительный вклад в этот документ заслуживают RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim и Hallvard Furuseth.
В раздел "Определение URL" внесены следующие технические изменения:
Пересмотрены все определения ABNF так, чтобы в них использовались общие конструкции из [RFC4512].
Ссылка на [RFC2396] заменена на [RFC3986] (это позволило использовать буквенные адреса IPv6 в конструкции <host>, об этом же читателю напоминается в примечаниях к определению URL). Указание [RFC3986] потребовало внесения изменений в определения ABNF и текст, поскольку те конструкции, которые больше не поддерживаются в [RFC3986], использовать было нельзя. Например, конструкция <hostport> не определена в [RFC3986], поэтому она была заменена на <host [COLON port]>. Обратите внимание, что [RFC3986] содержит новые определения для наборов символов "Reserved" и "Unreserved", в итоге это привело к тому, что два дополнительных символа "[" и "]", если они присутствуют где-либо в конструкции LDAP URL, должны быть закодированы с использованием процент-кодирования (изначально эти два символа были добавлены в набор "Reserved" в RFC 2732).
Изменено определение конструкции <attrdesc> так, чтобы она использовала конструкцию <attributeSelector> из [RFC4511]. Это позволило использовать символ "*" в части <attrdesc> URL. Считается, что существующие реализации RFC 2255 уже поддерживают такую возможность.
В правилах <dn>, <host>, <attrdesc> и <exvalue> не используются конструкции <prose-val> (строки в квадратных скобках).
Изменена ABNF для <ldapurl>: компонент <dn> сгруппирован с предшествующим <SLASH>.
Изменено правило <extype> так, чтобы оно соответствовало конструкции <oid> из [RFC4512].
Изменён текст о типах расширений, добавлена ссылка на [RFC4520].
Описание правил переупорядочено так, чтобы более точно соответствовать порядку, в котором элементы присутствуют в URL.
Раздел "Расширение Bindname" удалён, поскольку данное расширение практически нигде не было реализовано.
В заголовок документа добавлено указание протокола LDAP.
Примечание IESG: удалено замечание об отсутствии удовлетворительных механизмов аутентификации, обязательных для реализации.
Раздел "Статус документа": обновлён согласно новым требованиям к RFC.
Раздел "Тезисы" отделён от вступительного материала.
Добавлены разделы "Содержание" и "Интеллектуальная собственность".
Добавлен раздел "Введение" (отделён от "Тезисов"). Указано, что данный документ заменяет RFC 2255 (вместо RFC 1959). Добавлен текст о том, что LDAP URL используются для ссылок и отсылок. Исправлены стилистические ошибки. Добавлено замечание, поясняющее читателю, что не все параметры поисковой операции LDAP, описанной в [RFC4511], могут быть выражены с помощью данного формата.
Раздел "Определение URL": удалена вторая копия грамматики <ldapurl> и последующие два параграфа (ошибка редакторского плана в RFC 2255). Исправлен перенос строки внутри последовательности '!'. ABNF переформатирована для улучшения читабельности путём выравнивания комментариев и добавления пустых строк. В пояснениях, следующих за ABNF, формулировка "записи, содержащиеся на сервере LDAP" заменена на "записи, которые можно получить с LDAP-сервера". Удалена формулировка "индивидуальные имена attrdesc должны соответствовать определению AttributeDescription в [RFC4511]", поскольку конструкция <attributeSelector> из [RFC4511] теперь явно указана в ABNF. Переформулирован последний параграф для лучшего разъяснения, какие символы должны быть закодированы с применением процент-кодировки. Добавлен текст о том, что LDAP URL используются для ссылок и отсылок. Добавлено указание на ABNF из RFC 4234. Разъяснены и ужесточены требования в отношении обработки URL, содержащих реализованные и нереализованные расширения (для большего соответствия подходу, описанному в [RFC4511] для элементов управления LDAP).
Добавлен раздел "Значения по умолчанию для полей LDAP URL" (сформирован путём перемещения текста о значениях по умолчанию из раздела "Определение URL"). Прямое указание имени атрибута "*" заменено на ссылку на селектор <alluserattrs> "*", определённый в [RFC4511].
Удалён раздел "Обработка URL".
Раздел "Примеры": примеры изменены так, чтобы в них использовались имена хостов example.com и example.net. Добавлен недостающий знак '?' в пример LDAP URL, в котором фильтр содержит три null-байта. Удалены пробелы после запятых в DN. Пример с bindname переработан так, чтобы в нём использовалось расширение e-bindname. В одном из примеров для устранения возможной путаницы имя атрибута изменено с "int" на "four-octet". Добавлен пример, демонстрирующий взаимодействие между механизмом экранирования DN и механизмом экранирования URL. Добавлено несколько примеров, показывающих эквивалентность URL по отношению к части <dn> этих URL. В некоторых примерах использованы символы в верхнем регистре чтобы напомнить читателю, что определённые строковые значения являются нечувствительными к регистру символов.
Раздел "О безопасности": Добавлено замечание о повторном использовании соединения. Добавлено замечание об использовании методов строгой аутентификации для операций обновления. Добавлена ссылка на [RFC4513]. Добавлено замечание о том, что простое открытие соединения может нарушать требования некоторых пользователей по обеспечению конфиденциальности. Применена терминология LDAP, пересмотренная в ходе работы рабочей группы: слово "соединение" заменено по ситуации на "сеанс LDAP" или "соединение LDAP".
Раздел "Благодарности": добавлено заявление о том, что данный документ отменяет RFC 2255. Подчёркнут вклад Kurt Zeilenga, Jim Sermersheim и Hallvard Furuseth.
Раздел "Нормативные документы": переименован из "Документов" согласно новым требованиям к RFC. Стиль оформления ссылок изменён с [1] на [RFC4511] по всему документу. Добавлены ссылки на RFC 4234 и RFC 3629. Вместо ссылок на RFC 1738 указаны ссылки на соответствующие разделы [RFC3986]. Все ссылки на стандарты LDAP обновлены так, чтобы они ссылались на документы рабочей группы LDAPBis. Удалена ссылка на документ "Синтаксисы атрибутов LDAP" и добавлены ссылки на документы [RFC4513], [RFC4520] и [RFC4510].
Добавлен раздел "Информативные документы".
Заголовок и раздел "Адреса авторов": Mark Smith обозначен в качестве редактора документа. Обновлена информация о месте работы и контактная информация.
Уведомление об авторских правах: обновлён год.
По тексту документа: в описательном тексте все имена конструкций ABNF заключены в угловые скобки "<" и ">".
Mark Smith, редактор
Pearl Crescent, LLC, 447 Marlpool Dr. Saline, MI 48176, USA
Телефон: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Tim Howes
Opsware, Inc., 599 N. Mathilda Ave. Sunnyvale, CA 94085, USA
Телефон: +1 408 744-7509
EMail: howes@opsware.com
Copyright (C) Internet Society (2006).
На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу ietf-ipr@ietf.org.
Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).