Перевод выполнен участниками проекта Pro-LDAP.ru. Предложения по улучшению перевода и сообщения об ошибках принимаются на форуме проекта.
Network Working Group
Request for Comments: 2849
Категория: Standards Track
G. Good, iPlanet e-commerce Solutions
Июнь 2000 года

Формат обмена данными LDAP (LDAP Data Interchange Format, LDIF) — техническая спецификация

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

В этом документе определяется предложенный стандарт протокола Internet для сообщества Internet, а также принимаются обсуждения и предложения по его улучшению. Пожалуйста, отслеживайте текущую редакцию "Internet Official Protocol Standards" (STD 1) на предмет состояния стандартизации и статуса данного протокола. Ограничений на распространение этого документа не накладывается.

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

Copyright (C) Internet Society (2000). Все права защищены.

Тезисы

В этом документе описывается формат представления данных, предназначенный для описания информации, содержащейся в каталоге, либо описания модификаций, производимых над содержащейся в каталоге информацией. Данный формат, известный как LDIF, аббревиатура от LDAP Data Interchange Format, обычно используется для импорта и экспорта содержащейся в каталоге информации между серверами каталогов, основанными на LDAP, либо для описания набора изменений, которые требуется применить к каталогу.

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

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

Кроме того, использование чётко определённого формата обмена облегчает разработку инструментов импорта данных из систем, данные которых требуется унаследовать. Например, с помощью довольно простого набора инструментов, написанного на awk или perl, можно переконвертировать базу данных персональной информации в LDIF-файл. Затем этот файл можно импортировать в сервер каталогов, независимо от того, какое внутреннее представление базы данных использует целевой сервер каталогов.

Формат LDIF изначально был разработан и использовался в реализации LDAP Мичиганского Университета. Сначала LDIF использовался для описания записей каталога. Позднее формат был расширен, чтобы можно было представлять изменения записей каталога.

Взаимоотношения с типом содержимого MIME application/directory:

Тип содержимого MIME application/directory [1] представляет собой общую структуру и формат для передачи информации каталога, независящие от какого-либо конкретного сервиса каталога. Формат LDIF — более простой формат, с которым проще работать и, как уже было сказано, с его помощью можно описывать набор изменений, применяемых к каталогу.

Используемые в этом документе ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "MAY" (возможно), "SHOULD" (следует) и "SHOULD NOT" (не следует) должны интерпретироваться как описано в [7].

Определение LDAP Data Interchange Format

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

Существует однозначное соответствие между операциями LDAP модификации каталога (add, delete, modify и modrdn) и типами описанных ниже записей изменений changerecord ("add", "delete", "modify" и "modrdn" (или "moddn")). Это соответствие является преднамеренным и позволяет вызывать операции протокола простой трансляцией записей changerecord файла LDIF.

Формальный синтаксис определения LDIF

Приведённое ниже определение использует расширенную форму Бэкуса-Наура, определённую в RFC 2234 [2].

ldif-file                = ldif-content / ldif-changes

ldif-content             = version-spec 1*(1*SEP ldif-attrval-record)

ldif-changes             = version-spec 1*(1*SEP ldif-change-record)

ldif-attrval-record      = dn-spec SEP 1*attrval-spec

ldif-change-record       = dn-spec SEP *control changerecord

version-spec             = "version:" FILL version-number

version-number           = 1*DIGIT
                           ; version-number должен (MUST) быть "1" для
                           ; формата LDIF, описанного в этом документе.

dn-spec                  = "dn:" (FILL distinguishedName /
                                  ":" FILL base64-distinguishedName)

distinguishedName        = SAFE-STRING
                           ; отличительное имя, как определено в [3]

base64-distinguishedName = BASE64-UTF8-STRING
                           ; distinguishedName, закодированное base64
                           ; (смотрите примечание 10 ниже)

rdn                      = SAFE-STRING
                           ; относительное отличительное имя, определённое как
                           ; <name-component> в [3]

base64-rdn               = BASE64-UTF8-STRING
                           ; rdn, закодированное base64
                           ; (смотрите примечание 10 ниже)

control                  = "control:" FILL ldap-oid        ; controlType
                           0*1(1*SPACE ("true" / "false")) ; criticality
                           0*1(value-spec)                ; controlValue
                           SEP
                           ; (смотрите примечание 9 ниже)

ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
                           ; LDAPOID, как определено в [4]

attrval-spec             = AttributeDescription value-spec SEP

value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
                                ":" FILL (BASE64-STRING) /
                                "<" FILL url)
                           ; Смотрите примечания 7 и 8 ниже

url                      = <a Uniform Resource Locator,
                            как определено в [6]>
                                   ; (смотрите примечание 6 ниже)

AttributeDescription     = AttributeType [";" options]
                           ; Определение взято из [4]

AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))

options                  = option / (option ";" options)

option                   = 1*opt-char

attr-type-chars          = ALPHA / DIGIT / "-"

opt-char                 = attr-type-chars

changerecord             = "changetype:" FILL
                           (change-add / change-delete /
                            change-modify / change-moddn)

change-add               = "add"                SEP 1*attrval-spec

change-delete            = "delete"             SEP

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

change-modify            = "modify"             SEP *mod-spec

mod-spec                 = ("add:" / "delete:" / "replace:")
                           FILL AttributeDescription SEP
                           *attrval-spec
                           "-" SEP

SPACE                    = %x20
                           ; ASCII SP, space

FILL                     = *SPACE

SEP                      = (CR LF / LF)

CR                       = %x0D
                           ; ASCII CR, carriage return

LF                       = %x0A
                           ; ASCII LF, line feed

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

DIGIT                    = %x30-39
                           ; 0-9

UTF8-1                   = %x80-BF

UTF8-2                   = %xC0-DF UTF8-1

UTF8-3                   = %xE0-EF 2UTF8-1

UTF8-4                   = %xF0-F7 3UTF8-1

UTF8-5                   = %xF8-FB 4UTF8-1

UTF8-6                   = %xFC-FD 5UTF8-1

SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
                           ; любое значение <= 127 (десятичное), за исключением
                           ; NUL, LF и CR

SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
                           %x21-39 / %x3B / %x3D-7F
                           ; любое значение <= 127, за исключением NUL, LF, CR,
                           ; SPACE, двоеточие (":", ASCII 58 десятичное)
                           ; и знак меньше ("<" , ASCII 60 десятичное)

SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]

UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
                           UTF8-4 / UTF8-5 / UTF8-6

UTF8-STRING              = *UTF8-CHAR

BASE64-UTF8-STRING       = BASE64-STRING
                           ; должна (MUST) быть UTF8-STRING,
                           ; закодированная base64

BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
                           %x61-7A
                           ; +, /, 0-9, =, A-Z, and a-z
                           ; как определно в [5]

BASE64-STRING            = [*(BASE64-CHAR)]

Примечания по синтаксису LDIF

1) Для описанного в этом документе формата LDIF номер версии должен (MUST) быть "1". При отсутствии номера версии те, кто занимается реализацией, могут (MAY) интерпретировать содержимое либо как формат, описанный в этом документе, либо как старый формат файлов LDIF, поддерживаемый реализацией ldap-3.3 Мичиганского Университета [8].

2) Любая непустая строка в файле LDIF, включая строки комментариев, может (MAY) быть разбита на несколько строк путём вставки разделителя строк (SEP) и пробела SPACE. Недопустимо (MUST NOT) разбиение строки перед первым символом в этой строке. Другими словами, разбиение строки на две строки, первая из которых пуста, не разрешается. Любая строка, начинающаяся с единичного пробела, должна (MUST) рассматриваться как продолжение предыдущей (непустой) строки. При объединении разделённых строк должен быть отброшен ровно один символ пробела из каждой строки-продолжения. Тем, кто занимается реализацией, не следует (SHOULD NOT) разбивать строки так, чтобы при этом разбивались мультибайтовые символы UTF-8.

3) Любая строка, начинающаяся с символа решётки ("#", ASCII 35), является строкой комментария и при разборе LDIF-файла должна (MUST) быть проигнорирована.

4) Любое dn или rdn, содержащее символы, отличные от тех, которые определены как "SAFE-UTF8-CHAR", или начинающееся с символов, отличных от тех, которые определены как "SAFE-INIT-UTF8-CHAR" выше, должно (MUST) быть закодировано base-64. Другие значения могут (MAY) быть закодированы base-64. Любые значения, содержащие символы, отличные от тех, которые определены как "SAFE-CHAR", или начинающиеся с символов, отличных от тех, которые определены как "SAFE-INIT-CHAR" выше, должны (MUST) быть закодированы base-64. Другие значения могут (MAY) быть закодированы base-64.

5) Если непосредственно в LDIF-файл требуется включить значение атрибута нулевой длины, оно должно (MUST) быть представлено как AttributeDescription ":" FILL SEP. Например, "seeAlso:", за которым следует переход на новую строку, представляет собой значение нулевой длины атрибута "seeAlso". Также допустимо, чтобы значение, на которое ссылается URL, было нулевой длины.

6) Если в attrval-spec указывается URL, применяются следующие соглашения:

a) Реализациям следует (SHOULD) поддерживать формат URL file://. Содержимое файла, на который ссылается URL, должно быть дословно включено в интерпретируемый вывод данного LDIF-файла.

b) Реализации могут (MAY) поддерживать другие форматы URL. Семантики, ассоциируемые с каждым поддерживаемым форматом URL, должны быть задокументированы в прилагаемых к реализации заявлениях о соответствии (Applicability Statement).

7) Отличительные имена, относительные отличительные имена и значения атрибутов с синтаксисом DirectoryString должны (MUST) быть корректными строками UTF-8. Реализации, читающие LDIF, могут (MAY) интерпретировать файлы, в которых эти объекты хранятся в какой-либо иной кодировке символов, но реализации не должны (MUST NOT) генерировать LDIF, не содержащий корректных UTF-8 данных.

8) Значения отличительных имён, оканчивающиеся на символ пробела SPACE, должны (SHOULD) быть закодированы base-64.

9) При включении элементов управления (control) в LDIF-файл реализации могут (MAY) избрать игнорирование некоторых из них или даже всех. Это может быть необходимо, если описываемые в этом LDIF-файле изменения передаются подключению по протоколу LDAPv2 (который не поддерживает элементов управления), или какой-то конкретный элемент управления не поддерживается удалённым сервером. Если поле criticality элемента управления установлено в "true", то реализации либо должны (MUST) включать этот элемент управления, либо не должны (MUST NOT) отправлять данную операцию на удалённый сервер.

10) Если attrval-spec, distinguishedName или rdn закодированы base-64, применяются определённые в [5] правила кодирования со следующими исключениями: a) Требование, что поток вывода base-64 должен быть представлен в виде строк размером не более 76 символов, не применяется. Строки в файлах LDIF могут разбиваться только согласно правилам разбиения, описанным выше в примечании 2. b) В [5] указывается, что строки, закодированные base-64, могут содержать символы, отличные от набора, определённого как BASE64-CHAR, и такие символы игнорируются. LDIF не разрешает использование каких-либо посторонних символов, кроме тех, которые используются для разбиения строк.

Примеры LDAP Data Interchange Format

Пример 1: Простой LDAP-файл с двумя записями

version: 1
dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 555 1212
description: A big sailing fan.

dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212

Пример 2: Файл, содержащий запись с разбитым на несколько строк значением атрибута

version: 1
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass:top
objectclass:person
objectclass:organizationalPerson
cn:Barbara Jensen
cn:Barbara J Jensen
cn:Babs Jensen
sn:Jensen
uid:bjensen
telephonenumber:+1 408 555 1212
description:Babs is a big sailing fan, and travels extensively in sea
 rch of perfect sailing conditions.
title:Product Manager, Rod and Reel Division

Пример 3: Файл, содержащий значение, закодированное base-64

version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
 b3V0IG1vcmUu

Пример 4: Файл, содержащий записи с закодированными значениями атрибутов в UTF-8, включающими языковые теги. В комментариях указывается содержимое закодированных атрибутов и отличительных имён в UTF-8.

version: 1
dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: ou=<JapaneseOU>,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: <JapaneseOU>
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja:: <JapaneseOU>
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
ou;lang-en: Sales
description: Japanese office

dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
mail: rogasawara@airius.co.jp
givenname;lang-ja:: 44Ot44OJ44OL44O8
# givenname;lang-ja:: <JapaneseGivenname>
sn;lang-ja:: 5bCP56yg5Y6f
# sn;lang-ja:: <JapaneseSn>
cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn;lang-ja:: <JapaneseCn>
title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title;lang-ja:: <JapaneseTitle>
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname:: <JapaneseGivenname>
sn:: 5bCP56yg5Y6f
# sn:: <JapaneseSn>
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn:: <JapaneseCn>
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title:: <JapaneseTitle>
givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
# givenname;lang-ja;phonetic::
<JapaneseGivenname_in_phonetic_representation_kana>
sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title;lang-ja;phonetic::
# <JapaneseTitle_in_phonetic_representation_kana>
givenname;lang-en: Rodney
sn;lang-en: Ogasawara
cn;lang-en: Rodney Ogasawara
title;lang-en: Sales, Director

Пример 5: Файл, содержащий ссылку на внешний файл

version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Horatio Jensen

cn: Horatio N Jensen
sn: Jensen
uid: hjensen
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg

Пример 6: Файл, содержащий серию изменений записей с комментариями

version: 1
# Добавление новой записи
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Fiona Jensen
sn: Jensen
uid: fiona
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/fiona.jpg

# Удаление существующей записи
dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
changetype: delete

# Модификация относительного отличительного имени записи
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: cn=Paula Jensen
deleteoldrdn: 1

# Переименование записи и перемещение всех дочерних по отношению
# к ней записей в новое местоположение в дереве каталога
# (реализуется только серверами LDAPv3)
dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: ou=Product Development Accountants
deleteoldrdn: 0
newsuperior: ou=Accounting, dc=airius, dc=com

# Модификация записи: добавление дополнительного значения атрибута
# postaladdress, полное удаление атрибута description, замена
# значений атрибута telephonenumber двумя новыми значениями
# и удаление конкретного значения атрибута facsimiletelephonenumber
dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
changetype: modify
add: postaladdress
postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
-
delete: description
-
replace: telephonenumber
telephonenumber: +1 408 555 1234
telephonenumber: +1 408 555 5678
-
delete: facsimiletelephonenumber
facsimiletelephonenumber: +1 408 555 9876
-

# Модификация записи: замена значений атрибута postaladdress пустым
# набором значений (что приводит к удалению данного атрибута),
# а также всех значений атрибута description. Имейте ввиду, что
# первое действие всегда завершается успешно, а второе завершается
# успешно лишь когда у атрибута description имеется хотя бы одно значение.
dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
changetype: modify
replace: postaladdress
-
delete: description
-

Пример 7: LDIF-файл, содержащий изменение записи с элементом управления

version: 1
# Удаление записи. К данной операции будет присоединён элемент управления LDAPv3
# Tree Delete Control, определённый в [9]. Поле criticality установлено в "true",
# а поле controlValue отсутствует, согласно требованиям [9].
dn: ou=Product Development, dc=airius, dc=com
control: 1.2.840.113556.1.4.805 true
changetype: delete

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

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

Поскольку директивы ":<" могут привести к тому, что при обработке LDIF-файла в него может быть включено внешнее содержимое, следует быть осторожным при применении LDIF-файлов из внешних источников. В "троянском" LDIF-файле может быть указан файл с конфиденциальным содержимым, который будет включён в запись каталога, а эту запись можно будет потом несанкционированно считать через LDAP.

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

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

Формат обмена данными LDAP был разработан как часть эталонной реализации LDAP Мичиганского университета, разработчики: Tim Howes, Mark Smith и Gordon Good. Частично он основывается на работе, поддерживаемой Национальным научным фондом по гранту № NCR-9416667.

Много полезных предложений сделано членами рабочей группы IETF по дополнениям LDAP. В частности, значительный вклад в этот документ, включая тщательный анализ и пересоставление BNF, сделал Hallvard B. Furuseth из Университета Осло.

Документы

[1] Howes, T. and M. Smith, "A MIME Content-Type for Directory Information", RFC 2425, сентябрь 1998 г.

[2] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, ноябрь 1997 г.

[3] Wahl, M., Kille, S. and T. Howes, "A String Representation of Distinguished Names", RFC 2253, декабрь 1997 г.

[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, июль 1997 г.

[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, ноябрь 1996 г.

[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, декарь 1994 г.

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

[8] The SLAPD and SLURPD Administrators Guide. University of Michigan, апрель 1996 г. <URL: http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>

[9] M. P. Armijo, "Tree Delete Control", работы продолжаются.

Адрес автора

Gordon Good, iPlanet e-commerce Solutions.

150 Network Circle, Mailstop USCA17-201, Santa Clara, CA 95054, USA

Phone: +1 408 276 4351

EMail: ggood@netscape.com

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

Copyright (C) Internet Society (2000). Все права защищены.

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

Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.

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

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

Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.

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