RFC: 2849
Оригинал: The LDAP Data Interchange Format (LDIF) - Technical Specification
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Pro-LDAP.ru

RFC 2849, Страница 3 из 8

Примечания по синтаксису 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, применяются следующие соглашения:

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

    2. Реализации могут (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] правила кодирования со следующими исключениями:

    1. Требование, что поток вывода base-64 должен быть представлен в виде строк размером не более 76 символов, не применяется. Строки в файлах LDIF могут разбиваться только согласно правилам разбиения, описанным выше в примечании 2.

    2. В [5] указывается, что строки, закодированные base-64, могут содержать символы, отличные от набора, определённого как BASE64-CHAR, и такие символы игнорируются. LDIF не разрешает использование каких-либо посторонних символов, кроме тех, которые используются для разбиения строк.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.