Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)
О документе
Рабочая группа по сетевым вопросам K. Zeilenga
Запрос комментариев: 4520 OpenLDAP Foundation
BCP: 64 Июнь 2006
Заменяет: 3383
Категория: Лучшая современная практика
Вопросы, относящиеся к Internet Assigned Numbers Authority (IANA), для
Lightweight Directory Access Protocol (LDAP)
1. Введение
Lightweight Directory Access Protocol [RFC4510] (LDAP) является
расширяемым протоколом. LDAP поддерживает:
- добавление новых операций,
- расширение существующих операций и
- расширяемую схему.
Этот документ подробно описывает процедуры регистрации значений,
используемых для однозначной идентификации расширяемых элементов
протокола, включая следующее:
- типы сообщений LDAP
- расширенные операции и элементы управления LDAP
- коды результатов LDAP
- методы аутентификации LDAP
- параметры описания атрибута LDAP
- дескрипторы Object Identifier
Эти реестры поддерживаются 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
Ключевые слова не чувствительны к регистру.
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].
Реестр 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:
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 и не
могут быть зарегистрированы.
Параметры, начинающиеся с "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 и
не могут быть зарегистрированы.
Примечание: 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 в форме ключевого слова и неотрицательного номера варианта.
Номер варианта объединяется с классом (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.
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.
Ни Эксперт, ни 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].
7. Благодарность
Настоящий документ является продуктом рабочей группы (WG) IETF по пересмотру LDAP (LDAPBIS). Настоящий документ является пересмотром RFC 3383, также продукта WG LDAPBIS.
Настоящий документ включает текст, заимствованный из "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434], авторами которого являются Thomas Narten и Harald Alvestrand.
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.
[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.
Приложение A. Шаблоны регистрации
В этом приложении приведены шаблоны регистрации для регистрации новых значений LDAP. Обратите внимание, что запросить можно более одного значения, расширив шаблон перечислением нескольких значений или используя таблицы.
A.1. Шаблон регистрации идентификатора объекта LDAP
Тема: Запрос на регистрацию LDAP OID
Лицо и адрес электронной почты для связи с целью получения дополнительной информации:
Спецификация: (I-D)
Автор/контролёр изменений:
Комментарии:
(Любые комментарии, которые заявитель считает относящимися к запросу.)
A.2. Шаблон регистрации механизма протокола LDAP
Тема: Запрос на регистрацию механизма протокола LDAP
Идентификатор объекта:
Описание:
Лицо и адрес электронной почты для связи с целью получения дополнительной информации:
Использование: (Одно из: Control, Extension, Feature или другое)
Спецификация: (RFC, I-D, URI)
Автор/контролёр изменений:
Комментарии:
(Любые комментарии, которые заявитель считает относящимися к запросу.)
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)
Автор/контролёр изменений:
Комментарии:
(Любые комментарии, которые заявитель считает относящимися к запросу.)
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)
Автор/контролёр изменений:
Комментарии:
(Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)
A.8. Шаблон регистрации кода результата LDAP
Тема: Запрос на регистрацию кода результата LDAP
Имя кода результата:
Лицо и адрес электронной почты для связи для получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/контролёр изменений:
Комментарии:
(Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)
A.8. Шаблон регистрации области поиска LDAP
Тема: Запрос на регистрацию области поиска LDAP
Имя области поиска:
Строка области фильтра:
Лицо и адрес электронной почты для связи для получения дополнительной информации:
Спецификация: (RFC, I-D, URI)
Автор/контролёр изменений:
Комментарии:
(Любые комментарии, которые запрашивающая сторона считает относящимися к запросу.)
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'.
- Были добавлены реестры синтаксисов LDAP, областей поиска, вариантов
фильтра, операций ModifyRequest и префиксов authzId.
- Ссылки на RFC, составляющие технические спецификации LDAP, были обновлены
до последних редакций.
- Ссылки на ISO 10646 были заменены на [Unicode].
- Приложение «Назначенные значения», содержащее первоначальные значения
реестра, было удалено.
- Было внесено множество редакционных изменений.