Ldap Schema Viewer
Objectclass : inetOrgPerson
ID: 2.16.840.1.113730.3.2.2
The inetOrgPerson represents people who are associated with an organization in some way. It is a structural class and is derived from the organizationalPerson class which is defined in [X521].
Example of an inetOrgPerson Entry
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Barbara Jensen
cn: Babs Jensen
sn: Jensen
givenName: Barbara
initials: BJJ
title: manager, product development
uid: bjensen
mail: bjensen@aceindustry.com
telephoneNumber: +1 408 555 1862
facsimileTelephoneNumber: +1 408 555 1992
mobile: +1 408 555 1941
roomNumber: 0209
carLicense: 6ABC246
departmentNumber: 2604
employeeNumber: 42
employeeType: full time
preferredLanguage: fr, en-gb;q=0.8, en;q=0.7
labeledURI: http://www.aceindustry.com/users/bjensen My Home Page
BNC Syntax: 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 )
rfc2798
Extends objectClass:
Attributes:
Requires :
May Have:
Comments
Attribute: audio
Description:
Note: The syntax used here for the audio attribute type is Octet String. RFC 1274 uses a syntax called audio which is not defined in RFC 1274.
BNC Syntax: NAME 'audio' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{250000}
rfc1274
ID : 1.3.6.1.4.1.1466.115.121.1.40
Values in this syntax are encoded as octet strings.
Example:
secret
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String'
rfc2256
Description:
Servers which implement the extensibleMatch filter SHOULD allow the
matching rule listed in this section to be used in the
extensibleMatch. In general these servers SHOULD allow matching
rules to be used with all attribute types known to the server, when
the assertion syntax of the matching rule is the same as the value
syntax of the attribute.
BNC Syntax: 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
Description:
This attribute describes the kind of business performed by an organization.
BNC Syntax: 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description: vehicle license or registration plate
This multivalued field is used to record the values of the license or registration plate associated with an individual.
BNC Syntax: 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'vehicle license or registration plate' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
Description: identifies a department within an organization
Code for department to which a person belongs. This can also be strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123).
BNC Syntax: 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'identifies a department within an organization' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
Description: preferred name of a person to be used when displaying entries
When displaying an entry, especially within a one-line summary list, itis useful to be able to identify a name to be used. Since other attri-bute types such as 'cn' are multivalued, an additional attribute type isneeded. Display name is defined for this purpose.
BNC Syntax: 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'preferred name of a person to be used when displaying entries' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
draft-smith-ldap-inetorgperson-01
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
Description: numerically identifies an employee within an organization
Numeric or alphanumeric identifier assigned to a person, typically basedon order of hire or association with an organization. Single valued.
BNC Syntax: 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'numerically identifies an employee within an organization' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
Description: type of employment for a person
Used to identify the employer to employee relationship. Typical valuesused will be "Contractor", "Employee", "Intern", "Temp", "External", and "Unknown" but any value may be used.
BNC Syntax: 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'type of employment for a person' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
(based on attribute name)
Description:
The givenName attribute is used to hold the part of a person's name which is not their surname nor middle name.
BNC Syntax: 2.5.4.42 NAME 'givenName' SUP name
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description:
Note: RFC 1274 uses the longer name 'homeTelephoneNumber'.
BNC Syntax: 0.9.2342.19200300.100.1.20 NAME 'homePhone' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc1274
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: 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'
rfc2252
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: 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2252
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: 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
BNC Syntax: 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41
rfc1274
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: 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address'
rfc2252
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: 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41
rfc2252
(based on attribute name)
Description:
The initials attribute contains the initials of some or all of an individuals names, but not the surname(s).
BNC Syntax: 2.5.4.43 NAME 'initials' SUP name
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description: a JPEG image
Used to store one or more images of a person using the JPEG File Interchange Format
Note that the jpegPhoto attribute type was defined for use in the Inter-net X.500 pilots but no referencable definition for it could be located.
BNC Syntax: 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'a JPEG image' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28
rfc2798
ID : 1.3.6.1.4.1.1466.115.121.1.28
Values in this syntax are encoded as strings containing JPEG images in the JPEG File Interchange Format (JFIF), as described in JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG'
rfc2252
Description:
Examples of labeledURI Attribute Values from [RFC 2079]
An example of a labeledURI attribute value that does not include a label:
ftp://ds.internic.net/rfc/rfc822.txt
An example of a labeledURI attribute value that contains a tilde character in the URL (special characters in a URL must be encoded as specified by the URL document [1]). The label is "LDAP Home Page":
http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
Another example. This one includes a hint in the label to help the user realize that the URL points to a photo image.
http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]
BNC Syntax: 1.3.6.1.4.1.250.1.57 NAME 'labeledURI' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Attribute: mail
Description:
Note: RFC 1274 uses the longer name `rfc822Mailbox`
Note: changed syntax from 0.9.2342.19200300.100.3.5{256} to IA4 string
BNC Syntax: 0.9.2342.19200300.100.1.3 NAME 'mail' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
rfc1274
ID : 1.3.6.1.4.1.1466.115.121.1.26
The encoding of a value in this syntax is the string value itself.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String'
rfc2252
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: 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
rfc2252
Description:
BNC Syntax: 0.9.2342.19200300.100.1.10 NAME 'manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN'
rfc2252
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: 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
rfc2252
Description:
Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'.
BNC Syntax: 0.9.2342.19200300.100.1.41 NAME 'mobile' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'
rfc2252
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: 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2252
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: 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Attribute: o
(based on attribute name)
Description:
This attribute contains the name of an organization (organizationName).
The name of the organisation. Additional names like abbreviations should be used for better search results.
Example:
Uni Lausanne
Universite de Lausanne
Universit\c2e Lausanne (with a T.61 encoded umlaut)
University of Lausanne
unil
BNC Syntax: 2.5.4.10 NAME 'o' SUP name
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Attribute: pager
Description:
Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'.
BNC Syntax: 0.9.2342.19200300.100.1.42 NAME 'pager' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'
rfc2252
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: 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2252
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: 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Attribute: photo
Description:
Note: Photo attribute values are encoded in G3 fax format with an ASN.1 wrapper.
The Photo attribute type specifies a "photograph" for an object.
This should be encoded in G3 fax as explained in recommendation T.4,
with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as
defined in X.420.
Note: Assumed syntax is FAX
BNC Syntax: 0.9.2342.19200300.100.1.7 NAME 'photo' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23
rfc2798
Syntax: Fax
ID : 1.3.6.1.4.1.1466.115.121.1.23
Values in this syntax are encoded as if they were octet strings containing Group 3 Fax images as defined in .
Terminal Equipment and Protocols for Telematic Services -
Standardization of Group 3 facsimile apparatus for document
transmission. CCITT, Recommendation T.4.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax'
rfc2252
Description:
BNC Syntax: 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
BNC Syntax: 0.9.2342.19200300.100.1.21 NAME 'secretary' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN'
rfc2252
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: 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
rfc2252
Attribute: uid
Description:
Note: RFC 1274 uses the longer name `userid`.
BNC Syntax: 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
This attribute is to be stored and requested in the binary form, as 'userCertificate;binary'.
BNC Syntax: 2.5.4.36 NAME 'userCertificate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.8
rfc2256
ID : 1.3.6.1.4.1.1466.115.121.1.8
Because of the changes from X.509(1988) and X.509(1993) and additional changes to the ASN.1 definition to support certificate extensions, no string representation is defined, and values in this syntax MUST only be transferred using the binary encoding, by requesting or returning the attributes with descriptions "userCertificate;binary" or "caCertificate;binary". The BNF notation in RFC 1778 for "User Certificate" is not recommended to be used.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate'
rfc2252
Description:
The x500UniqueIdentifier attribute is used to distinguish between objects when a distinguished name has been reused. This is a different attribute type from both the "uid" and "uniqueIdentifier" types.
BNC Syntax: 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
rfc2256
ID : 1.3.6.1.4.1.1466.115.121.1.6
Values in this syntax are encoded according to the following BNF:
bitstring = "`" *binary-digit "`B"
binary-digit = "0" / "1"
Example:
`0101111101`B
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String'
rfc2252
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: 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
rfc2252
Description: preferred written or spoken language for a person
Used to indicate an individual's preferred written or spoken language.This is useful for international correspondence or human-computer interaction. Values for this attribute type MUST conform to the definition of the Accept-Language header field defined in [RFC2068] with one exception: the sequence "Accept-Language" ":" should be omitted. This is a single valued attribute type.
BNC Syntax: 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'preferred written or spoken language for a person' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
rfc2798
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
Description: signed message used to support S/MIME
An S/MIME [RFC1847] signed message with a zero-length body. This attribute is to be stored and requested in binary form, as 'userSMIMECertificate;binary'. It contains the person's entire certificate chain and the signed attribute that describes their algorithm capabilities, stored as an octetString. If available, this attribute is preferred over the userCertificate attribute for S/MIME applications.
BNC Syntax: 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' DESC 'signed message used to support S/MIME' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
rfc2798
ID : 1.3.6.1.4.1.1466.115.121.1.40
Values in this syntax are encoded as octet strings.
Example:
secret
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String'
rfc2256
Description: PKCS #12 PFX PDU for exchange of personal identity information
PKCS #12 [PKCS12] provides a format for exchange of personal identity information. When such information is stored in a directory service, the userPKCS12 attribute should be used. This attribute is to be stored and requested in binary form, as 'userPKCS12;binary'. The attribute values are PFX PDUs stored as octetStrings.
[PKCS12]
"PKCS #12: Personal Information Exchange Standard", Version 1.0 DRAFT, 30 April 1997.
BNC Syntax: 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'PKCS #12 PFX PDU for exchange of personal identity information' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
rfc2798
ID : 1.3.6.1.4.1.1466.115.121.1.40
Values in this syntax are encoded as octet strings.
Example:
secret
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String'
rfc2256
Attribute: title
(based on attribute name)
Description:
This attribute contains the title, such as "Vice President", of a person in their organizational context. The "personalTitle" attribute would be used for a person's title independent of their job function.
BNC Syntax: 2.5.4.12 NAME 'title' SUP name
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description:
BNC Syntax: 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String'
rfc2252
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: 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
rfc2252
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: 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
(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 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address'
rfc2252
Description:
This attribute is used for the telegram service.
BNC Syntax: 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
BNC Syntax: 2.5.4.28 NAME 'preferredDeliveryMethod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method'
rfc2256
Description:
The telex number in the international notation
Example: 817379, ch, ehhg
BNC Syntax: 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number'
rfc2256
Description:
BNC Syntax: 2.5.4.22 NAME 'teletexTerminalIdentifier' SYNTAX 1.3.6.1.4.1.1466.115.121.1.51
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier'
rfc2256
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 SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'
rfc2252
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: 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2252
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: 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
BNC Syntax: 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String'
rfc2252
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: 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
rfc2252
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: 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
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' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number'
rfc2252
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 SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
Description:
BNC Syntax: 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
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 SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40}
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
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 SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address'
rfc2252
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: 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41
rfc2252
Description:
BNC Syntax: 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
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
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Attribute: sn
(based on attribute name)
Description:
This is the X.500 surname attribute, which contains the family name of a person.
BNC Syntax: 2.5.4.4 NAME 'sn' SUP name
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
Description:
from earlier rfc2256:
Passwords are stored using an Octet String syntax and are not encrypted. Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
from later rfc2307
An entry of class posixAccount, posixGroup, or shadowAccount without A userPassword attribute MUST NOT be used for authentication. The client should be returned a non-matchable password such as "x".
userPassword values MUST be represented by following syntax:
passwordvalue = schemeprefix encryptedpassword
schemeprefix = "{" scheme "}"
scheme = "crypt" / "md5" / "sha" / altscheme
altscheme = "x-" keystring
encryptedpassword = encrypted password
The encrypted password contains of a plaintext key hashed using the algorithm scheme.
userPassword values which do not adhere to this syntax MUST NOT be used for authentication. The DUA MUST iterate through the values of the attribute until a value matching the above syntax is found. Only if encryptedpassword is an empty string does the user have no password. DUAs are not required to consider encryption schemes which the client will not recognize; in most cases, it may be sufficient to consider only "crypt".
Below is an example of a userPassword attribute:
userPassword: {crypt}X5/DBrWPOQQaI
A future standard may specify LDAP v3 attribute descriptions to represent hashed userPasswords, as noted below. This schema MUST NOT be used with LDAP v2 DUAs and DSAs.
attributetype = attributename sep attributeoption
attributename = "userPassword"
sep = ";"
attributeoption = schemeclass "-" scheme
schemeclass = "hash" / altschemeclass
scheme = "crypt" / "md5" / "sha" / altscheme
altschemeclass = "x-" keystring
altscheme = keystring
Below is an example of a userPassword attribute, represented with an LDAP v3 attribute description:
userPassword;hash-crypt: X5/DBrWPOQQaI
A DUA MAY utilise the attributes in the shadowAccount class to provide shadow password service (getspnam() and getspent()). In such cases, the DUA MUST NOT make use of the userPassword attribute for getpwnam() et al, and MUST return a non-matchable password (such as "x") to the client instead.
BNC Syntax: 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128}
rfc2307
ID : 1.3.6.1.4.1.1466.115.121.1.40
Values in this syntax are encoded as octet strings.
Example:
secret
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String'
rfc2256
Description:
Servers which implement the extensibleMatch filter SHOULD allow the
matching rule listed in this section to be used in the
extensibleMatch. In general these servers SHOULD allow matching
rules to be used with all attribute types known to the server, when
the assertion syntax of the matching rule is the same as the value
syntax of the attribute.
BNC Syntax: 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
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 SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32}
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'
rfc2252
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: 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
rfc2252
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: 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
(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
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN'
rfc2252
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 SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
rfc1617
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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'
rfc2252
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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
rfc2252
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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58
rfc2252
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 1.3.6.1.4.1.1466.115.121.1.38
rfc2256
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: 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID'
rfc2252
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: 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
rfc2252
|