Перевод выполнен участниками проекта Pro-LDAP.ru. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.
Network Working Group
Request for Comments: 3866
Категория: Standards Track
Отменяет: 2596
K. Zeilenga (OpenLDAP Foundation)
Июль 2004 года

Языковые теги и диапазоны в Lightweight Directory Access Protocol (LDAP)

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

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

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

Copyright (C) The Internet Society (2004).

Тезисы

Часто бывает желательно иметь возможность указывать естественный язык, связанный со значениями, хранящимися в каталоге, а также иметь возможность запрашивать в каталоге значения, удовлетворяющие языковым потребностям пользователя. В этом документе описывается использование языковых тегов и диапазонов в протоколе Lightweight Directory Access Protocol (LDAP).

1. Предпосылки и предназначение

Протокол Lightweight Directory Access Protocol (LDAP) [RFC3377] предоставляет клиентам средства для опроса и изменения информации, хранящейся в распределённой системе каталогов. Информация в каталоге содержится в виде значений атрибутов записей. Синтаксис большинства таких атрибутов — строки, пригодные для чтения человеком, и потому желательно иметь возможность указывать естественный язык, связанный со значениями атрибутов.

В этом документе описывается каким образом языковые теги и диапазоны [RFC3066] адаптированы для LDAP и должны интерпретироваться реализациями LDAP. Все реализации LDAP должны (MUST) быть готовы принимать языковые теги и диапазоны.

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

Этот документ заменяет RFC 2596. В приложении A собраны изменения, которые претерпел стандарт RFC 2596.

В приложении B обсуждаются отличия от механизма "контекстов" в X.500 (1997).

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

Далее в данном разделе приводятся обобщённые сведения по языковым тегам, языковым диапазонам и описаниям атрибутов.

1.1. Языковые теги

В разделе 2 BCP 47 [RFC3066] описывается формат языкового тега, используемого в LDAP. Если коротко, это строка из букв [ASCII] и дефисов. Примерами могут быть "fr", "en-US" и "ja-JP". Языковые теги нечувствительны к регистру символов. То есть, языковые теги "en-us" и "EN-US" — это одно и то же.

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

1.2. Языковые диапазоны

В разделе 2.5 BCP 47 [RFC3066] описываются языковые диапазоны. Языковые диапазоны используются для определения наборов языковых тегов.

Языковой диапазон соответствует языковому тегу, если он полностью эквивалентен этому тегу, либо если он полностью эквивалентен префиксу этого тега, когда первым символом после такого префикса является "-". То есть, языковой диапазон "de" соответствует языковым тегам "de" и "de-CH", но не соответствует тегу "den". Специальный языковой диапазон "*" соответствует всем языковым тегам.

В связи с ограничениями, накладываемыми на именование опций описания атрибута в LDAP, в данном документе определяется синтаксис языкового диапазона, отличный от определённого в разделе 2.5 BCP 47. Однако, семантики языковых диапазонов в LDAP согласуются с изложенными в BCP 47.

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

1.3. Описания атрибутов

В данном разделе представлен обзор описаний атрибутов в LDAP. Атрибуты и описания атрибутов LDAP определены в [RFC2251].

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

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

Описание атрибута с одной или несколькими опциями пометки является прямым подтипом каждого описания атрибута того же типа со всеми, кроме одной из этих опций пометки. Если тип в описании атрибута является прямым подтипом какого-то другого типа атрибута, то это описание атрибута также является прямым подтипом описания атрибута, состоящего из данного супертипа и всех перечисленных опций пометки. То есть, "CN;x-bar;x-foo" является прямым подтипом от "CN;x-bar", "CN;x-foo" и "name;x-bar;x-foo". Обратите внимание, что тип атрибута "CN" является подтипом от "name".

2. Использование языковых тегов в LDAP

В данном разделе описывается, каким образом реализации LDAP должны (MUST) интерпретировать языковые теги при выполнении операций.

Серверам, поддерживающим хранение атрибутов с опциями языковых тегов в информационном дереве каталога (DIT), следует (SHOULD) позволять любому распознаваемому ими типу атрибута с синтаксисами Directory String, IA5 String или другим текстовым синтаксисом иметь связанные с ним опции языковых тегов. Серверы могут (MAY) позволять другим типам атрибутов иметь связанные с ними языковые опции.

Клиентам не следует (SHOULD NOT) подразумевать, что серверы способны хранить в каталоге атрибуты с языковыми тегами.

Реализации не должны (MUST NOT) иным образом интерпретировать структуру тега при сравнении двух тегов, и должны (MUST) трактовать их просто как строки символов. Реализации должны (MUST) позволять любым произвольным строкам, удовлетворяющим синтаксису, определённому в BCP 47 [RFC3066], быть использованными в качестве языковых тегов.

2.1. Опции языковых тегов

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

Опция языкового тега удовлетворяет следующей ABNF [RFC2234]:

   language-tag-option = "lang-" Language-Tag

Синтаксис конструкции Language-Tag определён в BCP 47 [RFC3066]. Данная конструкция и её заимствования из [RFC2234] приведены ниже для удобства:

   Language-Tag = Primary-subtag *( "-" Subtag )

   Primary-subtag = 1*8ALPHA

   Subtag = 1*8(ALPHA / DIGIT)

   ALPHA = %x41-5A / %x61-7A   ; A-Z / a-z

   DIGIT = %x30-39             ; 0-9

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

Примеры допустимых конструкций AttributeDescription:

   givenName;lang-en-US
   CN;lang-ja
   SN;lang-de;lang-gem-PFL
   O;lang-i-klingon;x-foobar
   description;x-foobar
   CN

Примечания: В двух последних описаниях атрибута нет опций языковых тегов. Опция x-foobar фиктивная и используется в качестве примера.

2.2. Поисковый фильтр

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

Так, например, фильтр соответствия equality с типом атрибута "name;lang-en-US" и значением утверждения "Billy Ray" при сравнении с атрибутами приведённой ниже записи даст следующие результаты:

   dn: SN=Ray,DC=example,DC=com
   objectClass: person                 НЕСОВПАДЕНИЕ (неверный тип)
   objectClass: extensibleObject       НЕСОВПАДЕНИЕ (неверный тип)
   name;lang-en-US: Billy Ray          СОВПАДЕНИЕ
   name;lang-en-US: Billy Bob          НЕСОВПАДЕНИЕ (неверное значение)
   CN;lang-en-US: Billy Ray            СОВПАДЕНИЕ
   CN;lang-en-US;x-foobar: Billy Ray   СОВПАДЕНИЕ
   CN;lang-en;x-foobar: Billy Ray      НЕСОВПАДЕНИЕ (отличается lang-)
   CN;x-foobar: Billy Ray              НЕСОВПАДЕНИЕ (отсутствует lang-)
   name: Billy Ray                     НЕСОВПАДЕНИЕ (отсутствует lang-)
   SN;lang-en-GB;lang-en-US: Billy Ray СОВПАДЕНИЕ
   SN: Ray                             НЕСОВПАДЕНИЕ (отсутствует lang-,
                                           неверное значение)

Обратите внимание, что типы атрибутов "CN" и "SN" являются подтипами от "name".

Следует отметить, что предоставление опции языкового тега в конструкции AttributeDescription поискового фильтра приведёт к отфильтровыванию желательных значений, если нет точного соответствия тега. Например, фильтр (name;lang-en=Billy Ray) НЕ совпадёт с атрибутом "name;lang-en-US: Billy Ray".

Если сервер не поддерживает хранение в DIT атрибутов с опциями языковых тегов, то любые утверждения, включающие опцию языкового тега, не будут совпадать, как если бы имел место нераспознанный тип атрибута. В этом случае сервер не будет возвращать ошибку, утверждения наличия (presence) будут оцениваться как FALSE, а все остальные утверждения — как Undefined.

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

Так, например, фильтр соответствия equality с типом атрибута "name" и значением утверждения "Billy Ray" при сравнении с атрибутами приведённой ниже записи даст следующие результаты:

   dn: SN=Ray,DC=example,DC=com
   objectClass: person                 НЕСОВПАДЕНИЕ (неверный тип)
   objectClass: extensibleObject       НЕСОВПАДЕНИЕ (неверный тип)
   name;lang-en-US: Billy Ray          СОВПАДЕНИЕ
   name;lang-en-US: Billy Bob          НЕСОВПАДЕНИЕ (неверное значение)
   CN;lang-en-US;x-foobar: Billy Ray   СОВПАДЕНИЕ
   CN;lang-en;x-foobar: Billy Ray      СОВПАДЕНИЕ
   CN;x-foobar: Billy Ray              СОВПАДЕНИЕ
   name: Billy Ray                     СОВПАДЕНИЕ
   SN;lang-en-GB;lang-en-US: Billy Ray СОВПАДЕНИЕ
   SN: Ray                             НЕСОВПАДЕНИЕ (неверное значение)

2.3. Запрашиваемые при поиске атрибуты

Клиенты могут предоставлять опции языковых тегов в каждой конструкции AttributeDescription в списке запрашиваемых атрибутов поискового запроса.

Если опции языковых тегов предоставлены в описании атрибута, то в ответ на поисковый запрос должны быть возвращены только те атрибуты из записи каталога, у которых в описании атрибута имеется тот же тип атрибута или его подтип, а также содержится каждая из представленных (и, возможно, других) опций языковых тегов. Так, если клиент запрашивает только атрибут "name;lang-en", то сервер вернёт "name;lang-en" и "CN;lang-en;lang-ja", но не "SN" или "name;lang-fr".

Клиенты могут предоставлять в списке атрибутов несколько конструкций AttributeDescription, имеющих один и тот же базовый тип атрибута, но разные опции. Например, клиент может предоставить сразу "name;lang-en" и "name;lang-fr", что позволит вернуть атрибут с любой из этих опций языковой пометки. Обратите внимание, что нет необходимости предоставлять сразу и "name", и "name;lang-en", поскольку все подтипы от "name" будут совпадать с "name".

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

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

Например, если клиент запрашивает атрибут "description", а найденная запись содержит следующие атрибуты:

   objectClass: top
   objectClass: organization
   O: Software GmbH
   description: software products
   description;lang-en: software products
   description;lang-de: Softwareprodukte

то сервер вернёт:

   description: software products
   description;lang-en: software products
   description;lang-de: Softwareprodukte

2.4. Операция сравнения Compare

Опции языковых тегов могут присутствовать в конструкции AttributeDescription в составе конструкции AttributeValueAssertion, используемой в запросе Compare. В этом случае серверы должны трактовать их также, как при использовании опций языковых тегов в поисковом фильтре типа equality как описано в разделе 2.2. Если в сравниваемой записи отсутствует атрибут с тем же типом атрибута или его подтипом, содержащий каждую из представленных (и, возможно, других) опций языковых тегов, то должна быть возвращена ошибка noSuchAttributeType.

Так, например, запрос Compare с типом атрибута "name" и значением утверждения "Johann", выполняемый над записью, содержащей следующие атрибуты:

   objectClass: top
   objectClass: person
   givenName;lang-de-DE: Johann
   CN: Johann Sibelius
   SN: Sibelius

приведёт к тому, что сервер вернет compareTrue.

Однако, если клиент выполнит запрос Compare с типом атрибута "name;lang-de" и значением утверждения "Johann" над той же записью, этот запрос завершится неудачей с ошибкой noSuchAttributeType.

Если сервер не поддерживает хранение в DIT атрибутов с опциями языковых тегов, то при выполнении любых сравнений, в которых присутствует опция языкового тега, всегда будет невозможно определить требуемый атрибут и будет возвращаться ошибка noSuchAttributeType.

2.5. Операция добавления Add

Клиенты могут предоставлять языковые опции в конструкции AttributeDescription в атрибутах вновь создаваемой записи.

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

Например, следующий запрос является верно сформированным:

   dn: CN=John Smith,DC=example,DC=com
   objectClass: residentialPerson
   CN: John Smith
   CN;lang-en: John Smith
   SN: Smith
   SN;lang-en: Smith
   streetAddress: 1 University Street
   streetAddress;lang-en-US: 1 University Street
   streetAddress;lang-fr: 1 rue Universite
   houseIdentifier;lang-fr: 9e etage

Если сервер не поддерживает хранение в DIT опции языковых тегов со значениями атрибутов, то он должен (MUST) интерпретировать конструкцию AttributeDescription с опцией языкового тега как нераспознанный атрибут. Если сервер запрещает добавление нераспознанных атрибутов, то он должен (MUST) возвращать ошибку в ответ на такой запрос Add с соответствующим результирующим кодом.

2.6. Операция модификации Modify

Клиент может предоставить опции языковых тегов в конструкции AttributeDescription как часть элемента модификации в операции Modify.

Типы атрибутов и опции языковых тегов должны (MUST) точно совпадать с значениями, хранящимися в каталоге. Например, при типе модификации "delete", если у хранимого значения, которое требуется удалить, есть опции языковых тегов, то эти опции языковых тегов должны (MUST) быть предоставлены в операции Modify, а если у хранимого значения, которое требуется удалить, нет каких-либо опций языковых тегов, то в запросе не должно быть предоставлено никаких опций языковых тегов.

Если сервер не поддерживает хранение в DIT опции языковых тегов со значениями атрибутов, то он должен (MUST) интерпретировать конструкцию AttributeDescription с опцией языкового тега как нераспознанный атрибут и должен (MUST) возвращать ошибку в ответ на такой запрос Modify с соответствующим результирующим кодом.

3. Использование языковых диапазонов в LDAP

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

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

Опция языкового диапазона удовлетворяет следующей ABNF [RFC2234]:

   language-range-option = "lang-" [ Language-Tag "-" ]

Синтаксис конструкции Language-Tag определён в BCP 47 [RFC3066]. Данная конструкция и её заимствования из [RFC2234] приведены в разделе 2.1 данного документа для удобства.

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

Примеры правильно сформированных конструкций AttributeDescription, содержащих опции языковых диапазонов:

   givenName;lang-en-
   CN;lang-
   SN;lang-de-;lang-gem-
   O;lang-x-;x-foobar

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

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

Серверам следует (SHOULD) поддерживать утверждения с языковыми диапазонами для любых типов атрибутов, которые разрешено хранить с языковыми тегами.

3.1. Поисковый фильтр

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

Так, например, фильтр соответствия equality с типом атрибута "name;lang-en-" и значением утверждения "Billy Ray" при сравнении с атрибутами приведённой ниже записи даст следующие результаты:

   dn: SN=Ray,DC=example,DC=com
   objectClass: person                 НЕСОВПАДЕНИЕ (неверный тип)
   objectClass: extensibleObject       НЕСОВПАДЕНИЕ (неверный тип)
   name;lang-en-US: Billy Ray          СОВПАДЕНИЕ
   name;lang-en-US: Billy Bob          НЕСОВПАДЕНИЕ (неверное значение)
   CN;lang-en-US: Billy Ray            СОВПАДЕНИЕ
   CN;lang-en-US;x-foobar: Billy Ray   СОВПАДЕНИЕ
   CN;lang-en;x-foobar: Billy Ray      СОВПАДЕНИЕ
   CN;x-foobar: Billy Ray              НЕСОВПАДЕНИЕ (отсутствует lang-)
   name: Billy Ray                     НЕСОВПАДЕНИЕ (отсутствует lang-)
   SN;lang-en-GB;lang-en-US: Billy Ray СОВПАДЕНИЕ
   SN: Ray                             НЕСОВПАДЕНИЕ (отсутствует lang-,
                                         неверное значение)

Обратите внимание, что типы атрибутов "CN" и "SN" являются подтипами от "name".

Если сервер не поддерживает хранение в DIT атрибутов с опциями языковых тегов, то любые утверждения, включающие опцию языкового диапазона, не будут совпадать, как если бы имел место нераспознанный тип атрибута. В этом случае сервер не будет возвращать ошибку, утверждения наличия (presence) в фильтре будут оцениваться как FALSE, а все остальные утверждения — как Undefined.

3.2. Запрашиваемые при поиске атрибуты

Клиенты могут предоставлять опции языковых диапазонов в каждой конструкции AttributeDescription в списке запрашиваемых атрибутов поискового запроса.

Если опция языкового диапазона предоставлена в описании атрибута, то в ответ на поисковый запрос должны быть возвращены только те атрибуты из записи каталога, у которых в описании атрибута имеется тот же тип атрибута или его подтип, и какая-либо опция языкового тега в атрибуте записи соответствует предоставленной опции языкового диапазона. Так, если клиент запрашивает только атрибут "name;lang-en-", то сервер вернёт "name;lang-en-US" и "CN;lang-en;lang-ja", но не "SN" или "name;lang-fr".

Клиенты могут предоставлять в списке атрибутов несколько конструкций AttributeDescription, имеющих один и тот же базовый тип атрибута, но разные опции. Например, клиент может предоставить сразу "name;lang-en-" и "name;lang-fr-", что позволит вернуть атрибут с типом "name" или его подтипом, у которого опция языкового тега соответствует любому из предоставленных языковых диапазонов.

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

3.3. Операция сравнения Compare

Опции языковых диапазонов могут присутствовать в конструкции AttributeDescription в составе конструкции AttributeValueAssertion, используемой в запросе Compare. В этом случае серверы должны трактовать их также, как при использовании опций языковых диапазонов в поисковом фильтре типа equality как описано в разделе 3.1. Если в сравниваемой записи отсутствует атрибут с тем же типом атрибута или его подтипом и соответствующей опцией языкового тега, то должна быть возвращена ошибка noSuchAttributeType.

Так, например, запрос Compare с типом атрибута "name;lang-" и значением утверждения "Johann", выполняемый над записью, содержащей следующие атрибуты:

   objectClass: top
   objectClass: person
   givenName;lang-de-DE: Johann
   CN: Johann Sibelius
   SN: Sibelius

приведёт к тому, что сервер вернет compareTrue. (Обратите внимание, что опция языкового диапазона "lang-" соответствует любой опции языкового тега.)

Однако, если клиент выполнит запрос Compare с типом атрибута "name;lang-de" и значением утверждения "Sibelius" над той же записью, этот запрос завершится неудачей с ошибкой noSuchAttributeType.

Если сервер не поддерживает хранение в DIT атрибутов с опциями языковых тегов, то при выполнении любых сравнений, в которых присутствует опция языкового диапазона, всегда будет невозможно определить требуемый атрибут и будет возвращаться ошибка noSuchAttributeType.

4. Обнаружение поддержки языковых опций

Серверу следует (SHOULD) указывать, что он поддерживает хранение в DIT атрибутов с опциями языковых тегов, путём публикации 1.3.6.1.4.1.4203.1.5.4 в качестве значения атрибута "supportedFeatures" [RFC3674] записи root DSE.

Серверу следует (SHOULD) указывать, что он поддерживает поиск соответствия по языковому диапазону с хранимыми в DIT атрибутами с опциями языковых тегов, путём публикации 1.3.6.1.4.1.4203.1.5.5 в качестве значения атрибута "supportedFeatures" [RFC3674] в записи root DSE.

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

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

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

Согласно RFC 2251, "конструкция AttributeDescription с одной или несколькими опциями рассматривается как подтип типа атрибута без каких-либо опций". Сервер, не поддерживающий языковые теги, будет интерпретировать AttributeDescription с любыми опциями языковых тегов как нераспознанный тип атрибута. Клиент, не поддерживающий языковые теги, будет либо делать то же самое, либо интерпретировать такую конструкцию AttributeDescription как и любой другой неизвестный подтип. Обычно клиенты, не поддерживающие языковые теги, просто игнорируют нераспознанные подтипы (и нераспознанные типы) запрашиваемых ими атрибутов.

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

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

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

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

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

IANA произвела регистрацию данных механизмов протокола согласно требованиям RFC3383.

   Subject: Request for LDAP Protocol Mechanism Registration
   Object Identifier: 1.3.6.1.4.1.4203.1.5.4
   Description: Language Tag Options
   Object Identifier: 1.3.6.1.4.1.4203.1.5.5
   Description: Language Range Options
   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org>
   Usage: Feature
   Specification: RFC 3866
   Author/Change Controller: IESG
   Comments: none

Указанные OID были назначены [ASSIGN] OpenLDAP Foundation из выделенного им IANA пространства идентификаторов для частного предприятия [PRIVATE] для использования в данной спецификации.

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

Этот документ является ревизией RFC 2596, авторы Mark Wahl и Tim Howes. RFC 2596 — продукт рабочих групп IETF ASID и LDAPEXT. В этом документе также есть заимствования из ряда документов IETF, в том числе из BCP 47, автор H. Alvestrand.

9. Документы

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

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

[RFC2234] Под редакцией Crocker D. и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, ноябрь 1997 г.

[RFC2251] Wahl M., Howes T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.

[RFC3066] Alvestrand H., "Tags for the Identification of Languages", BCP 47, RFC 3066, январь 2001 г.

[RFC3377] Hodges J. и R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, сентябрь 2002 г.

[RFC3674] Zeilenga K., "Feature Discovery in Lightweight Directory Access Protocol (LDAP)", RFC 3674, декабрь 2003 г.

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

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

[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory, Models," X.501 (1997).

[RFC3383] Zeilenga K., "Internet Assigned Numbers Authority (IANA) Considerations for Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, сентябрь 2002 г.

[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.

[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.

Приложение A. Отличия от RFC 2596

В этом документе добавлена поддержка языковых диапазонов, предоставлен механизм, с помощью которого клиент может узнать о поддержке сервером языковых тегов и диапазонов, а также разъяснено, как нужно интерпретировать атрибуты с несколькими языковыми тегами. Текст RFC 2596 был существенно переработан.

Приложение B. Отличия от X.500 (1997)

X.500 (1997) [X.501] определяет различные механизмы (контексты) как средство представления языковых тегов (кодов). В этом разделе обобщены основные различия в подходах.

a) Операция X.500 с указанием языкового кода для значения определяет соответствие со значениями в каталоге без языкового кода.

b) LDAP ссылается на BCP 47 [RFC3066], который позволяет регистрировать в IANA как новые, так и незарегистрированные теги.

c) В LDAP поддерживаются языковые диапазоны (новое в данной версии стандарта).

d) В LDAP не разрешены языковые теги (и диапазоны) в уникальных именах.

e) В X.500 описаны процедуры администрирования подсхемы, позволяющие ассоциировать языковые коды с конкретными типами атрибутов.

Адрес автора

Kurt D. Zeilenga

OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

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

Copyright (C) Internet Society (2004). На этот документ распространяются права, лицензии и ограничения, содержащиеся в 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 обеспечивается Internet Society.

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