RFC4520 — Соображения для Internet Assigned Numbers Authority (IANA) по протоколу облегчённого доступа к каталогам (LDAP)

Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

Выжимка

RFC 4520 устанавливает процедуры регистрации расширяемых элементов LDAP и рекомендации для IANA по назначению новых значений. Он охватывает идентификаторы объектов, механизмы протокола, синтаксисы, дескрипторы, опции AttributeDescription, типы сообщений, методы аутентификации, коды результатов, области поиска, варианты фильтров, операции ModifyRequest и префиксы authzId. Документ определяет политики регистрации, требования к формам, публичному рассмотрению и сопровождению записей. Это BCP 64; документ заменяет RFC 3383.

Полный перевод

Рабочая группа по сетевым вопросам                                        K. Zeilenga
Запрос комментариев: 4520                           OpenLDAP Foundation
BCP: 64                                                        Июнь 2006
Заменяет: 3383
Категория: Лучшая современная практика


     Вопросы, относящиеся к Internet Assigned Numbers Authority (IANA), для
            Lightweight Directory Access Protocol (LDAP)

Статус настоящего меморандума

   Этот документ определяет Лучшие современные практики Интернета для
   интернет-сообщества и запрашивает обсуждение и предложения по
   улучшению. Распространение настоящего меморандума не ограничено.

Уведомление об авторских правах

   Copyright (C) The Internet Society (2006).

Аннотация

   Этот документ предоставляет процедуры регистрации расширяемых элементов
   Lightweight Directory Access Protocol (LDAP). Документ также
   предоставляет Internet Assigned Numbers Authority (IANA) руководящие
   указания, описывающие условия, при которых могут назначаться новые
   значения.

1.  Введение

   Lightweight Directory Access Protocol [RFC4510] (LDAP) является
   расширяемым протоколом. LDAP поддерживает:

      -  добавление новых операций,
      -  расширение существующих операций и
      -  расширяемую схему.

   Этот документ подробно описывает процедуры регистрации значений,
   используемых для однозначной идентификации расширяемых элементов
   протокола, включая следующее:

      - типы сообщений LDAP
      - расширенные операции и элементы управления LDAP
      - коды результатов LDAP
      - методы аутентификации LDAP
      - параметры описания атрибута LDAP
      - дескрипторы Object Identifier




Zeilenga                 Лучшая современная практика            [Страница 1]

RFC 4520              Вопросы IANA для LDAP                    Июнь 2006


   Эти реестры поддерживаются Internet Assigned Numbers Authority
   (IANA).

   Кроме того, этот документ предоставляет IANA руководящие указания,
   описывающие условия, при которых могут назначаться новые значения.

   Этот документ заменяет RFC 3383.

2.  Терминология и соглашения

   В этом разделе подробно описываются термины и соглашения, используемые
   в настоящем документе.

2.1.  Терминология политик

   Термины "IESG Approval", "Standards Action", "IETF Consensus",
   "Specification Required", "First Come First Served", "Expert Review"
   и "Private Use" используются в значениях, определённых в BCP 26
   [RFC2434].

   Термин "registration owner" (или "owner") относится к стороне,
   уполномоченной изменять регистрацию значения.

2.2.  Терминология требований

   Ключевые слова "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" и "OPTIONAL" в настоящем
   документе должны интерпретироваться так, как описано в BCP 14
   [RFC2119]. В данном случае "the specification", как этот термин
   используется в BCP 14, относится к обработке протоколов, представляемых
   в процесс стандартизации IETF.

2.3.  Общие продукции ABNF

   Ряд синтаксисов в настоящем документе описывается с использованием 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

   Ключевые слова не чувствительны к регистру.




Zeilenga                 Лучшая современная практика            [Страница 2]

RFC 4520              Вопросы IANA для LDAP                    Июнь 2006


3.  Вопросы IANA для LDAP

   В этом разделе подробно описывается каждый вид значения протокола,
   который может быть зарегистрирован, и предоставляются руководящие
   указания IANA о том, как назначать новые значения.

   IANA может отклонять заведомо фиктивные регистрации.

   Значения LDAP, определённые в RFC, ДОЛЖНЫ (MUST) быть зарегистрированы.
   Другие значения LDAP, кроме находящихся в пространствах имён частного
   использования, СЛЕДУЕТ (SHOULD) регистрировать. RFC НЕ СЛЕДУЕТ
   (SHOULD NOT) ссылаться на незарегистрированные значения LDAP,
   использовать их или иным образом признавать их.

3.1.  Идентификаторы объектов

   Многочисленные элементы схемы и протокола LDAP идентифицируются
   идентификаторами объектов (Object Identifiers, OIDs) [X.680].
   Спецификации, назначающие OID элементам, СЛЕДУЕТ (SHOULD) указывать,
   кто делегировал OID для их использования.

   Для элементов, разработанных IETF, спецификациям СЛЕДУЕТ (SHOULD)
   использовать OID в пределах "Internet Directory Numbers"
   (1.3.6.1.1.x). Для элементов, разработанных другими, может
   использоваться любой надлежащим образом делегированный OID, включая
   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 OID
   (1.3.6.1.3.x). Практики назначения IANA этих номеров Internet
   Experimental подробно описаны в RFC 2578 [RFC2578].

3.2.  Механизмы протокола

   LDAP предоставляет ряд атрибутов Root DSA-Specific Entry (DSE) для
   обнаружения механизмов протокола, идентифицируемых OID, включая
   атрибуты supportedControl, supportedExtension и supportedFeatures
   [RFC4512].



Zeilenga                 Лучшая современная практика            [Страница 3]

RFC 4520              Вопросы IANA для LDAP                    Июнь 2006


   Реестр OID, используемых для обнаружения механизмов протокола,
   предоставляется, чтобы позволить разработчикам реализаций и другим
   лицам находить техническую спецификацию этих механизмов протокола.
   Будущие спецификации дополнительных атрибутов Root DSE, содержащих
   значения, идентифицирующие механизмы протокола, МОГУТ (MAY) расширять
   этот реестр своими значениями.

   Механизмы протокола регистрируются на основе First Come First Served.

3.3.  Синтаксисы LDAP

   Этот реестр предоставляет перечень синтаксисов LDAP [RFC4512]. Каждый
   синтаксис LDAP идентифицируется OID. Этот реестр предоставляется,
   чтобы позволить разработчикам реализаций и другим лицам находить
   техническую спецификацию, описывающую конкретный синтаксис LDAP.

   Синтаксисы LDAP регистрируются на основе First Come First Served при
   наличии Specification Required.

   Примечание: В отличие от классов объектов, типов атрибутов и различных
         других видов элементов схемы, дескрипторы не используются в LDAP
         для идентификации синтаксисов LDAP.

3.4.  Дескрипторы идентификаторов объектов

   LDAP позволяет использовать короткие описательные имена (или
   дескрипторы) вместо числового Object Identifier для идентификации
   отдельных расширений протокола [RFC4511], элементов схемы [RFC4512],
   расширений LDAP URL [RFC4516] и других объектов.

   Хотя протокол в определённых случаях позволяет одному и тому же
   дескриптору ссылаться на разные идентификаторы объектов, а реестр
   поддерживает несколько регистраций одного и того же дескриптора
   (каждая из которых указывает иной вид элемента схемы и иной
   идентификатор объекта), множественных регистраций одного и того же
   дескриптора следует избегать. Все такие запросы на множественную
   регистрацию требуют Expert Review.

   Дескрипторы ограничены строками символов Unicode, кодированных в UTF-8
   [RFC3629] и ограниченных следующим ABNF:

      name = keystring

   Дескрипторы не чувствительны к регистру.

   Одному заданному OID может быть назначено несколько имён. Для целей
   регистрации OID должен представляться в числовой форме OID (например,
   1.1.0.23.40), соответствующей следующему ABNF:



Zeilenga                 Лучшая современная практика            [Страница 4]

RFC 4520              Вопросы IANA для LDAP                    Июнь 2006


      numericoid = number 1*( DOT number )

   Хотя протокол не устанавливает максимального ограничения длины
   дескрипторов, им следует быть короткими. Дескрипторы длиной более 48
   символов могут считаться слишком длинными для регистрации.

   Значение, оканчивающееся дефисом ("-"), резервирует все дескрипторы,
   начинающиеся с этого значения. Например, регистрация параметра
   "descrFamily-" резервирует для некоторой связанной цели все параметры,
   начинающиеся с "descrFamily-".

   Дескрипторы, начинающиеся с "x-", предназначены для Private Use и не
   могут быть зарегистрированы.

   Дескрипторы, начинающиеся с "e-", зарезервированы для экспериментов и
   будут регистрироваться на основе First Come First Served.

   Для регистрации всех прочих дескрипторов требуется Expert Review.

   Регистранту не требуется "владеть" именуемым OID.

   Пространством имён OID управляет ISO/IEC Joint Technical Committee 1 -
   Subcommittee 6.

3.5.  Параметры AttributeDescription

   AttributeDescription [RFC4512] может содержать ноль или более
   параметров, задающих дополнительную семантику. Параметр ДОЛЖЕН (SHALL)
   быть ограничен строкой символов Unicode, кодированных в UTF-8 и
   ограниченных следующим ABNF:

      option = keystring

   Параметры не чувствительны к регистру.

   Хотя протокол не устанавливает максимального ограничения длины строк
   параметров, им следует быть короткими. Параметры длиной более 24
   символов могут считаться слишком длинными для регистрации.

   Значения, оканчивающиеся дефисом ("-"), резервируют все имена
   параметров, начинающиеся с этого имени. Например, регистрация параметра
   "optionFamily-" резервирует для некоторой связанной цели все параметры,
   начинающиеся с "optionFamily-".

   Параметры, начинающиеся с "x-", предназначены для Private Use и не
   могут быть зарегистрированы.




Zeilenga                 Лучшая современная практика            [Страница 5]

RFC 4520              Вопросы IANA для LDAP                    Июнь 2006


   Параметры, начинающиеся с "e-", зарезервированы для экспериментов и
   будут регистрироваться на основе First Come First Served.

   Для регистрации всех прочих параметров требуется Standards Action или
   Expert Review при наличии Specification Required.

3.6.  Типы сообщений LDAP

   Каждое сообщение протокола инкапсулируется в оболочку LDAPMessage
   [RFC4511. Выбор protocolOp указывает тип инкапсулированного сообщения.
   Каждый тип сообщения состоит из идентификатора ASN.1 в форме ключевого
   слова и неотрицательного номера выбора. Номер выбора объединяется с
   классом (APPLICATION) и типом данных (CONSTRUCTED или PRIMITIVE) для
   формирования тега BER в кодировке сообщения. Номера выбора для
   существующих сообщений протокола неявно заданы ASN.1 протокола,
   определённым в [RFC4511].

   Новые значения будут регистрироваться после Standards Action.

   Примечание: LDAP предоставляет расширяемые сообщения, которые уменьшают,
         но не устраняют потребность в добавлении новых типов сообщений.

3.7.  Метод аутентификации LDAP

   Операция LDAP Bind поддерживает несколько методов аутентификации
   [RFC4511]. Каждый вариант аутентификации состоит из идентификатора
   ASN.1 в форме ключевого слова и неотрицательного целого числа.

   Регистрант ДОЛЖЕН (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 и
   не могут быть зарегистрированы.



Zeilenga                 Лучшая современная практика            [Страница 6]

RFC 4520              Вопросы IANA для LDAP                    Июнь 2006


   Примечание: LDAP поддерживает Simple Authentication and Security Layers
         [RFC4422] как вариант аутентификации. SASL является расширяемой
         средой аутентификации.

3.8.  Коды результатов LDAP

   Сообщения результатов LDAP содержат перечисляемое значение resultCode,
   указывающее результат операции [RFC4511]. Каждый код результата состоит
   из идентификатора ASN.1 в форме ключевого слова и неотрицательного
   целого числа.

   Для регистрации новых целых чисел resultCodes в диапазоне 0-1023
   требуется Standards Action. Для регистрации новых целых чисел resultCode
   в диапазоне 1024-4095 требуется Expert Review при наличии Specification
   Required. Новые целые числа resultCode в диапазоне 4096-16383 будут
   регистрироваться на основе First Come First Served. Ключевые слова,
   связанные с целыми числами в диапазоне 0-4095, НЕ ДОЛЖНЫ (SHALL NOT)
   начинаться с "e-" или "x-". Ключевые слова, связанные с целыми числами
   в диапазоне 4096-16383, ДОЛЖНЫ (SHALL) начинаться с "e-". Значения
   больше или равные 16384 и ключевые слова, начинающиеся с "x-",
   предназначены для Private Use и не могут быть зарегистрированы.

3.9.  Область поиска LDAP

   Сообщения LDAP SearchRequest содержат перечисляемое значение scope,
   указывающее охват поиска в пределах DIT [RFC4511]. Каждое значение
   поиска состоит из идентификатора ASN.1 в форме ключевого слова и
   неотрицательного целого числа.

Для регистрации новых целых чисел области действия в диапазоне 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 и не могут быть зарегистрированы.

3.10.  Вариант LDAP-фильтра

   LDAP-фильтры используются при выполнении утверждений относительно объекта, представленного в каталоге [RFC4511]. Вариант CHOICE фильтра указывает тип утверждения. Каждый вариант CHOICE фильтра состоит из идентификатора ASN.1 в форме ключевого слова и неотрицательного номера варианта.



Zeilenga                 Best Current Practice                  [Page 7]

RFC 4520              IANA Considerations for LDAP             June 2006


   Номер варианта объединяется с классом (APPLICATION) и типом данных (CONSTRUCTED или PRIMITIVE) для построения BER-тега при кодировании сообщения.

   Примечание: LDAP предоставляет вариант extensibleMatching, который уменьшает,
         но не устраняет необходимость добавлять новые варианты фильтров.

3.11.  Тип операции LDAP ModifyRequest

   LDAP ModifyRequest переносит последовательность операций модификации [RFC4511]. Каждый вид (например, add, delete, replace) операции состоит из идентификатора ASN.1 в форме ключевого слова и неотрицательного целого числа.

   Для регистрации новых целых чисел типа операции в диапазоне 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 и не могут быть зарегистрированы.

3.12.  Префиксы LDAP authzId

   Идентификаторы авторизации в 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.



Zeilenga                 Best Current Practice                  [Page 8]

RFC 4520              IANA Considerations for LDAP             June 2006


3.13.  Имена систем каталогов

   Реестр "Directory Systems Names" [IANADSN], который ведёт IANA и который содержит допустимые ключевые слова для широко известных атрибутов, использовался в строковом представлении отличительного имени LDAPv2 [RFC1779]. LDAPv2 теперь имеет исторический статус [RFC3494].

   Имена систем каталогов, насколько известно, не используются в каком-либо другом контексте. LDAPv3 [RFC4514] использует дескрипторы идентификаторов объектов [раздел 3.2] (имеющие иной синтаксис, чем имена систем каталогов).

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

4.  Процедура регистрации

   Приведённая здесь процедура ДОЛЖНА (MUST) использоваться любым лицом, желающим использовать новое значение типа, описанного в разделе 3 настоящего документа.

   Первым шагом заявитель должен заполнить соответствующую форму. Шаблоны приведены в приложении A.

   Если политикой является Standards Action, заполненную форму СЛЕДУЕТ (SHOULD) предоставить IESG вместе с запросом на Standards Action. После одобрения Standards Action IESG ДОЛЖНА (SHALL) переслать запрос (возможно, пересмотренный) в IANA. IESG ДОЛЖНА (SHALL) рассматриваться как владелец регистрации всех значений, требующих Standards Action.

   Если политикой является Expert Review, заявитель ДОЛЖЕН (SHALL) разместить заполненную форму в списке рассылки <directory@apps.ietf.org> для публичного рассмотрения. Период рассмотрения составляет две (2) недели. Если впоследствии представляется пересмотренная форма, период рассмотрения начинается заново. Любое лицо может подписаться на этот список, отправив запрос на <directory-request@apps.ietf.org>. В ходе рассмотрения любое лицо (включая Эксперта) может высказать в списке возражения. После завершения рассмотрения Эксперт на основе публичных комментариев ДОЛЖЕН (SHALL) либо одобрить запрос и переслать его в IANA, ЛИБО отклонить запрос. В любом случае Эксперт ДОЛЖЕН (SHALL) незамедлительно уведомить заявителя о действии. Действия Эксперта могут быть обжалованы [RFC2026]. Эксперт назначается директорами области приложений. Заявитель рассматривается как владелец регистрации значений, зарегистрированных в рамках Expert Review.

   Если политикой является First Come First Served, заявитель ДОЛЖЕН (SHALL) направить заполненную форму непосредственно в IANA: <iana@iana.org>. Заявитель рассматривается как владелец регистрации значений, зарегистрированных на основе First Come First Served.



Zeilenga                 Best Current Practice                  [Page 9]

RFC 4520              IANA Considerations for LDAP             June 2006


   Ни Эксперт, ни IANA не будут занимать позицию по заявлениям об авторском праве или товарных знаках в отношении заполненных форм.

   До представления Internet Draft (I-D) редактору RFC, но после рассмотрения IESG и предварительного одобрения, редактор документа СЛЕДУЕТ (SHOULD) пересмотреть I-D, чтобы использовать зарегистрированные значения.

5.  Сопровождение регистраций

   В этом разделе рассматривается сопровождение регистраций.

5.1.  Списки зарегистрированных значений

   IANA обеспечивает свободную доступность списков зарегистрированных значений для интернет-сообщества на своём веб-сайте: <http://www.iana.org/>.

5.2.  Контроль изменений

   Владелец регистрации МОЖЕТ (MAY) обновить регистрацию при соблюдении тех же ограничений и рассмотрения, что и для новых регистраций. В случаях, когда владелец регистрации не способен или не желает вносить необходимые обновления, IESG МОЖЕТ (MAY) принять на себя владение регистрацией, чтобы обновить её.

5.3.  Комментарии

   В случаях, когда другие лица (любое лицо, кроме владельца регистрации) имеют существенные возражения против заявлений в регистрации, а владелец регистрации не соглашается изменить регистрацию, комментарии МОГУТ (MAY) быть приложены к регистрации после Expert Review. В отношении регистраций, владельцем которых является IESG, возражения СЛЕДУЕТ (SHOULD) рассмотреть, инициировав запрос на Expert Review.

   Форма этих запросов является специальной, однако она ДОЛЖНА (MUST) включать конкретные возражения, подлежащие рассмотрению, и СЛЕДУЕТ (SHOULD), чтобы она содержала (непосредственно или по ссылке) материалы, подтверждающие возражения.

6.  Соображения безопасности

   Соображения безопасности, подробно изложенные в BCP 26 [RFC2434], в целом применимы к настоящему документу. Дополнительные соображения безопасности, специфичные для каждого пространства имён, где это уместно обсуждаются в разделе 3.

   Соображения безопасности для LDAP обсуждаются в документах, составляющих техническую спецификацию [RFC4510].





Zeilenga                 Best Current Practice                 [Page 10]

RFC 4520              IANA Considerations for LDAP             June 2006


7.  Благодарность

   Настоящий документ является продуктом рабочей группы (WG) IETF по пересмотру LDAP (LDAPBIS). Настоящий документ является пересмотром RFC 3383, также продукта WG LDAPBIS.

   Настоящий документ включает текст, заимствованный из "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434], авторами которого являются Thomas Narten и Harald Alvestrand.

8.  Ссылки

8.1.  Нормативные ссылки

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.



Zeilenga                 Best Current Practice                 [Page 11]

RFC 4520              IANA Considerations for LDAP             June 2006


   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
              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/).

   [X.680]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Abstract Syntax Notation One
              (ASN.1) - Specification of Basic Notation", X.680(2002)
              (также ISO/IEC 8824-1:2002).

8.2.  Справочные ссылки

   [RFC1779]  Kille, S., "A String Representation of Distinguished
              Names", RFC 1779, March 1995.

   [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
              version 2 (LDAPv2) to Historic Status", RFC 3494, March
              2003.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names", RFC
              4514, June 2006.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, June
              2006.

   [IANADSN]  IANA, "Directory Systems Names",
              http://www.iana.org/assignments/directory-system-names.














Zeilenga                 Best Current Practice                 [Page 12]

RFC 4520              IANA Considerations for LDAP             June 2006


Приложение A.  Шаблоны регистрации

   В этом приложении приведены шаблоны регистрации для регистрации новых значений LDAP. Обратите внимание, что запросить можно более одного значения, расширив шаблон перечислением нескольких значений или используя таблицы.

A.1.  Шаблон регистрации идентификатора объекта LDAP

   Тема: Запрос на регистрацию LDAP OID

   Лицо и адрес электронной почты для связи с целью получения дополнительной информации:

   Спецификация: (I-D)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые заявитель считает относящимися к запросу.)

A.2.  Шаблон регистрации механизма протокола LDAP

   Тема: Запрос на регистрацию механизма протокола LDAP

   Идентификатор объекта:

   Описание:

   Лицо и адрес электронной почты для связи с целью получения дополнительной информации:

   Использование: (Одно из: Control, Extension, Feature или другое)

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые заявитель считает относящимися к запросу.)







Zeilenga                 Best Current Practice                 [Page 13]

RFC 4520              IANA Considerations for LDAP             June 2006


A.3.  Шаблон регистрации синтаксиса LDAP

   Тема: Запрос на регистрацию синтаксиса LDAP

   Идентификатор объекта:

   Описание:

   Лицо и адрес электронной почты для связи с целью получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые заявитель считает относящимися к запросу.)

A.4.  Шаблон регистрации дескриптора LDAP

   Тема: Запрос на регистрацию дескриптора LDAP

   Дескриптор (краткое имя):

   Идентификатор объекта:

   Лицо и адрес электронной почты для связи с целью получения дополнительной информации:

   Использование: (Одно из: administrative role, attribute type, matching rule,
     name form, object class, URL extension или other)

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые заявитель считает относящимися к запросу.)








Zeilenga                 Best Current Practice                 [Page 14]

RFC 4520              IANA Considerations for LDAP             June 2006


A.5.  Шаблон регистрации опции описания атрибута LDAP

   Тема: Запрос на регистрацию опции описания атрибута LDAP
   Имя опции:

   Семейство параметров: (YES или NO)

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)

A.6.  Шаблон регистрации типа LDAP-сообщения

   Тема: Запрос на регистрацию типа LDAP-сообщения

   Имя LDAP-сообщения:

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (утверждённый I-D)

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)

A.7.  Шаблон регистрации метода аутентификации LDAP

   Тема: Запрос на регистрацию метода аутентификации LDAP

   Имя метода аутентификации:

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Предполагаемое использование: (одно из COMMON, LIMITED-USE, OBSOLETE)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)



Zeilenga                 Лучшая современная практика                 [Страница 15]

RFC 4520              Соображения IANA для LDAP             Июнь 2006


A.8.  Шаблон регистрации кода результата LDAP

   Тема: Запрос на регистрацию кода результата LDAP

   Имя кода результата:

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)

A.8.  Шаблон регистрации области поиска LDAP

   Тема: Запрос на регистрацию области поиска LDAP

   Имя области поиска:

   Строка области фильтра:

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)














Zeilenga                 Лучшая современная практика                 [Страница 16]

RFC 4520              Соображения IANA для LDAP             Июнь 2006


A.9.  Шаблон регистрации варианта фильтра LDAP

   Тема: Запрос на регистрацию варианта фильтра LDAP

   Имя варианта фильтра:

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)

A.10.  Шаблон регистрации операции LDAP ModifyRequest

   Тема: Запрос на регистрацию операции LDAP ModifyRequest

   Имя операции ModifyRequest:

   Лицо и адрес электронной почты для связи для получения дополнительной информации:

   Спецификация: (RFC, I-D, URI)

   Автор/контролёр изменений:

   Комментарии:

   (Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)

Приложение B.  Изменения со времени RFC 3383

   В этом информационном приложении приводится сводка изменений, внесённых со времени
   RFC 3383.

      -  Практики в отношении дескрипторов идентификаторов объектов были обновлены,
         чтобы требовать регистрации всех дескрипторов, определённых в RFC, и
         рекомендовать регистрацию всех прочих дескрипторов (за исключением
         находящихся в пространстве имён частного использования). Кроме того, все
         запросы на многократную регистрацию одного и того же дескриптора теперь
         подлежат процедуре Expert Review.

      -  Практики в отношении механизмов протокола были обновлены, чтобы включить
         значения типа атрибута 'supportedFeatures'.





Zeilenga                 Лучшая современная практика                 [Страница 17]

RFC 4520              Соображения IANA для LDAP             Июнь 2006


      -  Были добавлены реестры синтаксисов LDAP, областей поиска, вариантов
         фильтра, операций ModifyRequest и префиксов authzId.

      -  Ссылки на RFC, составляющие технические спецификации LDAP, были обновлены
         до последних редакций.

      -  Ссылки на ISO 10646 были заменены на [Unicode].

      -  Приложение «Назначенные значения», содержащее первоначальные значения
         реестра, было удалено.

      -  Было внесено множество редакционных изменений.

Адрес автора

   Kurt D. Zeilenga
   OpenLDAP Foundation

   EMail: Kurt@OpenLDAP.org
























Zeilenga                 Лучшая современная практика                 [Страница 18]

RFC 4520              Соображения IANA для LDAP             Июнь 2006


Полное заявление об авторских правах

   Авторское право (C) The Internet Society (2006).

   На настоящий документ распространяются права, лицензии и ограничения,
   содержащиеся в BCP 78, и, за исключением предусмотренного там, авторы
   сохраняют все свои права.

   Настоящий документ и содержащаяся в нём информация предоставляются на условиях
   «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ
   СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И THE INTERNET
   ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ
   ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, СРЕДИ ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
   СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ИЛИ ЛЮБЫЕ
   ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ
   ОПРЕДЕЛЁННОЙ ЦЕЛИ.

Интеллектуальная собственность

   IETF не занимает никакой позиции относительно действительности или объёма
   каких-либо прав интеллектуальной собственности либо иных прав, которые могут
   заявляться как относящиеся к реализации или использованию технологии,
   описанной в настоящем документе, или относительно того, может ли быть или не
   может быть доступна какая-либо лицензия в отношении таких прав; также она не
   заявляет, что предпринимала какие-либо независимые усилия для выявления таких
   прав. Информацию о процедурах в отношении прав в документах RFC можно найти в
   BCP 78 и BCP 79.

   Копии раскрытий IPR, направленных в Секретариат IETF, и любых заверений о
   лицензиях, которые будут предоставлены, либо результат попытки получить общую
   лицензию или разрешение на использование таких охраняемых прав разработчиками
   или пользователями этой спецификации можно получить в онлайновом репозитории
   IPR IETF по адресу
   http://www.ietf.org/ipr.

   IETF предлагает любой заинтересованной стороне довести до её сведения любые
   авторские права, патенты или заявки на патенты либо иные охраняемые права,
   которые могут распространяться на технологию, которая может потребоваться для
   реализации этого стандарта. Просим направлять информацию в IETF по адресу
   ietf-ipr@ietf.org.

Благодарность

   Финансирование функции RFC Editor обеспечивается деятельностью по
   административной поддержке IETF (IASA).






Zeilenga                 Лучшая современная практика                 [Страница 19]
Оригинал (EN)





Network Working Group                                        K. Zeilenga
Request for Comments: 4520                           OpenLDAP Foundation
BCP: 64                                                        June 2006
Obsoletes: 3383
Category: Best Current Practice


     Internet Assigned Numbers Authority (IANA) Considerations for
            the Lightweight Directory Access Protocol (LDAP)

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides procedures for registering extensible elements
   of the Lightweight Directory Access Protocol (LDAP).  The document
   also provides guidelines to the Internet Assigned Numbers Authority
   (IANA) describing conditions under which new values can be assigned.

1.  Introduction

   The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
   extensible protocol.  LDAP supports:

      -  the addition of new operations,
      -  the extension of existing operations, and
      -  the extensible schema.

   This document details procedures for registering values used to
   unambiguously identify extensible elements of the protocol, including
   the following:

      - LDAP message types
      - LDAP extended operations and controls
      - LDAP result codes
      - LDAP authentication methods
      - LDAP attribute description options
      - Object Identifier descriptors





Zeilenga                 Best Current Practice                  [Page 1]

RFC 4520              IANA Considerations for LDAP             June 2006


   These registries are maintained by the Internet Assigned Numbers
   Authority (IANA).

   In addition, this document provides guidelines to IANA describing the
   conditions under which new values can be assigned.

   This document replaces RFC 3383.

2.  Terminology and Conventions

   This section details terms and conventions used in this document.

2.1.  Policy Terminology

   The terms "IESG Approval", "Standards Action", "IETF Consensus",
   "Specification Required", "First Come First Served", "Expert Review",
   and "Private Use" are used as defined in BCP 26 [RFC2434].

   The term "registration owner" (or "owner") refers to the party
   authorized to change a value's registration.

2.2.  Requirement Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].  In
   this case, "the specification", as used by BCP 14, refers to the
   processing of protocols being submitted to the IETF standards
   process.

2.3.  Common ABNF Productions

   A number of syntaxes in this document are described using ABNF
   [RFC4234].  These syntaxes rely on the following common productions:

         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

   Keywords are case insensitive.




Zeilenga                 Best Current Practice                  [Page 2]

RFC 4520              IANA Considerations for LDAP             June 2006


3.  IANA Considerations for LDAP

   This section details each kind of protocol value that can be
   registered and provides IANA guidelines on how to assign new values.

   IANA may reject obviously bogus registrations.

   LDAP values specified in RFCs MUST be registered.  Other LDAP values,
   except those in private-use name spaces, SHOULD be registered.  RFCs
   SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
   values.

3.1.  Object Identifiers

   Numerous LDAP schema and protocol elements are identified by Object
   Identifiers (OIDs) [X.680].  Specifications that assign OIDs to
   elements SHOULD state who delegated the OIDs for their use.

   For IETF-developed elements, specifications SHOULD use OIDs under
   "Internet Directory Numbers" (1.3.6.1.1.x).  For elements developed
   by others, any properly delegated OID can be used, including those
   under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
   Enterprise Numbers" (1.3.6.1.4.1.x).

   Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
   Review with Specification Required.  Only one OID per specification
   will be assigned.  The specification MAY then assign any number of
   OIDs within this arc without further coordination with IANA.

   Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
   IANA <http://www.iana.org/cgi-bin/enterprise.pl>.  Practices for IANA
   assignment of Internet Private Enterprise Numbers are detailed in RFC
   2578 [RFC2578].

   To avoid interoperability problems between early implementations of a
   "work in progress" and implementations of the published specification
   (e.g., the RFC), experimental OIDs SHOULD be used in "works in
   progress" and early implementations.  OIDs under the Internet
   Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
   Practices for IANA assignment of these Internet Experimental numbers
   are detailed in RFC 2578 [RFC2578].

3.2.  Protocol Mechanisms

   LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
   for discovery of protocol mechanisms identified by OIDs, including
   the supportedControl, supportedExtension, and supportedFeatures
   attributes [RFC4512].



Zeilenga                 Best Current Practice                  [Page 3]

RFC 4520              IANA Considerations for LDAP             June 2006


   A registry of OIDs used for discovery of protocol mechanisms is
   provided to allow implementors and others to locate the technical
   specification for these protocol mechanisms.  Future specifications
   of additional Root DSE attributes holding values identifying protocol
   mechanisms MAY extend this registry for their values.

   Protocol mechanisms are registered on a First Come First Served
   basis.

3.3.  LDAP Syntaxes

   This registry provides a listing of LDAP syntaxes [RFC4512].  Each
   LDAP syntax is identified by an OID.  This registry is provided to
   allow implementors and others to locate the technical specification
   describing a particular LDAP Syntax.

   LDAP Syntaxes are registered on a First Come First Served with
   Specification Required basis.

   Note: Unlike object classes, attribute types, and various other kinds
         of schema elements, descriptors are not used in LDAP to
         identify LDAP Syntaxes.

3.4.  Object Identifier Descriptors

   LDAP allows short descriptive names (or descriptors) to be used
   instead of a numeric Object Identifier to identify select protocol
   extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
   extensions, and other objects.

   Although the protocol allows the same descriptor to refer to
   different object identifiers in certain cases and the registry
   supports multiple registrations of the same descriptor (each
   indicating a different kind of schema element and different object
   identifier), multiple registrations of the same descriptor are to be
   avoided.  All such multiple registration requests require Expert
   Review.

   Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
   Unicode characters restricted by the following ABNF:

      name = keystring

   Descriptors are case insensitive.

   Multiple names may be assigned to a given OID.  For purposes of
   registration, an OID is to be represented in numeric OID form (e.g.,
   1.1.0.23.40) conforming to the following ABNF:



Zeilenga                 Best Current Practice                  [Page 4]

RFC 4520              IANA Considerations for LDAP             June 2006


      numericoid = number 1*( DOT number )

   While the protocol places no maximum length restriction upon
   descriptors, they should be short.  Descriptors longer than 48
   characters may be viewed as too long to register.

   A value ending with a hyphen ("-") reserves all descriptors that
   start with that value.  For example, the registration of the option
   "descrFamily-" reserves all options that start with "descrFamily-"
   for some related purpose.

   Descriptors beginning with "x-" are for Private Use and cannot be
   registered.

   Descriptors beginning with "e-" are reserved for experiments and will
   be registered on a First Come First Served basis.

   All other descriptors require Expert Review to be registered.

   The registrant need not "own" the OID being named.

   The OID name space is managed by the ISO/IEC Joint Technical
   Committee 1 - Subcommittee 6.

3.5.  AttributeDescription Options

   An AttributeDescription [RFC4512] can contain zero or more options
   specifying additional semantics.  An option SHALL be restricted to a
   string of UTF-8 encoded Unicode characters limited by the following
   ABNF:

      option = keystring

   Options are case insensitive.

   While the protocol places no maximum length restriction upon option
   strings, they should be short.  Options longer than 24 characters may
   be viewed as too long to register.

   Values ending with a hyphen ("-") reserve all option names that start
   with the name.  For example, the registration of the option
   "optionFamily-" reserves all options that start with "optionFamily-"
   for some related purpose.

   Options beginning with "x-" are for Private Use and cannot be
   registered.





Zeilenga                 Best Current Practice                  [Page 5]

RFC 4520              IANA Considerations for LDAP             June 2006


   Options beginning with "e-" are reserved for experiments and will be
   registered on a First Come First Served basis.

   All other options require Standards Action or Expert Review with
   Specification Required to be registered.

3.6.  LDAP Message Types

   Each protocol message is encapsulated in an LDAPMessage envelope
   [RFC4511.  The protocolOp CHOICE indicates the type of message
   encapsulated.  Each message type consists of an ASN.1 identifier in
   the form of a keyword and a non-negative choice number.  The choice
   number is combined with the class (APPLICATION) and data type
   (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
   encoding.  The choice numbers for existing protocol messages are
   implicit in the protocol's ASN.1 defined in [RFC4511].

   New values will be registered upon Standards Action.

   Note: LDAP provides extensible messages that reduce but do not
         eliminate the need to add new message types.

3.7.  LDAP Authentication Method

   The LDAP Bind operation supports multiple authentication methods
   [RFC4511].  Each authentication choice consists of an ASN.1
   identifier in the form of a keyword and a non-negative integer.

   The registrant SHALL classify the authentication method usage using
   one of the following terms:

         COMMON      - method is appropriate for common use on the
                       Internet.
         LIMITED USE - method is appropriate for limited use.
         OBSOLETE    - method has been deprecated or otherwise found to
                       be inappropriate for any use.

   Methods without publicly available specifications SHALL NOT be
   classified as COMMON.  New registrations of the class OBSOLETE cannot
   be registered.

   New authentication method integers in the range 0-1023 require
   Standards Action to be registered.  New authentication method
   integers in the range 1024-4095 require Expert Review with
   Specification Required.  New authentication method integers in the
   range 4096-16383 will be registered on a First Come First Served
   basis.  Keywords associated with integers in the range 0-4095 SHALL
   NOT start with "e-" or "x-".  Keywords associated with integers in



Zeilenga                 Best Current Practice                  [Page 6]

RFC 4520              IANA Considerations for LDAP             June 2006


   the range 4096-16383 SHALL start with "e-".  Values greater than or
   equal to 16384 and keywords starting with "x-" are for Private Use
   and cannot be registered.

   Note: LDAP supports Simple Authentication and Security Layers
         [RFC4422] as an authentication choice.  SASL is an extensible
         authentication framework.

3.8.  LDAP Result Codes

   LDAP result messages carry a resultCode enumerated value to indicate
   the outcome of the operation [RFC4511].  Each result code consists of
   an ASN.1 identifier in the form of a keyword and a non-negative
   integer.

   New resultCodes integers in the range 0-1023 require Standards Action
   to be registered.  New resultCode integers in the range 1024-4095
   require Expert Review with Specification Required.  New resultCode
   integers in the range 4096-16383 will be registered on a First Come
   First Served basis.  Keywords associated with integers in the range
   0-4095 SHALL NOT start with "e-" or "x-".  Keywords associated with
   integers in the range 4096-16383 SHALL start with "e-".  Values
   greater than or equal to 16384 and keywords starting with "x-" are
   for Private Use and cannot be registered.

3.9.  LDAP Search Scope

   LDAP SearchRequest messages carry a scope-enumerated value to
   indicate the extent of search within the DIT [RFC4511].  Each search
   value consists of an ASN.1 identifier in the form of a keyword and a
   non-negative integer.

   New scope integers in the range 0-1023 require Standards Action to be
   registered.  New scope integers in the range 1024-4095 require Expert
   Review with Specification Required.  New scope integers in the range
   4096-16383 will be registered on a First Come First Served basis.
   Keywords associated with integers in the range 0-4095 SHALL NOT start
   with "e-" or "x-".  Keywords associated with integers in the range
   4096-16383 SHALL start with "e-".  Values greater than or equal to
   16384 and keywords starting with "x-" are for Private Use and cannot
   be registered.

3.10.  LDAP Filter Choice

   LDAP filters are used in making assertions against an object
   represented in the directory [RFC4511].  The Filter CHOICE indicates
   a type of assertion.  Each Filter CHOICE consists of an ASN.1
   identifier in the form of a keyword and a non-negative choice number.



Zeilenga                 Best Current Practice                  [Page 7]

RFC 4520              IANA Considerations for LDAP             June 2006


   The choice number is combined with the class (APPLICATION) and data
   type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
   message's encoding.

   Note: LDAP provides the extensibleMatching choice, which reduces but
         does not eliminate the need to add new filter choices.

3.11.  LDAP ModifyRequest Operation Type

   The LDAP ModifyRequest carries a sequence of modification operations
   [RFC4511].  Each kind (e.g., add, delete, replace) of operation
   consists of an ASN.1 identifier in the form of a keyword and a non-
   negative integer.

   New operation type integers in the range 0-1023 require Standards
   Action to be registered.  New operation type integers in the range
   1024-4095 require Expert Review with Specification Required.  New
   operation type integers in the range 4096-16383 will be registered on
   a First Come First Served basis.  Keywords associated with integers
   in the range 0-4095 SHALL NOT start with "e-" or "x-".  Keywords
   associated with integers in the range 4096-16383 SHALL start with
   "e-".  Values greater than or equal to 16384 and keywords starting
   with "x-" are for Private Use and cannot be registered.

3.12.  LDAP authzId Prefixes

   Authorization Identities in LDAP are strings conforming to the
   <authzId> production [RFC4513].  This production is extensible.  Each
   new specific authorization form is identified by a prefix string
   conforming to the following ABNF:

         prefix = keystring COLON
         COLON = %x3A ; COLON (":" U+003A)

   Prefixes are case insensitive.

   While the protocol places no maximum length restriction upon prefix
   strings, they should be short.  Prefixes longer than 12 characters
   may be viewed as too long to register.

   Prefixes beginning with "x-" are for Private Use and cannot be
   registered.

   Prefixes beginning with "e-" are reserved for experiments and will be
   registered on a First Come First Served basis.

   All other prefixes require Standards Action or Expert Review with
   Specification Required to be registered.



Zeilenga                 Best Current Practice                  [Page 8]

RFC 4520              IANA Considerations for LDAP             June 2006


3.13.  Directory Systems Names

   The IANA-maintained "Directory Systems Names" registry [IANADSN] of
   valid keywords for well-known attributes was used in the LDAPv2
   string representation of a distinguished name [RFC1779].  LDAPv2 is
   now Historic [RFC3494].

   Directory systems names are not known to be used in any other
   context.  LDAPv3 [RFC4514] uses Object Identifier Descriptors
   [Section 3.2] (which have a different syntax than directory system
   names).

   New Directory System Names will no longer be accepted.  For
   historical purposes, the current list of registered names should
   remain publicly available.

4.  Registration Procedure

   The procedure given here MUST be used by anyone who wishes to use a
   new value of a type described in Section 3 of this document.

   The first step is for the requester to fill out the appropriate form.
   Templates are provided in Appendix A.

   If the policy is Standards Action, the completed form SHOULD be
   provided to the IESG with the request for Standards Action.  Upon
   approval of the Standards Action, the IESG SHALL forward the request
   (possibly revised) to IANA.  The IESG SHALL be regarded as the
   registration owner of all values requiring Standards Action.

   If the policy is Expert Review, the requester SHALL post the
   completed form to the <directory@apps.ietf.org> mailing list for
   public review.  The review period is two (2) weeks.  If a revised
   form is later submitted, the review period is restarted.  Anyone may
   subscribe to this list by sending a request to <directory-
   request@apps.ietf.org>.  During the review, objections may be raised
   by anyone (including the Expert) on the list.  After completion of
   the review, the Expert, based on public comments, SHALL either
   approve the request and forward it to the IANA OR deny the request.
   In either case, the Expert SHALL promptly notify the requester of the
   action.  Actions of the Expert may be appealed [RFC2026].  The Expert
   is appointed by Applications Area Directors.  The requester is viewed
   as the registration owner of values registered under Expert Review.

   If the policy is First Come First Served, the requester SHALL submit
   the completed form directly to the IANA: <iana@iana.org>.  The
   requester is viewed as the registration owner of values registered
   under First Come First Served.



Zeilenga                 Best Current Practice                  [Page 9]

RFC 4520              IANA Considerations for LDAP             June 2006


   Neither the Expert nor IANA will take position on the claims of
   copyright or trademark issues regarding completed forms.

   Prior to submission of the Internet Draft (I-D) to the RFC Editor but
   after IESG review and tentative approval, the document editor SHOULD
   revise the I-D to use registered values.

5.  Registration Maintenance

   This section discusses maintenance of registrations.

5.1.  Lists of Registered Values

   IANA makes lists of registered values readily available to the
   Internet community on its web site: <http://www.iana.org/>.

5.2.  Change Control

   The registration owner MAY update the registration subject to the
   same constraints and review as with new registrations.  In cases
   where the registration owner is unable or is unwilling to make
   necessary updates, the IESG MAY assume ownership of the registration
   in order to update the registration.

5.3.  Comments

   For cases where others (anyone other than the registration owner)
   have significant objections to the claims in a registration and the
   registration owner does not agree to change the registration,
   comments MAY be attached to a registration upon Expert Review.  For
   registrations owned by the IESG, the objections SHOULD be addressed
   by initiating a request for Expert Review.

   The form of these requests is ad hoc, but MUST include the specific
   objections to be reviewed and SHOULD contain (directly or by
   reference) materials supporting the objections.

6.  Security Considerations

   The security considerations detailed in BCP 26 [RFC2434] are
   generally applicable to this document.  Additional security
   considerations specific to each name space are discussed in Section
   3, where appropriate.

   Security considerations for LDAP are discussed in documents
   comprising the technical specification [RFC4510].





Zeilenga                 Best Current Practice                 [Page 10]

RFC 4520              IANA Considerations for LDAP             June 2006


7.  Acknowledgement

   This document is a product of the IETF LDAP Revision (LDAPBIS)
   Working Group (WG).  This document is a revision of RFC 3383, also a
   product of the LDAPBIS WG.

   This document includes text borrowed from "Guidelines for Writing an
   IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
   Harald Alvestrand.

8.  References

8.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.



Zeilenga                 Best Current Practice                 [Page 11]

RFC 4520              IANA Considerations for LDAP             June 2006


   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
              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).

8.2.  Informative References

   [RFC1779]  Kille, S., "A String Representation of Distinguished
              Names", RFC 1779, March 1995.

   [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
              version 2 (LDAPv2) to Historic Status", RFC 3494, March
              2003.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names", RFC
              4514, June 2006.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, June
              2006.

   [IANADSN]  IANA, "Directory Systems Names",
              http://www.iana.org/assignments/directory-system-names.















Zeilenga                 Best Current Practice                 [Page 12]

RFC 4520              IANA Considerations for LDAP             June 2006


Appendix A.  Registration Templates

   This appendix provides registration templates for registering new
   LDAP values.  Note that more than one value may be requested by
   extending the template by listing multiple values, or through use of
   tables.

A.1.  LDAP Object Identifier Registration Template

   Subject: Request for LDAP OID Registration

   Person & email address to contact for further information:

   Specification: (I-D)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.2.  LDAP Protocol Mechanism Registration Template

   Subject: Request for LDAP Protocol Mechanism Registration

   Object Identifier:

   Description:

   Person & email address to contact for further information:

   Usage: (One of Control or Extension or Feature or other)

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)











Zeilenga                 Best Current Practice                 [Page 13]

RFC 4520              IANA Considerations for LDAP             June 2006


A.3.  LDAP Syntax Registration Template

   Subject: Request for LDAP Syntax Registration

   Object Identifier:

   Description:

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.4.  LDAP Descriptor Registration Template

   Subject: Request for LDAP Descriptor Registration

   Descriptor (short name):

   Object Identifier:

   Person & email address to contact for further information:

   Usage: (One of administrative role, attribute type, matching rule,
     name form, object class, URL extension, or other)

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)













Zeilenga                 Best Current Practice                 [Page 14]

RFC 4520              IANA Considerations for LDAP             June 2006


A.5.  LDAP Attribute Description Option Registration Template

   Subject: Request for LDAP Attribute Description Option Registration
   Option Name:

   Family of Options: (YES or NO)

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.6.  LDAP Message Type Registration Template

   Subject: Request for LDAP Message Type Registration

   LDAP Message Name:

   Person & email address to contact for further information:

   Specification: (Approved I-D)

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.7.  LDAP Authentication Method Registration Template

   Subject: Request for LDAP Authentication Method Registration

   Authentication Method Name:

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)



Zeilenga                 Best Current Practice                 [Page 15]

RFC 4520              IANA Considerations for LDAP             June 2006


A.8.  LDAP Result Code Registration Template

   Subject: Request for LDAP Result Code Registration

   Result Code Name:

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.8.  LDAP Search Scope Registration Template

   Subject: Request for LDAP Search Scope Registration

   Search Scope Name:

   Filter Scope String:

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)


















Zeilenga                 Best Current Practice                 [Page 16]

RFC 4520              IANA Considerations for LDAP             June 2006


A.9.  LDAP Filter Choice Registration Template

   Subject: Request for LDAP Filter Choice Registration

   Filter Choice Name:

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.10.  LDAP ModifyRequest Operation Registration Template

   Subject: Request for LDAP ModifyRequest Operation Registration

   ModifyRequest Operation Name:

   Person & email address to contact for further information:

   Specification: (RFC, I-D, URI)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

Appendix B.  Changes since RFC 3383

   This informative appendix provides a summary of changes made since
   RFC 3383.

      -  Object Identifier Descriptors practices were updated to require
         all descriptors defined in RFCs to be registered and
         recommending all other descriptors (excepting those in
         private-use name space) be registered.  Additionally, all
         requests for multiple registrations of the same descriptor are
         now subject to Expert Review.

      -  Protocol Mechanisms practices were updated to include values of
         the 'supportedFeatures' attribute type.





Zeilenga                 Best Current Practice                 [Page 17]

RFC 4520              IANA Considerations for LDAP             June 2006


      -  LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
         operation, and authzId prefixes registries were added.

      -  References to RFCs comprising the LDAP technical specifications
         have been updated to latest revisions.

      -  References to ISO 10646 have been replaced with [Unicode].

      -  The "Assigned Values" appendix providing initial registry
         values was removed.

      -  Numerous editorial changes were made.

Author's Address

   Kurt D. Zeilenga
   OpenLDAP Foundation

   EMail: Kurt@OpenLDAP.org
































Zeilenga                 Best Current Practice                 [Page 18]

RFC 4520              IANA Considerations for LDAP             June 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Zeilenga                 Best Current Practice                 [Page 19]