Network Working Group
Request for Comments: 4514
Категория: Standards Track
Под редакцией K. Zeilenga, OpenLDAP Foundation
Июнь 2006 года
Отменяет: RFC 2253

Lightweight Directory Access Protocol (LDAP): Строковое представление уникальных имён

Статус документа

Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.

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

Copyright (C) Internet Society (2006).

Тезисы

Каталог X.500 использует уникальные имена (Distinguished Names, DN) в качестве первичных ключей записей в каталоге. В этом документе определяется строковое представление, используемое в протоколе Lightweight Directory Access Protocol (LDAP) для передачи уникальных имён. Это строковое представление разработано с целью обеспечить простое и понятное представление обычно используемых уникальных имён, а также иметь возможность представить любые уникальные имена.

1. Предпосылки и предполагаемое использование

В системах каталогов, основанных на X.500 [X.500], в том числе тех, доступ к которым осуществляется с использованием протокола Lightweight Directory Access Protocol (LDAP) [RFC4510], уникальные имена (DN) используются для однозначного указания на записи каталога [X.501][RFC4512].

Структура DN [X.501] описывается в терминах ASN.1 [X.680]. В протоколе Directory Access Protocol стандарта X.500 [X.511] (и других определённых ITU протоколах, связанных с каталогами), DN кодируются с использованием Basic Encoding Rules (BER) [X.690]. В LDAP DN представляются в строковой форме, описанной в этом документе.

Важно иметь общепринятый формат, позволяющий однозначно представлять уникальные имена. Основная цель данной спецификации — обеспечить простоту кодирования и декодирования имён. Вторая цель — иметь имена, которые могли бы быть читаемы человеком. Не ожидается, что реализации LDAP с интерфейсом, рассчитанным на вывод информации человеку, будут отображать эти строки непосредственно пользователю; вероятнее всего, они будут выполнять трансляции (например, представление имён типов атрибутов на национальном языке).

В этом документе определяется строковое представление используемых в LDAP [RFC4511][RFC4517] уникальных имён. В разделе 2 приводится рекомендуемый (RECOMMENDED) алгоритм конвертирования DN из его структурированного представления ASN.1 в строку. В разделе 3 описывается, каким образом конвертировать DN из строки в структурированное представление ASN.1.

Хотя в других документах могут быть определены иные алгоритмы конвертирования DN из структурированного представления ASN.1 в строку, все алгоритмы должны (MUST) выдавать строки, соблюдающие требования, приведённые в разделе 3.

В этом документе не определяется каноническое строковое представление для DN. Сравнение DN на эквивалентность должно выполняться согласно правилу соответствия distinguishedNameMatch [RFC4517].

Этот документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей предыдущую техническую спецификацию LDAP, RFC 3377. Этот документ отменяет RFC 2253. Изменения, внесённые в RFC 2253, обобщены в приложении B.

В этой спецификации предполагается, что читатель знаком со стандартом X.500 [X.500] и концепцией уникального имени [X.501][RFC4512].

1.1. Соглашения

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

Обозначения символов в этом документе используют нотацию кодирования и именования из стандарта Unicode [Unicode]. Например, буква "a" может быть представлена либо как <U+0061>, либо как <LATIN SMALL LETTER A>.

Примечание: термины, используемые в Unicode, можно найти в соответствующем [Глоссарии]. Информацию о модели кодирования символов Unicode можно найти в [Техническом отчёте Unicode].

2. Конвертирование DistinguishedName из ASN.1 в строку

Стандарт X.501 [X.501] определяет структуру ASN.1 [X.680] уникального имени. Далее в обсуждении используется следующий вариант такой структуры:

      DistinguishedName ::= RDNSequence

      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
          AttributeTypeAndValue

      AttributeTypeAndValue ::= SEQUENCE {
          type  AttributeType,
          value AttributeValue }

В этом разделе определяется рекомендуемый (RECOMMENDED) алгоритм конвертирования уникального имени из структурированного представления ASN.1 в строковое представление в виде символов Unicode [Unicode], закодированных UTF-8 [RFC3629]. В других документах могут быть описаны другие алгоритмы конвертирования уникального имени в строку, но реализации LDAP должны (SHALL) выдавать только строки, которые соответствуют грамматике, определённой в разделе 3.

2.1. Конвертирование RDNSequence

Если последовательность RDNSequence пуста, результатом конвертирования будет пустая строка или строка нулевой длины.

В противном случае, вывод состоит из элементов RelativeDistinguishedName в последовательности RDNSequence, каждый из которых закодирован в строку (в соответствии с разделом 2.2), начиная с последнего элемента последовательности и двигаясь в обратном направлении в сторону первого.

Смежные строковые представления RelativeDistinguishedNames разделяются символом запятой (',' U+002C).

2.2. Конвертирование RelativeDistinguishedName

При конвертировании RelativeDistinguishedName из ASN.1 в строку вывод состоит из последовательностей AttributeTypeAndValue, каждая из которых закодирована в строку (в соответствии с разделом 2.3), в произвольном порядке.

Если RDN многозначный, смежные строковые представления AttributeTypeAndValues в выводе разделяются символом знака плюс ('+' U+002B).

2.3. Конвертирование AttributeTypeAndValue

Последовательность AttributeTypeAndValue кодируется как строковое представление AttributeType, за которым следует символ знака равенства ('=' U+003D), за которым следует строковое представление AttributeValue. Правила кодирования AttributeValue даны в разделе 2.4.

Если в определении AttributeType имеется короткое имя (дескриптор) [RFC4512] и известно, что это короткое имя зарегистрировано [REGISTRY] [RFC4520] как идентифицирующее данный AttributeType, используется это короткое имя (<descr>). В противном случае, AttributeType кодируется в виде точечно-цифрового представления (<numericoid>) его идентификатора объекта (OBJECT IDENTIFIER). Форматы <descr> и <numericoid> определены в [RFC4512].

Не ожидается, что реализации будут динамически обновлять свою базу знаний зарегистрированных коротких имён. Однако, в реализациях следует (SHOULD) предусматривать механизм, который позволял бы обновлять их базу знаний зарегистрированных коротких имён.

2.4. Конвертирование AttributeValue из ASN.1 в строку

Если AttributeType в точечно-цифровой форме, то AttributeValue представляется в виде символа решётки ('#' U+0023), за которым следуют шестнадцатеричные коды каждого октета закодированного в BER значения AttributeValue X.500. Также эта форма используется, когда у синтаксиса AttributeValue нет определённого для него специфичного для LDAP кодирования в строку (раздел 3.1 [RFC4517]), либо когда специфичное для LDAP кодирование в строку не ограничивается закодированными в UTF-8 символами Unicode. Эта форма также может быть использована и в других случаях, например, когда требуется обратимое строковое представление (смотрите раздел 5.2).

В противном случае, если у синтаксиса AttributeValue имеется специфичное для LDAP кодирование в строку, значение сначала конвертируется в строку символов Unicode, закодированных UTF-8, в соответствии со спецификацией синтаксиса этого значения (примеры смотрите в разделе 3.3 [RFC4517]). Если в этой закодированной UTF-8 строке Unicode не содержится каких-либо из приведённых ниже символов, требующих экранирования, то эта строка может быть использована как строковое представление данного значения.

Символы, которые необходимо экранировать:

• символ пробела (' ' U+0020) или решётки ('#' U+0023), находящийся в начале строки;
• символ пробела (' ' U+0020), находящийся в конце строки;
• один из символов '"', '+', ',', ';', '<', '>' или '\' (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E или U+005C, соответственно);
• символ null (U+0000).

Могут быть экранированы и другие символы.

Каждый байт экранируемого символа заменяется обратным слешем и двумя шестнадцатеричными цифрами, таким образом оформляется один октет в коде символа. С другой стороны, если экранируемый символ является одним из символов

' ', '"', '#', '+', ',', ';', '<', '=', '>' или '\' (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, U+003C, U+003D, U+003E, U+005C, соответственно)

Примеры данного механизма экранирования приведены в разделе 4.

3. Обратный разбор строки в уникальное имя

Строковое представление уникального имени ограничивается символами Unicode [Unicode], закодированными UTF-8 [RFC3629]. Структура этого строкового представления определяется с использованием следующей грамматики ABNF [RFC4234]:

      distinguishedName = [ relativeDistinguishedName
          *( COMMA relativeDistinguishedName ) ]
      relativeDistinguishedName = attributeTypeAndValue
          *( PLUS attributeTypeAndValue )
      attributeTypeAndValue = attributeType EQUALS attributeValue
      attributeType = descr / numericoid
      attributeValue = string / hexstring

      ; Следующие символы должны экранироваться, если они встречаются
      ; в кодируемом значении: ESC, один из <escaped>, начальные
      ; SHARP или SPACE, конечный SPACE, а также NULL.
      string =   [ ( leadchar / pair ) [ *( stringchar / pair )
         ( trailchar / pair ) ] ]

      leadchar = LUTF1 / UTFMB
      LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

      trailchar  = TUTF1 / UTFMB
      TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

      stringchar = SUTF1 / UTFMB
      SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

      pair = ESC ( ESC / special / hexpair )
      special = escaped / SPACE / SHARP / EQUALS
      escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
      hexstring = SHARP 1*hexpair
      hexpair = HEX HEX

В этой грамматике конструкции <descr>, <numericoid>, <COMMA>, <DQUOTE>, <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, <SPACE>, <SHARP> и <UTFMB> определены в [RFC4512].

Каждая из конструкций типа атрибута <attributeType>, представленная либо в виде <descr>, либо в виде <numericoid>, означает тип атрибута в утверждении значения атрибута (attribute value assertion, AVA). За <attributeType> следуют <EQUALS> и <attributeValue>. Конструкция значения атрибута <attributeValue> может быть либо в форме <string>, либо в форме <hexstring>.

Если значение атрибута в форме <string>, то значение утверждения может быть получено из строкового представления LDAP путём замены (слева направо, нерекурсивной) каждой пары <pair>, имеющейся в строке <string>, следующим образом:

<ESC><ESC> заменяется на <ESC>;

<ESC><special> заменяется на <special>;

<ESC><hexpair> заменяется байтом, на который указывает <hexpair>.

Если значение атрибута в форме <hexstring>, значение может быть получено из BER-представления путём конвертирования каждой пары <hexpair> строки <hexstring> в байт, на который указывает <hexpair>.

В относительном уникальном имени может быть одно или несколько утверждений значения атрибута, разделенных знаком <PLUS>.

В уникальном имени может быть ноль или более относительных уникальных имён, разделенных знаком <COMMA>.

Реализации должны (MUST) распознавать приведённые ниже строковые имена (дескрипторы) типов атрибутов AttributeType, но могут (MAY) распознавать и другие строковые имена.

      Строка  X.500 AttributeType
      ------  --------------------------------------------
      CN      commonName (2.5.4.3)
      L       localityName (2.5.4.7)
      ST      stateOrProvinceName (2.5.4.8)
      O       organizationName (2.5.4.10)
      OU      organizationalUnitName (2.5.4.11)
      C       countryName (2.5.4.6)
      STREET  streetAddress (2.5.4.9)
      DC      domainComponent (0.9.2342.19200300.100.1.25)
      UID     userId (0.9.2342.19200300.100.1.1)

Эти типы атрибутов описаны в [RFC4519].

Реализации могут (MAY) распознавать другие строковые представления DN. Однако, поскольку требование о распознавании альтернативных строковых представлений DN не выдвигается (и не приводится возможных механизмов такого распознавания), реализациям следует (SHOULD) генерировать только строковые представления DN в соответствии с разделом 2 этого документа.

4. Примеры

Данная нотация предназначена для удобного представления распространенных форм имени. В этом разделе даны несколько примеров уникальных имён, записанных с использованием этой нотации. Первый пример — имя, содержащее три относительных уникальных имени (RDN):

      UID=jsmith,DC=example,DC=net

Пример имени, содержащего три RDN, первое из которых многозначное:

      OU=Sales+CN=J.  Smith,DC=example,DC=net

В этом примере показан метод экранирования специальных символов, встречающихся в общепринятом имени (common name):

      CN=James \"Jim\" Smith\, III,DC=example,DC=net

В следующем примере показан метод кодирования значения, содержащего символ возврата каретки:

      CN=Before\0dAfter,DC=example,DC=net

В этом примере RDN тип атрибута RDN не распознан, а значение представляет собой BER-кодировку строки октетов (OCTET STRING), содержащей два октета (0x48 и 0x69):

      1.3.6.1.4.1.1466.0=#04024869

Наконец, в этом примере показано RDN, значение commonName которого состоит из 5 букв:

      Символ Unicode                   Код        UTF-8   Экранирование
      -------------------------------  ------     ------  -------------
      LATIN CAPITAL LETTER L           U+004C     0x4C    L
      LATIN SMALL LETTER U             U+0075     0x75    u
      LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
      LATIN SMALL LETTER I             U+0069     0x69    i
      LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87

Его можно закодировать в виде символов ASCII [ASCII], пригодных для вывода на печать (может быть полезно при выполнении отладки), так:

      CN=Lu\C4\8Di\C4\87

5. О безопасности

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

5.1. Раскрытие информации

Обычно уникальные имена содержат описательную информацию о тех записях, которые они именуют (это могут быть люди, организации, устройства или другие объекты реального мира). Часто в них включаются какие-либо из следующих видов информации:

• общепринятое имя объекта (например, полное имя человека)
• адрес электронной почты или TCP/IP
• физическое расположение объекта (страна, местность, город, почтовый адрес)
• организационные атрибуты (такие как наименование подразделения или принадлежность группе)

В некоторых случаях такая информация может считаться конфиденциальной. Во многих странах существуют законы о защите персональных данных, запрещающие раскрытие некоторых видов описательной информации (например, адресов электронной почты). Поэтому разработчикам серверов рекомендуется поддерживать правила структуры и формы имён информационного дерева каталога (Directory Information Tree, DIT) [RFC4512], так как они предоставляют администраторам механизм выбора подходящих атрибутов именования для записи. Администраторам рекомендуется использовать доступные механизмы, контроль доступа и другие виды административного контроля для ограничения использования атрибутов, содержащих конфиденциальную информацию, в именовании записей. Кроме того, должно предусматриваться использование сервисов аутентификации и обеспечения безопасности данных в LDAP [RFC4513][RFC4511].

5.2. Использование уникальных имён в приложениях, связанных с безопасностью

Трансформированные из формы X.501 в строковое представление LDAP значения AttributeValue не всегда возможно преобразовать обратно в ту же самую форму представления BER (Basic Encoding Rules) или DER (Distinguished Encoding Rules). В качестве примера ситуации, когда может понадобиться DER-форма уникального имени, можно привести верификацию сертификата X.509.

Например, уникальное имя, состоящее из одного RDN с одним AVA, в котором тип атрибута commonName, а значение — вариант TeletexString с буквами 'Sam', будет представлено в LDAP как строка <CN=Sam>. Другое уникальное имя, в котором значение также 'Sam', но в варианте PrintableString, будет иметь то же самое представление <CN=Sam>.

Приложениям, которым требуется реконструкция DER-формы значения, не следует (SHOULD NOT) использовать строковое представление синтаксисов атрибутов при конвертировании уникального имени в формат LDAP. Вместо этого, им следует (SHOULD) использовать шестнадцатеричную форму, перед которой указывается знак решётки ('#' U+0023), как описано в первом параграфе раздела 2.4.

6. Благодарности

Этот документ обновляет RFC 2253, авторы Mark Wahl, Tim Howes и Steve Kille. RFC 2253 — продукт рабочей группы IETF ASID.

Данный документ — продукт рабочей группы IETF LDAPBIS.

7. Документы

7.1. Нормативные документы

[REGISTRY] IANA, Object Identifier Descriptors Registry, <http://www.iana.org/assignments/ldap-parameters>.

[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.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Models", X.501(1993) (also ISO/IEC 9594-2:1994).

[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).

[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, ноябрь 2003 г.

[RFC4234] Crocker, D. и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, октябрь 2005 г.

[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC4510, июнь 2006 г.

[RFC4511] Под редакцией Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.

[RFC4512] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC4512, июнь 2006 г.

[RFC4513] Под редакцией Harrison, R., "Lightweight Directory Access Protocol (LDAP): Методы аутентификации и механизмы обеспечения безопасности", RFC 4513, июнь 2006 г.

[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, июнь 2006 г.

[RFC4519] Под редакцией Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC4519, июнь 2006 г.

[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, июнь 2006 г.

7.2. Информативные документы

[ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, август 2000 г.

[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.

[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Overview of concepts, models and services," X.500(1993) (также ISO/IEC 9594-1:1994).

[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (также ISO/IEC 9594-3:1993).

[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (также ISO/IEC 8825-1:1998).

[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Техническая спецификация", RFC2849, июнь 2000 г.

Приложение A. Вопросы представления

Это приложение приводится только в информационных целях; оно не является нормативной частью данной спецификации.

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

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

Не все пользовательские интерфейсы способны отобразить полный набор символов Unicode. Некоторые символы Unicode являются неотображаемыми.

Рекомендуется, чтобы интерфейсы, рассчитанные на вывод информации человеку, использовали для формирования строковых представлений, пригодных для отображения пользователю, опциональный механизм экранирования шестнадцатеричных пар (раздел 2.3). Например, приложение может генерировать для отображения строку DN, в которой заэкранированы все непечатные символы, встречающиеся в строковом представлении AttributeValue (как показано в последнем примере раздела 4).

Если строка DN встречается в произвольном тексте, возникает необходимость отличать строку DN от окружающего текста. Хотя часто это делается с помощью пробельных символов (как показано в разделе 4), следует иметь ввиду, что строки DN могут заканчиваться пробельным символом. Внимательные читатели раздела 3 помнят, что символы '<' (U+003C) и '>' (U+003E) могут встречаться в строке DN, только если они экранированы. Эти символы предназначены для того, чтобы можно было отделить строку DN от окружающего текста в произвольном тексте. Например, <CN=Sam\ > отделяет строковое представление DN, состоящего из одного RDN с одним AVA (атрибут commonName (CN) со значением 'Sam ') от окружающего текста. Пользователям следует помнить, что символы-ограничители '<' и '>' не являются частью строки DN.

Строки DN могут быть достаточно длинными. Часто возникает потребность переносить слишком длинные строки DN при их выводе. Перенос строк следует осуществлять путём вставки пробельного символа после символа-разделителя RDN или, при необходимости, после символа-разделителя AVA. Пользователям следует помнить, что вставленные пробельные символы не являются частью строки DN, и их нужно удалить перед использованием строки DN в LDAP. Пример длинной строки DN:

         CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
         O=OpenLDAP Foundation,ST=California,C=US

Она была разбита на две для повышения читабельности. Перед использованием в LDAP дополнительные пробельные символы необходимо удалить из строки DN.

Вставка пробельных символов не рекомендуется, поскольку для пользователя может быть не очевидно, какие из них являются частью строки DN, а какие были добавлены для повышения читабельности.

Альтернативный вариант — использовать формат обмена данными LDAP (LDAP Data Interchange Format, LDIF) [RFC2849]. Например:

         # У этой записи длинное DN...
         dn: CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
          O=OpenLDAP Foundation,ST=California,C=US
         CN: Kurt D.  Zeilenga
         SN: Zeilenga
         objectClass: person

Приложение B. Изменения, внесённые в RFC 2253

Это приложение приводится только в информационных целях; оно не является нормативной частью данной спецификации.

Основные изменения, внесённые в RFC 2253:

• Удалено примечание IESG. Поднимаемые в нём вопросы были решены.
• Все ссылки на ISO 10646-1 заменены на [Unicode].
• Уточнено (в разделе 1), что в этом документе не определяется каноническое строковое представление.
• Уточнено, что в разделе 2 описывается рекомендуемый (RECOMMENDED) алгоритм кодирования и что разрешены альтернативные алгоритмы. Некоторые опции кодирования, описанные в RFC 2253, в данной спецификации рассматриваются как альтернативные алгоритмы.
• Пересмотрена спецификация (в разделе 2): в строковом представлении DN разрешены короткие имена любых зарегистрированных типов атрибутов, а не только "приведённых в таблице". Убраны формулировки "в качестве примера". Добавлено заявление (в разделе 3), обязывающее распознавать приведённые в таблице имена, но также позволяющее распознавать дополнительные имена. Сама таблица обязательных для распознавания имён теперь находится в разделе 3.
• Удалена спецификация дополнительных требований для реализаций LDAPv2, также поддерживающих LDAPv3 (раздел 4 RFC 2253), поскольку LDAPv2 сейчас считается историческим протоколом.
• Разрешено распознавание альтернативных строковых представлений.
• Обновлён раздел 2.4: разрешено экранирование в виде шестнадцатеричных пар всех символов, а также уточнён порядок экранирования при наличии кодировок UTF-8 в несколько байт. Указано, что символ null (U+0000) должен экранироваться. Указано, что символ знака равенства ('=' U+003D) может экранироваться как '\='.
• Раздел 3 переписан так, чтобы использованная в нём ABNF соответствовала RFC 4234.
• Обновлена ABNF в разделе 3. Изменения:
  • разрешены короткие имена AttributeType длиной 1 символ (например, 'L'),
  • в AttributeTypes использована более ограниченная конструкция <oid>,
  • не требуется экранирование символа знака равенства ('=' U+003D),
  • не требуется экранирование символов знака решётки ('#' U+0023), если они не находятся в начале строки,
  • разрешено экранирование пробела (' ' U+0020) как '\ ',
  • требуется шестнадцатеричное экранирование символов null (U+0000), и
  • удалены конструкции, касавшиеся только LDAPv2.
• Обновлён раздел 3: добавлено описание того, как разбирать элементы грамматики.
• Переписаны примеры.
• Добавлены ссылки на документацию, содержащую общие вопросы безопасности LDAP.
• Добавлено обсуждение вопросов представления (приложение A).
• Добавлено это приложение.

Кроме того, выполнено множество редакторских правок.

Адрес редактора

Kurt D. Zeilenga

OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

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

Copyright (C) Internet Society (2006).

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

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

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

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

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

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

Признание заслуг

Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).