Network Working Group Request for Comments: 4521 BCP: 118 Категория: Best Current Practice K. Zeilenga, OpenLDAP Foundation Июнь 2006 года
Этот документ определяет лучший современный опыт Интернет (Internet Best Current Practices) для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
Lightweight Directory Access Protocol (LDAP) является расширяемым протоколом. Он предоставляет механизмы для добавления новых операций, расширения существующих операций, а также расширения пользовательских и системных схем данных. В этом документе обсуждаются соглашения для проектировщиков расширений LDAP.
Lightweight Directory Access Protocol (LDAP) [RFC4510] является расширяемым протоколом.
LDAP позволяет добавлять новые операции и расширять существующие [RFC4511].
LDAP позволяет определять дополнительные схемы данных [RFC4512][RFC4517]. Это могут быть дополнительные объектные классы, типы атрибутов, правила соответствия, дополнительные синтаксисы и другие элементы схемы данных каталога. LDAP предоставляет возможность расширять типы атрибутов с помощью опций [RFC4512].
LDAP поддерживает метод аутентификации Simple Authentication and Security Layer (SASL) [RFC4511][RFC4513]. SASL [RFC4422] является расширяемым механизмом. LDAP может быть расширен для поддержки дополнительных методов аутентификации [RFC4511].
LDAP поддерживает установление соединения с использованием протокола Transport Layer Security (TLS) [RFC4511][RFC4513]. TLS [RFC4346] является расширяемым протоколом.
У LDAP расширяемый формат единого указателя ресурса (Uniform Resource Locator, URL) [RFC4516].
Наконец, LDAP позволяет выполнять некоторые расширения в определении конструкций протокола, описанных в нотации Abstract Syntax Notation - One (ASN.1) [X.680]. Это может способствовать усовершенствованию протокола в широком диапазоне, например, добавлению новых результирующих кодов, требуемых для поддержки новых расширений, путём дополнения ASN.1-определения протокола.
В этом документе описываются практики и методы, которые должны учитываться инженерами при проектировании расширений для LDAP.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119]. В данном документе термин "спецификация", используемый в BCP 14, RFC 2119, относится к разработке расширений LDAP.
Термин "Элемент управления запроса" ("Request Control") относится к элементу управления, прикреплённому к сгенерированному клиентом сообщению, отправленному на сервер. Термин "Элемент управления ответа" ("Response Control") относится к элементу управления, прикреплённому к сгенерированному сервером сообщению, отправленному клиенту.
DIT означает информационное дерево каталога (Directory Information Tree). DSA означает системный агент каталога (Directory System Agent), то есть сервер. DSE означает специфичная для DSA запись (DSA-Specific Entry). DUA означает пользовательский агент каталога (Directory User Agent), то есть клиент. DN означает уникальное имя (Distinguished Name).
По взаимному соглашению узлов, совершающих обмен по протоколу, в пределах некоторого расширения могут быть внесены значительные изменения в семантику протокола. Однако проектировщики должны (MUST) учитывать влияние расширения на те узлы, совершающие обмен по протоколу, которые не согласились реализовать или иным образом распознать и осуществить поддержку данного расширения. Расширения должны (MUST) быть "действительно необязательными" ("truly optional") [RFC2119].
Проектировщикам следует (SHOULD) учитывать, как разработанные ими расширения взаимодействуют с другими расширениями.
Проектировщикам следует (SHOULD) учитывать расширяемость тех расширений, которые они специфицируют. Расширениям LDAP следует (SHOULD) самим быть расширяемыми.
За исключением случаев, когда указано иное, расширяемость подразумевается.
Расширениям следует (SHOULD) предоставлять адекватные механизмы обнаружения.
Дизайн LDAP основан на парадигме "запрос клиента/ответ сервера", основной подход к обнаружению заключается в том, что клиент должен определить возможности сервера, прежде чем использовать конкретное расширение. Обычно это обнаружение предполагает запрос в корневой DSE и/или других DSE операционной информации, связанной с расширением. LDAP не предоставляет механизм обнаружения сервером возможностей клиента.
Атрибут 'supportedControl' [RFC4512] используется для афиширования поддерживаемых элементов управления. Атрибут 'supportedExtension' [RFC4512] используется для афиширования поддерживаемых операций расширения. Атрибут 'supportedFeatures' [RFC4512] используется для афиширования функций. Для афиширования других возможностей могут (MAY) быть определены другие атрибуты корневой DSE.
LDAP спроектирован для поддержки полного набора символов Unicode [Unicode]. Расширениям следует (SHOULD) избегать без необходимости ограничивать приложения подмножествами Unicode (такими как Basic Multilingual Plane, ISO 8859-1, ASCII, Printable String).
Опции языковых тэгов LDAP [RFC3866] предоставляют механизм для тэгирования текстовых (и других) значений информацией о языке. Расширениям, определяющим типы атрибутов, следует (SHOULD) разрешать использование языковых тэгов с этими атрибутами.
Многие элементы LDAP описаны с использованием ASN.1 [X.680] и кодируются с применением конкретного подмножества [RFC4511, раздел 5.1] Базовых правил кодирования (Basic Encoding Rules, BER) [X.690]. Для того, чтобы можно было применять те же синтаксические анализаторы/генераторы, которые были использованы в реализации "ядра" технической спецификации LDAP [RFC4510], рекомендуется (RECOMMENDED), чтобы элементы расширения (например, специфичное для расширения содержимое полей controlValue, requestValue, responseValue) описывались с помощью ASN.1 и кодировались с использованием BER с ограничениями согласно разделу 5.1 RFC 4511.
В спецификациях, в соответствии с методическими рекомендациями IESG [FORMAL], следует использовать формальные языки.
В примерах строки DN должны (SHOULD) соответствовать синтаксису, определенному в [RFC4514]. В примерах строки поисковых фильтров LDAP должны (SHOULD) соответствовать синтаксису, определенному в [RFC4515]. В примерах LDAP URL должны (SHOULD) соответствовать синтаксису, определенному в [RFC4516]. Записи должны (SHOULD) быть представлены с использованием LDIF [RFC2849].
Проектировщикам нужно (SHALL) регистрировать значения протокола своих расширений LDAP в соответствии с BCP 64 [RFC4520]. В спецификациях, в которых создаются новые расширяемые элементы протокола, нужно (SHALL) либо расширять существующие регистрации, либо создавать новые регистрации для значений таких элементов в соответствии с BCP 64 [RFC4520] и BCP 26 [RFC2434].
При определении расширений, дополняющих существующие операции, следует (SHOULD) использовать элементы управления. В случаях, когда определяемое расширение не дополняет существующую операцию, проектировщикам следует (SHOULD) рассмотреть возможность вместо элемента управления определить операцию-расширение.
Например, операция удаления поддерева может быть спроектирована либо как расширение операции удаления, либо как новая операция. Поскольку данный функционал дополняет существующую операцию удаления, то в этом случае использование механизма элементов управления для расширения операции удаления, вероятно, является более подходящим.
В качестве контрпримера (не из существующей практики) можно привести операцию определения сервисов (операция будет возвращать для DN набор LDAP URL на сервисы, в которых может использоваться запись, названная этим DN). Такая операция может быть спроектирована либо как расширение операции поиска, либо как новая операция. Поскольку данный функционал не дополняет существующую операцию поиска (например, операция не предназначена для поиска записей, содержащихся в Информационном дереве каталога), то, вероятно, более подходящим в этом случае будет определение новой операции с использованием механизма операций-расширений.
Элементы управления [раздел 4.1.11 RFC 4511] являются рекомендуемым (RECOMMENDED) механизмом для расширения существующих операций. Существующей операцией может быть базовая операция, определённая в RFC4511 (например, Search, Modify), операция-расширение (например, Start TLS [RFC4511], Password Modify [RFC3062]), либо операция, определённая как расширение к базовой операции или операции-расширению.
Расширениям не следует (SHOULD NOT) возвращать элементы управления ответа, если у сервера отсутствует определённая осведомлённость о том, что клиент может использовать этот элемент управления. Как правило, клиент запрашивает возврат определенного элемента управления ответа, предоставляя связанный с ним элемент управления запроса.
Существующая операция может (MAY) быть расширена так, чтобы возвращать сообщение IntermediateResponse [раздел 4.13 RFC 4511].
Спецификациям не нужно (SHALL NOT) добавлять дополнительные семантики к полю criticality элементов управления помимо тех, которые определены в [разделе 4.1.11 RFC 4511]. В спецификациях может (MAY) выдвигаться обязательное требование, чтобы поле criticality принимало определенное значение (например, TRUE или FALSE) там, где это уместно.
Элементы управления, прикрепляемые к сообщениям запроса и ответа операции Bind [RFC4511], не защищены никакими уровнями обеспечения безопасности, устанавливаемыми этой операцией Bind.
В спецификациях, описывающих расширяющие операцию Bind элементы управления, нужно (SHALL) указывать, что согласованные операцией Bind уровни обеспечения безопасности не защищают информацию, содержащуюся в этих элементах управления, а также нужно (SHALL) указывать, каким образом защищается информация в этих элементах управления, либо почему её не требуется защищать.
Рекомендуется (RECOMMENDED), чтобы проектировщики рассматривали альтернативные механизмы для выполнения желаемой функции. Например, для обеспечения выполнения желаемой функции может быть использован вызов операции-расширения вслед за операцией Bind (тогда операция-расширение будет защищена уровнями обеспечения безопасности, согласованными в ходе операции Bind).
Кроме того, проектировщики расширения операции Bind в виде элемента управления также должны (MUST) рассмотреть вопрос о том, как семантика элементов управления взаимодействует с отдельными шагами многошаговой операции Bind. Обратите внимание, что некоторые из этих шагов являются опциональными, и потому могут потребовать особого внимания при проектировании.
Элементы управления, прикрепляемые к сообщениям запроса и ответа операции Start TLS [RFC4511], не защищены уровнями обеспечения безопасности, устанавливаемыми этой операцией Start TLS.
В спецификациях, описывающих расширяющие операцию Start TLS элементы управления, нужно (SHALL) указывать, что согласованные операцией Start TLS уровни обеспечения безопасности не защищают информацию, содержащуюся в этих элементах управления, а также нужно (SHALL) указывать, каким образом защищается информация в этих элементах управления, либо почему её не требуется защищать.
Рекомендуется (RECOMMENDED), чтобы проектировщики рассматривали альтернативные механизмы для выполнения желаемой функции. Например, для обеспечения выполнения желаемой функции может быть использован вызов операции-расширения вслед за операцией Start TLS (тогда операция-расширение будет защищена уровнями обеспечения безопасности, согласованными в ходе операции Start TLS).
В обработке операции Search есть две отдельные фазы:
В спецификациях, описывающих расширяющие операцию Search элементы управления, следует чётко указать, в какой фазе (фазах) применяется семантика конкретного элемента управления. Семантики элементов управления, не специфичных для операции Search, следует (SHOULD) применять в первой фазе (на этапе определения базового объекта).
Операции обновления имеют свойства атомарности, согласованности, изолированности и стойкости ([ACID]):
При определении элемента управления, запрашивающего выполнение дополнительных (или иных) изменений в DIT, эти дополнительные изменения не должны (SHOULD NOT) рассматриваться как часть отдельной транзакции. Спецификация должна (MUST) ясно определять, являются ли дополнительные изменения DIT частью той же транзакции, что и изменения DIT, выраженные в запросе базовой операции, либо частью отдельной транзакции.
При определении элемента управления, запрашивающего выполнение дополнительных (или иных) изменений в DIT, спецификация должна (MUST) ясно определять порядок, в котором эти изменения и базовые изменения должны применяться в DIT.
Операции Abandon и Unbind не включают сообщение ответа. Поэтому в спецификациях элементов управления, разработанных для присоединения к запросам Abandon и Unbind, следует (SHOULD) выдвигать обязательное требование о том, что поле criticality такого элемента управления должно быть установлено в FALSE.
Операции-расширения [раздел 4.12 RFC 4511] являются рекомендуемым (RECOMMENDED) механизмом для определения новых операций. Операция расширение состоит из сообщения ExtendedRequest, нуля или более сообщений IntermediateResponse и сообщения ExtendedResponse.
Для возврата промежуточных результатов расширениям нужно (SHALL) использовать сообщение IntermediateResponse вместо сообщения ExtendedResponse.
Произвольные уведомления [раздел 4.4 RFC 4511] предлагают серверу возможность уведомлять клиента о событиях, не связанных с обрабатываемой в данный момент операцией.
Расширения следует (SHOULD NOT) проектировать так, чтобы произвольные уведомления не возвращались, если у сервера отсутствует определённая осведомлённость о том, что клиент может использовать эти уведомления. Как правило, клиент запрашивает возврат определенного произвольного уведомления, выполняя соответствующую операцию-расширение.
Например, расширение синхронизации времени может быть спроектировано так, чтобы через определённые промежутки времени возвращать произвольные уведомления, отправка которых инициируется операцией-расширением (которая, возможно, задаёт желаемый интервал посылок).
LDAP позволяет производить ограниченное расширение [раздел 4 RFC 4511] определения ASN.1 для LDAP [приложение B к RFC 4511].
Расширениям, определяющим новые операции или усовершенствующим существующие операции, часто требуется определять новые результирующие коды. Расширению следует (SHOULD) быть спроектированным таким образом, чтобы у клиента было достаточно чёткое указание характера успешного или неуспешного результата.
Расширениям следует (SHOULD) использовать существующие результирующие коды для указания на возникновение условий, соответствующих предполагаемому значению этих кодов [RFC4511][X.511]. Расширения могут (MAY) вводить новые результирующие коды [RFC4520], если нет существующего результирующего кода, обеспечивающего адекватное указание на характер результата.
Расширения не должны (SHALL NOT) запрещать или иным образом ограничивать возврат результирующих кодов общего назначения, особенно тех, которые сообщают о проблемах протокола, работы сервиса или нарушения безопасности, либо указывают, что сервер не может или не желает выполнить операцию.
Хотя расширения могут определять новые типы сообщений LDAP путём дополнения структуры CHOICE protocolOp последовательности SEQUENCE LDAPMessage новыми вариантами, как правило, это не нужно и неуместно. Вместо этого следует (SHOULD) использовать существующие механизмы расширения операций (такие как операции-расширения, произвольные уведомления и промежуточные ответные сообщения). Однако возможны случаи, когда расширение не вписывается в эти механизмы.
В таких случаях следует (SHOULD) определить новый механизм так, чтобы он мог быть использован несколькими расширениями, имеющими схожие потребности.
В настоящий момент операция Bind поддерживает два метода аутентификации: Simple и SASL. SASL [RFC4422] представляет собой расширяемую платформу аутентификации, используемую многими протоколами прикладного уровня (непример, BEEP, IMAP, SMTP). Рекомендуется (RECOMMENDED), чтобы новые обработчики аутентификации определялись как механизмы SASL. Новые методы аутентификации LDAP могут (MAY) быть добавлены для поддержки новых платформ аутентификации.
Основная функция операции Bind — установить ассоциацию LDAP [RFC4513]. Не нужно (SHALL NOT) определять (или расширять) никаких других операций для установления ассоциации LDAP. Однако, можно (MAY) опеределять операции для установления других ассоциаций обеспечения безопасности (например, IPsec).
В разделе 4 RFC 4511 утверждается:
В целях поддержки будущих расширений данного протокола, расширяемость подразумевается там, где это разрешено в ASN.1 (то есть, расширяемыми являются типы sequence, set, choice и enumerated). Кроме того, типы ASN.1, которые являются явно расширяемыми, о чём говорится в RFC 4520, были снабжены многоточием (...). Из-за такой подразумеваемой расширяемости клиенты и серверы должны (MUST) (если не указано иное) игнорировать компоненты, находящиеся в конце конструкции SEQUENCE, теги которых они не могут распознать.
Проектировщикам следует (SHOULD) избегать введения расширений, полагающихся на то, что ничего не подозревающие реализации будут игнорировать конечные компоненты SEQUENCE, теги которых они не распознают.
Расширениям, определяющим элементы схемы данных LDAP, нужно (SHALL) предоставлять определения схемы данных, соответствующие синтаксисам, указанным в разделе 4.1 RFC 4512. Хотя представляемые определения могут (MAY) быть переформатированы для повышения читабельности (с помощью переноса строк), это нужно (SHALL) отметить в спецификации.
Для определений, в которых разрешено поле NAME, в новых элементах схемы данных следует (SHOULD) указывать одно и только одно имя. Этому имени следует (SHOULD) быть коротким.
Во всех определениях схемы данных разрешено поле DESC. Если поле DESC предоставлено, в него следует (SHOULD) помещать короткую описательную фразу. Поле DESC должно (MUST) рассматриваться как информационное. То есть спецификация должна (MUST) быть составлена так, чтобы её интерпретация была одинаковой как с предоставленными полями DESC, так и без них.
Расширениям не нужно (SHALL NOT) выдвигать обязательных требований о том, чтобы в реализациях, при публикации схемы данных каталога, предоставлялось то же самое поле DESC. Разработчики реализаций могут (MAY) заменять или удалять поле DESC.
Не нужно (SHALL NOT) переопределять опубликованные элементы схемы данных каталога. По мере необходимости следует (SHOULD) определять заменяющие элементы схемы данных (новые OID, новые NAME).
Проектировщикам схемы данных следует (SHOULD), там где это уместно, повторно использовать существующие элементы схемы данных. Однако, при любом повторном использовании не должна (MUST NOT) изменяться семантика элемента.
Каждый синтаксис LDAP [RFC4517] определён в терминах ASN.1 [X.680]. Каждое расширение, описывающее синтаксис LDAP, должно (MUST) указать связанное с этим синтаксисом определение данных ASN.1. Следует (SHOULD) создавать отдельный синтаксис LDAP для каждого отдельного определения данных ASN.1 (включая ограничения).
Каждому синтаксису LDAP следует (SHOULD) иметь определенную для него строковую кодировку. Рекомендуется (RECOMMENDED), чтобы эта строковая кодировка ограничивалась закодированными в UTF-8 [RFC3629] символами Unicode [Unicode]. Рекомендуется (RECOMMENDED) использование правил Generic String Encoding Rules (GSER) [RFC3641][RFC3642] или других общих правил кодирования строк для предоставления строковых кодировок для сложных определений данных ASN.1. В противном случае рекомендуется (RECOMMENDED), чтобы эта строковая кодировка была описана с использованием формального языка (например, ABNF [RFC4234]). Формальные языки следует (SHOULD) использовать в спецификациях в соответствии с руководящими принципами IESG [FORMAL].
Если не определяется никаких строковых кодировок, в расширении нужно (SHALL) устанавливать, как должна указываться кодировка передачи. Как правило, в расширении следует (SHOULD) выдвигать обязательное требование об использовании опции binary или другой опции кодирования передачи.
С типом атрибута могут быть связаны три основных типа правил соответствия (EQUALITY, ORDERING и SUBSTRING). Кроме того, LDAP предоставляет расширяемый механизм правил соответствия.
В спецификации правила соответствия следует (SHOULD) определять, к какому типу относится это правило соответствия, а также следует (SHOULD) описывать, какого типа значения можно с ним использовать.
В дополнение к требованиям, указанным в технической спецификации LDAP, правилам соответствия EQUALITY следует (SHOULD) быть коммутативными.
Проектировщикам следует (SHOULD) тщательно продумать, как должна быть ограничена структура значений. Проектировщикам следует (SHOULD) учитывать, что серверы будут обеспечивать только соблюдение ограничений синтаксиса атрибута. То есть, если атрибут предназначен для хранения URI, но имеет синтаксис directoryString, то нет строгого ограничения на то, что его значения будут представлять собой URI.
Проектировщикам следует (SHOULD) тщательно продумать, какие правила соответствия (если таковые имеются) подходят для данного типа атрибута. Определяемые для типа атрибута правила соответствия должны (MUST) быть совместимы с синтаксисом типа атрибута.
В расширениях, определяющих операционные атрибуты, должно (MUST) быть подробно описано, каким образом серверы должны обрабатывать и/или использовать значения каждого операционного атрибута.
Для каждого атрибута в объектном классе проектировщикам следует (SHOULD) тщательно продумать, следует ли ему быть обязательным ("MUST") или допустимым ("MAY").
В расширениях, определяющих объектные классы, допускающие (или требующие) наличие операционных атрибутов, должно (MUST) быть указано, каким образом серверы должны обрабатывать и/или использовать записи, принадлежащие к этим объектным классам.
Каждая опция обозначается строкой из букв, цифр и дефисов. Этой строке следует (SHOULD) быть короткой.
Расширениям, взаимодействующим с авторизационными идентификационными сущностями, нужно (SHALL) поддерживать формат LDAP authzId [RFC4513]. Формат authzId является расширяемым.
Расширения LDAP URL обозначаются короткой строкой (дескриптором). Как и в случае других дескрипторов, этой строке следует (SHOULD) быть короткой.
LDAP не накладывает необоснованных ограничений на виды расширений, которые могут быть реализованы. Хотя в этом документе делается попытка изложить некоторые специфичные проблемные вопросы, которые необходимо учитывать проектировщикам, он не является (и не может быть) всеобъемлющим. Проектировщики должны (MUST) самостоятельно оценить возможные вопросы обеспечения безопасности, применимые к их расширениям.
Проектировщики не должны (MUST NOT) полагать, что "ядро" технической спецификации LDAP [RFC4510] адекватно решает конкретные проблемы, связанные с их расширениями, или допускает, что их расширения не имеют специфических проблем.
Однако в спецификациях расширений следует (SHOULD) указывать, применимы ли к расширению соображения безопасности, относящиеся к функции, для выполнения которой они создаются, а также общие соображения безопасности LDAP.
Автор благодарит сообщество IETF LDAP за глубокомысленные комментарии.
Эта работа основывается на "Руководстве по стилю расширений для протокола LDAP" [GUIDE], автор Bruce Greenblatt.
[RFC2119] S. Bradner, "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, Март 1997 г.
[RFC2434] T. Narten и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, Октябрь 1998 г.
[RFC2849] G. Good, "Формат обмена данными LDAP (LDIF) — техническая спецификация", RFC 2849, Июнь 2000 г.
[RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, Ноябрь 2003 г.
[RFC3641] S. Legg, "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, Октябрь 2003 г.
[RFC3642] S. Legg, "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, Октябрь 2003 г.
[RFC3866] Под редакцией K. Zeilenga, "Языковые тэги и диапазоны в Lightweight Directory Access Protocol (LDAP)", RFC 3866, Июль 2004 г.
[RFC4234] D. Crocker и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Октябрь 2005 г.
[RFC4510] Под редакцией K. Zeilenga, "Lightweight Directory Access Protocol (LDAP): Путеводитель по технической спецификации", RFC 4510, Июнь 2006 г.
[RFC4511] Под редакцией J. Sermersheim, "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, Июнь 2006 г.
[RFC4512] K. Zeilenga, "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC 4512, Июнь 2006 г.
[RFC4513] Под редакцией R. Harrison, "Lightweight Directory Access Protocol (LDAP): Методы аутентификации и механизмы обеспечения безопасности", RFC 4513, Июнь 2006 г.
[RFC4514] K. Zeilenga, "Lightweight Directory Access Protocol (LDAP): Строковое представление уникальных имён", RFC 4514, Июнь 2006 г.
[RFC4515] Под редакцией M. Smith и T. Howes, "Lightweight Directory Access Protocol (LDAP): Строковое представление поисковых фильтров", RFC 4515, Июнь 2006 г.
[RFC4516] Под редакцией M. Smith и T. Howes, "Lightweight Directory Access Protocol (LDAP): Единый указатель ресурса (URL)", RFC 4516, Июнь 2006 г.
[RFC4517] Под редакцией S. Legg, "Lightweight Directory Access Protocol (LDAP): Синтаксисы и правила соответствия", RFC 4517, Июнь 2006 г.
[RFC4520] K. Zeilenga, "Соглашения IANA относительно Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, Июнь 2006 г.
[RFC4422] Под редакцией A. Melnikov и K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, Июнь 2006 г.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" определён в "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), с поправками "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) и "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[FORMAL] IESG, "Guidelines for the use of formal languages in IETF specifications", <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt>, 2001 г.
[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(2002) (also ISO/IEC 8825-1:2002).
[ACID] Раздел 4 ISO/IEC 10026-1:1992.
[GUIDE] B. Greenblatt, "LDAP Extension Style Guide", работы продолжаются.
[RFC3062] K. Zeilenga, "Расширенная операция LDAP модификации пароля Password Modify", RFC 3062, Февраль 2001 г.
[RFC4346] T. Dierks и E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, Апрель 2006 г.
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
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).