RFC4517 日本語訳
4517 Lightweight Directory Access Protocol (LDAP): Syntaxes andMatching Rules. S. Legg, Ed.. June 2006. (Format: TXT=114285 bytes) (Obsoletes RFC2252, RFC2256) (Updates RFC3698) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Legg, Ed. Request for Comments: 4517 eB2Bcom Obsoletes: 2252, 2256 June 2006 Updates: 3698 Category: Standards Track
Network Working Group S. Legg, Ed. Request for Comments: 4517 eB2Bcom Obsoletes: 2252, 2256 June 2006 Updates: 3698 Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
Abstract
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.
Table of Contents
Table of Contents
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Syntaxes ........................................................4
3.1. General Considerations .....................................5
3.2. Common Definitions .........................................5
3.3. Syntax Definitions .........................................6
3.3.1. Attribute Type Description ..........................6
3.3.2. Bit String ..........................................6
3.3.3. Boolean .............................................7
3.3.4. Country String ......................................7
3.3.5. Delivery Method .....................................8
1. Introduction ....................................................3 2. Conventions .....................................................4 3. Syntaxes ........................................................4 3.1. General Considerations .....................................5 3.2. Common Definitions .........................................5 3.3. Syntax Definitions .........................................6 3.3.1. Attribute Type Description ..........................6 3.3.2. Bit String ..........................................6 3.3.3. Boolean .............................................7 3.3.4. Country String ......................................7 3.3.5. Delivery Method .....................................8
Legg Standards Track [Page 1] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 1] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
3.3.6. Directory String ....................................8
3.3.7. DIT Content Rule Description ........................9
3.3.8. DIT Structure Rule Description .....................10
3.3.9. DN .................................................10
3.3.10. Enhanced Guide ....................................11
3.3.11. Facsimile Telephone Number ........................12
3.3.12. Fax ...............................................12
3.3.13. Generalized Time ..................................13
3.3.14. Guide .............................................14
3.3.15. IA5 String ........................................15
3.3.16. Integer ...........................................15
3.3.17. JPEG ..............................................15
3.3.18. LDAP Syntax Description ...........................16
3.3.19. Matching Rule Description .........................16
3.3.20. Matching Rule Use Description .....................17
3.3.21. Name and Optional UID .............................17
3.3.22. Name Form Description .............................18
3.3.23. Numeric String ....................................18
3.3.24. Object Class Description ..........................18
3.3.25. Octet String ......................................19
3.3.26. OID ...............................................19
3.3.27. Other Mailbox .....................................20
3.3.28. Postal Address ....................................20
3.3.29. Printable String ..................................21
3.3.30. Substring Assertion ...............................22
3.3.31. Telephone Number ..................................23
3.3.32. Teletex Terminal Identifier .......................23
3.3.33. Telex Number ......................................24
3.3.34. UTC Time ..........................................24
4. Matching Rules .................................................25
4.1. General Considerations ....................................25
4.2. Matching Rule Definitions .................................27
4.2.1. bitStringMatch .....................................27
4.2.2. booleanMatch .......................................28
4.2.3. caseExactIA5Match ..................................28
4.2.4. caseExactMatch .....................................29
4.2.5. caseExactOrderingMatch .............................29
4.2.6. caseExactSubstringsMatch ...........................30
4.2.7. caseIgnoreIA5Match .................................30
4.2.8. caseIgnoreIA5SubstringsMatch .......................31
4.2.9. caseIgnoreListMatch ................................31
4.2.10. caseIgnoreListSubstringsMatch .....................32
4.2.11. caseIgnoreMatch ...................................33
4.2.12. caseIgnoreOrderingMatch ...........................33
4.2.13. caseIgnoreSubstringsMatch .........................34
4.2.14. directoryStringFirstComponentMatch ................34
4.2.15. distinguishedNameMatch ............................35
4.2.16. generalizedTimeMatch ..............................36
3.3.6. Directory String ....................................8 3.3.7. DIT Content Rule Description ........................9 3.3.8. DIT Structure Rule Description .....................10 3.3.9. DN .................................................10 3.3.10. Enhanced Guide ....................................11 3.3.11. Facsimile Telephone Number ........................12 3.3.12. Fax ...............................................12 3.3.13. Generalized Time ..................................13 3.3.14. Guide .............................................14 3.3.15. IA5 String ........................................15 3.3.16. Integer ...........................................15 3.3.17. JPEG ..............................................15 3.3.18. LDAP Syntax Description ...........................16 3.3.19. Matching Rule Description .........................16 3.3.20. Matching Rule Use Description .....................17 3.3.21. Name and Optional UID .............................17 3.3.22. Name Form Description .............................18 3.3.23. Numeric String ....................................18 3.3.24. Object Class Description ..........................18 3.3.25. Octet String ......................................19 3.3.26. OID ...............................................19 3.3.27. Other Mailbox .....................................20 3.3.28. Postal Address ....................................20 3.3.29. Printable String ..................................21 3.3.30. Substring Assertion ...............................22 3.3.31. Telephone Number ..................................23 3.3.32. Teletex Terminal Identifier .......................23 3.3.33. Telex Number ......................................24 3.3.34. UTC Time ..........................................24 4. Matching Rules .................................................25 4.1. General Considerations ....................................25 4.2. Matching Rule Definitions .................................27 4.2.1. bitStringMatch .....................................27 4.2.2. booleanMatch .......................................28 4.2.3. caseExactIA5Match ..................................28 4.2.4. caseExactMatch .....................................29 4.2.5. caseExactOrderingMatch .............................29 4.2.6. caseExactSubstringsMatch ...........................30 4.2.7. caseIgnoreIA5Match .................................30 4.2.8. caseIgnoreIA5SubstringsMatch .......................31 4.2.9. caseIgnoreListMatch ................................31 4.2.10. caseIgnoreListSubstringsMatch .....................32 4.2.11. caseIgnoreMatch ...................................33 4.2.12. caseIgnoreOrderingMatch ...........................33 4.2.13. caseIgnoreSubstringsMatch .........................34 4.2.14. directoryStringFirstComponentMatch ................34 4.2.15. distinguishedNameMatch ............................35 4.2.16. generalizedTimeMatch ..............................36
Legg Standards Track [Page 2] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 2] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
4.2.17. generalizedTimeOrderingMatch ......................36
4.2.18. integerFirstComponentMatch ........................36
4.2.19. integerMatch ......................................37
4.2.20. integerOrderingMatch ..............................37
4.2.21. keywordMatch ......................................38
4.2.22. numericStringMatch ................................38
4.2.23. numericStringOrderingMatch ........................39
4.2.24. numericStringSubstringsMatch ......................39
4.2.25. objectIdentifierFirstComponentMatch ...............40
4.2.26. objectIdentifierMatch .............................40
4.2.27. octetStringMatch ..................................41
4.2.28. octetStringOrderingMatch ..........................41
4.2.29. telephoneNumberMatch ..............................42
4.2.30. telephoneNumberSubstringsMatch ....................42
4.2.31. uniqueMemberMatch .................................43
4.2.32. wordMatch .........................................44
5. Security Considerations ........................................44
6. Acknowledgements ...............................................44
7. IANA Considerations ............................................45
8. References .....................................................46
8.1. Normative References ......................................46
8.2. Informative References ....................................48
Appendix A. Summary of Syntax Object Identifiers ..................49
Appendix B. Changes from RFC 2252 .................................49
4.2.17. generalizedTimeOrderingMatch ......................36 4.2.18. integerFirstComponentMatch ........................36 4.2.19. integerMatch ......................................37 4.2.20. integerOrderingMatch ..............................37 4.2.21. keywordMatch ......................................38 4.2.22. numericStringMatch ................................38 4.2.23. numericStringOrderingMatch ........................39 4.2.24. numericStringSubstringsMatch ......................39 4.2.25. objectIdentifierFirstComponentMatch ...............40 4.2.26. objectIdentifierMatch .............................40 4.2.27. octetStringMatch ..................................41 4.2.28. octetStringOrderingMatch ..........................41 4.2.29. telephoneNumberMatch ..............................42 4.2.30. telephoneNumberSubstringsMatch ....................42 4.2.31. uniqueMemberMatch .................................43 4.2.32. wordMatch .........................................44 5. Security Considerations ........................................44 6. Acknowledgements ...............................................44 7. IANA Considerations ............................................45 8. References .....................................................46 8.1. Normative References ......................................46 8.2. Informative References ....................................48 Appendix A. Summary of Syntax Object Identifiers ..................49 Appendix B. Changes from RFC 2252 .................................49
1. Introduction
1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory [RFC4510], whose values may be transferred in the LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory [RFC4510], whose values may be transferred in the LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.
Readers are advised to familiarize themselves with the Directory Information Models [RFC4512] before reading the rest of this document. Section 3 provides definitions for the base set of LDAP syntaxes. Section 4 provides definitions for the base set of matching rules for LDAP.
Readers are advised to familiarize themselves with the Directory Information Models [RFC4512] before reading the rest of this document. Section 3 provides definitions for the base set of LDAP syntaxes. Section 4 provides definitions for the base set of matching rules for LDAP.
This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
Legg Standards Track [Page 3] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 3] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The remainder of RFC 2252 is obsoleted by this document. Sections 6 and 8 of RFC 2256 are obsoleted by this document. The remainder of RFC 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 of RFC 3698 is obsoleted by this document.
Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The remainder of RFC 2252 is obsoleted by this document. Sections 6 and 8 of RFC 2256 are obsoleted by this document. The remainder of RFC 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 of RFC 3698 is obsoleted by this document.
A number of schema elements that were included in the previous revision of the LDAP technical specification are not included in this revision of LDAP. Public Key Infrastructure schema elements are now specified in [RFC4523]. Unless reintroduced in future technical specifications, the remainder are to be considered Historic.
A number of schema elements that were included in the previous revision of the LDAP technical specification are not included in this revision of LDAP. Public Key Infrastructure schema elements are now specified in [RFC4523]. Unless reintroduced in future technical specifications, the remainder are to be considered Historic.
The changes with respect to RFC 2252 are described in Appendix B of this document.
The changes with respect to RFC 2252 are described in Appendix B of this document.
2. Conventions
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
Syntax definitions are written according to the <SyntaxDescription> ABNF [RFC4234] rule specified in [RFC4512], and matching rule definitions are written according to the <MatchingRuleDescription> ABNF rule specified in [RFC4512], except that the syntax and matching rule definitions provided in this document are line-wrapped for readability. When such definitions are transferred as attribute values in the LDAP protocol (e.g., as values of the ldapSyntaxes and matchingRules attributes [RFC4512], respectively), then those values would not contain line breaks.
Syntax definitions are written according to the <SyntaxDescription> ABNF [RFC4234] rule specified in [RFC4512], and matching rule definitions are written according to the <MatchingRuleDescription> ABNF rule specified in [RFC4512], except that the syntax and matching rule definitions provided in this document are line-wrapped for readability. When such definitions are transferred as attribute values in the LDAP protocol (e.g., as values of the ldapSyntaxes and matchingRules attributes [RFC4512], respectively), then those values would not contain line breaks.
3. Syntaxes
3. Syntaxes
Syntax definitions constrain the structure of attribute values stored in an LDAP directory, and determine the representation of attribute and assertion values transferred in the LDAP protocol.
Syntax definitions constrain the structure of attribute values stored in an LDAP directory, and determine the representation of attribute and assertion values transferred in the LDAP protocol.
Syntaxes that are required for directory operation, or that are in common use, are specified in this section. Servers SHOULD recognize all the syntaxes listed in this document, but are not required to otherwise support them, and MAY recognise or support other syntaxes. However, the definition of additional arbitrary syntaxes is discouraged since it will hinder interoperability. Client and server implementations typically do not have the ability to dynamically recognize new syntaxes.
Syntaxes that are required for directory operation, or that are in common use, are specified in this section. Servers SHOULD recognize all the syntaxes listed in this document, but are not required to otherwise support them, and MAY recognise or support other syntaxes. However, the definition of additional arbitrary syntaxes is discouraged since it will hinder interoperability. Client and server implementations typically do not have the ability to dynamically recognize new syntaxes.
Legg Standards Track [Page 4] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 4] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
3.1. General Considerations
3.1. General Considerations
The description of each syntax specifies how attribute or assertion values conforming to the syntax are to be represented when transferred in the LDAP protocol [RFC4511]. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values (e.g., the Basic Encoding Rules (BER) encoding [BER] used by X.500 [X.500] directories).
The description of each syntax specifies how attribute or assertion values conforming to the syntax are to be represented when transferred in the LDAP protocol [RFC4511]. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values (e.g., the Basic Encoding Rules (BER) encoding [BER] used by X.500 [X.500] directories).
The LDAP-specific encoding of a given attribute syntax always produces octet-aligned values. To the greatest extent possible, encoding rules for LDAP syntaxes should produce character strings that can be displayed with little or no translation by clients implementing LDAP. However, clients MUST NOT assume that the LDAP- specific encoding of a value of an unrecognized syntax is a human- readable character string. There are a few cases (e.g., the JPEG syntax) when it is not reasonable to produce a human-readable representation.
The LDAP-specific encoding of a given attribute syntax always produces octet-aligned values. To the greatest extent possible, encoding rules for LDAP syntaxes should produce character strings that can be displayed with little or no translation by clients implementing LDAP. However, clients MUST NOT assume that the LDAP- specific encoding of a value of an unrecognized syntax is a human- readable character string. There are a few cases (e.g., the JPEG syntax) when it is not reasonable to produce a human-readable representation.
Each LDAP syntax is uniquely identified with an object identifier [ASN.1] represented in the dotted-decimal format (short descriptive names are not defined for syntaxes). These object identifiers are not intended to be displayed to users. The object identifiers for the syntaxes defined in this document are summarized in Appendix A.
Each LDAP syntax is uniquely identified with an object identifier [ASN.1] represented in the dotted-decimal format (short descriptive names are not defined for syntaxes). These object identifiers are not intended to be displayed to users. The object identifiers for the syntaxes defined in this document are summarized in Appendix A.
A suggested minimum upper bound on the number of characters in an attribute value with a string-based syntax, or the number of octets in a value for all other syntaxes, MAY be indicated by appending the bound inside of curly braces following the syntax's OBJECT IDENTIFIER in an attribute type definition (see the <noidlen> rule in [RFC4512]). Such a bound is not considered part of the syntax identifier.
A suggested minimum upper bound on the number of characters in an attribute value with a string-based syntax, or the number of octets in a value for all other syntaxes, MAY be indicated by appending the bound inside of curly braces following the syntax's OBJECT IDENTIFIER in an attribute type definition (see the <noidlen> rule in [RFC4512]). Such a bound is not considered part of the syntax identifier.
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
definition suggests that the directory server will allow a value of
the attribute to be up to 64 characters long, although it may allow
longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet, since
UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64-
character string may be more than 64 octets in length.
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute definition suggests that the directory server will allow a value of the attribute to be up to 64 characters long, although it may allow longer character strings. Note that a single character of the Directory String syntax can be encoded in more than one octet, since UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64- character string may be more than 64 octets in length.
3.2. Common Definitions
3.2. Common Definitions
The following ABNF rules are used in a number of the syntax definitions in Section 3.3.
The following ABNF rules are used in a number of the syntax definitions in Section 3.3.
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA / HYPHEN / DOT / EQUALS /
Legg Standards Track [Page 5] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 5] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
SLASH / COLON / QUESTION / SPACE PrintableString = 1*PrintableCharacter IA5String = *(%x00-7F) SLASH = %x2F ; forward slash ("/") COLON = %x3A ; colon (":") QUESTION = %x3F ; question mark ("?")
The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in [RFC4512].
The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in [RFC4512].
3.3. Syntax Definitions
3.3. Syntax Definitions
3.3.1. Attribute Type Description
3.3.1. Attribute Type Description
A value of the Attribute Type Description syntax is the definition of an attribute type. The LDAP-specific encoding of a value of this syntax is defined by the <AttributeTypeDescription> rule in [RFC4512].
A value of the Attribute Type Description syntax is the definition of an attribute type. The LDAP-specific encoding of a value of this syntax is defined by the <AttributeTypeDescription> rule in [RFC4512].
For example, the following definition of the createTimestamp
attribute type from [RFC4512] is also a value of the Attribute
Type Description syntax. (Note: Line breaks have been added for
readability; they are not part of the value when transferred in
protocol.)
For example, the following definition of the createTimestamp attribute type from [RFC4512] is also a value of the Attribute Type Description syntax. (Note: Line breaks have been added for readability; they are not part of the value when transferred in protocol.)
( 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 )
( 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 )
The LDAP definition for the Attribute Type Description syntax is:
The LDAP definition for the Attribute Type Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
This syntax corresponds to the AttributeTypeDescription ASN.1 type from [X.501].
This syntax corresponds to the AttributeTypeDescription ASN.1 type from [X.501].
3.3.2. Bit String
3.3.2. Bit String
A value of the Bit String syntax is a sequence of binary digits. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
A value of the Bit String syntax is a sequence of binary digits. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"
BitString = SQUOTE *binary-digit SQUOTE "B" binary-digit = "0" / "1"
Legg Standards Track [Page 6] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 6] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The <SQUOTE> rule is defined in [RFC4512].
The <SQUOTE> rule is defined in [RFC4512].
Example:
'0101111101'B
Example: '0101111101'B
The LDAP definition for the Bit String syntax is:
The LDAP definition for the Bit String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
3.3.3. Boolean
3.3.3. Boolean
A value of the Boolean syntax is one of the Boolean values, true or false. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
A value of the Boolean syntax is one of the Boolean values, true or false. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
Boolean = "TRUE" / "FALSE"
Boolean = "TRUE" / "FALSE"
The LDAP definition for the Boolean syntax is:
The LDAP definition for the Boolean syntax is:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
3.3.4. Country String
3.3.4. Country String
A value of the Country String syntax is one of the two-character codes from ISO 3166 [ISO3166] for representing a country. The LDAP- specific encoding of a value of this syntax is defined by the following ABNF:
A value of the Country String syntax is one of the two-character codes from ISO 3166 [ISO3166] for representing a country. The LDAP- specific encoding of a value of this syntax is defined by the following ABNF:
CountryString = 2(PrintableCharacter)
CountryString = 2(PrintableCharacter)
The <PrintableCharacter> rule is defined in Section 3.2.
The <PrintableCharacter> rule is defined in Section 3.2.
Examples:
Examples:
US
AU
US AU
The LDAP definition for the Country String syntax is:
The LDAP definition for the Country String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
This syntax corresponds to the following ASN.1 type from [X.520]:
This syntax corresponds to the following ASN.1 type from [X.520]:
PrintableString (SIZE (2)) -- ISO 3166 codes only
PrintableString (SIZE (2)) -- ISO 3166 codes only
Legg Standards Track [Page 7] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 7] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
3.3.5. Delivery Method
3.3.5. Delivery Method
A value of the Delivery Method syntax is a sequence of items that indicate, in preference order, the service(s) by which an entity is willing and/or capable of receiving messages. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
A value of the Delivery Method syntax is a sequence of items that indicate, in preference order, the service(s) by which an entity is willing and/or capable of receiving messages. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
The <WSP> and <DOLLAR> rules are defined in [RFC4512].
The <WSP> and <DOLLAR> rules are defined in [RFC4512].
Example:
telephone $ videotex
Example: telephone $ videotex
The LDAP definition for the Delivery Method syntax is:
The LDAP definition for the Delivery Method syntax is:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
This syntax corresponds to the following ASN.1 type from [X.520]:
This syntax corresponds to the following ASN.1 type from [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) }
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) }
3.3.6. Directory String
3.3.6. Directory String
A value of the Directory String syntax is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS]. A zero-length character string is not permitted. The LDAP-specific encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of the character string. Such encodings conform to the following ABNF:
A value of the Directory String syntax is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS]. A zero-length character string is not permitted. The LDAP-specific encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of the character string. Such encodings conform to the following ABNF:
DirectoryString = 1*UTF8
DirectoryString = 1*UTF8
The <UTF8> rule is defined in [RFC4512].
The <UTF8> rule is defined in [RFC4512].
Legg Standards Track [Page 8] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 8] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Example:
This is a value of Directory String containing #!%#@.
Example: This is a value of Directory String containing #!%#@.
Servers and clients MUST be prepared to receive arbitrary UCS code points, including code points outside the range of printable ASCII and code points not presently assigned to any character.
Servers and clients MUST be prepared to receive arbitrary UCS code points, including code points outside the range of printable ASCII and code points not presently assigned to any character.
Attribute type definitions using the Directory String syntax should not restrict the format of Directory String values, e.g., by requiring that the character string conforms to specific patterns described by ABNF. A new syntax should be defined in such cases.
Attribute type definitions using the Directory String syntax should not restrict the format of Directory String values, e.g., by requiring that the character string conforms to specific patterns described by ABNF. A new syntax should be defined in such cases.
The LDAP definition for the Directory String syntax is:
The LDAP definition for the Directory String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
This syntax corresponds to the DirectoryString parameterized ASN.1 type from [X.520].
This syntax corresponds to the DirectoryString parameterized ASN.1 type from [X.520].
The DirectoryString ASN.1 type allows a choice between the TeletexString, PrintableString, or UniversalString ASN.1 types from [ASN.1]. However, note that the chosen alternative is not indicated in the LDAP-specific encoding of a Directory String value.
The DirectoryString ASN.1 type allows a choice between the TeletexString, PrintableString, or UniversalString ASN.1 types from [ASN.1]. However, note that the chosen alternative is not indicated in the LDAP-specific encoding of a Directory String value.
Implementations that convert Directory String values from the LDAP- specific encoding to the BER encoding used by X.500 must choose an alternative that permits the particular characters in the string and must convert the characters from the UTF-8 encoding into the character encoding of the chosen alternative. When converting Directory String values from the BER encoding to the LDAP-specific encoding, the characters must be converted from the character encoding of the chosen alternative into the UTF-8 encoding. These conversions SHOULD be done in a manner consistent with the Transcode step of the string preparation algorithms [RFC4518] for LDAP.
Implementations that convert Directory String values from the LDAP- specific encoding to the BER encoding used by X.500 must choose an alternative that permits the particular characters in the string and must convert the characters from the UTF-8 encoding into the character encoding of the chosen alternative. When converting Directory String values from the BER encoding to the LDAP-specific encoding, the characters must be converted from the character encoding of the chosen alternative into the UTF-8 encoding. These conversions SHOULD be done in a manner consistent with the Transcode step of the string preparation algorithms [RFC4518] for LDAP.
3.3.7. DIT Content Rule Description
3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition of a DIT (Directory Information Tree) content rule. The LDAP- specific encoding of a value of this syntax is defined by the <DITContentRuleDescription> rule in [RFC4512].
A value of the DIT Content Rule Description syntax is the definition of a DIT (Directory Information Tree) content rule. The LDAP- specific encoding of a value of this syntax is defined by the <DITContentRuleDescription> rule in [RFC4512].
Example:
( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )
Example: ( 2.5.6.4 DESC 'content rule for organization' NOT ( x121Address $ telexNumber ) )
Note: A line break has been added for readability; it is not part
of the value.
Note: A line break has been added for readability; it is not part of the value.
Legg Standards Track [Page 9] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 9] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The LDAP definition for the DIT Content Rule Description syntax is:
The LDAP definition for the DIT Content Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' )
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' )
This syntax corresponds to the DITContentRuleDescription ASN.1 type from [X.501].
This syntax corresponds to the DITContentRuleDescription ASN.1 type from [X.501].
3.3.8. DIT Structure Rule Description
3.3.8. DIT Structure Rule Description
A value of the DIT Structure Rule Description syntax is the definition of a DIT structure rule. The LDAP-specific encoding of a value of this syntax is defined by the <DITStructureRuleDescription> rule in [RFC4512].
A value of the DIT Structure Rule Description syntax is the definition of a DIT structure rule. The LDAP-specific encoding of a value of this syntax is defined by the <DITStructureRuleDescription> rule in [RFC4512].
Example:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
Example: ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
The LDAP definition for the DIT Structure Rule Description syntax is:
The LDAP definition for the DIT Structure Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.17
DESC 'DIT Structure Rule Description' )
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' )
This syntax corresponds to the DITStructureRuleDescription ASN.1 type from [X.501].
This syntax corresponds to the DITStructureRuleDescription ASN.1 type from [X.501].
3.3.9. DN
3.3.9. DN
A value of the DN syntax is the (purported) distinguished name (DN) of an entry [RFC4512]. The LDAP-specific encoding of a value of this syntax is defined by the <distinguishedName> rule from the string representation of distinguished names [RFC4514].
A value of the DN syntax is the (purported) distinguished name (DN) of an entry [RFC4512]. The LDAP-specific encoding of a value of this syntax is defined by the <distinguishedName> rule from the string representation of distinguished names [RFC4514].
Examples (from [RFC4514]):
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%%BODY%%dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
Examples (from [RFC4514]): 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%%BODY%%dAfter,DC=example,DC=net 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com CN=Lu\C4\8Di\C4\87
The LDAP definition for the DN syntax is:
The LDAP definition for the DN syntax is:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
The DN syntax corresponds to the DistinguishedName ASN.1 type from [X.501]. Note that a BER encoded distinguished name (as used by X.500) re-encoded into the LDAP-specific encoding is not necessarily
The DN syntax corresponds to the DistinguishedName ASN.1 type from [X.501]. Note that a BER encoded distinguished name (as used by X.500) re-encoded into the LDAP-specific encoding is not necessarily
Legg Standards Track [Page 10] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 10] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
reversible to the original BER encoding since the chosen string type in any DirectoryString components of the distinguished name is not indicated in the LDAP-specific encoding of the distinguished name (see Section 3.3.6).
reversible to the original BER encoding since the chosen string type in any DirectoryString components of the distinguished name is not indicated in the LDAP-specific encoding of the distinguished name (see Section 3.3.6).
3.3.10. Enhanced Guide
3.3.10. Enhanced Guide
A value of the Enhanced Guide syntax suggests criteria, which consist of combinations of attribute types and filter operators, to be used in constructing filters to search for entries of particular object classes. The Enhanced Guide syntax improves upon the Guide syntax by allowing the recommended depth of the search to be specified.
A value of the Enhanced Guide syntax suggests criteria, which consist of combinations of attribute types and filter operators, to be used in constructing filters to search for entries of particular object classes. The Enhanced Guide syntax improves upon the Guide syntax by allowing the recommended depth of the search to be specified.
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
EnhancedGuide = object-class SHARP WSP criteria WSP
SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
EnhancedGuideは物クラスSHARP WSP評価基準WSP SHARP WSP部分集合物クラス=WSP oid WSP部分集合="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 ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark ("!")
そして、そして、そして、「評価基準が等しい、-、用語、*、(BAR、-、用語、)、-、用語、=用語*(AMPERSAND用語) 本当の、または、LPAREN評価基準RPAREN/偽のマッチ用語=EXCLAIM attributetype DOLLARマッチ用語/タイプ/タイプは「「約」というEQの」 /"SUBSTR"/「ゲー」/"LE"/本当の=」と等しいです--本当」であるという誤った=」 偽」 バー=%x7C。 縦棒、(「|」、)、アンパーサンド=%x26。 (“&")が%x21と等しいと主張するアンパーサンド。 感嘆符("!")
The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and <DOLLAR> rules are defined in [RFC4512].
<シャープ>、<WSP>、<oid>、<LPAREN>、<RPAREN>、<attributetype>、および<DOLLAR>規則は[RFC4512]で定義されます。
The LDAP definition for the Enhanced Guide syntax is:
Enhancedガイド構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
(1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.21DESC'高められたガイド')
Example:
person#(sn$EQ)#oneLevel
例: 人#(sn$EQ)の#oneLevel
The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type from [X.520]. The EnhancedGuide type references the Criteria ASN.1 type, also from [X.520]. The <true> rule, above, represents an empty
Enhancedガイド構文は[X.520]からEnhancedGuide ASN.1タイプに文通されます。 EnhancedGuideは[X.520]からもCriteria ASN.1がタイプする参照をタイプします。 上の<正しい>規則が表す、空
Legg Standards Track [Page 11] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[11ページ]: 構文と2006年6月に規則を合わせること。
"and" expression in a value of the Criteria type. The <false> rule, above, represents an empty "or" expression in a value of the Criteria type.
Criteriaタイプの値における"and"表現。 <の誤った>規則は上にCriteriaタイプの値における空の“or"表現を表します。
3.3.11. Facsimile Telephone Number
3.3.11. ファクシミリ電話番号
A value of the Facsimile Telephone Number syntax is a subscriber number of a facsimile device on the public switched telephone network. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
Facsimile Telephone Number構文の値は公衆電話交換網のファクシミリ装置の加入者番号です。 この構文の価値のLDAP特有のコード化は以下のABNFによって定義されます:
fax-number = telephone-number *( DOLLAR fax-parameter )
telephone-number = PrintableString
fax-parameter = "twoDimensional" /
"fineResolution" /
"unlimitedLength" /
"b4Length" /
"a3Width" /
"b4Width" /
"uncompressed"
ファックス番号は電話番号*(DOLLARファックスパラメタ)電話番号=PrintableStringファックスパラメタと="twoDimensional"/"fineResolution"/"unlimitedLength"/"b4Length"/"a3Width"/"b4Width"/「解凍されていた」状態で等しいです。
The <telephone-number> is a string of printable characters that complies with the internationally agreed format for representing international telephone numbers [E.123]. The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<電話番号>は国際電話番号[E.123]を表すための国際的に同意された形式に従う一連の印刷可能なキャラクタです。 <PrintableString>規則はセクション3.2で定義されます。 <DOLLAR>規則は[RFC4512]で定義されます。
The LDAP definition for the Facsimile Telephone Number syntax is:
Facsimile Telephone Number構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
(1.3.6.1.4.1.1466.115.121.1.22DESC'ファクシミリ電話番号')
The Facsimile Telephone Number syntax corresponds to the FacsimileTelephoneNumber ASN.1 type from [X.520].
Facsimile Telephone Number構文は[X.520]からFacsimileTelephoneNumber ASN.1タイプに文通されます。
3.3.12. Fax
3.3.12. ファックス
A value of the Fax syntax is an image that is produced using the Group 3 facsimile process [FAX] to duplicate an object, such as a memo. The LDAP-specific encoding of a value of this syntax is the string of octets for a Group 3 Fax image as defined in [FAX].
ファックス構文の値は物をコピーするのに、Group3電送の過程[FAX]を使用することで作り出されるイメージです、メモのように。 この構文の価値のLDAP特有のコード化は[FAX]で定義されるようにGroup3ファックスイメージのための八重奏のストリングです。
The LDAP definition for the Fax syntax is:
ファックス構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
(1.3.6.1.4.1.1466.115.121.1.23DESC'ファックス')
The ASN.1 type corresponding to the Fax syntax is defined as follows, assuming EXPLICIT TAGS:
EXPLICIT TAGSを仮定して、ファックス構文に対応するASN.1タイプは以下の通り定義されます:
Legg Standards Track [Page 12] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[12ページ]: 構文と2006年6月に規則を合わせること。
Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
ファックスで、以下を送ってください:= 選択g3-ファクシミリ[3]G3FacsimileBodyPart
The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
G3FacsimileBodyPart ASN.1タイプは[X.420]で定義されます。
3.3.13. Generalized Time
3.3.13. 一般化された時間
A value of the Generalized Time syntax is a character string representing a date and time. The LDAP-specific encoding of a value of this syntax is a restriction of the format defined in [ISO8601], and is described by the following ABNF:
Generalized Time構文の値は日時を表す文字列です。 この構文の価値のLDAP特有のコード化は、[ISO8601]で定義された書式の制限であり、以下のABNFによって説明されます:
GeneralizedTime = century year month day hour
[ minute [ second / leap-second ] ]
[ fraction ]
g-time-zone
GeneralizedTimeは世紀月の日の[分[秒/閏秒]]一時間の年[断片]のg-時間帯と等しいです。
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59"
世紀=2(%x30-39)。 「「99インチの年は2(%x30-39)と等しいこと」への0インチ 「0インチから「99インチの月=(%x30%x31-39)」 「1インチ(1月)から「9インチ/(%x31%x30-32)」 「10インチから「12インチの日=(%x30%x31-39)」 「1インチから「9インチ/(%x31-32%x30-39)」 「10インチから「29インチ/(%x33%x30-31)」 「「31インチの時間=(%x30-31%x30-39)/(%x32%x30-33)」への30インチ 「0インチから「23インチの微小な=%x30-35%x30-39」 「0インチから「59インチ」
second = ( %x30-35 %x30-39 ) ; "00" to "59"
leap-second = ( %x36 %x30 ) ; "60"
秒=(%x30-35%x30-39)。 「「59インチ閏秒=(%x36%x30)」への0インチ "60"
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")
断片=(DOT / COMMA)1*(%x30-39)g-時間帯=%x5A。 g「Z」/特異なg特異な=(MINUS / PLUS)時間[微小な]MINUS=%x2D。 マイナス記号("-")
The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
<DOT>、<COMMA>、および<PLUS>規則は[RFC4512]で定義されます。
The above ABNF allows character strings that do not represent valid dates (in the Gregorian calendar) and/or valid times (e.g., February 31, 1994). Such character strings SHOULD be considered invalid for this syntax.
上のABNFは有効な期日(グレゴリオ暦における)、そして/または、有効な回(例えば、1994年2月31日)を表さない文字列を許容します。 この構文に無効の状態で考えられて、そのようなキャラクタはSHOULDを結びます。
The time value represents coordinated universal time (equivalent to Greenwich Mean Time) if the "Z" form of <g-time-zone> is used; otherwise, the value represents a local time in the time zone indicated by <g-differential>. In the latter case, coordinated
「Z」という<のg-時間帯の>のフォームが使用されているなら、時間的価値は連携ユニバーサルタイム(グリニッジ標準時に同等な)を表します。 さもなければ、値は<g特異な>によって示された時間帯における現地時間の1時を表します。 後者のケースと、連携で
Legg Standards Track [Page 13] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[13ページ]: 構文と2006年6月に規則を合わせること。
universal time can be calculated by subtracting the differential from the local time. The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential>.
現地時間からデフ装置を引き算することによって、ユニバーサルタイムについて計算できます。 「Z」という<のg-時間帯の>のフォームは<g特異な>に優先して使用されるべきです。
If <minute> is omitted, then <fraction> represents a fraction of an hour; otherwise, if <second> and <leap-second> are omitted, then <fraction> represents a fraction of a minute; otherwise, <fraction> represents a fraction of a second.
<の微小な>が省略されるなら、<断片>は1時間の何分の一を表します。 さもなければ、<の2番目の>と<閏秒>が省略されるなら、<断片>は1分の何分の一を表します。 さもなければ、<断片>は1秒の何分の一を表します。
Examples:
199412161032Z
199412160532-0500
例: 199412161032Z199412160532-0500
Both example values represent the same coordinated universal time: 10:32 AM, December 16, 1994.
両方の例の値は同じ連携ユニバーサルタイムを表します: 1994年12月16日の午前10時32分。
The LDAP definition for the Generalized Time syntax is:
Generalized Time構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
(1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.24DESCが'時間を一般化した'、)
This syntax corresponds to the GeneralizedTime ASN.1 type from [ASN.1], with the constraint that local time without a differential SHALL NOT be used.
この構文は使用されて、.1が規制で[ASN.1]からタイプするGeneralizedTime ASNに対応しています。
3.3.14. Guide
3.3.14. ガイド
A value of the Guide syntax suggests criteria, which consist of combinations of attribute types and filter operators, to be used in constructing filters to search for entries of particular object classes. The Guide syntax is obsolete and should not be used for defining new attribute types.
ガイド構文の値は評価基準を示します。(評価基準は、特定の物のクラスのエントリーを捜し求めるためにフィルタを組み立てる際に使用されるために属性タイプとフィルタオペレータの組み合わせから成ります)。 ガイド構文を時代遅れであり、新しい属性タイプを定義するのに使用するべきではありません。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の価値のLDAP特有のコード化は以下のABNFによって定義されます:
Guide = [ object-class SHARP ] criteria
ガイド=[物クラスシャープ]評価基準
The <object-class> and <criteria> rules are defined in Section 3.3.10. The <SHARP> rule is defined in [RFC4512].
<物クラス>と評価基準>が統治する<はセクション3.3.10で定義されます。 <シャープ>規則は[RFC4512]で定義されます。
The LDAP definition for the Guide syntax is:
ガイド構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
(1.3、'誘導.6.1.4.1.1466.115.121.1.25DESC')
The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
ガイド構文は[X.520]からガイドASN.1タイプに文通されます。
Legg Standards Track [Page 14] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[14ページ]: 構文と2006年6月に規則を合わせること。
3.3.15. IA5 String
3.3.15. IA5ストリング
A value of the IA5 String syntax is a string of zero, one, or more characters from International Alphabet 5 (IA5) [T.50], the international version of the ASCII character set. The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <IA5String> rule in Section 3.2.
IA5 String構文の値は一連のゼロです、国際Alphabet5(IA5)[T.50]からの1つ以上のキャラクタ、ASCII文字の組の国際的なバージョン。 この構文の価値のLDAP特有のコード化はキャラクタの非変換されたストリングです。(そのストリングはセクション3.2の<IA5String>規則に一致しています)。
The LDAP definition for the IA5 String syntax is:
IA5 String構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
(1.3.6.1.4.1.1466.115.121.1.26DESC'IA5ストリング')
This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
この構文は[ASN.1]からIA5String ASN.1タイプに文通されます。
3.3.16. Integer
3.3.16. 整数
A value of the Integer syntax is a whole number of unlimited magnitude. The LDAP-specific encoding of a value of this syntax is the optionally signed decimal digit character string representation of the number (for example, the number 1321 is represented by the character string "1321"). The encoding is defined by the following ABNF:
Integer構文の値は無制限な大きさの整数です。 この構文の価値のLDAP特有のコード化は数の任意にサインされた10進数字文字列表現(例えば、No.1321は文字列「1321」によって表される)です。 コード化は以下のABNFによって定義されます:
Integer = ( HYPHEN LDIGIT *DIGIT ) / number
整数=(HYPHEN LDIGIT*DIGIT)/番号
The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in [RFC4512].
<HYPHEN>、<LDIGIT>、<DIGIT>、および<数の>規則は[RFC4512]で定義されます。
The LDAP definition for the Integer syntax is:
Integer構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
(1.3.6.1.4.1.1466.115.121.1.27DESC'整数')
This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
この構文は[ASN.1]からINTEGER ASN.1タイプに文通されます。
3.3.17. JPEG
3.3.17. JPEG
A value of the JPEG syntax is an image in the JPEG File Interchange Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of a value of this syntax is the sequence of octets of the JFIF encoding of the image.
JPEG構文の値は[JPEG]で説明されるようにJPEG File Interchange Format(JFIF)のイメージです。 この構文の価値のLDAP特有のコード化はイメージのJFIFコード化の八重奏の系列です。
The LDAP definition for the JPEG syntax is:
JPEG構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
(1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.28DESC'JPEG')
The JPEG syntax corresponds to the following ASN.1 type:
JPEG構文は以下のASN.1タイプに文通されます:
Legg Standards Track [Page 15] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[15ページ]: 構文と2006年6月に規則を合わせること。
JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- contents octets are an image in the --
-- JPEG File Interchange Format -- })
JPEG:、:= 八重奏ストリング(CONSTRAINED BY、--、コンテンツ八重奏が中のイメージである--、--JPEG File Interchange Format--、)
3.3.18. LDAP Syntax Description
3.3.18. LDAP構文記述
A value of the LDAP Syntax Description syntax is the description of an LDAP syntax. The LDAP-specific encoding of a value of this syntax is defined by the <SyntaxDescription> rule in [RFC4512].
LDAP Syntax記述構文の値はLDAP構文の記述です。 この構文の価値のLDAP特有のコード化は[RFC4512]の<SyntaxDescription>規則で定義されます。
The LDAP definition for the LDAP Syntax Description syntax is:
LDAP Syntax記述構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
(1.3.6.1.4.1.1466.115.121.1.54DESC'LDAP構文記述')
The above LDAP definition for the LDAP Syntax Description syntax is itself a legal value of the LDAP Syntax Description syntax.
LDAP Syntax記述構文のための上のLDAP定義はそれ自体でLDAP Syntax記述構文の法定価格です。
The ASN.1 type corresponding to the LDAP Syntax Description syntax is defined as follows, assuming EXPLICIT TAGS:
EXPLICIT TAGSを仮定して、LDAP Syntax記述構文に対応するASN.1タイプは以下の通り定義されます:
LDAPSyntaxDescription ::= SEQUENCE {
identifier OBJECT IDENTIFIER,
description DirectoryString { ub-schema } OPTIONAL }
LDAPSyntaxDescription:、:= 系列識別子OBJECT IDENTIFIER、記述DirectoryString ub-図式OPTIONAL
The DirectoryString parameterized ASN.1 type is defined in [X.520].
DirectoryString parameterized ASN.1タイプは[X.520]で定義されます。
The value of ub-schema (an integer) is implementation defined. A non-normative definition appears in [X.520].
ub-図式(整数)の値は定義された実現です。 非標準の定義は[X.520]に現れます。
3.3.19. Matching Rule Description
3.3.19. 合っている規則記述
A value of the Matching Rule Description syntax is the definition of a matching rule. The LDAP-specific encoding of a value of this syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
Matching Rule記述構文の値は合っている規則の定義です。 この構文の価値のLDAP特有のコード化は[RFC4512]の<MatchingRuleDescription>規則で定義されます。
Example:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
例: (2.5.13.2名'caseIgnoreMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.15)
Note: A line break has been added for readability; it is not part of the syntax.
以下に注意してください。 ラインブレイクは読み易さのために加えられます。 それは構文の一部ではありません。
The LDAP definition for the Matching Rule Description syntax is:
Matching Rule記述構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
(1.3に、.6.1.4.1.1466.115.121.1.30DESC'マッチングが記述を統治する、'、)
This syntax corresponds to the MatchingRuleDescription ASN.1 type from [X.501].
この構文は[X.501]からMatchingRuleDescription ASN.1タイプに文通されます。
Legg Standards Track [Page 16] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[16ページ]: 構文と2006年6月に規則を合わせること。
3.3.20. Matching Rule Use Description
3.3.20. マッチング規則は記述を使用します。
A value of the Matching Rule Use Description syntax indicates the attribute types to which a matching rule may be applied in an extensibleMatch search filter [RFC4511]. The LDAP-specific encoding of a value of this syntax is defined by the <MatchingRuleUseDescription> rule in [RFC4512].
Matching Rule Use記述構文の値は合っている規則がextensibleMatch検索フィルタ[RFC4511]で適用されるかもしれない属性タイプを示します。 この構文の価値のLDAP特有のコード化は[RFC4512]の<MatchingRuleUseDescription>規則で定義されます。
Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) )
例: (2.5.13.16APPLIES(givenName$姓))
The LDAP definition for the Matching Rule Use Description syntax is:
Matching Rule Use記述構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' )
(.6.1.4.1.1466.115.121.1.31DESC'マッチングが統治する1.3が記述を使用する、'、)
This syntax corresponds to the MatchingRuleUseDescription ASN.1 type from [X.501].
この構文は[X.501]からMatchingRuleUseDescription ASN.1タイプに文通されます。
3.3.21. Name and Optional UID
3.3.21. 名前と任意のUID
A value of the Name and Optional UID syntax is the distinguished name [RFC4512] of an entity optionally accompanied by a unique identifier that serves to differentiate the entity from others with an identical distinguished name.
NameとOptional UID構文の値は同じ分類名で他のものと実体を区別するのに役立つユニークな識別子によって任意に伴われた実体の分類名[RFC4512]です。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の価値のLDAP特有のコード化は以下のABNFによって定義されます:
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
NameAndOptionalUIDはdistinguishedNameと等しいです。[鋭いBitString]
The <BitString> rule is defined in Section 3.3.2. The <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule is defined in [RFC4512].
<BitString>規則はセクション3.3.2で定義されます。 <distinguishedName>規則は[RFC4514]で定義されます。 <シャープ>規則は[RFC4512]で定義されます。
Note that although the '#' character may occur in the string representation of a distinguished name, no additional escaping of this character is performed when a <distinguishedName> is encoded in a <NameAndOptionalUID>.
'#'キャラクタが分類名のストリング表現で起こるかもしれませんが、<distinguishedName>が<NameAndOptionalUID>でコード化されるときこのキャラクタの追加エスケープでないのが実行されることに注意してください。
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
例: ○ = 1.3.6.1.4.1.1466.0は#04024869、と等しく、テスト、CはGB#'0101'Bと等しいです。
The LDAP definition for the Name and Optional UID syntax is:
NameとOptional UID構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
(1.3の.6.1.4.1.1466.115.121.1.34DESC'名の、そして、任意のUID、'、)
Legg Standards Track [Page 17] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[17ページ]: 構文と2006年6月に規則を合わせること。
This syntax corresponds to the NameAndOptionalUID ASN.1 type from [X.520].
この構文は[X.520]からNameAndOptionalUID ASN.1タイプに文通されます。
3.3.22. Name Form Description
3.3.22. 名前フォーム記述
A value of the Name Form Description syntax is the definition of a name form, which regulates how entries may be named. The LDAP- specific encoding of a value of this syntax is defined by the <NameFormDescription> rule in [RFC4512].
Name Form記述構文の値は名前形式の定義です。(それは、エントリーがどう命名されるかもしれないかを規制します)。 この構文の価値のLDAPの特定のコード化は[RFC4512]の<NameFormDescription>規則で定義されます。
Example:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
例: (2.5.15.3NAME'orgNameForm'OC組織がそうしなければならない、o)
The LDAP definition for the Name Form Description syntax is:
Name Form記述構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
(1.3.6.1.4.1.1466.115.121.1.35DESC'名が記述を形成する、'、)
This syntax corresponds to the NameFormDescription ASN.1 type from [X.501].
この構文は[X.501]からNameFormDescription ASN.1タイプに文通されます。
3.3.23. Numeric String
3.3.23. 数値ストリング
A value of the Numeric String syntax is a sequence of one or more numerals and spaces. The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the following ABNF:
Numeric String構文の値は1つ以上の数字と空間の系列です。 この構文の価値のLDAP特有のコード化はキャラクタの非変換されたストリングです:(それは、以下のABNFに一致しています)。
NumericString = 1*(DIGIT / SPACE)
NumericString=1*(ケタ/スペース)
The <DIGIT> and <SPACE> rules are defined in [RFC4512].
<DIGIT>と<SPACE>規則は[RFC4512]で定義されます。
Example:
15 079 672 281
例: 15 079 672 281
The LDAP definition for the Numeric String syntax is:
Numeric String構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
(1.3.6.1.4.1.1466.115.121.1.36DESC'数値ストリング')
This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
この構文は[ASN.1]からNumericString ASN.1タイプに文通されます。
3.3.24. Object Class Description
3.3.24. 物のクラス記述
A value of the Object Class Description syntax is the definition of an object class. The LDAP-specific encoding of a value of this syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
Object Class記述構文の値は物のクラスの定義です。 この構文の価値のLDAP特有のコード化は[RFC4512]の<ObjectClassDescription>規則で定義されます。
Legg Standards Track [Page 18] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[18ページ]: 構文と2006年6月に規則を合わせること。
Example:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) )
例: (2.5.6.2NAME'国'SUPの最高STRUCTURAL MUST c5月(searchGuide$記述))
Note: A line break has been added for readability; it is not part of the syntax.
以下に注意してください。 ラインブレイクは読み易さのために加えられます。 それは構文の一部ではありません。
The LDAP definition for the Object Class Description syntax is:
Object Class記述構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
(1.3.6.1.4.1.1466.115.121.1.37DESC'物が記述を分類する、'、)
This syntax corresponds to the ObjectClassDescription ASN.1 type from [X.501].
この構文は[X.501]からObjectClassDescription ASN.1タイプに文通されます。
3.3.25. Octet String
3.3.25. 八重奏ストリング
A value of the Octet String syntax is a sequence of zero, one, or more arbitrary octets. The LDAP-specific encoding of a value of this syntax is the unconverted sequence of octets, which conforms to the following ABNF:
Octet String構文の値はゼロ、1つ以上の任意の八重奏の系列です。 この構文の価値のLDAP特有のコード化は八重奏の非変換された系列です:(それは、以下のABNFに従います)。
OctetString = *OCTET
OctetStringは*八重奏と等しいです。
The <OCTET> rule is defined in [RFC4512]. Values of this syntax are not generally human-readable.
<OCTET>規則は[RFC4512]で定義されます。 一般に、この構文の値は人間読み込み可能ではありません。
The LDAP definition for the Octet String syntax is:
Octet String構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
(1.3.6.1.4.1.1466.115.121.1.40DESC'八重奏ストリング')
This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
この構文は[ASN.1]からOCTET STRING ASN.1タイプに文通されます。
3.3.26. OID
3.3.26. OID
A value of the OID syntax is an object identifier: a sequence of two or more non-negative integers that uniquely identify some object or item of specification. Many of the object identifiers used in LDAP also have IANA registered names [RFC4520].
OID構文の値は物の識別子です: 唯一仕様に関する、ある物か条項を特定する2つ以上の非負の整数の系列。 また、LDAPで使用される物の識別子の多くには、IANA登録名[RFC4520]があります。
The LDAP-specific encoding of a value of this syntax is defined by the <oid> rule in [RFC4512].
この構文の価値のLDAP特有のコード化は[RFC4512]の<oid>規則で定義されます。
Examples:
1.2.3.4
cn
例: 1.2.3.4 cn
The LDAP definition for the OID syntax is:
OID構文のためのLDAP定義は以下の通りです。
Legg Standards Track [Page 19] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[19ページ]: 構文と2006年6月に規則を合わせること。
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
(1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.38DESC'OID')
This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from [ASN.1].
この構文は[ASN.1]からOBJECT IDENTIFIER ASN.1タイプに文通されます。
3.3.27. Other Mailbox
3.3.27. 他のメールボックス
A value of the Other Mailbox syntax identifies an electronic mailbox, in a particular named mail system. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
Other Mailbox構文の値は特定の命名されたメールシステムでメールボックスを特定します。 この構文の価値のLDAP特有のコード化は以下のABNFによって定義されます:
OtherMailbox = mailbox-type DOLLAR mailbox
mailbox-type = PrintableString
mailbox = IA5String
メールボックスタイプDOLLARメールボックスメールボックスOtherMailbox=タイプはPrintableStringメールボックス=IA5Stringと等しいです。
The <mailbox-type> rule represents the type of mail system in which the mailbox resides (for example, "MCIMail"), and <mailbox> is the actual mailbox in the mail system described by <mailbox-type>. The <PrintableString> and <IA5String> rules are defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<メールボックスタイプ>は、メールボックスが住んでいるメールシステム(例えば、"MCIMail")のタイプが表すと裁決します、そして、<メールボックス>は<メールボックスタイプ>によって説明されたメールシステムの実際のメールボックスです。 <PrintableString>と<IA5String>規則はセクション3.2で定義されます。 <DOLLAR>規則は[RFC4512]で定義されます。
The LDAP definition for the Other Mailbox syntax is:
Other Mailbox構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
(1.3.6.1.4.1.1466.115.121.1.39DESC'他のメールボックス')
The ASN.1 type corresponding to the Other Mailbox syntax is defined as follows, assuming EXPLICIT TAGS:
EXPLICIT TAGSを仮定して、Other Mailbox構文に対応するASN.1タイプは以下の通り定義されます:
OtherMailbox ::= SEQUENCE {
mailboxType PrintableString,
mailbox IA5String
}
OtherMailbox:、:= 系列mailboxType PrintableString、メールボックスIA5String
3.3.28. Postal Address
3.3.28. 郵便の宛先
A value of the Postal Address syntax is a sequence of strings of one or more arbitrary UCS characters, which form an address in a physical mail system.
Postal Address構文の値は1つ以上の任意のUCSキャラクタのストリングの系列です。(キャラクタは物理的なメールシステムのアドレスを形成します)。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の価値のLDAP特有のコード化は以下のABNFによって定義されます:
Legg Standards Track [Page 20] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[20ページ]: 構文と2006年6月に規則を合わせること。
PostalAddress = line *( DOLLAR line )
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB
PostalAddress=が*(DOLLARは立ち並んでいる)線=1*線炭の線炭=%x00-23/を裏打ちする、(%x5C、「24インチ)」、。 「$」/%x25-5B/から逃げる、(%、x5C「5C」)、。 逃げられた「\」/%x5D-7F / UTFMB
Each character string (i.e., <line>) of a postal address value is encoded as a UTF-8 [RFC3629] string, except that "\" and "$" characters, if they occur in the string, are escaped by a "\" character followed by the two hexadecimal digit code for the character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
郵便の宛先価値の各文字列(すなわち、<線>)はUTF-8[RFC3629]ストリングとしてコード化されます、彼らがストリングに起こるなら「\」と「$」キャラクタ2 16進数字コードがキャラクタのためにあとに続いた「\」キャラクタによって逃げられるのを除いて。 <DOLLAR>と<UTFMB>規則は[RFC4512]で定義されます。
Many servers limit the postal address to no more than six lines of no more than thirty characters each.
多くのサーバが郵便の宛先をそれぞれ30未満のキャラクタの6つ未満の線に制限します。
Example:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
例: 1234年の主な$聖Anytown、カリフォルニア12345$米国2億4100万円賞金レースドルの私書箱1000000$普通の都市、12345ドルのカリフォルニア米国
The LDAP definition for the Postal Address syntax is:
Postal Address構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
(1.3.6.1.4.1.1466.115.121.1.41DESC'郵便の宛先')
This syntax corresponds to the PostalAddress ASN.1 type from [X.520]; that is
この構文は[X.520]からPostalAddress ASN.1タイプに文通されます。 すなわち
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string }
PostalAddress:、:= DirectoryStringの系列サイズ(1..ubの郵便の線)ubの郵便のストリング
The values of ub-postal-line and ub-postal-string (both integers) are implementation defined. Non-normative definitions appear in [X.520].
ubの郵便の線とubの郵便のストリング(両方の整数)の値は定義された実現です。 非標準の定義は[X.520]に現れます。
3.3.29. Printable String
3.3.29. 印刷可能なストリング
A value of the Printable String syntax is a string of one or more latin alphabetic, numeric, and selected punctuation characters as specified by the <PrintableCharacter> rule in Section 3.2.
セクション3.2の<PrintableCharacter>規則によってPrintable String構文の値は指定されるとして一連の1つ以上のラテンのアルファベットの、そして、数値の、そして、選択された句読文字です。
The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <PrintableString> rule in Section 3.2.
この構文の価値のLDAP特有のコード化はキャラクタの非変換されたストリングです。(そのストリングはセクション3.2の<PrintableString>規則に一致しています)。
Example:
This is a PrintableString.
例: これはPrintableStringです。
Legg Standards Track [Page 21] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[21ページ]: 構文と2006年6月に規則を合わせること。
The LDAP definition for the PrintableString syntax is:
PrintableString構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
(1.3.6.1.4.1.1466.115.121.1.44DESC'印刷可能なストリング')
This syntax corresponds to the PrintableString ASN.1 type from [ASN.1].
この構文は[ASN.1]からPrintableString ASN.1タイプに文通されます。
3.3.30. Substring Assertion
3.3.30. サブストリング主張
A value of the Substring Assertion syntax is a sequence of zero, one, or more character substrings used as an argument for substring extensible matching of character string attribute values; i.e., as the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS]. A zero-length substring is not permitted.
Substring Assertion構文の値はゼロの系列です、文字列属性値のサブストリングの広げることができるマッチングに議論として使用される1つ以上のキャラクタサブストリング。 すなわち、MatchingRuleAssertion[RFC4511]のmatchValueとして。 各サブストリングはUniversal文字コード(UCS)[UCS]からの一連の1人以上の気紛れな質です。 ゼロ・レングスサブストリングは受入れられません。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の価値のLDAP特有のコード化は以下のABNFによって定義されます:
SubstringAssertion = [ initial ] any [ final ]
SubstringAssertionはいずれとも等しいです[初期の]。[最終的]です。
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; asterisk ("*")
=サブストリングにどんな=ASTERISK*(サブストリングASTERISK)最終的な=サブストリングASTERISK=%x2A頭文字をつけてください。 アスタリスク("*")
substring = 1*substring-character
substring-character = %x00-29
/ (%x5C "2A") ; escaped "*"
/ %x2B-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB
サブストリング=1*サブストリングキャラクタサブストリングキャラクタ=%x00-29/(%x5C"2A")。 「*」/%x2B-5B/から逃げる、(%、x5C「5C」)、。 逃げられた「\」/%x5D-7F / UTFMB
Each <substring> of a Substring Assertion value is encoded as a UTF-8 [RFC3629] string, except that "\" and "*" characters, if they occur in the substring, are escaped by a "\" character followed by the two hexadecimal digit code for the character.
Substring Assertion価値のそれぞれの<サブストリング>はUTF-8[RFC3629]ストリングとしてコード化されます、彼らがサブストリングに起こるなら「\」と「*」キャラクタ2 16進数字コードがキャラクタのためにあとに続いた「\」キャラクタによって逃げられるのを除いて。
The Substring Assertion syntax is used only as the syntax of assertion values in the extensible match. It is not used as an attribute syntax, or in the SubstringFilter [RFC4511].
Substring Assertion構文は単に主張値の構文として広げることができるマッチで使用されます。 それは属性構文、またはSubstringFilter[RFC4511]で使用されません。
The LDAP definition for the Substring Assertion syntax is:
Substring Assertion構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
(1.3.6.1.4.1.1466.115.121.1.58DESC'サブストリング、主張、'、)
Legg Standards Track [Page 22] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[22ページ]: 構文と2006年6月に規則を合わせること。
This syntax corresponds to the SubstringAssertion ASN.1 type from [X.520].
この構文は[X.520]からSubstringAssertion ASN.1タイプに文通されます。
3.3.31. Telephone Number
3.3.31. 電話番号
A value of the Telephone Number syntax is a string of printable characters that complies with the internationally agreed format for representing international telephone numbers [E.123].
Telephone Number構文の値は国際電話番号[E.123]を表すための国際的に同意された形式に従う一連の印刷可能なキャラクタです。
The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <PrintableString> rule in Section 3.2.
この構文の価値のLDAP特有のコード化はキャラクタの非変換されたストリングです。(そのストリングはセクション3.2の<PrintableString>規則に一致しています)。
Examples:
+1 512 315 0280
+1-512-315-0280
+61 3 9896 7830
例: +1 512 315 0280 +1-512-315-0280 +61 3 9896 7830
The LDAP definition for the Telephone Number syntax is:
Telephone Number構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
(1.3.6.1.4.1.1466.115.121.1.50DESC'電話番号')
The Telephone Number syntax corresponds to the following ASN.1 type from [X.520]:
Telephone Number構文は[X.520]から以下のASN.1タイプに文通されます:
PrintableString (SIZE(1..ub-telephone-number))
PrintableString(サイズ(1..ub-電話番号))
The value of ub-telephone-number (an integer) is implementation defined. A non-normative definition appears in [X.520].
ub-電話番号(整数)の値は定義された実現です。 非標準の定義は[X.520]に現れます。
3.3.32. Teletex Terminal Identifier
3.3.32. テレテックス端末識別子
A value of this syntax specifies the identifier and (optionally) parameters of a teletex terminal.
この構文の値はテレテックス端末の識別子と(任意に)パラメタを指定します。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の価値の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-用語*(DOLLAR ttx-param)ttx-用語はPrintableStringと等しいです。 端末の識別子ttx-paramはttx主要なコロンttx-値と等しいです。 「ページ」/「個人的」ttx-値の=*ttx-価値パラメタttx主要な=「グラフィック」/「コントロール」/「雑ネタ」/八重奏
ttx-value-octet = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
ttx値の八重奏=%x00-23/、(%x5C、「24インチ)」、。 「$」/%x25-5B/から逃げる、(%、x5C「5C」)、。 逃げられた「\」
Legg Standards Track [Page 23] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[23ページ]: 構文と2006年6月に規則を合わせること。
/ %x5D-FF
/%x5D ff
The <PrintableString> and <COLON> rules are defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<PrintableString>と<コロン>規則はセクション3.2で定義されます。 <DOLLAR>規則は[RFC4512]で定義されます。
The LDAP definition for the Teletex Terminal Identifier syntax is:
Teletex Terminal Identifier構文のためのLDAP定義は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Teletex Terminal Identifier' )
( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type from [X.520].
This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type from [X.520].
3.3.33. Telex Number
3.3.33. Telex Number
A value of the Telex Number syntax specifies the telex number, country code, and answerback code of a telex terminal.
A value of the Telex Number syntax specifies the telex number, country code, and answerback code of a telex terminal.
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
telex-number = actual-number DOLLAR country-code
DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableString
telex-number = actual-number DOLLAR country-code DOLLAR answerback actual-number = PrintableString country-code = PrintableString answerback = PrintableString
The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
The LDAP definition for the Telex Number syntax is:
The LDAP definition for the Telex Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
3.3.34. UTC Time
3.3.34. UTC Time
A value of the UTC Time syntax is a character string representing a date and time to a precision of one minute or one second. The year is given as a two-digit number. The LDAP-specific encoding of a value of this syntax follows the format defined in [ASN.1] for the UTCTime type and is described by the following ABNF:
A value of the UTC Time syntax is a character string representing a date and time to a precision of one minute or one second. The year is given as a two-digit number. The LDAP-specific encoding of a value of this syntax follows the format defined in [ASN.1] for the UTCTime type and is described by the following ABNF:
UTCTime = year month day hour minute [ second ]
[ u-time-zone ]
u-time-zone = %x5A ; "Z"
/ u-differential
UTCTime = year month day hour minute [ second ] [ u-time-zone ] u-time-zone = %x5A ; "Z" / u-differential
Legg Standards Track [Page 24] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 24] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
u-differential = ( MINUS / PLUS ) hour minute
u-differential = ( MINUS / PLUS ) hour minute
The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> rules are defined in Section 3.3.13. The <PLUS> rule is defined in [RFC4512].
The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> rules are defined in Section 3.3.13. The <PLUS> rule is defined in [RFC4512].
The above ABNF allows character strings that do not represent valid dates (in the Gregorian calendar) and/or valid times. Such character strings SHOULD be considered invalid for this syntax.
The above ABNF allows character strings that do not represent valid dates (in the Gregorian calendar) and/or valid times. Such character strings SHOULD be considered invalid for this syntax.
The time value represents coordinated universal time if the "Z" form of <u-time-zone> is used; otherwise, the value represents a local time. In the latter case, if <u-differential> is provided, then coordinated universal time can be calculated by subtracting the differential from the local time. The <u-time-zone> SHOULD be present in time values, and the "Z" form of <u-time-zone> SHOULD be used in preference to <u-differential>.
The time value represents coordinated universal time if the "Z" form of <u-time-zone> is used; otherwise, the value represents a local time. In the latter case, if <u-differential> is provided, then coordinated universal time can be calculated by subtracting the differential from the local time. The <u-time-zone> SHOULD be present in time values, and the "Z" form of <u-time-zone> SHOULD be used in preference to <u-differential>.
The LDAP definition for the UTC Time syntax is:
The LDAP definition for the UTC Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
Note: This syntax is deprecated in favor of the Generalized Time syntax.
Note: This syntax is deprecated in favor of the Generalized Time syntax.
The UTC Time syntax corresponds to the UTCTime ASN.1 type from [ASN.1].
The UTC Time syntax corresponds to the UTCTime ASN.1 type from [ASN.1].
4. Matching Rules
4. Matching Rules
Matching rules are used by directory implementations to compare attribute values against assertion values when performing Search and Compare operations [RFC4511]. They are also used when comparing a purported distinguished name [RFC4512] with the name of an entry. When modifying entries, matching rules are used to identify values to be deleted and to prevent an attribute from containing two equal values.
Matching rules are used by directory implementations to compare attribute values against assertion values when performing Search and Compare operations [RFC4511]. They are also used when comparing a purported distinguished name [RFC4512] with the name of an entry. When modifying entries, matching rules are used to identify values to be deleted and to prevent an attribute from containing two equal values.
Matching rules that are required for directory operation, or that are in common use, are specified in this section.
Matching rules that are required for directory operation, or that are in common use, are specified in this section.
4.1. General Considerations
4.1. General Considerations
A matching rule is applied to attribute values through an AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The conditions under which an AttributeValueAssertion or MatchingRuleAssertion evaluates to Undefined are specified elsewhere [RFC4511]. If an assertion is not Undefined, then the result of the
A matching rule is applied to attribute values through an AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The conditions under which an AttributeValueAssertion or MatchingRuleAssertion evaluates to Undefined are specified elsewhere [RFC4511]. If an assertion is not Undefined, then the result of the
Legg Standards Track [Page 25] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 25] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
assertion is the result of applying the selected matching rule. A matching rule evaluates to TRUE, and in some cases Undefined, as specified in the description of the matching rule; otherwise, it evaluates to FALSE.
assertion is the result of applying the selected matching rule. A matching rule evaluates to TRUE, and in some cases Undefined, as specified in the description of the matching rule; otherwise, it evaluates to FALSE.
Each assertion contains an assertion value. The definition of each matching rule specifies the syntax for the assertion value. The syntax of the assertion value is typically, but not necessarily, the same as the syntax of the attribute values to which the matching rule may be applied. Note that an AssertionValue in a SubstringFilter [RFC4511] conforms to the assertion syntax of the equality matching rule for the attribute type rather than to the assertion syntax of the substrings matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
Each assertion contains an assertion value. The definition of each matching rule specifies the syntax for the assertion value. The syntax of the assertion value is typically, but not necessarily, the same as the syntax of the attribute values to which the matching rule may be applied. Note that an AssertionValue in a SubstringFilter [RFC4511] conforms to the assertion syntax of the equality matching rule for the attribute type rather than to the assertion syntax of the substrings matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
The definition of each matching rule indicates the attribute syntaxes to which the rule may be applied, by specifying conditions the corresponding ASN.1 type of a candidate attribute syntax must satisfy. These conditions are also satisfied if the corresponding ASN.1 type is a tagged or constrained derivative of the ASN.1 type explicitly mentioned in the rule description (i.e., ASN.1 tags and constraints are ignored in checking applicability), or is an alternative reference notation for the explicitly mentioned type. Each rule description lists, as examples of applicable attribute syntaxes, the complete list of the syntaxes defined in this document to which the matching rule applies. A matching rule may be applicable to additional syntaxes defined in other documents if those syntaxes satisfy the conditions on the corresponding ASN.1 type.
The definition of each matching rule indicates the attribute syntaxes to which the rule may be applied, by specifying conditions the corresponding ASN.1 type of a candidate attribute syntax must satisfy. These conditions are also satisfied if the corresponding ASN.1 type is a tagged or constrained derivative of the ASN.1 type explicitly mentioned in the rule description (i.e., ASN.1 tags and constraints are ignored in checking applicability), or is an alternative reference notation for the explicitly mentioned type. Each rule description lists, as examples of applicable attribute syntaxes, the complete list of the syntaxes defined in this document to which the matching rule applies. A matching rule may be applicable to additional syntaxes defined in other documents if those syntaxes satisfy the conditions on the corresponding ASN.1 type.
The description of each matching rule indicates whether the rule is suitable for use as the equality matching rule (EQUALITY), ordering matching rule (ORDERING), or substrings matching rule (SUBSTR) in an attribute type definition [RFC4512].
The description of each matching rule indicates whether the rule is suitable for use as the equality matching rule (EQUALITY), ordering matching rule (ORDERING), or substrings matching rule (SUBSTR) in an attribute type definition [RFC4512].
Each matching rule is uniquely identified with an object identifier. The definition of a matching rule should not subsequently be changed. If a change is desirable, then a new matching rule with a different object identifier should be defined instead.
Each matching rule is uniquely identified with an object identifier. The definition of a matching rule should not subsequently be changed. If a change is desirable, then a new matching rule with a different object identifier should be defined instead.
Servers MAY implement the wordMatch and keywordMatch matching rules, but they SHOULD implement the other matching rules in Section 4.2. Servers MAY implement additional matching rules.
Servers MAY implement the wordMatch and keywordMatch matching rules, but they SHOULD implement the other matching rules in Section 4.2. Servers MAY implement additional matching rules.
Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion
Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion
Legg Standards Track [Page 26] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 26] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
syntax of the matching rule is the same as the value syntax of the attribute.
syntax of the matching rule is the same as the value syntax of the attribute.
Servers MUST publish, in the matchingRules attribute, the definitions of matching rules referenced by values of the attributeTypes and matchingRuleUse attributes in the same subschema entry. Other unreferenced matching rules MAY be published in the matchingRules attribute.
Servers MUST publish, in the matchingRules attribute, the definitions of matching rules referenced by values of the attributeTypes and matchingRuleUse attributes in the same subschema entry. Other unreferenced matching rules MAY be published in the matchingRules attribute.
If the server supports the extensibleMatch filter, then the server MAY use the matchingRuleUse attribute to indicate the applicability (in an extensibleMatch filter) of selected matching rules to nominated attribute types.
If the server supports the extensibleMatch filter, then the server MAY use the matchingRuleUse attribute to indicate the applicability (in an extensibleMatch filter) of selected matching rules to nominated attribute types.
4.2. Matching Rule Definitions
4.2. Matching Rule Definitions
Nominated character strings in assertion and attribute values are prepared according to the string preparation algorithms [RFC4518] for LDAP when evaluating the following matching rules:
Nominated character strings in assertion and attribute values are prepared according to the string preparation algorithms [RFC4518] for LDAP when evaluating the following matching rules:
numericStringMatch,
numericStringSubstringsMatch,
caseExactMatch,
caseExactOrderingMatch,
caseExactSubstringsMatch,
caseExactIA5Match,
caseIgnoreIA5Match,
caseIgnoreIA5SubstringsMatch,
caseIgnoreListMatch,
caseIgnoreListSubstringsMatch,
caseIgnoreMatch,
caseIgnoreOrderingMatch,
caseIgnoreSubstringsMatch,
directoryStringFirstComponentMatch,
telephoneNumberMatch,
telephoneNumberSubstringsMatch and
wordMatch.
numericStringMatch, numericStringSubstringsMatch, caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch, caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, directoryStringFirstComponentMatch, telephoneNumberMatch, telephoneNumberSubstringsMatch and wordMatch.
The Transcode, Normalize, Prohibit, and Check bidi steps are the same for each of the matching rules. However, the Map and Insignificant Character Handling steps depend on the specific rule, as detailed in the description of these matching rules in the sections that follow.
The Transcode, Normalize, Prohibit, and Check bidi steps are the same for each of the matching rules. However, the Map and Insignificant Character Handling steps depend on the specific rule, as detailed in the description of these matching rules in the sections that follow.
4.2.1. bitStringMatch
4.2.1. bitStringMatch
The bitStringMatch rule compares an assertion value of the Bit String syntax to an attribute value of a syntax (e.g., the Bit String syntax) whose corresponding ASN.1 type is BIT STRING.
The bitStringMatch rule compares an assertion value of the Bit String syntax to an attribute value of a syntax (e.g., the Bit String syntax) whose corresponding ASN.1 type is BIT STRING.
Legg Standards Track [Page 27] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 27] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
If the corresponding ASN.1 type of the attribute syntax does not have a named bit list [ASN.1] (which is the case for the Bit String syntax), then the rule evaluates to TRUE if and only if the attribute value has the same number of bits as the assertion value and the bits match on a bitwise basis.
If the corresponding ASN.1 type of the attribute syntax does not have a named bit list [ASN.1] (which is the case for the Bit String syntax), then the rule evaluates to TRUE if and only if the attribute value has the same number of bits as the assertion value and the bits match on a bitwise basis.
If the corresponding ASN.1 type does have a named bit list, then bitStringMatch operates as above, except that trailing zero bits in the attribute and assertion values are treated as absent.
If the corresponding ASN.1 type does have a named bit list, then bitStringMatch operates as above, except that trailing zero bits in the attribute and assertion values are treated as absent.
The LDAP definition for the bitStringMatch rule is:
The LDAP definition for the bitStringMatch rule is:
( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
The bitStringMatch rule is an equality matching rule.
The bitStringMatch rule is an equality matching rule.
4.2.2. booleanMatch
4.2.2. booleanMatch
The booleanMatch rule compares an assertion value of the Boolean syntax to an attribute value of a syntax (e.g., the Boolean syntax) whose corresponding ASN.1 type is BOOLEAN.
The booleanMatch rule compares an assertion value of the Boolean syntax to an attribute value of a syntax (e.g., the Boolean syntax) whose corresponding ASN.1 type is BOOLEAN.
The rule evaluates to TRUE if and only if the attribute value and the assertion value are both TRUE or both FALSE.
The rule evaluates to TRUE if and only if the attribute value and the assertion value are both TRUE or both FALSE.
The LDAP definition for the booleanMatch rule is:
The LDAP definition for the booleanMatch rule is:
( 2.5.13.13 NAME 'booleanMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
The booleanMatch rule is an equality matching rule.
The booleanMatch rule is an equality matching rule.
4.2.3. caseExactIA5Match
4.2.3. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The caseExactIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
Legg Standards Track [Page 28] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 28] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The LDAP definition for the caseExactIA5Match rule is:
The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseExactIA5Match rule is an equality matching rule.
The caseExactIA5Match rule is an equality matching rule.
4.2.4. caseExactMatch
4.2.4. caseExactMatch
The caseExactMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of the alternative string types of DirectoryString, such as PrintableString (the other alternatives do not correspond to any syntax defined in this document).
The caseExactMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of the alternative string types of DirectoryString, such as PrintableString (the other alternatives do not correspond to any syntax defined in this document).
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseExactMatch rule is:
The LDAP definition for the caseExactMatch rule is:
( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactMatch rule is an equality matching rule.
The caseExactMatch rule is an equality matching rule.
4.2.5. caseExactOrderingMatch
4.2.5. caseExactOrderingMatch
The caseExactOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The caseExactOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
Legg Standards Track [Page 29] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 29] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseExactOrderingMatch rule is:
The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactOrderingMatch rule is an ordering matching rule.
The caseExactOrderingMatch rule is an ordering matching rule.
4.2.6. caseExactSubstringsMatch
4.2.6. caseExactSubstringsMatch
The caseExactSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The caseExactSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value substrings for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseExactSubstringsMatch rule is:
The LDAP definition for the caseExactSubstringsMatch rule is:
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseExactSubstringsMatch rule is a substrings matching rule.
The caseExactSubstringsMatch rule is a substrings matching rule.
4.2.7. caseIgnoreIA5Match
4.2.7. caseIgnoreIA5Match
The caseIgnoreIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The caseIgnoreIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
Legg Standards Track [Page 30] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 30] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreIA5Match rule is:
The LDAP definition for the caseIgnoreIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseIgnoreIA5Match rule is an equality matching rule.
The caseIgnoreIA5Match rule is an equality matching rule.
4.2.8. caseIgnoreIA5SubstringsMatch
4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
4.2.9. caseIgnoreListMatch
4.2.9. caseIgnoreListMatch
The caseIgnoreListMatch rule compares an assertion value that is a sequence of strings to an attribute value of a syntax (e.g., the
The caseIgnoreListMatch rule compares an assertion value that is a sequence of strings to an attribute value of a syntax (e.g., the
Legg Standards Track [Page 31] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 31] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type.
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of strings and corresponding strings (by position) match according to the caseIgnoreMatch matching rule.
The rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of strings and corresponding strings (by position) match according to the caseIgnoreMatch matching rule.
In [X.520], the assertion syntax for this matching rule is defined to be:
In [X.520], the assertion syntax for this matching rule is defined to be:
SEQUENCE OF DirectoryString {ub-match}
SEQUENCE OF DirectoryString {ub-match}
That is, it is different from the corresponding type for the Postal Address syntax. The choice of the Postal Address syntax for the assertion syntax of the caseIgnoreListMatch in LDAP should not be seen as limiting the matching rule to apply only to attributes with the Postal Address syntax.
That is, it is different from the corresponding type for the Postal Address syntax. The choice of the Postal Address syntax for the assertion syntax of the caseIgnoreListMatch in LDAP should not be seen as limiting the matching rule to apply only to attributes with the Postal Address syntax.
The LDAP definition for the caseIgnoreListMatch rule is:
The LDAP definition for the caseIgnoreListMatch rule is:
( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
The caseIgnoreListMatch rule is an equality matching rule.
The caseIgnoreListMatch rule is an equality matching rule.
4.2.10. caseIgnoreListSubstringsMatch
4.2.10. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type.
The caseIgnoreListSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the assertion value matches, per the caseIgnoreSubstringsMatch rule, the character string formed by concatenating the strings of the attribute value, except that none of the <initial>, <any>, or <final> substrings of the assertion value are considered to match a substring of the concatenated string which spans more than one of the original strings of the attribute value.
The rule evaluates to TRUE if and only if the assertion value matches, per the caseIgnoreSubstringsMatch rule, the character string formed by concatenating the strings of the attribute value, except that none of the <initial>, <any>, or <final> substrings of the assertion value are considered to match a substring of the concatenated string which spans more than one of the original strings of the attribute value.
Note that, in terms of the LDAP-specific encoding of the Postal Address syntax, the concatenated string omits the <DOLLAR> line separator and the escaping of "\" and "$" characters.
Note that, in terms of the LDAP-specific encoding of the Postal Address syntax, the concatenated string omits the <DOLLAR> line separator and the escaping of "\" and "$" characters.
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
Legg Standards Track [Page 32] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 32] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
4.2.11. caseIgnoreMatch
4.2.11. caseIgnoreMatch
The caseIgnoreMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The caseIgnoreMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreMatch rule is:
The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreMatch rule is an equality matching rule.
The caseIgnoreMatch rule is an equality matching rule.
4.2.12. caseIgnoreOrderingMatch
4.2.12. caseIgnoreOrderingMatch
The caseIgnoreOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The caseIgnoreOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is:
The LDAP definition for the caseIgnoreOrderingMatch rule is:
Legg Standards Track [Page 33] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 33] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreOrderingMatch rule is an ordering matching rule.
The caseIgnoreOrderingMatch rule is an ordering matching rule.
4.2.13. caseIgnoreSubstringsMatch
4.2.13. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The caseIgnoreSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
4.2.14. directoryStringFirstComponentMatch
4.2.14. directoryStringFirstComponentMatch
The directoryStringFirstComponentMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the DirectoryString ASN.1 type.
The directoryStringFirstComponentMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the DirectoryString ASN.1 type.
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
Legg Standards Track [Page 34] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 34] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The rule evaluates to TRUE if and only if the assertion value matches the first component of the attribute value using the rules of caseIgnoreMatch.
The rule evaluates to TRUE if and only if the assertion value matches the first component of the attribute value using the rules of caseIgnoreMatch.
The LDAP definition for the directoryStringFirstComponentMatch matching rule is:
The LDAP definition for the directoryStringFirstComponentMatch matching rule is:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The directoryStringFirstComponentMatch rule is an equality matching rule. When using directoryStringFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. An assertion value can be derived from an attribute value by taking the first component of that attribute value.
directoryStringFirstComponentMatch規則は平等の合っている規則です。 2つの属性値(適切な構文の)を比較するのにdirectoryStringFirstComponentMatchを使用するとき、最初に、属性値の1つから主張値を得なければなりません。 属性値からその属性値の最初のコンポーネントを取ることによって、主張値を得ることができます。
4.2.15. distinguishedNameMatch
4.2.15. distinguishedNameMatch
The distinguishedNameMatch rule compares an assertion value of the DN syntax to an attribute value of a syntax (e.g., the DN syntax) whose corresponding ASN.1 type is DistinguishedName.
distinguishedNameMatch規則は対応するASN.1タイプがDistinguishedNameである構文(例えば、DN構文)の属性値にDN構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of relative distinguished names and corresponding relative distinguished names (by position) are the same. A relative distinguished name (RDN) of the assertion value is the same as an RDN of the attribute value if and only if they have the same number of attribute value assertions and each attribute value assertion (AVA) of the first RDN is the same as the AVA of the second RDN with the same attribute type. The order of the AVAs is not significant. Also note that a particular attribute type may appear in at most one AVA in an RDN. Two AVAs with the same attribute type are the same if their values are equal according to the equality matching rule of the attribute type. If one or more of the AVA comparisons evaluate to Undefined and the remaining AVA comparisons return TRUE then the distinguishedNameMatch rule evaluates to Undefined.
規則がTRUEに評価する、属性値と主張値に同じ数の相対的な分類名と対応する相対的な分類名(位置のそばの)がある場合にだけ、同じくらいはそうです。 主張価値の相対的な分類名(RDN)が属性値のRDNと同じである、彼らに同じ数の属性値主張と最初のRDNのそれぞれの属性値主張(AVA)がある場合にだけ、同じ属性タイプがいる第2RDNのAVAと同じくらいはそうです。 AVAsの注文は重要ではありません。 また、特定の属性タイプが高々RDNの1AVAに現れるかもしれないことに注意してください。 属性タイプの平等の合っている規則に従って彼らの値が等しいなら、同じ属性タイプがいる2AVAsが同じです。 AVA比較のものか以上がUndefinedと残っているAVAに比較を評価するなら、distinguishedNameMatch規則がUndefinedに評価するその時をTRUEに返してください。
The LDAP definition for the distinguishedNameMatch rule is:
distinguishedNameMatch規則のためのLDAP定義は以下の通りです。
( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
(2.5.13.1名'distinguishedNameMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.12)
The distinguishedNameMatch rule is an equality matching rule.
distinguishedNameMatch規則は平等の合っている規則です。
Legg Standards Track [Page 35] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[35ページ]: 構文と2006年6月に規則を合わせること。
4.2.16. generalizedTimeMatch
4.2.16. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the Generalized Time syntax to an attribute value of a syntax (e.g., the Generalized Time syntax) whose corresponding ASN.1 type is GeneralizedTime.
generalizedTimeMatch規則は対応するASN.1タイプがGeneralizedTimeである構文(例えば、Generalized Time構文)の属性値にGeneralized Time構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the attribute value represents the same universal coordinated time as the assertion value. If a time is specified with the minutes or seconds absent, then the number of minutes or seconds (respectively) is assumed to be zero.
そして、規則がTRUEに評価する、属性値が同普遍的な連携時に主張値を表す場合にだけ。 数分か秒が欠けていた状態で時間が指定されるなら、数分か秒の数はゼロであると(それぞれ)思われます。
The LDAP definition for the generalizedTimeMatch rule is:
generalizedTimeMatch規則のためのLDAP定義は以下の通りです。
( 2.5.13.27 NAME 'generalizedTimeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
(2.5.13.27名'generalizedTimeMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.24)
The generalizedTimeMatch rule is an equality matching rule.
generalizedTimeMatch規則は平等の合っている規則です。
4.2.17. generalizedTimeOrderingMatch
4.2.17. generalizedTimeOrderingMatch
The generalizedTimeOrderingMatch rule compares the time ordering of an assertion value of the Generalized Time syntax to an attribute value of a syntax (e.g., the Generalized Time syntax) whose corresponding ASN.1 type is GeneralizedTime.
generalizedTimeOrderingMatch規則は、対応するASN.1タイプがGeneralizedTimeである構文(例えば、Generalized Time構文)の属性値にGeneralized Time構文の主張価値を注文しながら、時間を比較します。
The rule evaluates to TRUE if and only if the attribute value represents a universal coordinated time that is earlier than the universal coordinated time represented by the assertion value.
そして、規則がTRUEに評価する、属性値が普遍的な連携時間を表す場合にだけ、それは主張値によって表された普遍的な連携時間より初期です。
The LDAP definition for the generalizedTimeOrderingMatch rule is:
generalizedTimeOrderingMatch規則のためのLDAP定義は以下の通りです。
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
(2.5.13.28名'generalizedTimeOrderingMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.24)
The generalizedTimeOrderingMatch rule is an ordering matching rule.
generalizedTimeOrderingMatch規則は注文の合っている規則です。
4.2.18. integerFirstComponentMatch
4.2.18. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the DIT Structure Rule Description syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the INTEGER ASN.1 type.
integerFirstComponentMatch規則はINTEGER ASN.1タイプの義務的な最初の成分で対応するASN.1タイプがSEQUENCEである構文(例えば、DIT Structure Rule記述構文)の属性値にInteger構文の主張値をたとえます。
Legg Standards Track [Page 36] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[36ページ]: 構文と2006年6月に規則を合わせること。
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
この合っている規則の主張構文がこれが平等の合っている規則である属性の属性構文と異なっていることに注意してください。
The rule evaluates to TRUE if and only if the assertion value and the first component of the attribute value are the same integer value.
規則がTRUEに評価する、属性値の主張値と最初のコンポーネントである場合にだけ、整数が評価する同じくらいはそうです。
The LDAP definition for the integerFirstComponentMatch matching rule is:
integerFirstComponentMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.29 NAME 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
(2.5.13.29名'integerFirstComponentMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.27)
The integerFirstComponentMatch rule is an equality matching rule. When using integerFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. An assertion value can be derived from an attribute value by taking the first component of that attribute value.
integerFirstComponentMatch規則は平等の合っている規則です。 2つの属性値(適切な構文の)を比較するのにintegerFirstComponentMatchを使用するとき、最初に、属性値の1つから主張値を得なければなりません。 属性値からその属性値の最初のコンポーネントを取ることによって、主張値を得ることができます。
4.2.19. integerMatch
4.2.19. integerMatch
The integerMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the Integer syntax) whose corresponding ASN.1 type is INTEGER.
integerMatch規則は対応するASN.1タイプがINTEGERである構文(例えば、Integer構文)の属性値にInteger構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same integer value.
規則がTRUEに評価する、属性値と主張値である場合にだけ、整数が評価する同じくらいはそうです。
The LDAP definition for the integerMatch matching rule is:
integerMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.14 NAME 'integerMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
(2.5.13.14名'integerMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.27)
The integerMatch rule is an equality matching rule.
integerMatch規則は平等の合っている規則です。
4.2.20. integerOrderingMatch
4.2.20. integerOrderingMatch
The integerOrderingMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the Integer syntax) whose corresponding ASN.1 type is INTEGER.
integerOrderingMatch規則は対応するASN.1タイプがINTEGERである構文(例えば、Integer構文)の属性値にInteger構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the integer value of the attribute value is less than the integer value of the assertion value.
規則がTRUEに評価する、属性値の整数値である場合にだけ、主張価値の整数値以下はそうです。
The LDAP definition for the integerOrderingMatch matching rule is:
integerOrderingMatchの合っている規則のためのLDAP定義は以下の通りです。
Legg Standards Track [Page 37] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[37ページ]: 構文と2006年6月に規則を合わせること。
( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
(2.5.13.15名'integerOrderingMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.27)
The integerOrderingMatch rule is an ordering matching rule.
integerOrderingMatch規則は注文の合っている規則です。
4.2.21. keywordMatch
4.2.21. keywordMatch
The keywordMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax) whose corresponding ASN.1 type is DirectoryString.
keywordMatch規則は対応するASN.1タイプがDirectoryStringである構文(例えば、ディレクトリString構文)の属性値にディレクトリString構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the assertion value character string matches any keyword in the attribute value. The identification of keywords in the attribute value and the exactness of the match are both implementation specific.
そして、規則がTRUEに評価する、主張値の文字列が何か属性値におけるキーワードに合っている場合にだけ。 属性値における、キーワードの識別とマッチの正確は実装ともに特有です。
The LDAP definition for the keywordMatch rule is:
keywordMatch規則のためのLDAP定義は以下の通りです。
( 2.5.13.33 NAME 'keywordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.13.33名'keywordMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.15)
4.2.22. numericStringMatch
4.2.22. numericStringMatch
The numericStringMatch rule compares an assertion value of the Numeric String syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString.
numericStringMatch規則は対応するASN.1タイプがNumericStringである構文(例えば、Numeric String構文)の属性値にNumeric String構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
そして、規則がTRUEに評価する、準備された属性値文字列と準備された主張値の文字列に同じ数のキャラクタと対応するキャラクタがある場合にだけ、同じコード・ポイントを持ってください。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only numericString Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のために属性値と主張値を準備するのにおいて、キャラクタはMap準備ステップで折り重ねられたケースではありません、そして、numericString InsignificantキャラクターHandlingだけがInsignificantキャラクターHandlingステップで適用されます。
The LDAP definition for the numericStringMatch matching rule is:
numericStringMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
(2.5.13.8名'numericStringMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.36)
The numericStringMatch rule is an equality matching rule.
numericStringMatch規則は平等の合っている規則です。
Legg Standards Track [Page 38] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[38ページ]: 構文と2006年6月に規則を合わせること。
4.2.23. numericStringOrderingMatch
4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of the Numeric String syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString.
numericStringOrderingMatch規則は対応するASN.1タイプがNumericStringである構文(例えば、Numeric String構文)の属性値にNumeric String構文の主張値をたとえます。
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
そして、規則がTRUEに評価する、コードポイント照合命令に、準備された属性値文字列が準備された主張値の文字列より早く現れる場合にだけ。 すなわち、属性値がそうである、「」 主張値よりそれほど。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only numericString Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のために属性値と主張値を準備するのにおいて、キャラクタはMap準備ステップで折り重ねられたケースではありません、そして、numericString InsignificantキャラクターHandlingだけがInsignificantキャラクターHandlingステップで適用されます。
The rule is identical to the caseIgnoreOrderingMatch rule except that all space characters are skipped during comparison (case is irrelevant as the characters are numeric).
すべての間隔文字が比較の間、スキップされるのを除いて(キャラクタが数値であることのようにケースは無関係です)、規則はcaseIgnoreOrderingMatch規則と同じです。
The LDAP definition for the numericStringOrderingMatch matching rule is:
numericStringOrderingMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
(2.5.13.9名'numericStringOrderingMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.36)
The numericStringOrderingMatch rule is an ordering matching rule.
numericStringOrderingMatch規則は注文の合っている規則です。
4.2.24. numericStringSubstringsMatch
4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString.
numericStringSubstringsMatch規則は対応するASN.1タイプがNumericStringである構文(例えば、Numeric String構文)の属性値にSubstring Assertion構文の主張値をたとえます。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
規則がTRUEに評価する、(1) 単に、主張値のマッチの準備されたサブストリングはプレゼントと、用意ができていている属性値キャラクタの始まりが結ぶマッチと、(3)のa<の最終的な>サブストリングであるならプレゼント(用意ができていている属性値キャラクタの終わりが結ぶマッチ)であるなら(2) 主張値、<の初期の>サブストリングにおける、サブストリングの注文における準備された属性値文字列の部分をばらばらにならせます。 対応するキャラクタに同じコード・ポイントがあるなら、準備されたサブストリングは準備された属性値文字列の部分に合っています。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only
比較のために属性値と主張値を準備するのにおいて、キャラクタはMap準備ステップ、および唯一で折り重ねられたケースではありません。
Legg Standards Track [Page 39] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[39ページ]: 構文と2006年6月に規則を合わせること。
numericString Insignificant Character Handling is applied in the Insignificant Character Handling step.
numericString InsignificantキャラクターHandlingはInsignificantキャラクターHandlingステップで適用されます。
The LDAP definition for the numericStringSubstringsMatch matching rule is:
numericStringSubstringsMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
(2.5.13.10名'numericStringSubstringsMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.58)
The numericStringSubstringsMatch rule is a substrings matching rule.
numericStringSubstringsMatch規則は規則に合っているサブストリングです。
4.2.25. objectIdentifierFirstComponentMatch
4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion value of the OID syntax to an attribute value of a syntax (e.g., the Attribute Type Description, DIT Content Rule Description, LDAP Syntax Description, Matching Rule Description, Matching Rule Use Description, Name Form Description, or Object Class Description syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the OBJECT IDENTIFIER ASN.1 type.
objectIdentifierFirstComponentMatch規則はOBJECT IDENTIFIER ASN.1タイプの義務的な最初の成分で対応するASN.1タイプがSEQUENCEである構文(例えば、Attribute Type記述、DIT Content Rule記述、LDAP Syntax記述、Matching Rule記述、Matching Rule Use記述、Name Form記述、またはObject Class記述構文)の属性値にOID構文の主張値をたとえます。
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
この合っている規則の主張構文がこれが平等の合っている規則である属性の属性構文と異なっていることに注意してください。
The rule evaluates to TRUE if and only if the assertion value matches the first component of the attribute value using the rules of objectIdentifierMatch.
そして、規則がTRUEに評価する、objectIdentifierMatchの規則を使用することで主張値が属性値の最初のコンポーネントに合っている場合にだけ。
The LDAP definition for the objectIdentifierFirstComponentMatch matching rule is:
objectIdentifierFirstComponentMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
(2.5.13.30名'objectIdentifierFirstComponentMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.38)
The objectIdentifierFirstComponentMatch rule is an equality matching rule. When using objectIdentifierFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. An assertion value can be derived from an attribute value by taking the first component of that attribute value.
objectIdentifierFirstComponentMatch規則は平等の合っている規則です。 2つの属性値(適切な構文の)を比較するのにobjectIdentifierFirstComponentMatchを使用するとき、最初に、属性値の1つから主張値を得なければなりません。 属性値からその属性値の最初のコンポーネントを取ることによって、主張値を得ることができます。
4.2.26. objectIdentifierMatch
4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID syntax to an attribute value of a syntax (e.g., the OID syntax) whose corresponding ASN.1 type is OBJECT IDENTIFIER.
objectIdentifierMatch規則は対応するASN.1タイプがOBJECT IDENTIFIERである構文(例えば、OID構文)の属性値にOID構文の主張値をたとえます。
Legg Standards Track [Page 40] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[40ページ]: 構文と2006年6月に規則を合わせること。
The rule evaluates to TRUE if and only if the assertion value and the attribute value represent the same object identifier; that is, the same sequence of integers, whether represented explicitly in the <numericoid> form of <oid> or implicitly in the <descr> form (see [RFC4512]).
そして、規則がTRUEに評価する、主張値と属性値が同じオブジェクト識別子を表す場合にだけ。 すなわち、<descr>フォーム([RFC4512]を見る)に明らかに<oid>の<numericoid>形かそれとなく表されるか否かに関係なく、整数の同じ系列。
If an LDAP client supplies an assertion value in the <descr> form and the chosen descriptor is not recognized by the server, then the objectIdentifierMatch rule evaluates to Undefined.
LDAPクライアントが<descr>フォームで主張値を供給して、選ばれた記述子がサーバによって認められないなら、objectIdentifierMatch規則がUndefinedに評価するその時です。
The LDAP definition for the objectIdentifierMatch matching rule is:
objectIdentifierMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
(2.5.13.0名'objectIdentifierMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.38)
The objectIdentifierMatch rule is an equality matching rule.
objectIdentifierMatch規則は平等の合っている規則です。
4.2.27. octetStringMatch
4.2.27. octetStringMatch
The octetStringMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type.
octetStringMatch規則は対応するASN.1タイプがOCTET STRING ASN.1タイプである構文(例えば、Octet StringかJPEG構文)の属性値にOctet String構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same length and corresponding octets (by position) are the same.
規則がTRUEに評価する、属性値と主張値が同じ長さの、そして、対応する八重奏(位置のそばの)である場合にだけ、同じくらいはそうです。
The LDAP definition for the octetStringMatch matching rule is:
octetStringMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
(2.5.13.17名'octetStringMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.40)
The octetStringMatch rule is an equality matching rule.
octetStringMatch規則は平等の合っている規則です。
4.2.28. octetStringOrderingMatch
4.2.28. octetStringOrderingMatch
The octetStringOrderingMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type.
octetStringOrderingMatch規則は対応するASN.1タイプがOCTET STRING ASN.1タイプである構文(例えば、Octet StringかJPEG構文)の属性値にOctet String構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the attribute value appears earlier in the collation order than the assertion value. The rule compares octet strings from the first octet to the last octet, and from the most significant bit to the least significant bit within the octet. The first occurrence of a different bit determines the ordering of the strings. A zero bit precedes a one bit. If the
そして、規則がTRUEに評価する、属性値が主張値より照合命令で早く現れる場合にだけ。 規則は八重奏の中で最初の八重奏から最後の八重奏まで最も重要なビットから最下位ビットに八重奏ストリングをたとえます。 異なったビットの最初の発生はストリングの注文を決定します。 ゼロ・ビットは1ビットに先行します。 the
Legg Standards Track [Page 41] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[41ページ]: 構文と2006年6月に規則を合わせること。
strings contain different numbers of octets but the longer string is identical to the shorter string up to the length of the shorter string, then the shorter string precedes the longer string.
より長いストリングが、より脆いストリングと、より脆いストリングの長さまで同じである、ストリングは異なった数の八重奏を含んでいますが、そして、より脆いストリングは、より長いストリングに先行します。
The LDAP definition for the octetStringOrderingMatch matching rule is:
octetStringOrderingMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.18 NAME 'octetStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
(2.5.13.18名'octetStringOrderingMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.40)
The octetStringOrderingMatch rule is an ordering matching rule.
octetStringOrderingMatch規則は注文の合っている規則です。
4.2.29. telephoneNumberMatch
4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the Telephone Number syntax to an attribute value of a syntax (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is a PrintableString representing a telephone number.
telephoneNumberMatch規則は対応するASN.1タイプが電話番号を表すPrintableStringである構文(例えば、Telephone Number構文)の属性値にTelephone Number構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
そして、規則がTRUEに評価する、準備された属性値文字列と準備された主張値の文字列に同じ数のキャラクタと対応するキャラクタがある場合にだけ、同じコード・ポイントを持ってください。
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only telephoneNumber Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のために属性値と主張値を準備するのにおいて、キャラクタはMap準備ステップで折り重ねられたケースです、そして、telephoneNumber InsignificantキャラクターHandlingだけがInsignificantキャラクターHandlingステップで適用されます。
The LDAP definition for the telephoneNumberMatch matching rule is:
telephoneNumberMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
(2.5.13.20名'telephoneNumberMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.50)
The telephoneNumberMatch rule is an equality matching rule.
telephoneNumberMatch規則は平等の合っている規則です。
4.2.30. telephoneNumberSubstringsMatch
4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is a PrintableString representing a telephone number.
telephoneNumberSubstringsMatch規則は対応するASN.1タイプが電話番号を表すPrintableStringである構文(例えば、Telephone Number構文)の属性値にSubstring Assertion構文の主張値をたとえます。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and
そして規則がTRUEに評価する、(1) 値のマッチが準備の部分をばらばらにならせるという主張の準備されたサブストリングが単に存在しているならキャラクタが(2) 主張値、<の初期の>サブストリングにおける、サブストリングの注文で結ぶ値、用意ができていている属性値キャラクタの始まりが結ぶマッチを結果と考える。
Legg Standards Track [Page 42] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[42ページ]: 構文と2006年6月に規則を合わせること。
(3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
(3) 存在しているなら、<の最終的な>サブストリングは準備された属性値文字列の終わりに合っています。 対応するキャラクタに同じコード・ポイントがあるなら、準備されたサブストリングは準備された属性値文字列の部分に合っています。
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only telephoneNumber Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のために属性値と主張値のサブストリングを準備するのにおいて、キャラクタはMap準備ステップで折り重ねられたケースです、そして、telephoneNumber InsignificantキャラクターHandlingだけがInsignificantキャラクターHandlingステップで適用されます。
The LDAP definition for the telephoneNumberSubstringsMatch matching rule is:
telephoneNumberSubstringsMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
(2.5.13.21名'telephoneNumberSubstringsMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.58)
The telephoneNumberSubstringsMatch rule is a substrings matching rule.
telephoneNumberSubstringsMatch規則は規則に合っているサブストリングです。
4.2.31. uniqueMemberMatch
4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name And Optional UID syntax to an attribute value of a syntax (e.g., the Name And Optional UID syntax) whose corresponding ASN.1 type is NameAndOptionalUID.
uniqueMemberMatch規則は対応するASN.1タイプがNameAndOptionalUIDである構文(例えば、Name And Optional UID構文)の属性値にName And Optional UID構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the <distinguishedName> components of the assertion value and attribute value match according to the distinguishedNameMatch rule and either, (1) the <BitString> component is absent from both the attribute value and assertion value, or (2) the <BitString> component is present in both the attribute value and the assertion value and the <BitString> component of the assertion value matches the <BitString> component of the attribute value according to the bitStringMatch rule.
規則がTRUEに評価する、単に、主張値と属性の<distinguishedName>の部品はdistinguishedNameMatch規則とどちらかに従ったマッチ、(1)を<BitString>の部品が属性値と主張値の両方からある評価します; または、(2) <BitString>の部品は両方に属性値を提示することです、そして、bitStringMatch規則に従って、主張価値の主張値と<BitString>の部品は属性値の<BitString>の部品に合っています。
Note that this matching rule has been altered from its description in X.520 [X.520] in order to make the matching rule commutative. Server implementors should consider using the original X.520 semantics (where the matching was less exact) for approximate matching of attributes with uniqueMemberMatch as the equality matching rule.
この合っている規則が合っている規則を交換可能にするようにX.520[X.520]の記述から変更されたことに注意してください。 サーバ作成者は、平等マッチングに統治されるようにuniqueMemberMatchとの属性の大体のマッチングに、オリジナルのX.520意味論(マッチングがそれほど正確でなかったところ)を使用すると考えるべきです。
The LDAP definition for the uniqueMemberMatch matching rule is:
uniqueMemberMatchの合っている規則のためのLDAP定義は以下の通りです。
( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
(2.5.13.23名'uniqueMemberMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.34)
The uniqueMemberMatch rule is an equality matching rule.
uniqueMemberMatch規則は平等の合っている規則です。
Legg Standards Track [Page 43] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[43ページ]: 構文と2006年6月に規則を合わせること。
4.2.32. wordMatch
4.2.32. wordMatch
The wordMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax) whose corresponding ASN.1 type is DirectoryString.
wordMatch規則は対応するASN.1タイプがDirectoryStringである構文(例えば、ディレクトリString構文)の属性値にディレクトリString構文の主張値をたとえます。
The rule evaluates to TRUE if and only if the assertion value word matches, according to the semantics of caseIgnoreMatch, any word in the attribute value. The precise definition of a word is implementation specific.
規則がTRUEに評価する、単に、caseIgnoreMatch(属性値におけるどんな単語も)の意味論によると、主張値の単語は合っています。 単語の厳密な定義は実装特有です。
The LDAP definition for the wordMatch rule is:
wordMatch規則のためのLDAP定義は以下の通りです。
( 2.5.13.32 NAME 'wordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.13.32名'wordMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.15)
5. Security Considerations
5. セキュリティ問題
In general, the LDAP-specific encodings for syntaxes defined in this document do not define canonical encodings. That is, a transformation from an LDAP-specific encoding into some other encoding (e.g., BER) and back into the LDAP-specific encoding will not necessarily reproduce exactly the original octets of the LDAP- specific encoding. Therefore, an LDAP-specific encoding should not be used where a canonical encoding is required.
一般に、本書では定義された構文のためのLDAP特有のencodingsは正準なencodingsを定義しません。 すなわち、ある他のコード化(例えば、BER)の中と、そして、LDAP特有のコード化の中へのLDAP特有のコード化からの変換は必ずまさにLDAPの特定のコード化のオリジナルの八重奏を再生させるというわけではないでしょう。 したがって、正準なコード化が必要であるところでLDAP特有のコード化を使用するべきではありません。
Furthermore, the LDAP-specific encodings do not necessarily enable an alternative encoding of values of the Directory String and DN syntaxes to be reconstructed; e.g., a transformation from a Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific encoding and back to a DER encoding may not reproduce the original DER encoding. Therefore, LDAP-specific encodings should not be used where reversibility to DER is needed; e.g., for the verification of digital signatures. Instead, DER or a DER-reversible encoding should be used.
その上、LDAP特有のencodingsは、必ずディレクトリStringとDN構文の値をコード化する代替手段が再建されるのを可能にするというわけではありません。 例えば、LDAP特有のコード化と後部にコード化するDistinguished Encoding Rules(DER)[BER]からDERコード化までの変換はオリジナルのDERコード化を再生させないかもしれません。 したがって、DERへのリバーシブルが必要であるところでLDAP特有のencodingsを使用するべきではありません。 例えば、デジタル署名の検証のために。 代わりに、DERかDERリバーシブルのコード化が使用されるべきです。
When interpreting security-sensitive fields (in particular, fields used to grant or deny access), implementations MUST ensure that any matching rule comparisons are done on the underlying abstract value, regardless of the particular encoding used.
セキュリティ敏感な分野(特に、分野は、アクセスを承諾するか、または拒絶するのを使用した)を解釈するとき、実装は、基本的な抽象的な値でどんな合っている規則比較もするのを確実にしなければなりません、使用される特定のコード化にかかわらず。
6. Acknowledgements
6. 承認
This document is primarily a revision of RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working Group.
このドキュメントは主としてM.ウォール、A.Coulbeck、T.ハウズ、およびS.KilleによるRFC2252の改正です。 RFC2252はIETF ASID作業部会の製品でした。
Legg Standards Track [Page 44] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[44ページ]: 構文と2006年6月に規則を合わせること。
This document is based on input from the IETF LDAPBIS working group. The author would like to thank Kathy Dally for editing the early drafts of this document, and Jim Sermersheim and Kurt Zeilenga for their significant contributions to this revision.
このドキュメントはIETF LDAPBISワーキンググループからの入力に基づいています。 このドキュメントの早めの草稿を編集して頂いて、キャシー・ダリーに感謝します、そして、作者は、この改正への彼らの重要な貢献のためにジムSermersheimとカートZeilengaに感謝したいです。
7. IANA Considerations
7. IANA問題
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [BCP64] as indicated by the following templates:
インターネットAssigned民数記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
Subject: LDAP Descriptor Registration Update Descriptor(省略名)のために以下を要求してください。 コメントObject Identifierを見てください: 詳細のために連絡するコメントPersonとEメールアドレスを見てください: スティーブン Legg <steven.legg@eb2bcom.com 、gt;、用法: コメントSpecificationを見てください: RFC4517作者/変化コントローラ: 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
名前タイプOID------------------------------------------------------------------ bitStringMatch M2.5.13.16booleanMatch M2.5.13.13caseExactIA5Match M1.3.6.1.4.1.1466.109.114.1caseExactMatch M2.5、.13.5caseExactOrderingMatch M2.5.13.6caseExactSubstringsMatch M2.5.13.7caseIgnoreIA5Match M1.3.6.1.4.1.1466.109.114.2caseIgnoreListMatch M2.5.13.11caseIgnoreListSubstringsMatch M2.5.13.12caseIgnoreMatch M2.5.13.2caseIgnoreOrderingMatch M、2.5.13.3caseIgnoreSubstringsMatch M2.5.13.4directoryStringFirstComponentMatch M、2.5、.13; 31、distinguishedNameMatch M2.5.13.1generalizedTimeMatch M2.5.13.27generalizedTimeOrderingMatch M2.5.13.28integerFirstComponentMatch M2.5.13.29integerMatch M2.5.13.14integerOrderingMatch M2.5.13.15keywordMatch M2.5.13、.33numericStringMatch M、2.5.13.8numericStringOrderingMatch M2.5.13.9numericStringSubstringsMatch M2.5.13.10objectIdentifierFirstComponentMatch M2.5.13.30octetStringMatch M2.5.13.17octetStringOrderingMatch M2.5.13.18telephoneNumberMatch M2.5.13.20
Legg Standards Track [Page 45] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg規格はRFC4517LDAPを追跡します[45ページ]: 構文と2006年6月に規則を合わせること。
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32
telephoneNumberSubstringsMatch M2.5.13.21uniqueMemberMatch M2.5.13.23wordMatch M2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly
registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
It has been changed to the following, with a reference to
RFC 4517.
オブジェクト識別子のための記述子、2.5、.13、.0、objectIdentifiersMatch(異質な\'s')としてBCP64に不当に登録されました。 RFC4517の参照に応じて、それは以下に変わりました。
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
名前タイプOID------------------------------------------------------------------ objectIdentifierMatch M2.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
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
8. References
8. References
8.1. Normative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
Legg Standards Track [Page 46] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 46] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", RFC
4514, June 2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Internationalized String Preparation", RFC 4518,
June 2006.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988.
[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
[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
[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.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.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
[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
[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".
[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".
[ISO8601] ISO 8601:2004, "Data elements and interchange formats -- Information interchange -- Representation of dates and times".
Legg Standards Track [Page 47] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 47] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
[UCS] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-
1: 1993 (with amendments).
[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.
[JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992.
8.2. Informative References
8.2. Informative References
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, June
2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 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
[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)
[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)
Legg Standards Track [Page 48] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 48] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Appendix A. Summary of Syntax Object Identifiers
Appendix A. Summary of Syntax Object Identifiers
The following list summarizes the object identifiers assigned to the syntaxes defined in this document.
The following list summarizes the object identifiers assigned to the syntaxes defined in this document.
Syntax OBJECT IDENTIFIER
==============================================================
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
Syntax OBJECT IDENTIFIER ============================================================== 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
Appendix B. Changes from RFC 2252
Appendix B. Changes from RFC 2252
This annex lists the significant differences between this specification and RFC 2252.
This annex lists the significant differences between this specification and RFC 2252.
Legg Standards Track [Page 49] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 49] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
This annex is provided for informational purposes only. It is not a normative part of this specification.
This annex is provided for informational purposes only. It is not a normative part of this specification.
1. The IESG Note has been removed.
1. The IESG Note has been removed.
2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
and revised. Changes to the parts of these sections moved to
[RFC4512] are detailed in [RFC4512].
2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] and revised. Changes to the parts of these sections moved to [RFC4512] are detailed in [RFC4512].
3. BNF descriptions of syntax formats have been replaced by ABNF
[RFC4234] specifications.
3. BNF descriptions of syntax formats have been replaced by ABNF [RFC4234] specifications.
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
use of a backslash quoting mechanism to escape separator symbols
has been removed. The escaping mechanism is now explicitly
represented in the ABNF for the syntaxes where this provision
applies.
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the use of a backslash quoting mechanism to escape separator symbols has been removed. The escaping mechanism is now explicitly represented in the ABNF for the syntaxes where this provision applies.
5. The description of each of the LDAP syntaxes has been expanded so
that they are less dependent on knowledge of X.500 for
interpretation.
5. The description of each of the LDAP syntaxes has been expanded so that they are less dependent on knowledge of X.500 for interpretation.
6. The relationship of LDAP syntaxes to corresponding ASN.1 type
definitions has been made explicit.
6. The relationship of LDAP syntaxes to corresponding ASN.1 type definitions has been made explicit.
7. The set of characters allowed in a <PrintableString> (formerly
<printablestring>) has been corrected to align with the
PrintableString ASN.1 type in [ASN.1]. Specifically, the double
quote character has been removed and the single quote character
and equals sign have been added.
7. The set of characters allowed in a <PrintableString> (formerly <printablestring>) has been corrected to align with the PrintableString ASN.1 type in [ASN.1]. Specifically, the double quote character has been removed and the single quote character and equals sign have been added.
8. Values of the Directory String, Printable String and Telephone
Number syntaxes are now required to have at least one character.
8. Values of the Directory String, Printable String and Telephone Number syntaxes are now required to have at least one character.
9. The <DITContentRuleDescription>, <NameFormDescription> and
<DITStructureRuleDescription> rules have been moved to [RFC4512].
9. The <DITContentRuleDescription>, <NameFormDescription> and <DITStructureRuleDescription> rules have been moved to [RFC4512].
10. The corresponding ASN.1 type for the Other Mailbox syntax has
been incorporated from RFC 1274.
10. The corresponding ASN.1 type for the Other Mailbox syntax has been incorporated from RFC 1274.
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
has been invented.
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax has been invented.
12. The Binary syntax has been removed because it was not adequately
specified, implementations with different incompatible
interpretations exist, and it was confused with the ;binary
transfer encoding.
12. The Binary syntax has been removed because it was not adequately specified, implementations with different incompatible interpretations exist, and it was confused with the ;binary transfer encoding.
Legg Standards Track [Page 50] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 50] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
13. All discussion of transfer options, including the ";binary"
option, has been removed. All imperatives regarding binary
transfer of values have been removed.
13. All discussion of transfer options, including the ";binary" option, has been removed. All imperatives regarding binary transfer of values have been removed.
14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
Terminal Identifier and Telex Number syntaxes from RFC 2256 have
been incorporated.
14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex Terminal Identifier and Telex Number syntaxes from RFC 2256 have been incorporated.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
been extended to accommodate empty "and" and "or" expressions.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has been extended to accommodate empty "and" and "or" expressions.
16. An encoding for the <ttx-value> rule in the Teletex Terminal
Identifier syntax has been defined.
16. An encoding for the <ttx-value> rule in the Teletex Terminal Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair) have been removed. They are reintroduced in
[RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
17. The PKI-related syntaxes (Certificate, Certificate List and Certificate Pair) have been removed. They are reintroduced in [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity.
18. The MHS OR Address syntax has been removed since its specification (in RFC 2156) is not at draft standard maturity.
19. The DL Submit Permission syntax has been removed as it depends on
the MHS OR Address syntax.
19. The DL Submit Permission syntax has been removed as it depends on the MHS OR Address syntax.
20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity.
20. The Presentation Address syntax has been removed since its specification (in RFC 1278) is not at draft standard maturity.
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
Type, LDAP Schema Description, Master And Shadow Access Points,
Modify Rights, Protocol Information, Subtree Specification,
Supplier Information, Supplier Or Consumer and Supplier And
Consumer syntaxes have been removed. These syntaxes are
referenced in RFC 2252, but not defined.
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE Type, LDAP Schema Description, Master And Shadow Access Points, Modify Rights, Protocol Information, Subtree Specification, Supplier Information, Supplier Or Consumer and Supplier And Consumer syntaxes have been removed. These syntaxes are referenced in RFC 2252, but not defined.
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
Mail Preference syntax have been removed on the grounds that they
are out of scope for the core specification.
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the Mail Preference syntax have been removed on the grounds that they are out of scope for the core specification.
23. The description of each of the matching rules has been expanded
so that they are less dependent on knowledge of X.500 for
interpretation.
23. The description of each of the matching rules has been expanded so that they are less dependent on knowledge of X.500 for interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
been added.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has been added.
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreSubstringsMatch matching rules have been added to the
list of matching rules for which the provisions for handling
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules have been added to the list of matching rules for which the provisions for handling
Legg Standards Track [Page 51] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 51] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
leading, trailing and multiple adjoining whitespace characters
apply (now through string preparation). This is consistent with
the definitions of these matching rules in X.500. The
caseIgnoreIA5SubstringsMatch rule has also been added to the
list.
leading, trailing and multiple adjoining whitespace characters apply (now through string preparation). This is consistent with the definitions of these matching rules in X.500. The caseIgnoreIA5SubstringsMatch rule has also been added to the list.
26. The specification of the octetStringMatch matching rule from
RFC 2256 has been added to this document.
26. The specification of the octetStringMatch matching rule from RFC 2256 has been added to this document.
27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity.
27. The presentationAddressMatch matching rule has been removed as it depends on an assertion syntax (Presentation Address) that is not at draft standard maturity.
28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information).
28. The protocolInformationMatch matching rule has been removed as it depends on an undefined assertion syntax (Protocol Information).
29. The definitive reference for ASN.1 has been changed from X.208 to
X.680 since X.680 is the version of ASN.1 referred to by X.500.
29. The definitive reference for ASN.1 has been changed from X.208 to X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added.
30. The specification of the caseIgnoreListSubstringsMatch matching rule from RFC 2798 & X.520 has been added.
31. String preparation algorithms have been applied to the character
string matching rules.
31. String preparation algorithms have been applied to the character string matching rules.
32. The specifications of the booleanMatch, caseExactMatch,
caseExactOrderingMatch, caseExactSubstringsMatch,
directoryStringFirstComponentMatch, integerOrderingMatch,
keywordMatch, numericStringOrderingMatch,
octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added.
32. The specifications of the booleanMatch, caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch, directoryStringFirstComponentMatch, integerOrderingMatch, keywordMatch, numericStringOrderingMatch, octetStringOrderingMatch and wordMatch matching rules from RFC 3698 & X.520 have been added.
Author's Address
Author's Address
Steven Legg eB2Bcom Suite3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
Steven Legg eB2Bcom Suite3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com
Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com
Legg Standards Track [Page 52] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Legg Standards Track [Page 52] RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
Legg Standards Track [Page 53]
Legg Standards Track [Page 53]
一覧
スポンサーリンク
