Network Working Group Request for Comments: 3296 Категория: Standards Track K. Zeilenga, OpenLDAP Foundation Июль 2002 года
Этот документ определяет стандарт протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) The Internet Society (2002). Все права защищены.
В этом документе описывается схема данных и элементы протокола для представления и управления именованными ссылками подчинённости в каталогах Lightweight Directory Access Protocol (LDAP).
Определения схемы данных предоставляются с использованием принятых в LDAPv3 форматов описания [RFC2252]. Представленные в этом документе определения отформатированы (разбиты на несколько строк) для повышения читабельности.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
Повышение интереса к каталогам LDAP (Lightweight Directory Access Protocol) [RFC2251] вне рамок их использования в качестве внешних интерфейсов к каталогам X.500 [X.500] привело к необходимости представлять информацию о взаимосвязях (knowledge information) в более общем виде. Информация о взаимосвязях — это информация об одном или нескольких серверах, поддерживаемая на другом сервере, которая используется для соединения серверов и служб друг с другом.
В этом документе описана схема данных и элементы протокола для представления и управления именованными ссылками подчинённости в каталогах LDAP. Объект referral используется для хранения в каталоге информации о ссылке подчинённости. В таких объектах referral в значениях атрибутов ref содержатся один или несколько URI [RFC2396], используемых для генерации таких элементов протокола, как отсылки и поисковые ссылки-продолжения.
Элемент управления ManageDsaIT определён для того, чтобы позволить производить манипуляции с объектами referral и другими специальными объектами как с нормальными объектами. Как следует из названия элемента управления, он должен быть аналогичен опции служб каталогов ManageDsaIT, описанной в X.511(97) [X.511].
В этом документе не даётся описаний других форм информации о взаимосвязях. Они могут быть описаны в последующих документах.
В этом документе подробно описаны требования для серверов по обработке ссылок подчинённости. В этом документе не описываются синтаксисы и семантики протокола. Они описываются в RFC 2251.
В этом документе нет описания порядка использования информации о взаимосвязях для поддержки реплицированных сред или распределённых операций (например, цепочки операций от одного сервера на другие серверы).
Объект referral представляет собой запись каталога со структурным объектным классом referral (или унаследованным от него).
( 2.16.840.1.113730.3.2.6
NAME 'referral'
DESC 'named subordinate reference object'
STRUCTURAL
MUST ref )
Объектный класс referral является структурным объектным классом, используемым для представления в каталоге ссылки подчинённости. Объектный класс referral следует (SHOULD) использовать в сочетании с объектным классом extensibleObject для поддержки атрибутов именования, используемых в уникальном имени (Distinguished Name, DN) [RFC2253] записи.
Обычно объекты referral создаются в DSE непосредственно дочерними по отношению к записям объектов в контексте именования, хранимом в DSA. Объекты referral являются аналогом объекта знаний о подчинённости (subr) в X.500 DSE [X.501].
При наличии элемента управления ManageDsaIT объекты referral обрабатываются как обычные записи согласно описанию в разделе 3. Обратите внимание, что атрибут ref является операционным и будет возвращён в ответ на поисковый запрос, только если он был явно запрошен.
При отсутствии элемента управления ManageDsaIT содержимое объектов referral используется для построения отсылок и поисковых ссылок-продолжений, как описано в разделе 4, и потому сами записи referral невидимы для клиентов.
( 2.16.840.1.113730.3.1.34
NAME 'ref'
DESC 'named reference - a labeledURI'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE distributedOperation )
Тип атрибута ref имеет синтаксис directoryString и его значения чувствительны к регистру символов. Атрибут ref является многозначным. Помещаемые в данный атрибут значения должны (MUST) соответствовать спецификации, заданной для атрибута labeledURI [RFC2079]. Спецификация labeledURI определяет формат, представляющий собой URI, за которым могут следовать пробел и метка. В данном документе метка из указанного синтаксиса не используется. В последующих документах может (MAY) быть определён новый функционал путём указания дополнительной структуры для поля метки в данном синтаксисе, когда это поле представлено в значении атрибута ref.
Если содержащийся в значении атрибута ref идентификатор URI ссылается на сервер LDAP [RFC2251], он должен (MUST) быть задан в форме LDAP URL [RFC2255]. В этом LDAP URL не должны (SHOULD NOT) содержаться явный спецификатор поискового диапазона, фильтр, список описаний атрибутов или любые расширения. В этом LDAP URL должен (SHOULD) содержаться непустой DN. Обработка LDAP URL с отсутствующей или пустой частью DN, либо с явно указанным спецификатором поискового диапазона данной спецификацией не определяется.
Могут быть (MAY) использованы и другие схемы URI, если это позволяет выполнить все операции, возвращающие отсылки на основании значения URI. В данном документе не раскрывается использование других URI, помимо LDAP. Это предмет будущих спецификаций.
Серверу, хранящему или возвращающему URI, не следует (SHOULD NOT) проверять ссылочную целостность этого URI (будь то значение атрибута, составная часть результата referral или ссылки-продолжения ответа операции поиска).
При возврате результата referral или поисковой ссылки-продолжения сервер не должен (MUST NOT) возвращать как часть этой ссылки разделитель или метку из значений атрибута. Если у атрибута несколько значений, то при построении результата referral или поисковой ссылки-продолжения используются части URI каждого из этих значений.
Значения атрибута ref не следует (SHOULD NOT) использовать в качестве относительного компонента имени DN записи каталога [RFC2253].
В этом документе атрибут ref используется в сочетании с объектным классом referral для представления ссылок подчиненности. В других документах может быть определено использование атрибута ref для иных целей.
Клиент может предоставлять с какой-либо операцией элемент управления ManageDsaIT, чтобы указать, что эта операция предназначена для управления объектами в информационном дереве DSA (сервера). При наличии данного элемента управления специфичные для каталога записи (Directory-specific entries, DSE), независимо от их типа, должны обрабатываться как нормальные записи, позволяя клиентам опрашивать и обновлять эти записи с помощью операций LDAP.
Клиент может (MAY) указывать этот элемент управления при выполнении запросов add, compare, delete, modify, modifyDN, search, либо с расширенными операциями, для которых этот элемент управления определён.
Тип элемента управления — 2.16.840.1.113730.3.4.2. Поле criticality элемента управления может быть либо установлено в TRUE, либо отсутствовать (что будет означать FALSE). Значение элемента управления отсутствует.
При наличии данного элемента управления в запросе серверу не нужно (SHALL NOT) генерировать отсылку или ссылку-продолжение на основании хранимой в объектах referral информации, вместо этого ему нужно (SHALL) рассматривать объект referral как обычную запись. Тем не менее, сервер по-прежнему может возвращать отсылки по иным причинам. При отсутствии данного элемента управления с объектами referral нужно (SHALL) обращаться, как описано выше.
Наличие данного элемента управления может (MAY) приводить к тому, что и другие объекты будут рассматриваться как обычные записи. Это будет определено в последующих документах.
Именованная ссылка подчиненности организуется путем создания экземпляра объекта referral на ссылающемся сервере со значениями атрибута ref, которые указывают на соответствующее поддерево, обслуживаемое на сервере, на который указывает ссылка. В общем случае имя объекта referral совпадает с именем объекта, на который происходит ссылка, и этот объект ссылки представляет собой префикс контекста [X.501].
То есть, если на сервере A хранится контекст "DC=example,DC=net", а на сервере B хранится контекст "DC=sub,DC=example,DC=net", то на сервере A может содержаться объект referral с именем "DC=sub,DC=example,DC=net", в котором будет атрибут ref со значением "ldap://B/DC=sub,DC=example,DC=net".
dn: DC=sub,DC=example,DC=net
dc: sub
ref: ldap://B/DC=sub,DC=example,DC=net
objectClass: referral
objectClass: extensibleObject
Обычно DN объекта referral и DN объекта на сервере, на который происходит ссылка, совпадают.
Если у атрибута ref несколько значений, всем содержащимся в LDAP URL именам DN следует (SHOULD) быть эквивалентными. Администраторам при использовании ссылок следует (SHOULD) избегать создания таких конфигураций, при которых будет возможно зацикливание по именам.
Если в запрос включён элемент управления ManageDsaIT, то именованная ссылка должна (MUST) рассматриваться как обычная запись согласно описанию в разделе 3.
В следующих подразделах содержатся спецификации использования объектов referral в различных сценариях, за которыми следуют примеры, иллюстрирующие такое использование. В описываемых здесь сценариях рассматривается обработка объекта referral при нахождении целевой записи непоисковой операции, при нахождении базы операции поиска и при создании поисковых ссылок. В конце представлены соображения по обработке других операций.
Следует иметь ввиду, что в этом документе операция поиска концептуально разделяется на две отдельные последовательные фазы: (1) нахождение базового объекта, от которого должен начинаться поиск, и (2) выполнение самого поиска. Первая фаза аналогична поиску целевой записи непоисковой операции, но не совпадает с ней.
Также следует иметь ввиду, что атрибут ref может иметь несколько значений, и там, где в последующих подразделах указано единственное значение атрибута ref, может быть подставлено несколько значений атрибута ref. В этом случае их следует (SHOULD) обрабатывать и возвращать (в любом порядке) как группу в результате referral или поисковой ссылке таким же образом, как описано для единственного значения атрибута ref.
Поисковые ссылки-продолжения, возвращаемые в ответ на конкретный запрос, могут быть возвращены в любом порядке.
Например, предположим, что сервер, к которому выполняется подключение (hosta), содержит запись "O=MNN,C=WW" и запись "CN=Manager,O=MNN,C=WW", а также следующие объекты referral:
dn: OU=People,O=MNN,C=WW
ou: People
ref: ldap://hostb/OU=People,O=MNN,C=US
ref: ldap://hostc/OU=People,O=MNN,C=US
objectClass: referral
objectClass: extensibleObject
dn: OU=Roles,O=MNN,C=WW
ou: Roles
ref: ldap://hostd/OU=Roles,O=MNN,C=WW
objectClass: referral
objectClass: extensibleObject
В первом предоставляемом данным сервером объекте referral указана информация о взаимосвязях, согласно которой поддерево "OU=People,O=MNN,C=WW" содержится на серверах hostb и hostc (например, один из них является главным сервером, а второй — резервной копией). Во втором предоставляемом данным сервером объекте referral указана информация о взаимосвязях, согласно которой поддерево "OU=Roles,O=MNN,C=WW" содержится на сервере hostd.
Также, в контексте этого документа, под "ближайшим контекстом именования" понимается наиболее глубокий контекст, в котором находится объект. То есть, если объект находится в нескольких контекстах именования, то ближайшим контекстом именования будет тот, который подчиняется всем другим контекстам именования, в которых находится данный объект.
В этом разделе описывается обработка ссылок для операций add, compare, delete, modify и modify DN. Если клиент запрашивает какую-либо из этих операций, то существует четыре возможных случая в отношении к целевому объекту операции, которые сервер должен уметь обработать.
Часть DN должна (MUST) быть модифицирована так, чтобы она ссылалась на соответствующую запись на указанном сервере (как описано ниже). Даже если DN, которое требуется вернуть, совпадает с целевым DN, часть DN не следует (SHOULD NOT) удалять из URI.
В случае, если возвращаемый URI представляет собой LDAP URL, серверу перед возвращением такого URI следует (SHOULD) удалить из него любые присутствующие компоненты поискового диапазона, фильтра или списка атрибутов. Критические расширения не должны (MUST NOT) быть удалены или модифицированы.
Случай 1: Целевой объект не хранится на данном сервере, а также не находится в составе или в подчинении какому-либо контексту именования, либо в подчинении к какому-либо объекту referral, содержащимся на данном сервере.
Серверу следует (SHOULD) обрабатывать такой запрос обычным образом, в соответствии с порядком действий для несуществующей базы поиска, находящейся за пределами какого-либо контекста именования данного сервера (обычно возвращается ответ с кодом noSuchObject, либо отсылка, сформированная на основании информации о взаимосвязях, указывающей на вышестоящие каталоги (superior knowledge reference information)). В этом документе не даётся описание порядка управления или обработки информации о взаимосвязях, указывающей на вышестоящие каталоги.
Случай 2: Целевой объект хранится на данном сервере и является объектом referral.
Серверу следует (SHOULD) вернуть значение URI, содержащееся в атрибуте ref объекта referral, после применения описанных выше модификаций.
Пример: Если от клиента поступил запрос modify для целевого объекта "OU=People,O=MNN,c=WW", сервер вернёт:
ModifyResponse (referral) {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
Случай 3: Целевой объект не хранится на данном сервере, и в ближайшем контексте именования не содержится объект referral, которому подчинялся бы этот целевой объект.
Если в ближайшем контексте именования не содержится объект referral, которому подчинялся бы целевой объект, то серверу следует (SHOULD) обработать такой запрос в соответствии с порядком действий для несуществующего целевого объекта (обычно возвращается ответ с кодом noSuchObject).
Случай 4: Целевой объект не хранится на данном сервере, но в ближайшем контексте именования содержится объект referral, которому подчиняется этот целевой объект.
Если клиент запрашивает операцию, целевой объект которой не хранится на данном сервере, но в ближайшем контексте именования содержится объект referral, которому подчиняется этот целевой объект, серверу следует (SHOULD) вернуть ответ referral, построенный из части URI значения атрибута ref этого объекта referral.
Пример: Если от клиента поступил запрос add для целевого объекта c DN "CN=Manager,OU=Roles,O=MNN,C=WW", сервер вернёт:
AddResponse (referral) {
ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
}
Обратите внимание, что в LDAP URL часть DN была модифицирована так, чтобы она ссылалась на соответствующую запись на указанном сервере.
В этом разделе описывается обработка ссылок при работе с базовым объектом в операциях search. Как и при работе с целевыми объектами для непоисковых операций, здесь возможны четыре случая.
В случае, если возвращаемый URI представляет собой LDAP URL, сервер перед его возвращением должен (MUST) предоставить явный поисковый диапазон из этого LDAP URL. Кроме того, часть DN должна (MUST) быть модифицирована так, чтобы она ссылалась на соответствующую целевую запись на указанном сервере (как описано ниже).
Если для нахождения объекта referral было необходимо выполнить разыменование псевдонима, часть DN в URI должна (MUST) быть заменена базовым DN, изменённым в процессе разыменования псевдонима таким образом, чтобы возвращаемый URL ссылался на новый целевой объект согласно требованиям раздела 4.1.11 RFC2251.
Критические расширения не должны (MUST NOT) быть удалены или модифицированы.
Случай 1: Базовый объект не хранится на данном сервере, а также не находится в составе или в подчинении какому-либо контексту именования, содержащемуся на данном сервере.
Серверу следует (SHOULD) обрабатывать такой запрос обычным образом, в соответствии с порядком действий для несуществующей базы поиска, находящейся за пределами какого-либо контекста именования данного сервера (обычно возвращается отсылка, сформированная на основании информации о взаимосвязях, указывающей на вышестоящие каталоги, либо ответ с кодом noSuchObject). В этом документе не даётся описание порядка управления или обработки информации о взаимосвязях, указывающей на вышестоящие каталоги.
Случай 2: Базовый объект хранится на данном сервере и является объектом referral.
Серверу следует (SHOULD) вернуть значение URI, содержащееся в атрибуте ref объекта referral, после применения описанных выше модификаций.
Пример: Если от клиента поступил запрос search с диапазоном subtree, базовый объект которого "OU=Roles,O=MNN,C=WW", сервер вернёт:
SearchResultDone (referral) {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
Если бы клиент запрашивал операцию search с диапазонами base или oneLevel вместо subtree, в возвращаемом LDAP URL нужно было бы явно указать, соответственно, "base" или "one", вместо "sub".
Случай 3: Базовый объект не хранится на данном сервере, и в ближайшем контексте именования не содержится объект referral, которому подчинялся бы этот базовый объект.
Если в ближайшем контексте именования не содержится объект referral, которому подчинялся бы базовый объект, то серверу следует (SHOULD) обработать такой запрос в соответствии с порядком действий для несуществующего базового объекта (обычно возвращается ответ с кодом noSuchObject).
Случай 4: Базовый объект не хранится на данном сервере, но в ближайшем контексте именования содержится объект referral, которому подчиняется этот базовый объект.
Если клиент запрашивает операцию, целевой объект которой не хранится на данном сервере, но в ближайшем контексте именования содержится объект referral, которому подчиняется этот целевой объект, серверу следует (SHOULD) вернуть ответ referral, построенный из части URI значения ref этого объекта referral.
Пример: Если от клиента поступил запрос search с диапазоном base и базой поиска "CN=Manager,OU=Roles,O=MNN,C=WW", сервер вернёт:
SearchResultDone (referral) {
ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
}
Если бы клиент запрашивал операцию search с диапазонами subtree или oneLevel вместо base, в возвращаемом LDAP URL нужно было бы явно указать, соответственно, "sub" или "one", вместо "base".
Обратите внимание, что в LDAP URL часть DN была модифицирована так, чтобы она ссылалась на соответствующую запись на указанном сервере.
В операциях поиска search после того, как базовый объект был найден и установлено, что он не является объектом referral, можно осуществлять поиск. Любая запись, соответствующая поисковому фильтру и диапазону, и не являющаяся объектом referral, возвращается клиенту нормальным образом, как описано в [RFC2251].
Для каждого объекта referral, попадающего в запрашиваемый поисковый диапазон, независимо от поискового фильтра, серверу следует (SHOULD) возвратить SearchResultReference, сконструированный из компонента URI значения атрибута ref. Если этот компонент URI не является LDAP URL, его следует возвращать без изменений. Если часть DN в LDAP URL отсутствует или пуста, данная часть DN должна быть модифицирована так, чтобы содержать DN объекта referral. Если рассматриваемый компонент URI является LDAP URL, этот URI следует (SHOULD) модифицировать так, чтобы добавить явный спецификатор поискового диапазона.
Пример с диапазоном Subtree:
Если клиент запросил поиск с диапазоном subtree по поддереву "O=MNN,C=WW", то в дополнение к любым записям в этом диапазоне, соответствующим запрашиваемому фильтру, hosta также вернёт две поисковые ссылки-продолжения, поскольку в диапазон поиска попали два объекта referral. Один из возможных ответов в этом случае:
SearchEntry for O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW??sub
ldap://hostc/OU=People,O=MNN,C=WW??sub
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
SearchResultDone (success)
Пример с диапазоном One Level:
Если клиент запросил поиск с диапазоном one level по поддереву "O=MNN,C=WW", то в дополнение к любым записям на один уровень ниже записи "O=MNN,C=WW", соответствующим запрашиваемому фильтру, сервер также вернёт две поисковые ссылки-продолжения, поскольку в диапазон поиска попали два объекта referral. Один из возможных ответов в этом случае:
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW??base
ldap://hostc/OU=People,O=MNN,C=WW??base
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??base
}
SearchResultDone (success)
Примечание: В отличие от примеров, приведённых в разделе 4.5.3.1 RFC 2251, возвращаемые в сообщениях SearchResultReference LDAP URL согласно требованиям данной спецификации содержат явно указанный поисковый диапазон.
В этом разделе приводятся детали обработки других операций.
Серверам не следует (SHOULD NOT) возвращать результирующий код referral, если используемое в операции bind имя (либо аутентификационная или авторизационная сущность) является объектом referral (или подчиняется ему), но они могут (MAY) использовать информацию о взаимосвязях для обработки запроса bind (например, для поддержки будущих спецификаций распределённых операций). Если сервер не может использовать информацию о взаимосвязях, он обрабатывает запрос нормальным образом как для несуществующей аутентификационной или авторизационной сущности (например, возвращать invalidCredentials).
Если запись, указанная в значении поля newSuperior, представляет собой объект referral или подчиняется объекту referral, серверу следует (SHOULD) вернуть affectsMultipleDSAs. Если запись с RDN, указанным в поле newRDN, уже существует, но является объектом referral, серверу следует (SHOULD) вернуть affectsMultipleDSAs вместо entryAlreadyExists.
В этом документе определены механизмы, которые можно использовать для связывания LDAP-серверов (и других серверов) вместе. Информацию, используемую для связывания сервисов, следует защищать от неавторизованной модификации. Если информация об адресации серверов в сети не является общедоступной, её также следует защитить от неавторизованного раскрытия.
Этот документ во многом заимствован из предшествующих публикаций рабочей группы IETF LDAPext. В частности, он основан на просроченном черновом стандарте (Internet Draft) "Именованные ссылки в каталогах LDAP" от Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith и Mark Wahl.
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, январь 1997 г.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC2251] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997 г.
[RFC2253] Wahl, M., Kille, S. и T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, декабрь 1997 г.
[RFC2255] Howes, T. и M. Smith, "The LDAP URL Format", RFC 2255, декабрь 1997 г.
[RFC2396] Berners-Lee, T., Fielding, R. и L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, август 1998 г.
[X.501] ITU-T, "The Directory: Models", X.501, 1993 г.
[X.500] ITU-T, "The Directory: Overview of Concepts, Models, and Services", X.500, 1993 г.
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.500, 1997 г.
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Copyright (C) Internet Society (2003). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.