Network Working Group Request for Comments: 4520 BCP: 64 Категория: Best Current Practice K. Zeilenga, OpenLDAP Foundation Июнь 2006 года Отменяет: 3383
Этот документ определяет лучший современный опыт Интернет (Internet Best Current Practices) для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
В этом документе даются процедуры для регистрации расширяемых элементов протокола Lightweight Directory Access Protocol (LDAP). В документе также содержатся рекомендации для Администрации адресного пространства Интернет (Internet Assigned Numbers Authority, IANA), описывающие условия, при которых новые значения могут быть назначены.
Lightweight Directory Access Protocol [RFC4510] (LDAP) — расширяемый протокол. LDAP поддерживает:
В этом документе детально описываются процедуры регистрации значений, используемых для однозначной идентификации расширяемых элементов данного протокола, в том числе:
Реестры этих значений поддерживаются Администрацией адресного пространства Интернет (IANA).
Кроме того, в этом документе содержатся рекомендации для IANA, описывающие условия, при которых новые значения могут быть назначены.
Этот документ заменяет RFC 3383.
В данном разделе описываются термины и соглашения, используемые в этом документе.
Термины "IESG Approval" (одобрено IESG), "Standards Action" (заявка на включение стандарт), "IETF Consensus" (согласование IETF), "Specification Required" (требуется для спецификации), "First Come First Served" (обслуживание в порядке поступления заявок), "Expert Review" (экспертная оценка) и "Private Use" (для частного использования) используются как определено в BCP 26 [RFC2434].
Термин "владелец регистрации" ("registration owner") (или просто "владелец" ("owner")) относится к стороне, уполномоченной изменять регистрацию какого-то значения.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119]. В данном случае, термин "спецификация", используемый в BCP 14, относится к работе над протоколами, представляемыми для стандартизации в IETF.
Ряд синтаксисов в этом документе описывается с помощью ABNF [RFC4234]. Эти синтаксисы основаны на следующих общих конструкциях:
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" LDIGIT = %x31-39 ; "1"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9" HYPHEN = %x2D ; "-" DOT = %x2E ; "." number = DIGIT / ( LDIGIT 1*DIGIT ) keychar = ALPHA / DIGIT / HYPHEN leadkeychar = ALPHA keystring = leadkeychar *keychar keyword = keystring
Ключевые слова нечувствительны к регистру символов.
В данном разделе описываются все виды значений протокола, которые можно зарегистрировать, а также приводятся рекомендации для IANA о том, как назначать новые значения.
IANA вправе отклонять явно фиктивные регистрации.
Значения LDAP, спецификация которых дана в RFC, должны (MUST) быть зарегистрированы. Другие значения LDAP, за исключением тех, которые попадают в пространство имён для частного использования, следует (SHOULD) регистрировать. В RFC не следует (SHOULD NOT) ссылаться, использовать или иным образом выражать признание незарегистрированных значений LDAP.
Многие элементы схемы данных и протокола LDAP идентифицируются с помощью идентификаторов объектов (OID) [X.680]. В спецификациях, где элементам присваиваются OID, следует (SHOULD) указывать, кто делегировал OID для использования в них.
Для элементов, разрабатываемых IETF, в спецификациях следует (SHOULD) использовать OID из пространства "Internet Directory Numbers" (1.3.6.1.1.x). Для элементов, разрабатываемых другими разработчиками, могут быть использованы любые корректно делегированные OID, в том числе из пространств "Internet Directory Numbers" (1.3.6.1.1.x) или "Internet Private Enterprise Numbers" (1.3.6.1.4.1.x).
Идентификаторы из пространства "Internet Directory Numbers" (1.3.6.1.1.x) назначаются после экспертной оценки (Expert Review) и только в том случае, если они будут использоваться в спецификации (Specification Required). Для каждой спецификации будет назначен только один OID. В свою очередь в рамках спецификации может (MAY) быть назначено любое количество OID из выделенного ей пространства без необходимости дальнейшей координации с IANA.
Идентификаторы из пространства "Internet Private Enterprise Numbers" (1.3.6.1.4.1.x) назначаются IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Практика IANA по присвоению идентификаторов из пространства "Internet Private Enterprise Numbers" подробно изложена в RFC 2578 [RFC2578].
Во избежание проблем совместимости между ранними реализациями стандартов, находящихся в стадии разработки ("work in progress") и реализациями опубликованных спецификаций (например, RFC), в документах "works in progress" и ранних реализациях следует (SHOULD) использовать экспериментальные OID. Для этой цели могут использоваться OID из пространства "Internet Experimental" (1.3.6.1.3.x). Практика IANA по присвоению идентификаторов из пространства "Internet Experimental" подробно изложена в RFC 2578 [RFC2578].
LDAP предоставляет ряд атрибутов в записи Root DSA-Specific Entry (DSE) для обнаружения механизмов протокола, идентифицируемых по OID, в том числе атрибуты supportedControl, supportedExtension и supportedFeatures [RFC4512].
Реестр OID, используемых для обнаружения механизмов протокола, предусмотрен для того, чтобы позволить разработчикам и другим лицам найти техническую спецификацию для этих механизмов протокола. Последующие спецификации дополнительных атрибутов записи Root DSE, в которых будут содержаться значения, идентифицирующие механизмы протокола, могут (MAY) расширить этот реестр своими значениями.
Механизмы протокола регистрируются в порядке поступления заявок (First Come First Served).
Данный реестр содержит список LDAP-синтаксисов [RFC4512]. Каждый синтаксис LDAP идентифицируется с помощью OID. Реестр предусмотрен для того, чтобы позволить разработчикам и другим лицам найти техническую спецификацию, описывающую конкретный синтаксис LDAP.
Синтаксисы LDAP регистрируются в порядке поступления заявок (First Come First Served) и только в том случае, если они будут использоваться в спецификации (Specification Required).
Примечание: В отличие от объектных классов, типов атрибутов и других разновидностей элементов схемы данных, для идентификации синтаксисов LDAP не используются дескрипторы.
LDAP позволяет использовать короткие описательные имена (или дескрипторы) вместо числовых идентификаторов объектов для идентификации избранных расширений протокола [RFC4511], элементов схемы данных [RFC4512], расширений LDAP URL [RFC4516] и других объектов.
Хотя протокол позволяет в определенных случаях одному и тому же дескриптору ссылаться на разные идентификаторы объектов, и реестр поддерживает несколько регистраций одного и того же дескриптора (каждая из которых указывает на разные виды элементов схемы данных и разные идентификаторы объекта), следует избегать множественных регистраций одного и того же дескриптора. Все подобные запросы на множественную регистрацию должны проходить экспертную оценку (Expert Review).
Дескрипторы регистрируются в виде строк, состоящих из закодированных в UTF-8 [RFC3629] символов Unicode, ограниченных следующей ABNF:
name = keystring
Дескрипторы нечувствительны к регистру символов.
Заданному OID могут быть назначены несколько имён. В целях регистрации OID представляются в числовой форме (например, 1.1.0.23.40), удовлетворяющей следующей ABNF:
numericoid = number 1*( DOT number )
Хотя протокол не ограничивает максимальную длину дескрипторов, им следует быть короткими. Дескрипторы длиннее 48 символов могут рассматриваться как слишком длинные для регистрации.
Значения, заканчивающиеся на символ дефиса ("-"), резервируют все дескрипторы, начинающиеся с этого значения. Например, регистрация опции "descrFamily-" приведёт к резервированию (в каких-либо целях) всех вариантов дескрипторов, начинающихся с "descrFamily-".
Дескрипторы, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
Дескрипторы, начинающиеся с "e-", зарезервированы для экспериментов и будут регистрироваться в порядке поступления заявок (First Come First Served).
Для регистрации всех остальных дескрипторов требуется прохождение ими экспертной оценки (Expert Review).
Подающий заявку на регистрацию дескриптора не обязан быть "владельцем" ("owner") того OID, для именования которого предназначается данный дескриптор.
Пространство имен OID управляется Подкомитетом 6 Объединённого технического комитета 1 ISO/IEC.
Описание атрибута (AttributeDescription) [RFC4512] может содержать ноль или более опций, определяющих дополнительные семантики. Опции следует (SHALL) регистрировать в виде строк, состоящих из закодированных в UTF-8 символов Unicode, ограниченных следующей ABNF:
option = keystring
Опции нечувствительны к регистру символов.
Хотя протокол не ограничивает максимальную длину имён опций, им следует быть короткими. Опции длиннее 24 символов могут рассматриваться как слишком длинные для регистрации.
Значения, заканчивающиеся на символ дефиса ("-"), резервируют все имена опций, начинающиеся с этого значения. Например, регистрация опции "optionFamily-" приведёт к резервированию (в каких-либо целях) всех вариантов опций, начинающихся с "optionFamily-".
Опции, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
Опции, начинающиеся с "e-", зарезервированы для экспериментов и будут регистрироваться в порядке поступления заявок (First Come First Served).
Для регистрации всех остальных опций требуется, чтобы они были либо в заявке на включение в стандарт (Standards Action), либо прошли экспертную оценку (Expert Review) и требовались для какой-либо спецификации (Specification Required).
Каждое сообщение протокола инкапсулируется в конверт LDAPMessage [RFC4511]. Тип инкапсулированного сообщения определяется указанным в конверте сообщения вариантом protocolOp (ASN.1-конструкция CHOICE). Каждый тип сообщения состоит из идентификатора ASN.1 в форме ключевого слова (keyword) и неотрицательного номера варианта. Данный номер варианта комбинируется с признаком класса (APPLICATION) и типом данных (CONSTRUCTED или PRIMITIVE) для построения тэга BER в кодировке сообщения. Номера вариантов для существующих сообщений протокола неявно заданы в ASN.1-определении протокола [RFC4511].
Для регистрации новых значений требуется, чтобы они были в заявке на включение в стандарт (Standards Action).
Примечание: В LDAP предусмотрены расширяемые сообщения, что снижает, но не устраняет потребность в добавлении новых типов сообщений.
LDAP-операция Bind поддерживает несколько методов аутентификации [RFC4511]. Каждый вариант аутентификации состоит из идентификатора ASN.1 в форме ключевого слова (keyword) и неотрицательного целого числа.
Подающему заявку на регистрацию нужно (SHALL) классифицировать применение метода аутентификации с использованием одного из следующих терминов:
COMMON — метод подходит для общего пользования в Интернете.
LIMITED USE — метод предназначен для ограниченного использования.
OBSOLETE — метод устарел или иным образом признан неприемлемым для какого-либо использования.
Методы без общедоступных спецификаций не следует (SHALL NOT) классифицировать как общепринятые (COMMON). Не могут быть зарегистрированы новые заявки на регистрацию метода с классом OBSOLETE.
Для регистрации новых методов аутентификации с целочисленными значениями в диапазоне 0-1023 требуется, чтобы они были в заявке на включение в стандарт (Standards Action). Для регистрации новых методов аутентификации с целочисленными значениями в диапазоне 1024-4095 требуется, чтобы они прошли экспертную оценку (Expert Review) и требовались для какой-либо спецификации (Specification Required). Новые методы аутентификации с целочисленными значениями в диапазоне 4096-16383 будут регистрироваться в порядке поступления заявок (First Come First Served). Ключевым словам, назначаемым целочисленным значениям в диапазоне 0-4095, не следует (SHALL NOT) начинаться с "e-" или "x-". Ключевым словам, назначаемым целочисленным значениям в диапазоне 4096-16383, следует (SHALL) начинаться с "e-". Значения, большие или равные 16384, а также ключевые слова, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
Примечание: В качестве одного из вариантов аутентификации LDAP поддерживает Simple Authentication and Security Layers [RFC4422]. SASL представляет собой расширяемую технологию аутентификации.
Результирующие сообщения LDAP содержат значение resultCode (из набора поименованных значений), указывающее на результат выполнения операции [RFC4511]. Каждый результирующий код состоит из идентификатора ASN.1 в форме ключевого слова (keyword) и неотрицательного целого числа.
Для регистрации новых результирующих кодов с целочисленными значениями в диапазоне 0-1023 требуется, чтобы они были в заявке на включение в стандарт (Standards Action). Для регистрации новых результирующих кодов с целочисленными значениями в диапазоне 1024-4095 требуется, чтобы они прошли экспертную оценку (Expert Review) и требовались для какой-либо спецификации (Specification Required). Новые результирующие коды с целочисленными значениями в диапазоне 4096-16383 будут регистрироваться в порядке поступления заявок (First Come First Served). Ключевым словам, назначаемым целочисленным значениям в диапазоне 0-4095, не следует (SHALL NOT) начинаться с "e-" или "x-". Ключевым словам, назначаемым целочисленным значениям в диапазоне 4096-16383, следует (SHALL) начинаться с "e-". Значения, большие или равные 16384, а также ключевые слова, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
Сообщения LDAP SearchRequest содержат значение scope (из набора поименованных значений), указывающее глубину поиска в DIT [RFC4511]. Каждое значение диапазона поиска состоит из идентификатора ASN.1 в форме ключевого слова (keyword) и неотрицательного целого числа.
Для регистрации новых диапазонов поиска с целочисленными значениями в диапазоне 0-1023 требуется, чтобы они были в заявке на включение в стандарт (Standards Action). Для регистрации новых диапазонов поиска с целочисленными значениями в диапазоне 1024-4095 требуется, чтобы они прошли экспертную оценку (Expert Review) и требовались для какой-либо спецификации (Specification Required). Новые диапазоны поиска с целочисленными значениями в диапазоне 4096-16383 будут регистрироваться в порядке поступления заявок (First Come First Served). Ключевым словам, назначаемым целочисленным значениям в диапазоне 0-4095, не следует (SHALL NOT) начинаться с "e-" или "x-". Ключевым словам, назначаемым целочисленным значениям в диапазоне 4096-16383, следует (SHALL) начинаться с "e-". Значения, большие или равные 16384, а также ключевые слова, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
Фильтры LDAP используются при создании суждений об объектах, представленных в каталоге [RFC4511]. Вариант поля Filter указывает тип суждения. Каждый вариант (из ASN.1-конструкции CHOICE) поля Filter состоит из идентификатора ASN.1 в форме ключевого слова (keyword) и неотрицательного целого числа. Данный номер варианта комбинируется с признаком класса (APPLICATION) и типом данных (CONSTRUCTED или PRIMITIVE) для построения тэга BER в кодировке сообщения.
Примечание: В LDAP представлен вариант extensibleMatching, что снижает, но не устраняет потребность в добавлении новых вариантов для построения фильтра.
Запрос LDAP ModifyRequest содержит последовательность операций модификации [RFC4511]. Каждый тип операции (например, add, delete, replace) состоит из идентификатора ASN.1 в форме ключевого слова (keyword) и неотрицательного целого числа.
Для регистрации новых типов операций с целочисленными значениями в диапазоне 0-1023 требуется, чтобы они были в заявке на включение в стандарт (Standards Action). Для регистрации новых типов операций с целочисленными значениями в диапазоне 1024-4095 требуется, чтобы они прошли экспертную оценку (Expert Review) и требовались для какой-либо спецификации (Specification Required). Новые типы операций с целочисленными значениями в диапазоне 4096-16383 будут регистрироваться в порядке поступления заявок (First Come First Served). Ключевым словам, назначаемым целочисленным значениям в диапазоне 0-4095, не следует (SHALL NOT) начинаться с "e-" или "x-". Ключевым словам, назначаемым целочисленным значениям в диапазоне 4096-16383, следует (SHALL) начинаться с "e-". Значения, большие или равные 16384, а также ключевые слова, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
В LDAP авторизационные идентификационные сущности представляют собой строки, соответствующие конструкции <authzId> [RFC4513]. Данная конструкция является расширяемой. Каждая новая конкретная форма авторизации идентифицируется строкой префикса, соответствующей следующей ABNF:
prefix = keystring COLON
COLON = %x3A ; COLON (":" U+003A)
Префиксы нечувствительны к регистру символов.
Хотя протокол не ограничивает максимальную длину строк префиксов, им следует быть короткими. Префиксы длиннее 12 символов могут рассматриваться как слишком длинные для регистрации.
Префиксы, начинающиеся с "x-", предназначены для частного использования (Private Use) и не могут быть зарегистрированы.
Префиксы, начинающиеся с "e-", зарезервированы для экспериментов и будут регистрироваться в порядке поступления заявок (First Come First Served).
Для регистрации всех остальных префиксов требуется, чтобы они были либо в заявке на включение в стандарт (Standards Action), либо прошли экспертную оценку (Expert Review) и требовались для какой-либо спецификации (Specification Required).
Поддерживаемый IANA реестр "Системные имена для каталогов" [IANADSN] содержит допустимые ключевые слова для широко известных атрибутов, используемых в строковом представлении уникальных имён записей в протоколе LDAPv2 [RFC1779]. В настоящее время LDAPv2 имеет статус исторического протокола [RFC3494].
Использование системных имён для каталогов в каком-либо ином контексте не предусмотрено. В LDAPv3 [RFC4514] используются дескрипторы идентификаторов объектов [раздел 3.2 настоящего документа], синтаксис которых отличается от синтаксиса системных имён для каталогов.
Заявки на регистрацию новых системных имён для каталогов больше не принимаются. По историческим причинам текущий список зарегистрированных имён остаётся в открытом доступе.
Приведённая здесь процедура должна (MUST) быть выполнена любым лицом, желающим использовать новое значение какого-либо из типов, описанных в разделе 3 настоящего документа.
Первым шагом для заявителя является заполнение соответствующей формы. Шаблоны форм представлены в приложении A.
Если для регистрации значения установлена политика "Standards Action", то заполненную форму следует (SHOULD) предоставить в IESG вместе с запросом на принятие соответствующего стандарта. После одобрения соответствующего стандарта, IESG нужно (SHALL) направить заявку на регистрацию значения (возможно, пересмотренную) далее в IANA. IESG должен (SHALL) рассматриваться как владелец регистрации ("registration owner") всех значений, требуемых для включения в стандарты.
Если для регистрации значения установлена политика "Expert Review", заявителю нужно (SHALL) отправить заполненную форму в список рассылки <directory@apps.ietf.org> для публичного рассмотрения. Период рассмотрения — две недели. Если после начала периода рассмотрения была представлена пересмотренная форма, то отсчёт периода рассмотрения начинается заново. Любой желающий может подписаться на данную рассылку, отправив запрос по адресу <directory-request@apps.ietf.org>. В ходе рассмотрения возражения могут быть поданы любым лицом (включая эксперта, принимающего окончательное решение) из соответствующего списка рассылки. После завершения рассмотрения принимающему решение эксперту на основании публичных комментариев следует (SHALL) либо одобрить заявку и направить её далее в IANA, либо отклонить заявку. В любом случае эксперту следует (SHALL) незамедлительно уведомить заявителя об окончательном решении. Действия эксперта могут быть обжалованы [RFC2026]. Эксперт назначается Директоратом областей применения (Applications Area Directors). Заявитель рассматривается как владелец регистрации ("registration owner") значений, регистрируемых после экспертной оценки.
Если для регистрации значения установлена политика "First Come First Served", заявителю нужно (SHALL) отправить заполненную форму напрямую в IANA: <iana@iana.org>. Заявитель рассматривается как владелец регистрации ("registration owner") значений, регистрируемых в порядке поступления заявок.
Ни эксперты, ни IANA не принимают решений по претензиям, касающимся авторского права или торговых марок, в отношении заполненных форм на регистрацию значений.
Перед отправкой документа Интернет-проекта (Internet Draft, I-D) в Группу редакторов RFC (RFC Editor), но после того, как этот документ был рассмотрен и предварительно одобрен IESG, редактору документа следует (SHOULD) пересмотреть свой I-D на предмет того, чтобы в нём использовались зарегистрированные значения.
В этом разделе обсуждается обслуживание регистраций.
IANA публикует доступный для чтения сообществу Интернет список зарегистрированных значений на своём веб-сайте: <http://www.iana.org/>.
Владелец регистрации может (MAY) обновить регистрацию значения, при этом должны быть соблюдены те же ограничения и пройдены те же процедуры проверки, что и при новой регистрации. В случаях, когда владелец регистрации не в состоянии или не желает осуществить необходимые обновления, the IESG может (MAY) взять на себя право владения данной регистрацией в целях её обновления.
В случаях, когда у других лиц (не владельца регистрации) имеются существенные возражения по поводу предмета регистрации, а владелец регистрации не соглашается её изменить, можно (MAY) добавить комментарии к рассылке рассмотрения регистрации и после экспертной оценки (Expert Review). Для регистраций, владельцем которых является IESG, возражения следует (SHOULD) направлять путем инициирования запроса на экспертную оценку (Expert Review).
Подобные запросы не формализованы, но должны (MUST) включать конкретные возражения, которые должны быть рассмотрены, а также в них следует (SHOULD) помещать (непосредственно или в виде ссылки) материалы, обосновывающие данные возражения.
Описанные в BCP 26 [RFC2434] соображения безопасности в целом применимы к этому документу. Дополнительные соображения безопасности, специфичные для каждого пространства имён, обсуждаются в разделе 3, где это необходимо.
Cоображения безопасности для протокола LDAP обсуждаются в документах, содержащих его техническую спецификацию [RFC4510].
Данный документ является продуктом рабочей группы IETF по пересмотру LDAP (LDAPBIS). Он представляет собой ревизию документа RFC3383, который также был продуктом рабочей группы LDAPBIS.
Данный документ включает текст, заимствованный из "Руководство по написанию раздела по регистрации IANA в RFC" [RFC2434], авторы Thomas Narten и Harald Alvestrand.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, октябрь 1996 г.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC2434] Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, октябрь 1998 г.
[RFC2578] McCloghrie, K., Perkins, D. и J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, апрель 1999 г.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, ноябрь 2003 г.
[RFC4234] Crocker, D. и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, октябрь 2005 г.
[RFC4510] Под редакцией Zeilenga, K., "Путеводитель по технической спецификации LDAP", RFC 4510, июнь 2006 г.
[RFC4511] Под редакцией Sermersheim, J., "Определение протокола LDAP", RFC 4511, июнь 2006 г.
[RFC4512] Zeilenga, K., "LDAP: Информационные модели каталога", RFC 4512, июнь 2006 г.
[RFC4513] Под редакцией Harrison, R., "LDAP: Методы аутентификации и механизмы обеспечения безопасности", RFC 4513, июнь 2006 г.
[RFC4516] Под редакцией Smith, M. и T. Howes, "LDAP: Единый указатель ресурса (URL)", RFC 4516, июнь 2006 г.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[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).
[RFC1779] Kille, S., "A String Representation of Distinguished Names", RFC 1779, март 1995 г.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", RFC 3494, март 2003 г.
[RFC4514] Под редакцией Zeilenga, K., "LDAP: Строковое представление уникальных имён", RFC 4514, июнь 2006 г.
[RFC4422] Под редакцией Melnikov, A. и K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, июнь 2006 г.
[IANADSN] IANA, "Системные имена для каталогов", http://www.iana.org/assignments/directory-system-names.
В данном приложении предоставлены шаблоны для подачи заявок на регистрацию новых значений LDAP. Обратите внимание, что может быть подан запрос на регистрацию более чем одного значения, для чего шаблон может быть расширен перечислением нескольких значений или использованием табличной формы.
Предмет: Запрос на регистрацию OID LDAP
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (I-D)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию механизма протокола LDAP
Идентификатор объекта:
Описание:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Применение: (Один из вариантов: элемент управления, либо расширение, либо свойство, либо что-то ещё)
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию синтаксиса LDAP
Идентификатор объекта:
Описание:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию дескриптора LDAP
Дескриптор (короткое имя):
Идентификатор объекта:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Применение: (Один из вариантов: административная роль, тип атрибута, правило соответствия, форма имени, объектный класс, расширение URL либо что-то ещё)
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию опции описания атрибута LDAP
Имя опции:
Семейство опций: (Да или Нет)
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию типа сообщения LDAP
Наименование сообщения LDAP:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (Одобренный I-D)
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию метода аутентификации LDAP
Наименование метода аутентификации:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Предполагаемое использование: (Один из вариантов: COMMON, LIMITED-USE, OBSOLETE)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию результирующего кода LDAP
Имя результирующего кода:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию диапазона поиска LDAP
Наименование диапазона поиска:
Строка диапазона поиска:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию варианта для построения фильтра LDAP
Наименование варианта для построения фильтра:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
Предмет: Запрос на регистрацию типа операции ModifyRequest LDAP
Наименование типа операции ModifyRequest:
Персона и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/Лицо, ответственное за управление изменениями:
Комментарии:
(Любые комментарии, которые, по мнению заявителя, имеют отношение к запросу).
В этом информационном приложении представлена сводка изменений, внесённых в RFC 3383.
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).