Network Working Group Request for Comments: 4517 Категория: Standards Track Под редакцией S. Legg, eB2Bcom Июнь 2006 года Отменяет: 2252, 2256 Обновляет: 3698
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
У каждого хранящегося в каталоге Lightweight Directory Access Protocol (LDAP) атрибута, значение которого может быть передано в протоколе LDAP, имеется определённый синтаксис, ограничивающий структуру и формат его значений. Семантики сравнения для значений какого-либо синтаксиса не являются частью определения этого синтаксиса, а предоставляются с помощью определяемых отдельно правил соответствия. В правилах соответствия задаётся аргумент, — значение утверждения, — который также имеет определённый синтаксис. В этом документе определяется базовый набор синтаксисов и правил соответствия для использования в определениях атрибутов каталогов LDAP.
У каждого хранящегося в каталоге LDAP [RFC4510] атрибута, значение которого может быть передано в протоколе LDAP [RFC4511], имеется определённый синтаксис (то есть, тип данных), ограничивающий структуру и формат его значений. Семантики сравнения для значений какого-либо синтаксиса не являются частью определения этого синтаксиса, а предоставляются с помощью определяемых отдельно правил соответствия. В правилах соответствия задаётся аргумент, — значение утверждения, — который также имеет определённый синтаксис. В этом документе определяется базовый набор синтаксисов и правил соответствия для использования в определениях атрибутов каталогов LDAP.
Читателям рекомендуется ознакомиться с информационными моделями каталога [RFC4512] перед тем, как читать этот документ далее. В разделе 3 приводятся определения базового набора синтаксисов LDAP. В разделе 4 приводятся определения базового набора правил соответствия LDAP.
Данный документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей ранее определённую техническую спецификацию LDAP, RFC 3377.
Разделы 4, 5 и 7 RFC 2252 отменены RFC 4512. Оставшаяся часть RFC 2252 отменена этим документом. Разделы 6 и 8 RFC 2256 отменены этим документом. Оставшаяся часть RFC 2256 отменена RFC 4519 и RFC 4512. RFC 3698, за исключением раздела 2.11, отменён этим документом.
Некоторые элементы схемы данных, включённые в предыдущую ревизию технической спецификации LDAP, не включены в данную ревизию LDAP. Элементы схемы данных, касающиеся инфраструктуры открытых ключей (Public Key Infrastructure), теперь определяются в RFC 4523. Остальные исключённые элементы схемы данных, если они не переопределяются в последующих технических спецификациях, должны рассматриваться как исторические.
Изменения, внесённые в RFC 2252, описаны в приложении B этого документа.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14, RFC 2119.
Определения синтаксисов составлены в соответствии с правилом ABNF [RFC4234] <SyntaxDescription>, определённом в RFC 4512, а определения правил соответствия составлены в соответствии с правилом ABNF <MatchingRuleDescription>, определённом в RFC 4512, за исключением того, что приведённые в этом документе определения синтаксисов и правил соответствия разбиты на строки для повышения читабельности. Когда такие определения передаются в протоколе LDAP как значения атрибута (например, как значения атрибутов ldapSyntaxes и matchingRules [RFC4512], соответственно), такие значения не должны содержать переносов строк.
Определения синтаксисов содержат структуру значений атрибутов, хранящихся в каталоге LDAP, а также определяют представления атрибутов и значений утверждений, передаваемых в протоколе LDAP.
В этом разделе приводятся спецификации синтаксисов, требуемых для работы каталога, либо часто используемых. Серверам следует (SHOULD) распознавать все перечисленные в этом документе синтаксисы, но какой-либо иной поддержки этих синтаксисов от них не требуется. Кроме того, они могут (MAY) распознавать или поддерживать другие синтаксисы. Однако, определение дополнительных произвольных синтаксисов не рекомендуется, так как это будет препятствовать совместимости. Реализации клиентов и серверов обычно не могут динамически распознавать новые синтаксисы.
Описание каждого синтаксиса определяет, как соответствующие этому синтаксису значения атрибута или утверждения должны быть представлены при передаче в протоколе LDAP [RFC4511]. Это представление называется специфичной для LDAP кодировкой (LDAP-specific encoding). Такое именование позволяет отличать её от других методов кодирования значений атрибутов (например, кодировки Basic Encoding Rules (BER) [BER], используемой в каталогах X.500 [X.500]).
Специфичная для LDAP кодировка заданного синтаксиса атрибута всегда выдаёт значения, выровненные по границе октета (длина которых кратна восьми битам). Везде, где это возможно, правила кодирования для синтаксисов LDAP должны выдавать символьные строки, которые могут отображаться клиентскими реализациями LDAP с минимальными преобразованиями, либо вообще без преобразований. Однако, клиенты не должны (MUST NOT) подразумевать, что специфичная для LDAP кодировка значения с нераспознанным синтаксисом является символьной строкой, пригодной для чтения человеком. В некоторых случаях (например, при синтаксисе JPEG) нецелесообразно выдавать пригодное для чтения человеком представление.
Каждый синтаксис LDAP уникально идентифицируется идентификатором объекта [ASN.1], представленном в точечно-цифровом формате (короткие описательные имена для синтаксисов не определяются). Такие идентификаторы объектов не предназначены для отображения пользователям. В приложении A собраны все идентификаторы объектов для синтаксисов, определённых в этом документе.
Рекомендуемая минимальная верхняя граница (по количеству символов в значениях атрибутов с синтаксисами, основанными на строках, либо по количеству байт в значениях с любыми другими синтаксисами), может (MAY) быть указана путём добавления числа в фигурных скобках вслед за идентификатором объекта синтаксиса в определении типа атрибута (смотрите правило <noidlen> в RFC 4512). Такая граница не рассматривается как часть идентификатора синтаксиса.
Например, в формулировке "1.3.6.1.4.1.1466.115.121.1.15{64}" в определении атрибута рекомендуется, чтобы сервер каталога позволял значению этого атрибута быть длиной в 64 символа, но он может позволить и более длинные строки. Имейте ввиду, что один символ в синтаксисе Directory String может быть закодирован более чем одним октетом, поскольку UTF-8 [RFC3629] является кодировкой с переменным размером символа. Поэтому строка в 64 символа может быть длиной более 64 байт.
Следующие правила ABNF используются в некоторых определениях синтаксисов в разделе 3.3.
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; прямой слеш ("/")
COLON = %x3A ; двоеточие (":")
QUESTION = %x3F ; знак вопроса ("?")
Правила <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, <HYPHEN>, <DOT>, <EQUALS> и <SPACE> определены в RFC 4512.
Значением синтаксиса Attribute Type Description является определение типа атрибута. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <AttributeTypeDescription> в RFC 4512.
Например, следующее определение атрибута createTimestamp из RFC 4512 представляет собой значение синтаксиса Attribute Type Description (примечание: переносы строк добавлены для лучшей читабельности; при передаче в протоколе они не включаются в значение):
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Определение LDAP для синтаксиса Attribute Type Description:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
Данный синтаксис соответствует ASN.1-типу AttributeTypeDescription из [X.501].
Значением синтаксиса Bit String является последовательность двоичных цифр. Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"
Правило <SQUOTE> определено в RFC 4512.
Пример:
'0101111101'B
Определение LDAP для синтаксиса Bit String:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
Данный синтаксис соответствует ASN.1-типу BIT STRING из [ASN.1].
Значением синтаксиса Boolean является одно из логических значений, истина или ложь. Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
Boolean = "TRUE" / "FALSE"
Определение LDAP для синтаксиса Boolean:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
Данный синтаксис соответствует ASN.1-типу BOOLEAN из [ASN.1].
Значением синтаксиса Country String является один из двухсимвольных кодов представления страны из ISO 3166 [ISO3166]. Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
CountryString = 2(PrintableCharacter)
Правило <PrintableCharacter> определено в разделе 3.2.
Примеры:
US
AU
Определение LDAP для синтаксиса Country String:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
Данный синтаксис соответствует следующему ASN.1-типу из [X.520]:
PrintableString (SIZE (2)) -- только коды ISO 3166
Значением синтаксиса Delivery Method является последовательность пунктов, указывающих, в порядке предпочтения, сервис (сервисы), с помощью которых сущность желает и/или может получать сообщения. Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
Правила <WSP> и <DOLLAR> определены в RFC 4512.
Пример:
telephone $ videotex
Определение LDAP для синтаксиса Delivery Method:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
Данный синтаксис соответствует следующему ASN.1-типу из [X.520]:
SEQUENCE OF INTEGER {
any-delivery-method (0),
mhs-delivery (1),
physical-delivery (2),
telex-delivery (3),
teletex-delivery (4),
g3-facsimile-delivery (5),
g4-facsimile-delivery (6),
ia5-terminal-delivery (7),
videotex-delivery (8),
telephone-delivery (9) }
Значением синтаксиса Directory String является строка из одного или нескольких произвольных символов из набора Universal Character Set (UCS) [UCS]. Строки нулевой длины не допускаются. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой строку символов, закодированных в UTF-8 [RFC3629]. Такая кодировка соответствует следующей ABNF:
DirectoryString = 1*UTF8
Правило <UTF8> определено в RFC 4512.
Пример:
This is a value of Directory String containing #!%#@.
Серверы и клиенты должны (MUST) быть готовы получать произвольные кодовые элементы UCS, в том числе кодовые элементы за пределами диапазона печатных символов ASCII, а также кодовые элементы, которые в настоящее время не относятся к какому-либо символу.
Определения типов атрибутов, использующие синтаксис Directory String, не должны накладывать дополнительных ограничений на формат значений Directory String, например, путём выдвижения требований, чтобы строка символов удовлетворяла определённому шаблону, описанному с помощью ABNF. В этих случаях должен определяться новый синтаксис.
Определение LDAP для синтаксиса Directory String:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
Данный синтаксис соответствует параметризованному ASN.1-типу DirectoryString из [X.520].
ASN.1-тип DirectoryString позволяет выбирать между ASN.1-типами TeletexString, PrintableString, или UniversalString из [ASN.1]. Однако имейте ввиду, что выбранная альтернатива не указывается в специфичной для LDAP кодировке значения Directory String.
Реализации, выполняющие конвертирование значений Directory String из специфичной для LDAP кодировки в кодировку BER, используемую в X.500, должны выбирать ту альтернативу, которая допускает использование конкретных символов в итоговой строке, а также должны осуществлять конвертирование символов из кодировки UTF-8 в кодировку символов выбранной альтернативы. При конвертировании значений Directory String из кодировки BER в специфичную для LDAP кодировку, символы должны быть сконвертированы из кодировки символов выбранной альтернативы в кодировку UTF-8. Эти преобразования следует (SHOULD) выполнять в соответствии с шагом транскодирования (Transcode) алгоритмов подготовки строк для LDAP [RFC4518].
Значением синтаксиса DIT Content Rule Description является определение правила содержимого DIT (Directory Information Tree). Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <DITContentRuleDescription> в RFC 4512.
Пример:
( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )
Примечание: перенос строки добавлен для лучшей читабельности; он не является частью значения.
Определение LDAP для синтаксиса DIT Content Rule Description:
( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' )
Данный синтаксис соответствует ASN.1-типу DITContentRuleDescription из [X.501].
Значением синтаксиса DIT Structure Rule Description является определение правила структуры DIT. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <DITStructureRuleDescription> в RFC 4512.
Пример:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
Определение LDAP для синтаксиса DIT Structure Rule Description:
( 1.3.6.1.4.1.1466.115.121.1.17
DESC 'DIT Structure Rule Description' )
Данный синтаксис соответствует ASN.1-типу DITStructureRuleDescription из [X.501].
Значением синтаксиса DN является (предполагаемое) уникальное имя (DN) записи [RFC4512]. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <distinguishedName> из строкового представления уникальных имён [RFC4514].
Примеры (из RFC 4514):
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
Определение LDAP для синтаксиса DN:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
Синтаксис DN соответствует ASN.1-типу DistinguishedName из [X.501]. Обратите внимание, что уникальные имена, закодированные в BER (как в X.500), при их перекодировании в специфичную для LDAP кодировку не обязательно обратимы в оригинальную BER-кодировку, поскольку выбранный тип строки в каком-либо компоненте DirectoryString уникального имени не указывается в специфичной для LDAP кодировке этого уникального имени (смотрите раздел 3.3.6).
Значение синтаксиса Enhanced Guide представляет собой предполагаемый критерий, состоящий из комбинации типов атрибутов и операторов фильтрации, который должен использоваться при построении фильтров для поиска записей конкретных объектных классов. Синтаксис Enhanced Guide усовершенствует синтаксис Guide, позволяя указывать рекомендуемую глубину поиска.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
EnhancedGuide = object-class SHARP WSP criteria WSP
SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
criteria = and-term *( BAR and-term )
and-term = term *( AMPERSAND term )
term = EXCLAIM term /
attributetype DOLLAR match-type /
LPAREN criteria RPAREN /
true /
false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = "?true"
false = "?false"
BAR = %x7C ; вертикальная черта ("|")
AMPERSAND = %x26 ; амперсанд ("&")
EXCLAIM = %x21 ; восклицательный знак ("!")
Правила <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> и <DOLLAR> определены в RFC 4512.
Определение LDAP для синтаксиса Enhanced Guide:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Пример:
person#(sn$EQ)#oneLevel
Синтаксис Enhanced Guide соответствует ASN.1-типу EnhancedGuide из [X.520]. Тип EnhancedGuide ссылается на ASN.1-тип Criteria, также из [X.520]. Указанное выше правило <true> представляет собой пустое выражение "and" в значении типа Criteria. Указанное выше правило <false> представляет собой пустое выражение "or" в значении типа Criteria.
Значением синтаксиса Facsimile Telephone Number является номер факсимильного аппарата в коммутируемой телефонной сети общего пользования. Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
fax-number = telephone-number *( DOLLAR fax-parameter )
telephone-number = PrintableString
fax-parameter = "twoDimensional" /
"fineResolution" /
"unlimitedLength" /
"b4Length" /
"a3Width" /
"b4Width" /
"uncompressed"
<telephone-number> представляет собой строку печатных символов, соответствующую международно-согласованному формату представления международных телефонных номеров [E.123]. Правило <PrintableString> определено в разделе 3.2. Правило <DOLLAR> определено в RFC 4512.
Определение LDAP для синтаксиса Facsimile Telephone Number:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
Синтаксис Facsimile Telephone Number соответствует ASN.1-типу FacsimileTelephoneNumber из [X.520].
Значением синтаксиса Fax является изображение, создаваемое с помощью факсимильного процесса Group 3 [FAX] с целью получения дубликата объекта, например, листа бумаги с записями. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой строку октетов для факсимильного изображения Group 3, как определено в [FAX].
Определение LDAP для синтаксиса Fax:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
ASN.1-тип, соответствующий синтаксису Fax, определяется следующим образом (в конструкции предполагаются явные теги EXPLICIT TAGS):
Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
ASN.1-тип G3FacsimileBodyPart определён в [X.420].
Значением синтаксиса Generalized Time является строка символов, представляющая собой дату и время. Специфичная для LDAP кодировка значения этого синтаксиса — это ограниченное подмножество формата, определённого в [ISO8601]. Она описывается следующей ABNF:
GeneralizedTime = century year month day hour
[ minute [ second / leap-second ] ]
[ fraction ]
g-time-zone
century = 2(%x30-39) ; от "00" до "99"
year = 2(%x30-39) ; от "00" до "99"
month = ( %x30 %x31-39 ) ; от "01" (January) до "09"
/ ( %x31 %x30-32 ) ; от "10" до "12"
day = ( %x30 %x31-39 ) ; от "01" до "09"
/ ( %x31-32 %x30-39 ) ; от "10" до "29"
/ ( %x33 %x30-31 ) ; от "30" до "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; от "00" до "23"
minute = %x30-35 %x30-39 ; от "00" до "59"
second = ( %x30-35 %x30-39 ) ; от "00" до "59"
leap-second = ( %x36 %x30 ) ; "60"
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; знак "минус" ("-")
Правила <DOT>, <COMMA> и <PLUS> определены в RFC 4512.
Приведённой выше ABNF могут соответствовать строки символов, которые не являются правильной датой (по Григорианскому календарю) и/или правильным временем (например, February 31, 1994). Такие строки символов следует (SHOULD) считать неверными для данного синтаксиса.
Значение времени представляет собой всемирное координированное время (эквивалент среднего времени по Гринвичу), если используется форма "Z" правила <g-time-zone>; в противном случае, это значение представляет собой локальное время в часовом поясе, который указывается правилом <g-differential>. В последнем случае всемирное координированное время может быть вычислено путем вычитания дифференциала из локального времени. Использование формы "Z" правила <g-time-zone> следует (SHOULD) считать более предпочтительным, чем использование правила <g-differential>.
Если поле <minute> опущено, то поле <fraction> представляет собой долю часа; если поле <minute> присутствует, а поля <second> и <leap-second> опущены, то поле <fraction> представляет собой долю минуты; в противном случае, поле <fraction> представляет собой долю секунды.
Примеры:
199412161032Z
199412160532-0500
В обоих примерах значения представляют собой одно и то же всемирное координированное время: 10:32 AM, December 16, 1994.
Определение LDAP для синтаксиса Generalized Time:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
Данный синтаксис соответствует ASN.1-типу GeneralizedTime из [ASN.1] с тем ограничением, что локальное время без дифференциала использовать не следует (SHALL NOT).
Значение синтаксиса Guide представляет собой предполагаемый критерий, состоящий из комбинации типов атрибутов и операторов фильтрации, который должен использоваться при построении фильтров для поиска записей конкретных объектных классов. Синтаксис Guide является устаревшим и не должен использоваться для определения новых типов атрибутов.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
Guide = [ object-class SHARP ] criteria
Правила <object-class> и <criteria> определены в разделе 3.3.10. Правило <SHARP> определено в RFC 4512.
Определение LDAP для синтаксиса Guide:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
Синтаксис Guide соответствует ASN.1-типу Guide из [X.520].
Значением синтаксиса IA5 String является строка из нуля, одного или более символов из International Alphabet 5 (IA5) [T.50], международной версии набора символов ASCII. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой неизменённую строку символов, удовлетворяющую правилу <IA5String> из раздела 3.2.
Определение LDAP для синтаксиса IA5 String:
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
Данный синтаксис соответствует ASN.1-типу IA5String из [ASN.1].
Значением синтаксиса Integer является целое число неограниченной величины. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой строковое представление числа, состоящее из необязательного знака и символов десятичных цифр (например, число 1321 будет представлено строкой символов "1321"). Такая кодировка определяется следующей ABNF:
Integer = ( HYPHEN LDIGIT *DIGIT ) / number
Правила <HYPHEN>, <LDIGIT>, <DIGIT> и <number> определены в RFC 4512.
Определение LDAP для синтаксиса Integer:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
Данный синтаксис соответствует ASN.1-типу INTEGER из [ASN.1].
Значением синтаксиса JPEG является изображение в формате JPEG File Interchange Format (JFIF), как описано в [JPEG]. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой последовательность октетов изображения в кодировке JFIF.
Определение LDAP для синтаксиса JPEG:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
Синтаксис JPEG соответствует следующему ASN.1-типу:
JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- октеты содержимого представляют собой изображение в формате --
-- JPEG File Interchange Format -- })
Значением синтаксиса LDAP Syntax Description является описание синтаксиса LDAP. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <SyntaxDescription> в RFC 4512.
Определение LDAP для синтаксиса LDAP Syntax Description:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
Данное определение LDAP для синтаксиса LDAP Syntax Description само по себе является правильным значением синтаксиса LDAP Syntax Description.
ASN.1-тип, соответствующий синтаксису LDAP Syntax Description, определяется следующим образом (в конструкции предполагаются явные теги EXPLICIT TAGS):
LDAPSyntaxDescription ::= SEQUENCE {
identifier OBJECT IDENTIFIER,
description DirectoryString { ub-schema } OPTIONAL }
Параметризованный ASN.1-тип DirectoryString определён в [X.520].
Значение ub-schema (целое число) определяется при реализации. Ненормативное определение есть в [X.520].
Значением синтаксиса Matching Rule Description является определение правила соответствия. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <MatchingRuleDescription> в RFC 4512.
Пример:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Примечание: перенос строки добавлен для лучшей читабельности; он не является частью синтаксиса.
Определение LDAP для синтаксиса Matching Rule Description:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
Данный синтаксис соответствует ASN.1-типу MatchingRuleDescription из [X.501].
В значении синтаксиса Matching Rule Use Description указываются типы атрибутов, к которым может применяться правило соответствия в поисковом фильтре extensibleMatch [RFC4511]. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <MatchingRuleUseDescription> в RFC 4512.
Пример:
( 2.5.13.16 APPLIES ( givenName $ surname ) )
Определение LDAP для синтаксиса Matching Rule Use Description:
( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' )
Данный синтаксис соответствует ASN.1-типу MatchingRuleUseDescription из [X.501].
Значением синтаксиса Name and Optional UID является уникальное имя [RFC4512] сущности, которое может опционально сопровождаться уникальным идентификатором, служащим для того, чтобы отличить данную сущность от других с идентичным уникальным именем.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
Правило <BitString> определено в разделе 3.3.2. Правило <distinguishedName> определяется в RFC 4514. Правило <SHARP> определяется в RFC 4512.
Обратите внимание, что символ '#' также может встречаться в строковом представлении уникального имени, при этом, когда <distinguishedName> кодируется в <NameAndOptionalUID>, дополнительного экранирования данного символа не осуществляется.
Пример:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
Определение LDAP для синтаксиса Name and Optional UID:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
Данный синтаксис соответствует ASN.1-типу NameAndOptionalUID из [X.520].
Значением синтаксиса Name Form Description является определение формы имени, регулирующей то, как запись может именоваться. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <NameFormDescription> в RFC 4512.
Пример:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
Определение LDAP для синтаксиса Name Form Description:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
Данный синтаксис соответствует ASN.1-типу NameFormDescription из [X.501].
Значением синтаксиса Numeric String является последовательность из одной или нескольких цифр и пробелов. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой оставленную без изменений строку символов, удовлетворяющую следующей ABNF:
NumericString = 1*(DIGIT / SPACE)
Правила <DIGIT> и <SPACE> определены в RFC 4512.
Пример:
15 079 672 281
Определение LDAP для синтаксиса Numeric String:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
Данный синтаксис соответствует ASN.1-типу NumericString из [ASN.1].
Значением синтаксиса Object Class Description является определение объектного класса. Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <ObjectClassDescription> в RFC 4512.
Пример:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) )
Примечание: перенос строки добавлен для лучшей читабельности; он не является частью синтаксиса.
Определение LDAP для синтаксиса Object Class Description:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
Данный синтаксис соответствует ASN.1-типу ObjectClassDescription из [X.501].
Значением синтаксиса Octet String является последовательность из нуля, одного или более произвольных октетов. Специфичная для LDAP кодировка значения этого синтаксиса представляет собой оставленную без изменений последовательность октетов, удовлетворяющую следующей ABNF:
OctetString = *OCTET
Правило <OCTET> определено в RFC 4512. В общем случае значения этого синтаксиса не предназначены для чтения человеком.
Определение LDAP для синтаксиса Octet String:
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
Данный синтаксис соответствует ASN.1-типу OCTET STRING из [ASN.1].
Значением синтаксиса OID является идентификатор объекта: последовательность из двух или более положительных целых чисел, уникально идентифицирующая некоторый объект или элемент спецификации. Многие используемые в LDAP идентификаторы объектов также имеют зарегистрированные IANA имена [RFC4520].
Специфичная для LDAP кодировка значения этого синтаксиса определяется правилом <oid> в RFC 4512.
Примеры:
1.2.3.4
cn
Определение LDAP для синтаксиса OID:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
Данный синтаксис соответствует ASN.1-типу OBJECT IDENTIFIER из [ASN.1].
Значение синтаксиса Other Mailbox идентифицирует электронный почтовый ящик в почтовой системе с определённым именем. Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
OtherMailbox = mailbox-type DOLLAR mailbox
mailbox-type = PrintableString
mailbox = IA5String
Правило <mailbox-type> представляет собой тип почтовой системы, в которой находится данный почтовый ящик (например, "MCIMail"), а <mailbox> — это собственно почтовый ящик в почтовой системе, описанной в правиле <mailbox-type>. Правила <PrintableString> и <IA5String> определены в разделе 3.2. Правило <DOLLAR> определено в RFC 4512.
Определение LDAP для синтаксиса Other Mailbox:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
ASN.1-тип, соответствующий синтаксису Other Mailbox, определяется следующим образом (в конструкции предполагаются явные теги EXPLICIT TAGS):
OtherMailbox ::= SEQUENCE {
mailboxType PrintableString,
mailbox IA5String
}
Значением синтаксиса Postal Address является последовательность строк, состоящих из одного или более произвольных символов UCS, формирующих адрес в физической почтовой системе.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
PostalAddress = line *( DOLLAR line )
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; экранированный символ "$"
/ %x25-5B
/ (%x5C "5C") ; экранированный символ "\"
/ %x5D-7F
/ UTFMB
Каждая строка символов (то есть, <line>) значения почтового адреса кодируется как строка UTF-8 [RFC3629], за исключением того, что символы "\" и "$", если таковые присутствуют в этой строке, экранируются символом "\", за которым следует код данного символа в виде двух шестнадцатеричных цифр. Правила <DOLLAR> и <UTFMB> определены в RFC 4512.
Многие серверы ограничивают размер почтового адреса не более чем шестью строками, каждая из которых может быть не более тридцати символов.
Пример:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
Определение LDAP для синтаксиса Postal Address:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
Данный синтаксис соответствует ASN.1-типу PostalAddress из [X.520]:
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string }
Значения (целочисленные) элементов ub-postal-line и ub-postal-string определяются при реализации. Ненормативные определения даны в стандарте [X.520].
Значением синтаксиса Printable String является строка из одной или более букв латинского алфавита, цифр и некоторых символов пунктуации, как определено правилом <PrintableCharacter> в разделе 3.2.
Специфичная для LDAP кодировка значения этого синтаксиса представляет собой оставленную без изменений строку символов, удовлетворяющих правилу <PrintableString> в разделе 3.2.
Пример:
This is a PrintableString.
Определение LDAP для синтаксиса PrintableString:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
Данный синтаксис соответствует ASN.1-типу PrintableString из [ASN.1].
Значением синтаксиса Substring Assertion является последовательность из нуля, одной или более символьных подстрок, используемых в качестве аргумента в расширенном сравнении (extensible match) подстрок со значениями атрибутов, имеющих синтаксис символьной строки; то есть в качестве matchValue в конструкции MatchingRuleAssertion [RFC4511]. Каждая подстрока представляет собой строку из одного или более произвольных символов из универсального набора символов (Universal Character Set, UCS) [UCS]. Подстроки нулевой длины не допускаются.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
SubstringAssertion = [ initial ] any [ final ]
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; символ звёздочки ("*")
substring = 1*substring-character
substring-character = %x00-29
/ (%x5C "2A") ; экранированный символ "*"
/ %x2B-5B
/ (%x5C "5C") ; экранированный символ "\"
/ %x5D-7F
/ UTFMB
Каждая подстрока <substring> из значения Substring Assertion кодируется как строка UTF-8 [RFC3629], за исключением того, что символы "\" и "*", если таковые присутствуют в этой строке, экранируются символом "\", за которым следует код данного символа в виде двух шестнадцатеричных цифр.
Синтаксис Substring Assertion используется только в качестве синтаксиса значений утверждений в поисковых фильтрах extensible match. Он не используется в качестве синтаксиса атрибутов или в фильтрах SubstringFilter [RFC4511].
Определение LDAP для синтаксиса Substring Assertion:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
Данный синтаксис соответствует ASN.1-типу SubstringAssertion из [X.520].
Значением синтаксиса Telephone Number является строка пригодных для печати символов, удовлетворяющих международно-согласованному формату для представления международных телефонных номеров [E.123].
Специфичная для LDAP кодировка значения этого синтаксиса представляет собой оставленную без изменений строку символов, удовлетворяющих правилу <PrintableString> в разделе 3.2.
Примеры:
+1 512 315 0280
+1-512-315-0280
+61 3 9896 7830
Определение LDAP для синтаксиса Telephone Number:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
Синтаксис Telephone Number соответствует следующему ASN.1-типу из [X.520]:
PrintableString (SIZE(1..ub-telephone-number))
Значение (целочисленное) элемента ub-telephone-number определяется при реализации. Ненормативное определение дано в стандарте [X.520].
Значение данного синтаксиса определяет идентификатор и (опционально) параметры терминала телетекста.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-octet
ttx-value-octet = %x00-23
/ (%x5C "24") ; экранированный символ "$"
/ %x25-5B
/ (%x5C "5C") ; экранированный символ "\"
/ %x5D-FF
Правила <PrintableString> и <COLON> определены в разделе 3.2. Правило <DOLLAR> определено в RFC 4512.
Определение LDAP для синтаксиса Teletex Terminal Identifier:
( 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Teletex Terminal Identifier' )
Данный синтаксис соответствует ASN.1-типу TeletexTerminalIdentifier из [X.520].
Значение синтаксиса Telex Number определяет номер телекса, код страны и код автоответа терминала телекса.
Специфичная для LDAP кодировка значения этого синтаксиса определяется следующей ABNF:
telex-number = actual-number DOLLAR country-code
DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableString
Правило <PrintableString> определено в разделе 3.2. Правило <DOLLAR> определено в RFC 4512.
Определение LDAP для синтаксиса Telex Number:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
Данный синтаксис соответствует ASN.1-типу TelexNumber из [X.520].
Значением синтаксиса UTC Time является строка символов, представляющая дату и время с точностью до одной минуты или одной секунды. Год задаётся двумя цифрами. Специфичная для LDAP кодировка значения этого синтаксиса следует определённому в [ASN.1] формату для типа UTCTime и описывается следующей ABNF:
UTCTime = year month day hour minute [ second ]
[ u-time-zone ]
u-time-zone = %x5A ; "Z"
/ u-differential
u-differential = ( MINUS / PLUS ) hour minute
Правила <year>, <month>, <day>, <hour>, <minute>, <second> и <MINUS> определены в разделе 3.3.13. Правило <PLUS> определено в RFC 4512.
Приведённой выше ABNF могут соответствовать строки символов, которые не являются правильной датой (по Григорианскому календарю) и/или правильным временем. Такие строки символов следует (SHOULD) считать неверными для данного синтаксиса.
Значение времени представляет собой всемирное координированное время (эквивалент среднего времени по Гринвичу), если используется форма "Z" правила <u-time-zone>; в противном случае, это значение представляет собой локальное время. В последнем случае, если приведено значение дифференциала, определяемое правилом <u-differential>, всемирное координированное время может быть вычислено путём вычитания этого дифференциала из локального времени. Значение, определяемое правилом <u-time-zone>, должно (SHOULD) присутствовать в значениях времени. Использование формы "Z" правила <u-time-zone> следует (SHOULD) считать более предпочтительным, чем использование правила <u-differential>.
Определение LDAP для синтаксиса UTC Time:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
Примечание: Данный синтаксис является устаревшим в пользу синтаксиса Generalized Time.
Синтаксис UTC Time соответствует ASN.1-типу UTCTime из [ASN.1].
Правила соответствия используются в реализациях каталогов для сравнения значений атрибутов со значениями утверждений при выполнении операций поиска Search и сравнения Compare [RFC4511]. Также они используются при сравнении предполагаемого уникального имени [RFC4512] с именем записи. При модификации записей правила соответствия используются для идентификации значений, которые необходимо удалить, а также для предотвращения дублирования значений атрибута.
В этом разделе определяются правила соответствия, которые требуются для работы каталога, либо широко используются.
Правило соответствия применяется к значениям атрибута посредством его использования в конструкциях AttributeValueAssertion или MatchingRuleAssertion [RFC4511]. Условия, при которых конструкции AttributeValueAssertion или MatchingRuleAssertion оцениваются как Undefined, определены в других документах [RFC4511]. Если утверждение оценено не как Undefined, то результатом этого утверждения является результат применения выбранного правила соответствия. Правило соответствия оценивается как TRUE (и, в некоторых случаях, как Undefined) согласно определению, приведённому в описании этого правила соответствия; в противном случае оно оценивается как FALSE.
Каждое утверждение содержит значение утверждения. В определении каждого правила соответствия указывается синтаксис для этого значения утверждения. Обычно (но не обязательно) синтаксис значения утверждения совпадает с синтаксисом значения атрибута, к которому может быть применено данное правило соответствия. Обратите внимание, значение AssertionValue в фильтрах SubstringFilter [RFC4511] соответствует синтаксису утверждения правила соответствия equality, а не правила соответствия substrings для данного типа атрибута. Концептуально, перед применением правила соответствия substrings вся конструкция SubstringFilter преобразуется в значение утверждения этого правила соответствия.
В определении каждого правила соответствия указываются синтаксисы атрибутов, к которым данное правило может быть применено, путём задания условий, которым должны удовлетворять соответствующие ASN.1-типы синтаксисов атрибутов-кандидатов. Эти условия также считаются выполненными, если соответствующий ASN.1-тип является тэгированной или ограниченной производной от ASN.1-типа, явно упоминаемого в описании правила (то есть, тэги и ограничения ASN.1 при проверке возможности применения правила игнорируются), либо если соответствующий ASN.1-тип представляет собой альтернативное ссылочное обозначение для явно указанного типа. В описании каждого правила соответствия перечисляется (в качестве примера применимых синтаксисов атрибутов) полный список синтаксисов, к которым применяется данное правило соответствия (определения этих синтаксисов даны в этом документе). Правило соответствия может применяться к дополнительным синтаксисам, определённым в других документах, если такие синтаксисы удовлетворяют условиям, выдвигаемым к соответствующим ASN.1-типам.
В описании каждого правила соответствия указывается, применяется ли это правило как правило соответствия equality (EQUALITY), правило соответствия ordering (ORDERING) или правило соответствия substrings (SUBSTR) в определении типа атрибута [RFC4512].
Каждое правило соответствия уникально идентифицируется идентификатором объекта. Впоследствии определение правила соответствия не должно изменяться. Если требуется внести изменение в правило соответствия, то вместо этого определяется новое правило соответствия с другим идентификатором объекта.
Серверы могут (MAY) реализовывать правила соответствия wordMatch и keywordMatch, остальные правила соответствия из раздела 4.2 они должны (SHOULD) реализовывать. Серверы могут (MAY) реализовывать дополнительные правила соответствия.
Серверам, реализующим фильтры extensibleMatch, следует (SHOULD) разрешать использовать в фильтрах extensibleMatch правила соответствия, перечисленные в разделе 4.2, а также следует (SHOULD) разрешать использовать правила соответствия со всеми известными серверу типами атрибута, если синтаксис утверждения правила соответствия совпадает с синтаксисом значения атрибута.
Серверы должны (MUST) публиковать в атрибуте matchingRules определения правил соответствия, на которые ссылаются значения атрибутов attributeTypes и matchingRuleUse в той же записи subschema сервера. В атрибуте matchingRules могут (MAY) быть опубликованы другие правила соответствия, на которые не ссылаются значения указанных выше атрибутов.
Если сервер поддерживает фильтры extensibleMatch, то он может (MAY) использовать атрибут matchingRuleUse, чтобы указать на возможность применения (в фильтрах extensibleMatch) конкретных правил соответствия к предлагаемым типам атрибутов.
Предлагаемые строки символов в утверждениях и значениях атрибутов подготавливаются в соответствии с алгоритмами подготовки строк для LDAP [RFC4518] при их сопоставлении со следующими правилами соответствия:
numericStringMatch,
numericStringSubstringsMatch,
caseExactMatch,
caseExactOrderingMatch,
caseExactSubstringsMatch,
caseExactIA5Match,
caseIgnoreIA5Match,
caseIgnoreIA5SubstringsMatch,
caseIgnoreListMatch,
caseIgnoreListSubstringsMatch,
caseIgnoreMatch,
caseIgnoreOrderingMatch,
caseIgnoreSubstringsMatch,
directoryStringFirstComponentMatch,
telephoneNumberMatch,
telephoneNumberSubstringsMatch и
wordMatch.
Шаги транскодирования, нормализации, запрета и проверки двунаправленности являются одинаковыми для всех перечисленных правил соответствия. Однако шаги отображения и обработки малозначительных символов зависят от конкретного правила (смотрите пояснения, приведённые в описании этих правил соответствия в подразделах ниже).
С помощью правила bitStringMatch выполняется сравнение значения утверждения, имеющего синтаксис Bit String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу BIT STRING (например, синтаксис Bit String).
Если у соответствующего синтаксису атрибута ASN.1-типа нет списка именованных бит [ASN.1] (как в случае с синтаксисом Bit String), то данное правило оценивается как TRUE, если и только если значение атрибута состоит из такого же количества бит, что и значение утверждения, и эти биты совпадают на побитовой основе.
Если у соответствующего ASN.1-типа есть список именованных бит, то правило bitStringMatch работает также, как описано выше, за исключением того, что конечные нулевые биты в значениях атрибута и утверждения интерпретируются как отсутствующие.
Определение LDAP для правила bitStringMatch:
( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
Правило bitStringMatch является правилом соответствия equality.
С помощью правила booleanMatch выполняется сравнение значения утверждения, имеющего синтаксис Boolean, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу BOOLEAN (например, синтаксис Boolean).
Данное правило оценивается как TRUE, если и только если значение атрибута и значение утверждения одновременно являются либо TRUE, либо FALSE.
Определение LDAP для правила booleanMatch:
( 2.5.13.13 NAME 'booleanMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
Правило booleanMatch является правилом соответствия equality.
С помощью правила caseExactIA5Match выполняется сравнение значения утверждения, имеющего синтаксис IA5 String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу IA5String (например, синтаксис IA5 String).
Данное правило оценивается как TRUE, если и только если подготовленная строка символов в значении атрибута и подготовленная строка символов в значении утверждения имеют одинаковое количество символов и коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения, на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseExactIA5Match:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Правило caseExactIA5Match является правилом соответствия equality.
С помощью правила caseExactMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString или одному из альтернативных по отношению к DirectoryString строковых типов, таких как PrintableString (другие альтернативные строковые типы ASN.1 не соответствуют каким-либо определённым в этом документе синтаксисам). Примеры подходящих синтаксисов атрибутов LDAP: Directory String, Printable String, Country String или Telephone Number.
Данное правило оценивается как TRUE, если и только если подготовленная строка символов в значении атрибута и подготовленная строка символов в значении утверждения имеют одинаковое количество символов и коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения, на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseExactMatch:
( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Правило caseExactMatch является правилом соответствия equality.
С помощью правила caseExactOrderingMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString или одному из альтернативных по отношению к DirectoryString строковых типов. Примеры подходящих синтаксисов атрибутов LDAP: Directory String, Printable String, Country String или Telephone Number.
Данное правило оценивается как TRUE (с учётом того, что порядок символов определяется по значению их кода), если и только если подготовленная строка символов в значении атрибута располагается раньше, чем подготовленная строка символов в значении утверждения; то есть, значение атрибута "меньше чем" значение утверждения.
При подготовке значения атрибута и значения утверждения для выполнения сравнения, на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseExactOrderingMatch:
( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Правило caseExactOrderingMatch является правилом соответствия ordering.
С помощью правила caseExactSubstringsMatch выполняется сравнение значения утверждения, имеющего синтаксис Substring Assertion, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString или одному из альтернативных по отношению к DirectoryString строковых типов. Примеры подходящих синтаксисов атрибутов LDAP: Directory String, Printable String, Country String или Telephone Number.
Данное правило оценивается как TRUE, если и только если: (1) подготовленные подстроки в значении утверждения соответствуют непересекающимся частям подготовленной строки символов в значении атрибута в том порядке, в котором эти подстроки представлены в значении утверждения; (2) подстрока <initial>, если таковая присутствует, соответствует началу подготовленной строки символов в значении атрибута; (3) подстрока <final>, если таковая присутствует, соответствует окончанию подготовленной строки символов в значении атрибута. Подготовленная подстрока соответствует части подготовленной строки символов в значении атрибута, если коды соответствующих символов совпадают.
При подготовке значения атрибута и подстрок значения утверждения для выполнения сравнения на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseExactSubstringsMatch:
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
Правило caseExactSubstringsMatch является правилом соответствия substrings.
С помощью правила caseIgnoreIA5Match выполняется сравнение значения утверждения, имеющего синтаксис IA5 String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу IA5String (например, синтаксис IA5 String).
Данное правило оценивается как TRUE, если и только если подготовленная строка символов в значении атрибута и подготовленная строка символов в значении утверждения имеют одинаковое количество символов и коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения, на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseIgnoreIA5Match:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Правило caseIgnoreIA5Match является правилом соответствия equality.
С помощью правила caseIgnoreIA5SubstringsMatch выполняется сравнение значения утверждения, имеющего синтаксис Substring Assertion, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу IA5String (например, синтаксис IA5 String).
Данное правило оценивается как TRUE, если и только если: (1) подготовленные подстроки в значении утверждения соответствуют непересекающимся частям подготовленной строки символов в значении атрибута в том порядке, в котором эти подстроки представлены в значении утверждения; (2) подстрока <initial>, если таковая присутствует, соответствует началу подготовленной строки символов в значении атрибута; (3) подстрока <final>, если таковая присутствует, соответствует окончанию подготовленной строки символов в значении атрибута. Подготовленная подстрока соответствует части подготовленной строки символов в значении атрибута, если коды соответствующих символов совпадают.
При подготовке значения атрибута и подстрок значения утверждения для выполнения сравнения на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseIgnoreIA5SubstringsMatch:
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
Правило caseIgnoreIA5SubstringsMatch является правилом соответствия substrings.
С помощью правила caseIgnoreListMatch выполняется сравнение значения утверждения, представляющего собой последовательность строк, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу, представляющему собой последовательность (SEQUENCE OF) ASN.1-типов DirectoryString (например, синтаксис Postal Address).
Данное правило оценивается как TRUE, если и только если значение атрибута и значение утверждения состоят из одинакового количества строк, и соответствующие (по позициям) строки совпадают согласно правилу соответствия caseIgnoreMatch.
В [X.520] синтаксис утверждения для данного правила соответствия определяется как:
SEQUENCE OF DirectoryString {ub-match}
То есть, оно отличается от определения типа, соответствующего синтаксису Postal Address. В LDAP выбор синтаксиса Postal Address для синтаксиса утверждения правила caseIgnoreListMatch не следует рассматривать как ограничение, налагаемое на это правило соответствия. Оно может применяться не только к атрибутам с синтаксисом Postal Address.
Определение LDAP для правила caseIgnoreListMatch:
( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
Правило caseIgnoreListMatch является правилом соответствия equality.
С помощью правила caseIgnoreListSubstringsMatch выполняется сравнение значения утверждения, имеющего синтаксис Substring Assertion, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу, представляющему собой последовательность (SEQUENCE OF) ASN.1-типов DirectoryString (например, синтаксис Postal Address).
Данное правило оценивается как TRUE, если и только если значение утверждения соответствует (по правилу caseIgnoreSubstringsMatch) строке символов, сформированной путём конкатенации строк из значения атрибута, за исключением того, что ни одна из подстрок <initial>, <any> или <final> из значения утверждения не считается совпавшей с частью строки, полученной в результате конкатенации, если эта часть охватывает более чем одну оригинальную строку из значения атрибута.
Обратите внимание, что с точки зрения специфичной для LDAP кодировки синтаксиса Postal Address, в конкатентированной строке опускаются разделители строк <DOLLAR>, а также экранируются символы "\" и "$".
Определение LDAP для правила caseIgnoreListSubstringsMatch:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
Правило caseIgnoreListSubstringsMatch является правилом соответствия substrings.
С помощью правила caseIgnoreMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString или одному из альтернативных по отношению к DirectoryString строковых типов. Примеры подходящих синтаксисов атрибутов LDAP: Directory String, Printable String, Country String или Telephone Number.
Данное правило оценивается как TRUE, если и только если подготовленная строка символов в значении атрибута и подготовленная строка символов в значении утверждения имеют одинаковое количество символов и коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseIgnoreMatch:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreMatch является правилом соответствия equality.
С помощью правила caseIgnoreOrderingMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString или одному из альтернативных по отношению к DirectoryString строковых типов. Примеры подходящих синтаксисов атрибутов LDAP: Directory String, Printable String, Country String или Telephone Number.
Данное правило оценивается как TRUE (с учётом того, что порядок символов определяется по значению их кода), если и только если подготовленная строка символов в значении атрибута располагается раньше, чем подготовленная строка символов в значении утверждения; то есть, значение атрибута "меньше чем" значение утверждения.
При подготовке значения атрибута и значения утверждения для выполнения сравнения на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseIgnoreOrderingMatch:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Правило caseIgnoreOrderingMatch является правилом соответствия ordering.
С помощью правила caseIgnoreSubstringsMatch выполняется сравнение значения утверждения, имеющего синтаксис Substring Assertion, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString или одному из альтернативных по отношению к DirectoryString строковых типов. Примеры подходящих синтаксисов атрибутов LDAP: Directory String, Printable String, Country String или Telephone Number.
Данное правило оценивается как TRUE, если и только если: (1) подготовленные подстроки в значении утверждения соответствуют непересекающимся частям подготовленной строки символов в значении атрибута в том порядке, в котором эти подстроки представлены в значении утверждения; (2) подстрока <initial>, если таковая присутствует, соответствует началу подготовленной строки символов в значении атрибута; (3) подстрока <final>, если таковая присутствует, соответствует окончанию подготовленной строки символов в значении атрибута. Подготовленная подстрока соответствует части подготовленной строки символов в значении атрибута, если коды соответствующих символов совпадают.
При подготовке значения атрибута и подстрок значения утверждения для выполнения сравнения на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных пробельных символов.
Определение LDAP для правила caseIgnoreSubstringsMatch:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreSubstringsMatch является правилом соответствия substrings.
С помощью правила directoryStringFirstComponentMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу, представляющему собой последовательность (SEQUENCE), в которой обязательный первый компонент имеет ASN.1-тип DirectoryString.
Обратите внимание, что синтаксис утверждения в данном правиле соответствия отличается от синтаксиса атрибутов для тех атрибутов, по отношению к которым это правило является правилом соответствия equality.
Данное правило оценивается как TRUE, если и только если значение утверждения совпадает с первым компонентом значения атрибута согласно правилу соответствия caseIgnoreMatch.
Определение LDAP для правила соответствия directoryStringFirstComponentMatch:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Правило directoryStringFirstComponentMatch является правилом соответствия equality. При использовании directoryStringFirstComponentMatch для сравнения двух значений атрибутов (синтаксис которых позволяет применять это правило), значение утверждения сначала должно быть получено из значения одного из этих атрибутов. Значение утверждения может быть получено из значения атрибута путём выделения первого компонента этого значения атрибута.
С помощью правила distinguishedNameMatch выполняется сравнение значения утверждения, имеющего синтаксис DN, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DistinguishedName (например, синтаксис DN).
Данное правило оценивается как TRUE, если и только если значение атрибута и значение утверждения состоят из одинакового количества относительных уникальных имён и соответствующие (по позициям) относительные уникальные имена совпадают. Отноcительное уникальное имя (RDN) в значении утверждения совпадает с RDN в значении атрибута, если и только если они состоят из одинакового количества утверждений значений атрибутов (AVA) и каждое AVA первого RDN совпадает с AVA с тем же типом атрибута из второго RDN. Порядок следования AVA в RDN не существенен. Также имейте ввиду, что конкретный тип атрибута может присутствовать максимум в одном AVA в RDN. Два AVA с одним и тем же типом атрибута являются одинаковыми, если их значения эквивалентны согласно правилу соответствия equality данного типа атрибута. Если сравнения одного или нескольких AVA оцениваются как Undefined, а оставшиеся сравнения AVA возвращают TRUE, то правило distinguishedNameMatch оценивается как Undefined.
Определение LDAP для правила distinguishedNameMatch:
( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
Правило distinguishedNameMatch является правилом соответствия equality.
С помощью правила generalizedTimeMatch выполняется сравнение значения утверждения, имеющего синтаксис Generalized Time, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу GeneralizedTime (например, синтаксис Generalized Time).
Данное правило оценивается как TRUE, если и только если значение атрибута представляет собой то же самое всемирное координированное время, что и значение утверждения. Если в определении времени отсутствуют минуты и секунды, то подразумевается, что число минут и секунд (соответственно) равно нулю.
Определение LDAP для правила generalizedTimeMatch:
( 2.5.13.27 NAME 'generalizedTimeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Правило generalizedTimeMatch является правилом соответствия equality.
С помощью правила generalizedTimeOrderingMatch выполняется сравнение порядка следования величин времени в значении утверждения, имеющего синтаксис Generalized Time, и в значении атрибута, имеющего синтаксис, соответствующий ASN.1-типу GeneralizedTime (например, синтаксис Generalized Time).
Данное правило оценивается как TRUE, если и только если значение атрибута представляет собой всемирное координированное время, которое является более ранним по отношению ко всемирному координированному времени, представленному в значении утверждения.
Определение LDAP для правила generalizedTimeOrderingMatch:
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Правило generalizedTimeOrderingMatch является правилом соответствия ordering.
С помощью правила integerFirstComponentMatch выполняется сравнение значения утверждения, имеющего синтаксис Integer, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу, представляющему собой последовательность (SEQUENCE), в которой обязательный первый компонент имеет ASN.1-тип INTEGER (например, синтаксис DIT Structure Rule Description).
Обратите внимание, что синтаксис утверждения в данном правиле соответствия отличается от синтаксиса атрибутов для тех атрибутов, по отношению к которым это правило является правилом соответствия equality.
Данное правило оценивается как TRUE, если и только если значение утверждения и первый компонент значения атрибута являются одним и тем же целочисленным значением.
Определение LDAP для правила соответствия integerFirstComponentMatch:
( 2.5.13.29 NAME 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
Правило integerFirstComponentMatch является правилом соответствия equality. При использовании integerFirstComponentMatch для сравнения двух значений атрибутов (синтаксис которых позволяет применять это правило), значение утверждения сначала должно быть получено из значения одного из этих атрибутов. Значение утверждения может быть получено из значения атрибута путём выделения первого компонента этого значения атрибута.
С помощью правила integerMatch выполняется сравнение значения утверждения, имеющего синтаксис Integer, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу INTEGER (например, синтаксис Integer).
Данное правило оценивается как TRUE, если и только если значение атрибута и значение утверждения являются одним и тем же целочисленным значением.
Определение LDAP для правила integerMatch matching:
( 2.5.13.14 NAME 'integerMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
Правило integerMatch является правилом соответствия equality.
С помощью правила integerOrderingMatch выполняется сравнение значения утверждения, имеющего синтаксис Integer, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу INTEGER (например, синтаксис Integer).
Данное правило оценивается как TRUE, если и только если целочисленное значение в значении атрибута меньше, чем целочисленное значение в значении утверждения.
Определение LDAP для правила соответствия integerOrderingMatch:
( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
Правило integerOrderingMatch является правилом соответствия ordering.
С помощью правила keywordMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString (например, синтаксис Directory String).
Данное правило оценивается как TRUE, если и только если строка символов в значении утверждения совпадает с любым ключевым словом в значении атрибута. Идентификация ключевых слов в значении атрибута и определение точности совпадения определяются разработчиками реализации.
Определение LDAP для правила keywordMatch:
( 2.5.13.33 NAME 'keywordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
С помощью правила numericStringMatch выполняется сравнение значения утверждения, имеющего синтаксис Numeric String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу NumericString (например, синтаксис Numeric String).
Данное правило оценивается как TRUE, если и только если подготовленная строка символов в значении атрибута и подготовленная строка символов в значении утверждения имеют одинаковое количество символов и коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных символов для строк numericString.
Определение LDAP для правила соответствия numericStringMatch:
( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
Правило numericStringMatch является правилом соответствия equality.
С помощью правила numericStringOrderingMatch выполняется сравнение значения утверждения, имеющего синтаксис Numeric String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу NumericString (например, синтаксис Numeric String).
Данное правило оценивается как TRUE, если и только если (с учётом того, что порядок символов определяется по значению их кода) подготовленная строка символов в значении атрибута располагается раньше, чем подготовленная строка символов в значении утверждения; то есть, значение атрибута "меньше чем" значение утверждения.
При подготовке значения атрибута и значения утверждения для выполнения сравнения на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных символов для строк numericString.
Данное правило идентично правилу caseIgnoreOrderingMatch, за исключением того, что во время сравнения все пробельные символы пропускаются (регистр символов не имеет значения, поскольку все символы в строке числовые).
Определение LDAP для правила соответствия numericStringOrderingMatch:
( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
Правило numericStringOrderingMatch является правилом соответствия ordering.
С помощью правила numericStringSubstringsMatch выполняется сравнение значения утверждения, имеющего синтаксис Substring Assertion, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу NumericString (например, синтаксис Numeric String).
Данное правило оценивается как TRUE, если и только если: (1) подготовленные подстроки в значении утверждения соответствуют непересекающимся частям подготовленной строки символов в значении атрибута в том порядке, в котором эти подстроки представлены в значении утверждения; (2) подстрока <initial>, если таковая присутствует, соответствует началу подготовленной строки символов в значении атрибута; (3) подстрока <final>, если таковая присутствует, соответствует окончанию подготовленной строки символов в значении атрибута. Подготовленная подстрока соответствует части подготовленной строки символов в значении атрибута, если коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения на шаге отображения регистр символов сохраняется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных символов для строк numericString.
Определение LDAP для правила соответствия numericStringSubstringsMatch:
( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
Правило numericStringSubstringsMatch является правилом соответствия substrings.
С помощью правила objectIdentifierFirstComponentMatch выполняется сравнение значения утверждения, имеющего синтаксис OID, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу, представляющему собой последовательность (SEQUENCE), в которой обязательный первый компонент имеет ASN.1-тип OBJECT IDENTIFIER. Примеры подходящих синтаксисов атрибутов LDAP: Attribute Type Description, DIT Content Rule Description, LDAP Syntax Description, Matching Rule Description, Matching Rule Use Description, Name Form Description или Object Class Description.
Обратите внимание, что синтаксис утверждения в данном правиле соответствия отличается от синтаксиса атрибутов для тех атрибутов, по отношению к которым это правило является правилом соответствия equality.
Данное правило оценивается как TRUE, если и только если значение утверждения совпадает с первым компонентом значения атрибута согласно правилу соответствия objectIdentifierMatch.
Определение LDAP для правила соответствия objectIdentifierFirstComponentMatch:
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Правило objectIdentifierFirstComponentMatch является правилом соответствия equality. При использовании objectIdentifierFirstComponentMatch для сравнения двух значений атрибутов (синтаксис которых позволяет применять это правило), значение утверждения сначала должно быть получено из значения одного из этих атрибутов. Значение утверждения может быть получено из значения атрибута путём выделения первого компонента этого значения атрибута.
С помощью правила objectIdentifierMatch выполняется сравнение значения утверждения, имеющего синтаксис OID, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу OBJECT IDENTIFIER (например, синтаксис OID).
Данное правило оценивается как TRUE, если и только если значение утверждения и значение атрибута представляют собой один и тот же идентификатор объекта; то есть, одну и ту же последовательность целых чисел <oid>, либо явно представленную в форме <numericoid>, либо неявно в форме <descr> (смотрите RFC 4512).
Если LDAP-клиент предоставил значение утверждения в форме <descr>, но выбранный дескриптор не распознан сервером, правило objectIdentifierMatch оценивается как Undefined.
Определение LDAP для правила соответствия objectIdentifierMatch:
( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Правило objectIdentifierMatch является правилом соответствия equality.
С помощью правила octetStringMatch выполняется сравнение значения утверждения, имеющего синтаксис Octet String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу OCTET STRING (например, синтаксисы Octet String или JPEG).
Данное правило оценивается как TRUE, если и только если значение атрибута и значение утверждения имеют одинаковую длину и соответствующие (по позициям) октеты совпадают.
Определение LDAP для правила соответствия octetStringMatch:
( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Правило octetStringMatch является правилом соответствия equality.
С помощью правила octetStringOrderingMatch выполняется сравнение значения утверждения, имеющего синтаксис Octet String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу OCTET STRING (например, синтаксисы Octet String или JPEG).
Данное правило оценивается как TRUE, если и только если значение атрибута располагается раньше (в порядке сопоставления), чем значение утверждения. Правило сравнивает строки октетов от первого октета до последнего, и, внутри октета, от самого старшего бита до самого младшего. Порядок следования строк определяется при нахождении первого несовпадающего бита. Бит "ноль" предшествует биту "один". Если количество октетов в строках разное, но более длинная строка идентична более короткой вплоть до окончания короткой строки, то более короткая строка предшествует более длинной.
Определение LDAP для правила соответствия octetStringOrderingMatch:
( 2.5.13.18 NAME 'octetStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Правило octetStringOrderingMatch является правилом соответствия ordering.
С помощью правила telephoneNumberMatch выполняется сравнение значения утверждения, имеющего синтаксис Telephone Number, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу PrintableString, представляющему номер телефона (например, синтаксис Telephone Number).
Данное правило оценивается как TRUE, если и только если подготовленная строка символов в значении атрибута и подготовленная строка символов в значении утверждения имеют одинаковое количество символов и коды соответствующих символов совпадают.
При подготовке значения атрибута и значения утверждения для выполнения сравнения на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных символов для строк telephoneNumber.
Определение LDAP для правила соответствия telephoneNumberMatch:
( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
Правило telephoneNumberMatch является правилом соответствия equality.
С помощью правила telephoneNumberSubstringsMatch выполняется сравнение значения утверждения, имеющего синтаксис Substring Assertion, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу PrintableString, представляющему номер телефона (например, синтаксис Telephone Number).
Данное правило оценивается как TRUE, если и только если: (1) подготовленные подстроки в значении утверждения соответствуют непересекающимся частям подготовленной строки символов в значении атрибута в том порядке, в котором эти подстроки представлены в значении утверждения; (2) подстрока <initial>, если таковая присутствует, соответствует началу подготовленной строки символов в значении атрибута; (3) подстрока <final>, если таковая присутствует, соответствует окончанию подготовленной строки символов в значении атрибута. Подготовленная подстрока соответствует части подготовленной строки символов в значении атрибута, если коды соответствующих символов совпадают.
При подготовке значения атрибута и подстрок значения утверждения для выполнения сравнения на шаге отображения регистр символов унифицируется, а на шаге обработки малозначительных символов выполняется только обработка малозначительных символов для строк telephoneNumber.
Определение LDAP для правила соответствия telephoneNumberSubstringsMatch:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
Правило telephoneNumberSubstringsMatch является правилом соответствия substrings.
С помощью правила uniqueMemberMatch выполняется сравнение значения утверждения, имеющего синтаксис Name And Optional UID, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу NameAndOptionalUID (например, синтаксис Name And Optional UID).
Данное правило оценивается как TRUE, если и только если компоненты <distinguishedName> в значении утверждения и в значении атрибута совпадают (по правилу distinguishedNameMatch), а также: либо (1) <BitString> отсутствует как в значении атрибута, так и в значении утверждения, либо (2) компонент <BitString> присутствует как в значении атрибута, так и в значении утверждения, и компонент <BitString> в значении утверждения совпадает с компонентом <BitString> в значении атрибута по правилу bitStringMatch.
Обратите внимание, что данное правило соответствия отличается от описанного в X.520 [X.520]. Изменения были внесены для того, чтобы сделать данное правило соответствия коммутативным. Разработчикам сервера следует рассмотреть возможность использования оригинальной семантики X.520 (в которой соответствие определяется менее точно), чтобы иметь возможность использовать uniqueMemberMatch как правило соответствия equality для выполнения приблизительного сравнения атрибутов.
Определение LDAP для правила соответствия uniqueMemberMatch:
( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
Правило uniqueMemberMatch является правилом соответствия equality.
С помощью правила wordMatch выполняется сравнение значения утверждения, имеющего синтаксис Directory String, со значением атрибута, имеющего синтаксис, соответствующий ASN.1-типу DirectoryString (например, синтаксис Directory String).
Данное правило оценивается как TRUE, если и только если слово в значении утверждения совпадает (по семантике правила caseIgnoreMatch) с любым словом в значении атрибута. Конкретное определение того, что является словом, отдано на откуп разработчикам реализации.
Определение LDAP для правила wordMatch:
( 2.5.13.32 NAME 'wordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
В целом, приведённая в этом документе специфичная для LDAP кодировка синтаксисов не определяет каноническое кодирование. То есть, трансформация из специфичной для LDAP кодировки в какую-то другую (например, BER) и обратно не обязательно приведёт к воспроизведению в точности последовательности байт оригинальной специфичной для LDAP кодировки. Поэтому там, где требуется каноническое кодирование, использовать специфичную для LDAP кодировку не следует.
Более того, специфичная для LDAP кодировка не всегда позволяет реконструировать альтернативные кодировки значений с синтаксисами Directory String и DN; например, трансформация из кодировки Distinguished Encoding Rules (DER) [BER] в специфичную для LDAP кодировку и обратно может не привести к воспроизведению оригинальной кодировки DER. Поэтому там, где требуется обеспечить обратимость в DER-кодировку, использовать специфичную для LDAP кодировку не следует; например, для проверки подлинности цифровых подписей. Вместо неё следует использовать DER или DER-обратимые кодировки.
При интерпретации значимых для безопасности полей (в частности, тех, которые используются для предоставления или запрета доступа), разработчики должны (MUST) убедиться, что любые сравнения по правилам соответствия производятся с первоначальным абстрактным значением, независимо от применяемой в конкретном случае кодировки.
В основном данный документ представляет собой ревизию RFC 2252, авторы M. Wahl, A. Coulbeck, T. Howes и S. Kille. RFC 2252 — продукт рабочей группы IETF ASID.
Этот документ основан на входных данных рабочей группы IETF LDAPBIS. Автор благодарит Kathy Dally за редактирование черновых материалов этого документа, а также Jim Sermersheim и Kurt Zeilenga за их значительный вклад в эту работу.
Администрация адресного пространства Интернет (Internet Assigned Numbers Authority, IANA) обновила регистр дескрипторов LDAP [BCP64] как указано в следующей форме:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment
Specification: RFC 4517
Author/Change Controller: IESG
NAME Type OID
------------------------------------------------------------------
bitStringMatch M 2.5.13.16
booleanMatch M 2.5.13.13
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseExactMatch M 2.5.13.5
caseExactOrderingMatch M 2.5.13.6
caseExactSubstringsMatch M 2.5.13.7
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
caseIgnoreListMatch M 2.5.13.11
caseIgnoreListSubstringsMatch M 2.5.13.12
caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3
caseIgnoreSubstringsMatch M 2.5.13.4
directoryStringFirstComponentMatch M 2.5.13.31
distinguishedNameMatch M 2.5.13.1
generalizedTimeMatch M 2.5.13.27
generalizedTimeOrderingMatch M 2.5.13.28
integerFirstComponentMatch M 2.5.13.29
integerMatch M 2.5.13.14
integerOrderingMatch M 2.5.13.15
keywordMatch M 2.5.13.33
numericStringMatch M 2.5.13.8
numericStringOrderingMatch M 2.5.13.9
numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17
octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32
В BCP 64 дескриптор для идентификтора объекта 2.5.13.0 был некорректно зарегистрирован как objectIdentifiersMatch (лишняя \`s'). Регистрация была изменена следующим образом (со ссылкой на RFC 4517):
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M)
Specification: RFC 4517
Author/Change Controller: IESG
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, ноябрь 2003 г.
[RFC4234] Под редакцией Crocker, D., и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, октябрь 2005 г.
[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, июнь 2006 г.
[RFC4511] Под редакцией Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.
[RFC4512] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC 4512, июнь 2006 г.
[RFC4514] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Строковое представление уникальных имён", RFC 4514, июнь 2006 г.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Подготовка интернационализированных строк", RFC 4518, июнь 2006 г.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, июнь 2006 г.
[E.123] Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988.
[FAX] Standardization of Group 3 facsimile apparatus for document transmission - Terminal Equipment and Protocols for Telematic Services, ITU-T Recommendation T.4, 1993.
[T.50] International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded Character Set for Information Interchange, ITU-T Recommendation T.50, 1992
[X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, Information Technology - Message Handling Systems (MHS): Interpersonal messaging system
[X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models
[X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types
[ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
[ISO3166] ISO 3166, "Codes for the representation of names of countries".
[ISO8601] ISO 8601:2004, "Data elements and interchange formats -- Information interchange -- Representation of dates and times".
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646- 1: 1993 (with amendments).
[JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, июнь 2006 г.
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, июнь 2006 г.[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
В следующем списке приведена сводка идентификаторов объектов, присвоенных определённым в этом документе синтаксисам:
Синтаксис Идентификатор объекта
==============================================================
Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
Bit String 1.3.6.1.4.1.1466.115.121.1.6
Boolean 1.3.6.1.4.1.1466.115.121.1.7
Country String 1.3.6.1.4.1.1466.115.121.1.11
Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
Directory String 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
DN 1.3.6.1.4.1.1466.115.121.1.12
Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Fax 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String 1.3.6.1.4.1.1466.115.121.1.26
Integer 1.3.6.1.4.1.1466.115.121.1.27
JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53
В этом приложении перечислены значимые отличия данной спецификации от RFC 2252.
Это приложение приводится только в информационных целях. Оно не является нормативной частью данной спецификации.
Steven Legg
eB2Bcom, Suite3, Woodhouse Corporate Centre, 935 Station Street, Box Hill North, Victoria 3129, AUSTRALIA
Телефон: +61 3 9896 7830
Факс: +61 3 9896 7801
EMail: steven.legg@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).