ldap objectclass
AKBK Home :: LDAP
:: ObjectClasses ::
Object Class: organizationalRole
ID: 2.5.6.8
Example:
dn: cn=Directory Manager, o=SWITCH, c=CH
objectClass:top
objectClass:organizationalRole
cn:Directory Manager
description:SWITCH Directory Managers
roleOccupant:CN=Martin Berli, O=SWITCH, C=CH
roleOccupant:CN=Thomas Lenggenhager, O=SWITCH, C=CH
l:Zuerich
l:Zurich
l:{T.61}Z\c8urich
st:Zurich
st:Zuerich
st:ZH
st:{T.61}Z\c8urich
postalAddress:SWITCHdirectory $ SWITCH $
Limmatquai 138 $ CH-8001 Zurich
postalCode:CH-8001
street:Limmatquai 138
telephoneNumber:+41 1 268 1540
facsimileTelephoneNumber:+41 1 268 1568
BNC Syntax: 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MAY ( description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ preferredDeliveryMethod $ registeredAddress $ roleOccupant $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ x121Address )
MUST ( cn )
rfc1617
Extends objectClass:
Attributes:
Attribute: cn
(based on attribute name)
Description:
This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.
BNC Syntax: 2.5.4.3 NAME 'cn'
SUP name
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
This attribute contains a human-readable description of the object.
A short informal explanation of special interests of a person or organisation. Overlap with businessCategory, organizationalStatus and title should be avoided.
Example:
Networking, distributed systems, OSI, implementation.
BNC Syntax: 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
This attribute is used for the telegram service.
BNC Syntax: 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.44
The encoding of a value in this syntax is the string value itself. PrintableString is limited to the characters in production p of section 4.1.
Example:
This is a PrintableString
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
The phone number in the international notation according to CCITT E.123. The separator `-` instead of space may be used according to the local habit, it should be used consistently within a country.
Format: "+" ["x" ]
Example: +41 1 268 1540
BNC Syntax: 2.5.4.23 NAME 'facsimileTelephoneNumber'
ID : 1.3.6.1.4.1.1466.115.121.1.22
Facsimile Telephone Number
Values in this syntax are encoded according to the following BNF:
fax-number = printablestring [ "$" faxparameters ]
faxparameters = faxparm / ( faxparm "$" faxparameters )
faxparm = "twoDimensional" / "fineResolution" /
"unlimitedLength" /
"b4Length" / "a3Width" / "b4Width" / "uncompressed"
In the above, the first printablestring is the telephone number, based on E.123 [15], and the faxparm tokens represent fax parameters.
BNC Syntax:
Description:
BNC Syntax: 2.5.4.25 NAME 'internationaliSDNNumber'
EQUALITY numericStringMatch
ID : 1.3.6.1.4.1.1466.115.121.1.36
The encoding of a string in this syntax is the string value itself.
Example:
1997
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Attribute: l
(based on attribute name)
Description:
This attribute contains the name of a locality, such as a city, county or other geographic region (localityName).
Example:
Bale
B\c3ale (with a T.61 encoded accented character) Basel
Basilea
Basle
BNC Syntax: 2.5.4.7 NAME 'l'
SUP name
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
An LDAP server implementation SHOULD recognize the attribute types described in this section. The values of the objectClass attribute describe the kind of object which an entry represents. The objectClass attribute is present in every entry, with at least two values. One of the values is either "top" or "alias".
BNC Syntax: 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
Syntax: OID
ID : 1.3.6.1.4.1.1466.115.121.1.38
Values in the Object Identifier syntax are encoded according to the BNF in section 4.1 for "oid".
Example:
1.2.3.4
cn
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
If the client supplies a filter using an objectIdentifierMatch whose
matchValue oid is in the "descr" form, and the oid is not recognized
by the server, then the filter is Undefined.
BNC Syntax:
Attribute: ou
(based on attribute name)
Description:
This attribute contains the name of an organizational unit (organizationalUnitName).
The name of a part of the organisation. Additional names like abbreviations should be provided for better search results.
Example:
Institut fuer Angewandte Mathematik
Mathematik
iam
BNC Syntax: 2.5.4.11 NAME 'ou'
SUP name
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
BNC Syntax: 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
BNC Syntax: 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
The full postal address (but not including the name) in international notation, with up to 6 lines with 30 characters each.
Example: SWITCH
Limmatquai 13
CH-8001 Zurich
BNC Syntax: 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
ID : 1.3.6.1.4.1.1466.115.121.1.41
Values in this syntax are encoded according to the following BNF:
postal-address = dstring *( "$" dstring )
In the above, each dstring component of a postal address value is encoded as a value of type Directory String syntax. Backslashes and dollar characters, if they occur in the component, are quoted as described in section 4.3. Many servers limit the postal address to six lines of up to thirty characters.
Example:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
BNC Syntax:
Description:
The postalCode will be the same as used in the postalAddress (i international notation).
Example: CH-8001
BNC Syntax: 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
BNC Syntax: 2.5.4.28 NAME 'preferredDeliveryMethod'
ID : 1.3.6.1.4.1.1466.115.121.1.14
Servers SHOULD recognize the syntaxes defined in this section. Each syntax begins with a sample value of the ldapSyntaxes attribute which defines the OBJECT IDENTIFIER of the syntax. The descriptions of syntax names are not carried in protocol, and are not guaranteed to be unique.
Values in this syntax are encoded according to the following BNF:
delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
Example:
telephone
BNC Syntax:
(based on attribute postalAddress)
Description:
This attribute holds a postal address suitable for reception of telegrams or expedited documents, where it is necessary to have the recipient accept delivery.
BNC Syntax: 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress
EQUALITY caseIgnoreListMatch
ID : 1.3.6.1.4.1.1466.115.121.1.41
Values in this syntax are encoded according to the following BNF:
postal-address = dstring *( "$" dstring )
In the above, each dstring component of a postal address value is encoded as a value of type Directory String syntax. Backslashes and dollar characters, if they occur in the component, are quoted as described in section 4.3. Many servers limit the postal address to six lines of up to thirty characters.
Example:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
BNC Syntax:
(based on attribute distinguishedName)
Description:
The person(s) in that role. This is the Distinguished Name of the entry of the person(s).
Example:
CN=Beverly Pyke, O=ISODE Consortium, C=GB
BNC Syntax: 2.5.4.33 NAME 'roleOccupant'
SUP distinguishedName
EQUALITY distinguishedNameMatch
Syntax: DN
ID : 1.3.6.1.4.1.1466.115.121.1.12
Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known.
Examples (from [5]):
CN=Steve Kille,O=Isode Limited,C=GB
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=Before\0DAfter,O=Test,C=GB
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
SN=Lu\C4\8Di\C4\87
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
(based on attribute distinguishedName)
Description:
Reference to another closely related entry in the DIT, e.g., from a room to the person using that room. It is the Distinguished Name of the entry.
Example:
CN=Beverly Pyke, O=ISODE Consortium, C=GB
BNC Syntax: 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName
EQUALITY distinguishedNameMatch
Syntax: DN
ID : 1.3.6.1.4.1.1466.115.121.1.12
Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known.
Examples (from [5]):
CN=Steve Kille,O=Isode Limited,C=GB
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=Before\0DAfter,O=Test,C=GB
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
SN=Lu\C4\8Di\C4\87
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Attribute: st
(based on attribute name)
Description:
This attribute contains the full name of a state or province (stateOrProvinceName).
Name of the canton, county, department, province or state with values in local and other languages as useful. If official and commonly used abbreviations exist for the states, they should be supplied as additional values
Example:
Ticino
Tessin
TI
BNC Syntax: 2.5.4.8 NAME 'st'
SUP name
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery (streetAddress).
It shall be the street where the person has its office. Mostly, it will be the street part of the postalAddress.
Example: Limmatquai 138
BNC Syntax: 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
The phone number in the international notation according to CCITT E.123. The separator '-' instead of space may be used according to the local habit, it should be used consistently within a country.
Format: "+" ["x" ]
Example: +41 1 268 1540
BNC Syntax: 2.5.4.20 NAME 'telephoneNumber'
EQUALITY telephoneNumberMatch
ID : 1.3.6.1.4.1.1466.115.121.1.50
Values in this syntax are encoded as if they were Printable String types. Telephone numbers are recommended in X.520 to be in international form, as described in E.123 [15].
Example:
+1 512 305 0280
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
BNC Syntax: 2.5.4.22 NAME 'teletexTerminalIdentifier'
ID : 1.3.6.1.4.1.1466.115.121.1.51
Values in this syntax are encoded according to the following BNF:
teletex-id = ttx-term 0*("$" ttx-param)
ttx-term = printablestring
ttx-param = ttx-key ":" ttx-value
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = octetstring
In the above, the first printablestring is the encoding of the first portion of the teletex terminal identifier to be encoded, and the subsequent 0 or more octetstrings are subsequent portions of the teletex terminal identifier.
BNC Syntax:
Description:
The telex number in the international notation
Example: 817379, ch, ehhg
BNC Syntax: 2.5.4.21 NAME 'telexNumber'
ID : 1.3.6.1.4.1.1466.115.121.1.52
Values in this syntax are encoded according to the following BNF:
telex-number = actual-number "$" country "$" answerback
actual-number = printablestring
country = printablestring
answerback = printablestring
In the above, actual-number is the syntactic representation of the number portion of the TELEX number being encoded, country is the TELEX country code, and answerback is the answerback code of a TELEX terminal.
BNC Syntax:
Description:
BNC Syntax: 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch
ID : 1.3.6.1.4.1.1466.115.121.1.36
The encoding of a string in this syntax is the string value itself.
Example:
1997
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
|
