Перевод выполнен участниками проекта Pro-LDAP.ru. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.
Network Working Group
Request for Comments: 4519
Категория: Standards Track
Под редакцией A. Sciberras, eB2Bcom
Июнь 2006 года
Отменяет: 2256
Обновляет: 2247, 2798, 2377

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

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

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

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

Copyright (C) Internet Society (2006).

Тезисы

Этот документ является неотъемлемой частью технической спецификации протокола Lightweight Directory Access Protocol (LDAP). В нём представлена техническая спецификация типов атрибутов и объектных классов, предназначенных для использования клиентами каталогов LDAP во многих службах каталогов, таких как "Белые страницы" ("White Pages"). Данные объекты широко используются в качестве основы для схемы данных во многих каталогах LDAP. Этот документ не включает атрибуты, используемые для администрирования серверов каталогов, а также не включает объекты каталога для специфических нужд — они определяются в других документах.

Содержание

1. Введение

В этом документе представлен обзор типов атрибутов и объектных классов, предназначенных для использования клиентами каталогов LDAP во многих службах каталогов, таких как "Белые страницы" ("White Pages"). Первоначально определённые в документах X.500 [X.500], данные объекты широко используются в качестве основы для схемы данных во многих каталогах LDAP. Этот документ не включает атрибуты, используемые для администрирования серверов каталогов, а также не включает объекты каталога для специфических нужд — они определяются в других документах.

1.1. Взаимосвязь с другими спецификациями

Данный документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей ранее определённую техническую спецификацию LDAP, RFC 3377. В отношении RFC 2256: разделы 6 и 8 RFC 2256 отменены RFC 4517. Разделы 5.1, 5.2, 7.1 и 7.2 RFC 2256 отменены RFC 4512. Оставшаяся часть RFC 2256 отменяется этим документом. Технические спецификации типа атрибута 'dc' и объектного класса 'dcObject' в RFC 2247 заменяются разделами 2.4 и 3.3 этого документа. Оставшаяся часть RFC 2247 остаётся в силе.

Данный документ обновляет RFC 2798 путём замены информативного описания типа атрибута 'uid' на дефинитивное описание (приводится в разделе 2.39).

Данный документ обновляет RFC 2377 путём замены информативного описания объектного класса 'uidObject' на дефинитивное описание (приводится в разделе 3.14).

Некоторые элементы схемы данных, которые были включены в предыдущую редакцию технической спецификации LDAP, в эту редакцию не включены. Элементы схемы данных, относящиеся к PKI, теперь определяются в RFC 4523. Остальные исключённые элементы, если они не будут заново определены в будущих технических спецификациях, должны рассматриваться как исторические.

Приводимые в этом документе описания должны (SHALL) рассматриваться как дефинитивные для использования в LDAP.

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

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

1.3. Общие замечания

В этом документе упоминаются синтаксисы, определённые в разделе 3 RFC 4517, и правила соответствия, определённые в разделе 4 RFC 4517.

Определения типов атрибутов и объектных классов записаны с использованием ABNF-форм [RFC4234] AttributeTypeDescription и ObjectClassDescription, приведённых в RFC 4512. Строки были разбиты для повышения читабельности. При передаче таких значений в качестве значений атрибутов в протоколе LDAP переносов строк в них быть не должно.

2. Типы атрибутов

В определяемых в этом разделе типах атрибутов хранится пользовательская информация.

Не выдвигается требования, чтобы реализации серверов поддерживали типы атрибутов 'searchGuide' и 'teletexTerminalIdentifier'. Фактически, использовать их не рекомендуется.

Реализациям LDAP-серверов следует (SHOULD) распознавать остальные описанные в этом разделе типы атрибутов.

2.1. 'businessCategory'

Тип атрибута 'businessCategory' описывает разновидности бизнеса, осуществляемые организацией. Каждая разновидность представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.15 NAME 'businessCategory'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Примеры: "banking", "transportation" и "real estate".

2.2. 'c'

Тип атрибута 'c' (в X.500 — 'countryName') содержит двухбуквенный код страны согласно стандарту ISO 3166 [ISO3166].

(Источник: X.520 [X.520])

      ( 2.5.4.6 NAME 'c'
         SUP name
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
         SINGLE-VALUE )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.11 указывает на синтаксис Country String [RFC4517].

Примеры: "DE", "AU" и "FR".

2.3. 'cn'

Тип атрибута 'cn' (в X.500 — 'commonName') содержит имена объекта. Каждое имя представлено одним значением этого многозначного атрибута. Если объект соответствует человеку, то обычно это полное имя этого человека.

(Источник: X.520 [X.520])

      ( 2.5.4.3 NAME 'cn'
         SUP name )

Примеры: "Martin K Smith", "Marty Smith" и "printer12".

2.4. 'dc'

Тип атрибута 'dc' (в RFC 1274 — 'domainComponent') представляет собой строку, содержащую один компонент (метку) доменного имени DNS [RFC1034][RFC2181], именующего хост [RFC1123]. То есть, значение этого атрибута представляет собой строку символов ASCII, соблюдающую следующую ABNF [RFC4234]:

   label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
   ALPHA   = %x41-5A / %x61-7A     ; "A"-"Z" / "a"-"z"
   DIGIT   = %x30-39               ; "0"-"9"
   HYPHEN  = %x2D                  ; дефис ("-")

Кодировка IA5String для использования в LDAP представляет собой просто символы ASCII этой метки. Правило соответствия equality не требует соблюдения регистра символов, что соответствует сегодняшним реалиям DNS. (Источник: RFC 2247 и RFC 1274)

      ( 0.9.2342.19200300.100.1.25 NAME 'dc'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
         SINGLE-VALUE )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.26 указывает на синтаксис IA5 String [RFC4517].

Примеры: Правильные значения — "example" и "com", но не "example.com". Последнее значение является неверным, поскольку оно содержит несколько компонентов домена.

Следует иметь ввиду, что служба каталогов не должна обеспечивать того, чтобы значения этого атрибута соответствовали ограничениям на метку хоста [RFC1123], проиллюстрированным приведённой выше конструкцией <label>. Обеспечение того, что сохраняемые в этом атрибуте метки должным образом ограничены, входит в сферу ответственности клиента каталога.

Приложениям каталога, поддерживающим интернационализированные доменные имена, для формирования метки доменного компонента нужно (SHALL) использовать метод ToASCII [RFC3490]. В зависимости от того, будет ли данный доменный компонент использоваться в качестве строк "stored" или "query", должны быть приняты во внимание особые соображения, обсуждаемые в разделе 4 RFC 3490.

2.5. 'description'

Тип атрибута 'description' содержит описательные фразы об объекте, предназначенные для чтения человеком. Каждое описание представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.13 NAME 'description'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Примеры: "a color printer", "Maintenance is done every Monday, at 1pm." и "distribution list for all technical staff".

2.6. 'destinationIndicator'

Тип атрибута 'destinationIndicator' содержит ассоциированные с объектом (адресатом) строки страны и города, необходимые для предоставления услуг Public Telegram Service. Строки составляются в соответствии с рекомендациями CCITT F.1 [F.1] и F.31 [F.31]. Каждая строка представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.27 NAME 'destinationIndicator'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.44 указывает на синтаксис Printable String [RFC4517].

Примеры: "AASD" как указатель места назначения для Sydney, Australia. "GBLD" как указатель места назначения для London, United Kingdom.

Следует иметь ввиду, что служба каталогов не должна обеспечивать того, чтобы значения этого атрибута удовлетворяли рекомендациям CCITT F.1 и F.31. Обеспечение того, что сохраняемые в этом атрибуте указатели места назначения должным образом составлены, входит в сферу ответственности приложения.

2.7. 'distinguishedName'

Тип атрибута 'distinguishedName' не используется для хранения имени самого объекта, вместо этого он представляет собой базовый тип, от которого могут быть унаследованы некоторые пользовательские типы атрибутов с синтаксисом DN.

Маловероятно, что значения самого этого типа будут присутствовать в записи. Реализациям LDAP-сервера, не поддерживающим подтипы атрибутов, не нужно распознавать этот атрибут в запросах. Реализации клиентов не должны (MUST NOT) предполагать, что LDAP-серверы поддерживают подтипы атрибутов.

(Источник: X.520 [X.520])

      ( 2.5.4.49 NAME 'distinguishedName'
         EQUALITY distinguishedNameMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.12 указывает на синтаксис DN [RFC4517].

2.8. 'dnQualifier'

Тип атрибута 'dnQualifier' содержит информационные строки, призванные устранять неоднозначности, для добавления к относительному уникальному имени записи. Информация предназначена для использования при объединении данных из нескольких источников в целях предотвращения конфликтов между записями, которые в противном случае могли бы иметь одинаковое имя. Каждая строка представлена одним значением этого многозначного атрибута. Рекомендуется, чтобы значение атрибута 'dnQualifier' было одинаковым для всех записей из одного источника.

(Источник: X.520 [X.520])

      ( 2.5.4.46 NAME 'dnQualifier'
         EQUALITY caseIgnoreMatch
         ORDERING caseIgnoreOrderingMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.44 указывает на синтаксис Printable String [RFC4517].

Примеры: "20050322123345Z" — отметки времени могут быть использованы для устранения неоднозначности информации. "123456A" — серийные номера могут быть использованы для устранения неоднозначности информации.

2.9. 'enhancedSearchGuide'

Тип атрибута 'enhancedSearchGuide' содержит наборы информации, предназначенные для использования клиентами каталогов при построении поисковых фильтров. Каждый набор представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.47 NAME 'enhancedSearchGuide'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.21 указывает на синтаксис Enhanced Guide [RFC4517].

Примеры: "person#(sn$APPROX)#wholeSubtree" и "organizationalUnit#(ou$SUBSTR)#oneLevel".

2.10. 'facsimileTelephoneNumber'

Тип атрибута 'facsimileTelephoneNumber' содержит телефонные номера (и, опционально, параметры) для терминалов факсимильной связи. Каждый телефонный номер представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.22 указывает на синтаксис Facsimile Telephone Number [RFC4517].

Примеры: "+61 3 9896 7801" и "+81 3 347 7418$fineResolution".

2.11. 'generationQualifier'

Тип атрибута 'generationQualifier' содержит строки именования, обычно представляющие собой суффикс, прибавляемый к имени человека. Каждая строка представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.44 NAME 'generationQualifier'
         SUP name )

Примеры: "III", "3rd" и "Jr.".

2.12. 'givenName'

Тип атрибута 'givenName' содержит строки именования, представляющие собой часть имени человека, в которую не входит фамилия. Каждая строка представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.42 NAME 'givenName'
         SUP name )

Примеры: "Andrew", "Charles" и "Joanne".

2.13. 'houseIdentifier'

Тип атрибута 'houseIdentifier' содержит идентификаторы для здания в описании местоположения. Каждый идентификатор представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.51 NAME 'houseIdentifier'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Пример: "20" представляет собой номер дома 20.

2.14. 'initials'

Тип атрибута 'initials' содержит строки инициалов для некоторых или всех имён индивидуума, кроме фамилии (фамилий). Каждая строка представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.43 NAME 'initials'
         SUP name )

Примеры: "K. A." и "K".

2.15. 'internationalISDNNumber'

Тип атрибута 'internationalISDNNumber' содержит адреса Integrated Services Digital Network (ISDN), как определено в рекомендациях International Telecommunication Union (ITU) E.164 [E.164]. Каждый адрес представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.25 NAME 'internationalISDNNumber'
         EQUALITY numericStringMatch
         SUBSTR numericStringSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.36 указывает на синтаксис Numeric String [RFC4517].

Пример: "0198 333 333".

2.16. 'l'

Тип атрибута 'l' (в X.500 — 'localityName') содержит названия населенного пункта или места, таких как город, округ или другой географический район. Каждое имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.7 NAME 'l'
         SUP name )

Примеры: "Geneva", "Paris" и "Edinburgh".

2.17. 'member'

Тип атрибута 'member' содержит уникальные имена объектов, находящихся в списке или в группе. Каждое имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.31 NAME 'member'
         SUP distinguishedName )

Примеры: "cn=James Clarke,ou=Finance,o=Widget\, Inc." и "cn=John Xerri,ou=Finance,o=Widget\, Inc." могут быть двумя членами финансового подразделения (группы) в Widget, Inc., в этом случае оба этих уникальных имени будут представлены отдельными значениями атрибута member.

2.18. 'name'

Тип атрибута 'name' представляет собой супертип атрибута, от которого наследуются пользовательские типы атрибутов с синтаксисом имени. Такие типы атрибутов обычно используются для именования. Данный тип атрибута многозначный.

Маловероятно, что значения самого этого типа будут присутствовать в записи. Реализациям LDAP-сервера, не поддерживающим подтипы атрибутов, не нужно распознавать этот атрибут в запросах. Реализации клиентов не должны (MUST NOT) предполагать, что LDAP-серверы поддерживают подтипы атрибутов.

(Источник: X.520 [X.520])

      ( 2.5.4.41 NAME 'name'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

2.19. 'o'

Тип атрибута 'o' (в X.500 — 'organizationName') содержит имена организации. Каждое имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.10 NAME 'o'
         SUP name )

Примеры: "Widget", "Widget, Inc." и "Widget, Incorporated.".

2.20. 'ou'

Тип атрибута 'ou' (в X.500 — 'organizationalUnitName') содержит имена подразделения организации. Каждое имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.11 NAME 'ou'
         SUP name )

Примеры: "Finance", "Human Resources" и "Research and Development".

2.21. 'owner'

Тип атрибута 'owner' содержит уникальные имена объектов, исполняющих обязанности владельца по отношению к данному объекту. Каждое имя владельца представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.32 NAME 'owner'
         SUP distinguishedName )

Пример: Объект списка рассылки с DN "cn=All Employees, ou=Mailing List,o=Widget\, Inc." принадлежит Human Resources Director.

Следовательно, значением атрибута 'owner' в объекте списка рассылки будет DN этого руководителя (роли): "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".

2.22. 'physicalDeliveryOfficeName'

Тип атрибута 'physicalDeliveryOfficeName' содержит имена, используемые службой почты (Postal Service) для идентификации почтового отделения.

(Источник: X.520 [X.520])

      ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Примеры: "Bremerhaven, Main" и "Bremerhaven, Bonnstrasse".

2.23. 'postalAddress'

Тип атрибута 'postalAddress' содержит адреса, используемые службой почты (Postal Service) в целях выполнения услуг для данного объекта. Каждый адрес представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.16 NAME 'postalAddress'
         EQUALITY caseIgnoreListMatch
         SUBSTR caseIgnoreListSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.41 указывает на синтаксис Postal Address [RFC4517].

Пример: "15 Main St.$Ottawa$Canada".

2.24. 'postalCode'

Тип атрибута 'postalCode' содержит коды, используемые службой почты (Postal Service) для идентификации зон предоставления почтовых услуг. Каждый код представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.17 NAME 'postalCode'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Пример: "22180", идентифицирует Vienna, VA, USA.

2.25. 'postOfficeBox'

Тип атрибута 'postOfficeBox' содержит идентификаторы почтовых ящиков, используемые службой почты (Postal Service), когда получение почты клиентом организовано в почтовый ящик на территории службы почты. Каждый идентификатор почтового ящика представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.18 NAME 'postOfficeBox'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Пример: "Box 45".

2.26. 'preferredDeliveryMethod'

Тип атрибута 'preferredDeliveryMethod' содержит указание предпочтительного способа получения сообщений для данного объекта.

(Источник: X.520 [X.520])

      ( 2.5.4.28 NAME 'preferredDeliveryMethod'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
         SINGLE-VALUE )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.14 указывает на синтаксис Delivery Method [RFC4517].

Пример: Если метод доставки mhs более предпочтителен, чем метод доставки telephone, который, в свою очередь, более предпочтителен, чем все остальные методы, то значение атрибута будет: "mhs $ telephone".

2.27. 'registeredAddress'

Тип атрибута 'registeredAddress' содержит почтовые адреса, на которые можно принимать телеграммы или документы с ускоренной доставкой, когда требуется подтверждение доставки получателем. Каждый адрес представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.26 NAME 'registeredAddress'
         SUP postalAddress
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.41 указывает на синтаксис Postal Address [RFC4517].

Пример: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".

2.28. 'roleOccupant'

Тип атрибута 'roleOccupant' содержит уникальные имена объектов (обычно людей), исполняющих обязанности роли, описанной этим объектом. Каждое уникальное имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.33 NAME 'roleOccupant'
         SUP distinguishedName )

Пример: Объект роли, "cn=Human Resources Director,ou=Position,o=Widget\, Inc."; эту роль исполняют два человека, имена объектов которых: "cn=Mary Smith,ou=employee,o=Widget\, Inc." и "cn=James Brown,ou=employee,o=Widget\, Inc.". Атрибут 'roleOccupant' объекта роли будет содержать оба этих уникальных имени, поскольку оба они выполняют эту роль.

2.29. 'searchGuide'

Тип атрибута 'searchGuide' содержит наборы информации, предназначенные для использования клиентами при построении поисковых фильтров. Этот тип атрибута заменён описанным выше в разделе 2.9 типом 'enhancedSearchGuide'. Каждый набор представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.14 NAME 'searchGuide'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.25 указывает на синтаксис Guide [RFC4517].

Пример: "person#sn$EQ".

2.30. 'seeAlso'

Тип атрибута 'seeAlso' содержит уникальные имена объектов, связанных с данным объектом. Каждое имя связанного объекта представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.34 NAME 'seeAlso'
         SUP distinguishedName )

Пример: Объект человека "cn=James Brown,ou=employee,o=Widget\, Inc." связан с объектами ролей "cn=Football Team Captain,ou=sponsored activities,o=Widget\, Inc." и "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". Поскольку объекты роли связаны с данным объектом человека, атрибут 'seeAlso' будет содержать уникальные имена каждого объекта роли отдельным значением.

2.31. 'serialNumber'

Тип атрибута 'serialNumber' содержит серийные номера устройств. Каждый серийный номер представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.5 NAME 'serialNumber'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.44 указывает на синтаксис Printable String [RFC4517].

Примеры: "WI-3005" и "XF551426".

2.32. 'sn'

Тип атрибута 'sn' (в X.500 — 'surname') содержит строки именования для фамилии человека. Каждая строка представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.4 NAME 'sn'
         SUP name )

Пример: "Smith".

2.33. 'st'

Тип атрибута 'st' (в X.500 — 'stateOrProvinceName') содержит полные имена штатов или провинций. Каждое имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.8 NAME 'st'
         SUP name )

Пример: "California".

2.34. 'street'

Тип атрибута 'street' (в X.500 — 'streetAddress') содержит информацию по местоположению из почтового адреса (то есть, название улицы, места, проспекта и номер дома). Каждая улица представлена одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.9 NAME 'street'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Пример: "15 Main St.".

2.35. 'telephoneNumber'

Тип атрибута 'telephoneNumber' содержит телефонные номера, соответствующие рекомендации ITU E.123 [E.123]. Каждый номер представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.20 NAME 'telephoneNumber'
         EQUALITY telephoneNumberMatch
         SUBSTR telephoneNumberSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.50 указывает на синтаксис Telephone Number [RFC4517].

Пример: "+1 234 567 8901".

2.36. 'teletexTerminalIdentifier'

В соответствии с выводом рекомендации F.200 данный атрибут был исключён.

(Источник: X.520 [X.520])

      ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.51 указывает на синтаксис Teletex Terminal Identifier [RFC4517].

2.37. 'telexNumber'

Тип атрибута 'telexNumber' содержит наборы строк, представляющих собой номер телекса, код страны и код автоответа терминала телекса. Каждый набор представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.21 NAME 'telexNumber'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.52 указывает на синтаксис Telex Number [RFC4517].

Пример: "12345$023$ABCDE".

2.38. 'title'

Тип атрибута 'title' содержит наименование человека в контексте его организации. Каждое наименование представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.12 NAME 'title'
         SUP name )

Примеры: "Vice President", "Software Engineer" и "CEO".

2.39. 'uid'

Тип атрибута 'uid' (в RFC 1274 — 'userid') содержит имена учётных записей компьютерных систем, ассоциированных с этим объектом. Каждое имя представлено одним значением этого многозначного атрибута.

(Источник: RFC 2798 и RFC 1274)

      ( 0.9.2342.19200300.100.1.1 NAME 'uid'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.15 указывает на синтаксис Directory String [RFC4517].

Примеры: "s9709015", "admin" и "Administrator".

2.40. 'uniqueMember'

Тип атрибута 'uniqueMember' содержит уникальные имена объектов, находящихся в списке или в группе. При этом относительные уникальные имена этих объектов включают значение, уникальное среди этих объектов, что позволяет отличать их, если уникальные имена объектов используются повторно. Каждое уникальное имя представлено одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.50 NAME 'uniqueMember'
         EQUALITY uniqueMemberMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.34 указывает на синтаксис Name and Optional UID [RFC4517].

Пример: Если батальон "ou=1st Battalion,o=Defense,c=US" расформирован, то при формировании нового батальона с тем же именем к этому имени будет добавлено значение уникального идентификатора, в результате чего получится "ou=1st Battalion, o=Defense,c=US#'010101'B".

2.41. 'userPassword'

Тип атрибута 'userPassword' содержит строки октетов, известных только пользователю и системе, к которой пользователь имеет доступ. Каждая строка представлена одним значением этого многозначного атрибута.

Приложению следует (SHOULD) выполнять подготовку текстовых строк, используемых в качестве паролей, путём транскодирования их в Unicode, применения алгоритма SASLprep [RFC4013] и кодирования в виде UTF-8. Определение того, является ли пароль текстовым, возлагается на локального клиента.

(Источник: X.509 [X.509])

      ( 2.5.4.35 NAME 'userPassword'
         EQUALITY octetStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.40 указывает на синтаксис Octet String [RFC4517].

Пароли хранятся с использованием синтаксиса Octet String и не шифруются. Передача паролей открытым текстом настоятельно не рекомендуется в случаях, когда базовая служба транспортировки не может гарантировать конфиденциальности, в результате чего может произойти раскрытие пароля посторонними лицами.

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

2.42. 'x121Address'

Тип атрибута 'x121Address' содержит данные сетевых адресов, как определено рекомендациями ITU X.121 [X.121]. Каждый адрес представлен одним значением этого многозначного атрибута.

(Источник: X.520 [X.520])

      ( 2.5.4.24 NAME 'x121Address'
         EQUALITY numericStringMatch
         SUBSTR numericStringSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.36 указывает на синтаксис Numeric String [RFC4517].

Пример: "36111222333444555".

2.43. 'x500UniqueIdentifier'

Тип атрибута 'x500UniqueIdentifier' содержит двоичные строки, применяемые для того, чтобы отличать объекты при повторном использовании уникальных имён. Каждая строка представлена одним значением этого многозначного атрибута.

В X.520 [X.520] этот атрибут называется 'uniqueIdentifier'. Этот тип атрибута отличается от типов атрибутов LDAP 'uid' и 'uniqueIdentifier'. Тип атрибута 'uniqueIdentifier' определён в RFC 4524.

(Источник: X.520 [X.520])

      ( 2.5.4.45 NAME 'x500UniqueIdentifier'
         EQUALITY bitStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

Идентификатор 1.3.6.1.4.1.1466.115.121.1.6 указывает на синтаксис Bit String [RFC4517].

3. Объектные классы

LDAP-серверам следует (SHOULD) распознавать все перечисленные в этом разделе объектные классы как значения атрибута 'objectClass' (смотрите RFC 4512).

3.1. 'applicationProcess'

Определение объектного класса 'applicationProcess' является основой записи, которая представляет собой приложение, выполняющееся в компьютерной системе.

(Источник: X.521 [X.521])

      ( 2.5.6.11 NAME 'applicationProcess'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( seeAlso $
               ou $
               l $
               description ) )

3.2. 'country'

Определение объектного класса 'country' является основой записи, которая представляет собой страну.

(Источник: X.521 [X.521])

      ( 2.5.6.2 NAME 'country'
         SUP top
         STRUCTURAL
         MUST c
         MAY ( searchGuide $
               description ) )

3.3. 'dcObject'

Объектный класс 'dcObject' позволяет записи содержать информацию компонента домена. Данный объектный класс определён как вспомогательный, поскольку он предназначен для использования в сочетании с существующим структурным объектным классом.

(Источник: RFC 2247 [RFC2247])

      ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
         SUP top
         AUXILIARY
         MUST dc )

3.4. 'device'

Объектный класс 'device' является основой записи, которая представляет собой прибор, компьютер или элемент сети.

(Источник: X.521 [X.521])

      ( 2.5.6.14 NAME 'device'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( serialNumber $
               seeAlso $
               owner $
               ou $
               o $
               l $
               description ) )

3.5. 'groupOfNames'

Объектный класс 'groupOfNames' является основой записи, которая представляет собой набор именованных объектов, а также включает информацию о цели создания и способах обслуживания этого набора.

(Источник: X.521 [X.521])

      ( 2.5.6.9 NAME 'groupOfNames'
         SUP top
         STRUCTURAL
         MUST ( member $
               cn )
         MAY ( businessCategory $
               seeAlso $
               owner $
               ou $
               o $
               description ) )

3.6. 'groupOfUniqueNames'

Объектный класс 'groupOfUniqueNames'  то же самое, что и объектный класс 'groupOfNames', за исключением того, что в пределах этого набора имена объектов не повторяются и не переназначаются.

(Источник: X.521 [X.521])

      ( 2.5.6.17 NAME 'groupOfUniqueNames'
         SUP top
         STRUCTURAL
         MUST ( uniqueMember $
               cn )
         MAY ( businessCategory $
               seeAlso $
               owner $
               ou $
               o $
               description ) )

3.7. 'locality'

Объектный класс 'locality' является основой записи, которая представляет собой место в физическом мире.

(Источник: X.521 [X.521])

      ( 2.5.6.3 NAME 'locality'
         SUP top
         STRUCTURAL
         MAY ( street $
               seeAlso $
               searchGuide $
               st $
               l $
               description ) )

3.8. 'organization'

Объектный класс 'organization' является основой записи, которая представляет собой структурированную группу людей.

(Источник: X.521 [X.521])

      ( 2.5.6.4 NAME 'organization'
         SUP top
         STRUCTURAL
         MUST o
         MAY ( userPassword $ searchGuide $ seeAlso $
               businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ street $ postOfficeBox $
               postalCode $ postalAddress $ physicalDeliveryOfficeName $
               st $ l $ description ) )

3.9. 'organizationalPerson'

Объектный класс 'organizationalPerson' является основой записи, которая представляет собой человека по отношению к организации.

(Источник: X.521 [X.521])

      ( 2.5.6.7 NAME 'organizationalPerson'
         SUP person
         STRUCTURAL
         MAY ( title $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ street $ postOfficeBox $
               postalCode $ postalAddress $ physicalDeliveryOfficeName $
               ou $ st $ l ) )

3.10. 'organizationalRole'

Объектный класс 'organizationalRole' является основой записи, которая представляет работу, обязанности или должность в организации.

(Источник: X.521 [X.521])

      ( 2.5.6.8 NAME 'organizationalRole'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( x121Address $ registeredAddress $ destinationIndicator $
               preferredDeliveryMethod $ telexNumber $
               teletexTerminalIdentifier $ telephoneNumber $
               internationalISDNNumber $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $
               description ) )

3.11. 'organizationalUnit'

Объектный класс 'organizationalUnit' является основой записи, которая представляет собой часть организации.

(Источник: X.521 [X.521])

      ( 2.5.6.5 NAME 'organizationalUnit'
         SUP top
         STRUCTURAL
         MUST ou
         MAY ( businessCategory $ description $ destinationIndicator $
               facsimileTelephoneNumber $ internationalISDNNumber $ l $
               physicalDeliveryOfficeName $ postalAddress $ postalCode $
               postOfficeBox $ preferredDeliveryMethod $
               registeredAddress $ searchGuide $ seeAlso $ st $ street $
               telephoneNumber $ teletexTerminalIdentifier $
               telexNumber $ userPassword $ x121Address ) )

3.12 'person'

Объектный класс 'person' является основой записи, которая представляет собой человека.

(Источник: X.521 [X.521])

      ( 2.5.6.6 NAME 'person'
         SUP top
         STRUCTURAL
         MUST ( sn $
               cn )
         MAY ( userPassword $
               telephoneNumber $
               seeAlso $ description ) )

3.13. 'residentialPerson'

Объектный класс 'residentialPerson' является основой записи, которая включает местонахождение человека при его описании.

(Источник: X.521 [X.521])

      ( 2.5.6.10 NAME 'residentialPerson'
         SUP person
         STRUCTURAL
         MUST l
         MAY ( businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st $ l ) )

3.14. 'uidObject'

Объектный класс 'uidObject' позволяет записи содержать информацию об идентификации пользователя. Данный объектный класс определён как вспомогательный, поскольку он предназначен для использования в сочетании с существующим структурным объектным классом.

(Источник: RFC 2377 [RFC2377])

      ( 1.3.6.1.1.3.1 NAME 'uidObject'
         SUP top
         AUXILIARY
         MUST uid )

4. Регистрация в IANA

Администрация адресного пространства Интернет (Internet Assigned Numbers Authority, IANA) обновила регистр дескрипторов LDAP, как указано в следующей форме:

      Subject: Request for LDAP Descriptor Registration Update
      Descriptor (short name): see comments
      Object Identifier: see comments
      Person & email address to contact for further information:
         Andrew Sciberras <andrew.sciberras@eb2bcom.com>
      Usage: (A = attribute type, O = Object Class) see comment
      Specification: RFC 4519
      Author/Change Controller: IESG

   Comments

      In the LDAP descriptors registry, the following descriptors (short
      names) have been updated to refer to RFC 4519. Names that need to
      be reserved, rather than assigned to an Object Identifier, will
      contain an Object Identifier value of RESERVED.

      NAME                         Type OID
      ------------------------     ---- ----------------------------
      applicationProcess           O    2.5.6.11
      businessCategory             A    2.5.4.15
      c                            A    2.5.4.6
      cn                           A    2.5.4.3
      commonName                   A    2.5.4.3
      country                      O    2.5.6.2
      countryName                  A    2.5.4.6
      dc                           A    0.9.2342.19200300.100.1.25
      dcObject                     O    1.3.6.1.4.1.1466.344
      description                  A    2.5.4.13
      destinationIndicator         A    2.5.4.27
      device                       O    2.5.6.14
      distinguishedName            A    2.5.4.49
      dnQualifier                  A    2.5.4.46
      domainComponent              A    0.9.2342.19200300.100.1.25
      enhancedSearchGuide          A    2.5.4.47
      facsimileTelephoneNumber     A    2.5.4.23
      generationQualifier          A    2.5.4.44
      givenName                    A    2.5.4.42
      gn                           A    RESERVED
      groupOfNames                 O    2.5.6.9
      groupOfUniqueNames           O    2.5.6.17
      houseIdentifier              A    2.5.4.51
      initials                     A    2.5.4.43
      internationalISDNNumber      A    2.5.4.25
      l                            A    2.5.4.7
      locality                     O    2.5.6.3
      localityName                 A    2.5.4.7
      member                       A    2.5.4.31
      name                         A    2.5.4.41
      o                            A    2.5.4.10
      organization                 O    2.5.6.4
      organizationName             A    2.5.4.10
      organizationalPerson         O    2.5.6.7
      organizationalRole           O    2.5.6.8
      organizationalUnit           O    2.5.6.5
      organizationalUnitName       A    2.5.4.11
      ou                           A    2.5.4.11
      owner                        A    2.5.4.32
      person                       O    2.5.6.6
      physicalDeliveryOfficeName   A    2.5.4.19
      postalAddress                A    2.5.4.16
      postalCode                   A    2.5.4.17
      postOfficeBox                A    2.5.4.18
      preferredDeliveryMethod      A    2.5.4.28
      registeredAddress            A    2.5.4.26
      residentialPerson            O    2.5.6.10
      roleOccupant                 A    2.5.4.33
      searchGuide                  A    2.5.4.14
      seeAlso                      A    2.5.4.34
      serialNumber                 A    2.5.4.5
      sn                           A    2.5.4.4
      st                           A    2.5.4.8
      street                       A    2.5.4.9
      surname                      A    2.5.4.4
      telephoneNumber              A    2.5.4.20
      teletexTerminalIdentifier    A    2.5.4.22
      telexNumber                  A    2.5.4.21
      title                        A    2.5.4.12
      uid                          A    0.9.2342.19200300.100.1.1
      uidObject                    O    1.3.6.1.1.3.1
      uniqueMember                 A    2.5.4.50
      userid                       A    0.9.2342.19200300.100.1.1
      userPassword                 A    2.5.4.35
      x121Address                  A    2.5.4.24
      x500UniqueIdentifier         A    2.5.4.45

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

Атрибуты записей каталога используются для предоставления описательной информации об объектах реального мира, которые они представляют. Такими объектами могут быть люди, организации или устройства. В большинстве стран имеются законы, касающиеся защиты конфиденциальности при публикации информации о людях.

Передача паролей в открытом виде настоятельно не рекомендуется там, где используемый транспортный сервис не может гарантировать конфиденциальности и целостности, поскольку это может привести к раскрытию пароля посторонними лицами.

Использовать несколько значений в атрибуте 'userPassword' следует с осторожностью. В особенности, при наличии нескольких значений пароля для разных приложений, сброс/удаление пароля администратором без знания старого пароля пользователя становится затруднительным или даже невозможным.

Безусловно, приложениям, предназначенным для замены значения (значений) атрибута 'userPassword' новым значением (значениями), следует использовать операции modify/replaceValues (или modify/deleteAttribute+addAttribute). Кроме того, реализациям сервера рекомендуется обеспечить возможность административного контроля, который, при включении, ограничивал атрибут 'userPassword' одним значением.

Имейте ввиду, что при использовании в целях аутентификации [RFC4513], пользователю требуется подтвердить знание только одного, а не всех значений атрибута 'userPassword'.

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

Определения, на которых основан этот документ, были разработаны комитетами по телекоммуникациям и международным стандартам.

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

Задаваемые в этом документе определения типа атрибута 'dc' и объектного класса 'dcObject' заменяют спецификации, приведённые в RFC 2247, авторы S. Kille, M. Wahl, A. Grimstad, R. Huber и S. Sataluri.

Задаваемое в этом документе определение типа атрибута 'uid' заменяет спецификацию 'userid', приведённую в RFC 1274 by P. Barker and S. Kille and of the uid in RFC 2798, автор M. Smith.

Задаваемое в этом документе определение объектного класса 'uidObject' заменяет спецификацию 'uidObject', приведённую в RFC 2377, авторы A. Grimstad, R. Huber, S. Sataluri и M. Wahl.

Этот документ основан на входных данных рабочей группы IETF LDAPBIS. Автор благодарит S. Legg и K. Zeilenga за их значительный вклад в эту работу. Автор также благодарит Kathy Dally за редактирование ранних версий этого документа.

7. Документы

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

[E.123] Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988 г.

[E.164] The international public telecommunication numbering plan, ITU-T Recommendation E.164, 1997 г.

[F.1] Operational Provisions For The International Public Telegram Service Transmission System, CCITT Recommendation F.1, 1992 г.

[F.31] Telegram Retransmission System, CCITT Recommendation F.31, 1988 г.

[ISO3166] ISO 3166, "Codes for the representation of names of countries".

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, ноябрь 1987 г.

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, октябрь 1989 г.

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

[RFC2181] Elz, R. и R. Bush, "Clarifications to the DNS Specification", RFC 2181, июль 1997 г.

[RFC3490] Faltstrom, P., Hoffman, P. и A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, март 2003 г.

[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, февраль 2005 г.

[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", RFC 4510, июнь 2006 г.

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

[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Синтаксисы и правила соответствия", RFC 4517, июнь 2006 г.

[X.121] International numbering plan for public data networks, ITU-T Recommendation X.121, 1996 г.

[X.509] The Directory: Authentication Framework, ITU-T Recommendation X.509, 1993 г.

[X.520] The Directory: Selected Attribute Types, ITU-T Recommendation X.520, 1993 г.

[X.521] The Directory: Selected Object Classes. ITU-T Recommendation X.521, 1993 г.

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

[RFC1274] Barker, P. и S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, ноябрь 1991 г.

[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. и S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, январь 1998 г.

[RFC2377] Grimstad, A., Huber, R., Sataluri, S. и M. Wahl, "Naming Plan for Internet Directory-Enabled Applications", RFC 2377, сентябрь 1998 г.

[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, апрель 2000 г.

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

[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, июнь 2006 г.

[RFC4524] Под редакцией Zeilenga, E., "COSINE LDAP/X.500 Schema", RFC 4524, июнь 2006 г.

[X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.

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

В этом приложении перечислены изменения, внесённые в RFC 2256 этим документом.

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

  1. Изменено название документа.
  2. Удалено примечание IESG.
  3. Исключены зависимости от RFC 1274.
  4. Добавлены разделы "О безопасности" и "Регистрация в IANA".
  5. Удалено требование соответствия для объектных классов subschema в пользу заявления, приведённого в RFC 4517.
  6. Добавлены пояснения для каждого типа атрибута и объектного класса.
  7. Удалены раздел 4 (синтаксисы) и раздел 6 (правила соответствия). Они перемещены в RFC 4517.
  8. Удалены связанные с сертификатами типы атрибутов: authorityRevocationList, cACertificate, certificateRevocationList, crossCertificatePair, deltaRevocationList, supportedAlgorithms и userCertificate. Удалены связанные с сертификатами объектные классы: certificationAuthority, certificationAuthority-V2, cRLDistributionPoint, strongAuthenticationUser и userSecurityInformation. LDAP PKI сейчас обсуждается в RFC 4523.
  9. Удалены типы атрибутов dmdName, knowledgeInformation, presentationAddress, protocolInformation и supportedApplicationContext, а также объектные классы dmd, applicationEntity и dSA.
  10. Удалены определения типов атрибутов aliasedObjectName и objectClass. Удалены определения объектных классов alias и top. Теперь они включены в RFC 4512.
  11. Добавлен тип атрибута 'dc' из RFC 2247, отмечено различие между значениями "stored" и "query" при подготовке строк IDN.
  12. Произведены многочисленные редакторские правки.
  13. Во всех определениях атрибутов удалены верхние границы после oid в поле SYNTAX.
  14. Добавлена информация о Unicode, SASLprep [RFC4013] и UTF-8 для значений атрибута 'userPassword'.
  15. Включены определения, комментарии и источники для 'dcObject' и 'uidObject'.
  16. Для элементов схемы данных PKI дана отсылка на RFC 4523.
  17. Аббревиатура ABNF (при первом появлении) расшифрована и приведена ссылка на стандарт.
  18. Удалён раздел 4 ("Источники"). Таблица источников заменена на явное указание источника в каждом определении.
  19. Все указания типов атрибутов и объектных классов заключены в одинарные кавычки.
  20. Для обеспечения согласованности материала по всему документу был изменён макет определения типа атрибута. В него входят: В некоторые определения добавлены также дополнительные примеры.
  21. Указания альтернативных имён типов атрибутов приведены со ссылками на документы, в которых они были определены изначально.
  22. В определении типов атрибутов 'distinguishedName' и 'name' разъяснено, что они являются супертипами.
  23. Аббревиатура ISDN (при первом появлении) расшифрована.
  24. Для идентификатора поля SYNTAX в определении типа атрибута 'teletexTerminalIdentifier' добавлена ссылка на RFC 4517.
  25. В регистр IANA были добавлены дополнительные имена. Это 'commonName', 'dcObject', 'domainComponent', 'GN', 'localityName', 'organizationName', 'organizationUnitName', 'surname', 'uidObject' и 'userid'.
  26. Исправлены опечатки.
  27. Источники [F.1], [F.31] и [RFC4013] перенесены из информативных в нормативные документы.
  28. Определение типа атрибута 'c' изменено так, чтобы соответствовать определению в X.500.

Адрес автора

Andrew Sciberras

eB2Bcom, Suite 3, Woodhouse Corporate Centre, 935 Station Street, Box Hill North, Victoria 3129, AUSTRALIA

Телефон: +61 3 9896 7833

EMail: andrew.sciberras@eb2bcom.com

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

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).

Перевод выполнен участниками проекта Pro-LDAP.ru. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.