Roo J Solutions Ltd
LDAP Schema | Roo J Solutions Ltd. >>>
ldap objectclass
Roojs :: LDAP :: ObjectClasses ::

Object Class: 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 $ preferredLanguage $ roomNumber $ secretary $ uid $ userCertificate $ userPKCS12 $ userSMIMECertificate $ x500uniqueIdentifier ) 

rfc2798

Extends objectClass:

Attributes:

Must Have:
  • objectClass (Inherited from top)
  • cn (Inherited from person)
  • sn (Inherited from person)
May Have:


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 NAME 'audio' EQUALITY octetStringMatch

Syntax: Octet String

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:

Equality Matching: octetStringMatch

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: 




Attribute:  businessCategory 

Description:
This attribute describes the kind of business performed by an organization.

BNC Syntax: 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  carLicense 

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' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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:  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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  departmentNumber 

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' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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:  description 

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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  destinationIndicator 

Description:
This attribute is used for the telegram service.

BNC Syntax: 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch

Syntax: Printable String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  displayName 

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' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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:  employeeNumber 

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' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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:  employeeType 

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' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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:  facsimileTelephoneNumber 

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: Facsimile Telephone Number

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:



Attribute:  givenName 

(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 EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  homePhone 

Description:
Note: RFC 1274 uses the longer name 'homeTelephoneNumber'.

BNC Syntax: 0.9.2342.19200300.100.1.20 NAME 'homePhone' EQUALITY telephoneNumberMatch

Syntax: Telephone Number

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:

Equality Matching: telephoneNumberMatch

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: 

Substring Matching: telephoneNumberSubstringsMatch

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:  homePostalAddress 

Description:


BNC Syntax: 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' EQUALITY caseIgnoreListMatch

Syntax: Postal Address

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:

Equality Matching: caseIgnoreListMatch

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: 

Substring Matching: caseIgnoreListSubstringsMatch

Description:


BNC Syntax:


 


Attribute:  initials 

(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 EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  internationaliSDNNumber 

Description:


BNC Syntax: 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch

Syntax: Numeric String

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:

Equality Matching: numericStringMatch

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: 

Substring Matching: numericStringSubstringsMatch

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:  jpegPhoto 

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'

Syntax: JPEG

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:



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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  labeledURI 

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

Syntax: Directory String

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:

Equality Matching: caseExactMatch

Description:


BNC Syntax: 


Substring Matching: caseExactSubstringsMatch

Description:


BNC Syntax:


 


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

Syntax: IA5 String

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:

Equality Matching: caseIgnoreIA5Match

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: 

Substring Matching: caseIgnoreIA5SubstringsMatch

Description:


BNC Syntax:


 


Attribute:  manager 

Description:


BNC Syntax: 0.9.2342.19200300.100.1.10 NAME 'manager' 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:

Equality Matching: distinguishedNameMatch

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:  mobile 

Description:
Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'.

BNC Syntax: 0.9.2342.19200300.100.1.41 NAME 'mobile' EQUALITY telephoneNumberMatch

Syntax: Telephone Number

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:

Equality Matching: telephoneNumberMatch

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: 

Substring Matching: telephoneNumberSubstringsMatch

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:  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 EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  objectClass 

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:

Equality Matching: objectIdentifierMatch

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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  pager 

Description:
Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'.

BNC Syntax: 0.9.2342.19200300.100.1.42 NAME 'pager' EQUALITY telephoneNumberMatch

Syntax: Telephone Number

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:

Equality Matching: telephoneNumberMatch

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: 

Substring Matching: telephoneNumberSubstringsMatch

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:  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: 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:



Attribute:  physicalDeliveryOfficeName 

Description:


BNC Syntax: 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  postOfficeBox 

Description:


BNC Syntax: 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  postalAddress 

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

Syntax: Postal Address

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:

Equality Matching: caseIgnoreListMatch

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: 

Substring Matching: caseIgnoreListSubstringsMatch

Description:


BNC Syntax:


 


Attribute:  postalCode 

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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  preferredDeliveryMethod 

Description:


BNC Syntax: 2.5.4.28 NAME 'preferredDeliveryMethod'

Syntax: Delivery Method

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:



Attribute:  preferredLanguage 

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' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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:  registeredAddress 

(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

Syntax: Postal Address

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:

Equality Matching: caseIgnoreListMatch

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: 

Substring Matching: caseIgnoreListSubstringsMatch

Description:


BNC Syntax:


 


Attribute:  roomNumber 

Description:


BNC Syntax: 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  secretary 

Description:


BNC Syntax: 0.9.2342.19200300.100.1.21 NAME 'secretary' 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:

Equality Matching: distinguishedNameMatch

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:  seeAlso 

(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:

Equality Matching: distinguishedNameMatch

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:  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 EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  street 

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

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  telephoneNumber 

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

Syntax: Telephone Number

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:

Equality Matching: telephoneNumberMatch

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: 

Substring Matching: telephoneNumberSubstringsMatch

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:  teletexTerminalIdentifier 

Description:


BNC Syntax: 2.5.4.22 NAME 'teletexTerminalIdentifier'

Syntax: Teletex Terminal Identifier

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:



Attribute:  telexNumber 

Description:
The telex number in the international notation

Example: 817379, ch, ehhg


BNC Syntax: 2.5.4.21 NAME 'telexNumber'

Syntax: Telex Number

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:



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 EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  uid 

Description:
Note: RFC 1274 uses the longer name `userid`.

BNC Syntax: 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch

Syntax: Directory String

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:

Equality Matching: caseIgnoreMatch

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: 

Substring Matching: caseIgnoreSubstringsMatch

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:  userCertificate 

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: Certificate

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:



Attribute:  userPKCS12 

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'

Syntax: Octet String

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:



Attribute:  userPassword 

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: Octet String

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:

Equality Matching: octetStringMatch

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: 




Attribute:  userSMIMECertificate 

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'

Syntax: Octet String

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:



Attribute:  x121Address 

Description:


BNC Syntax: 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch

Syntax: Numeric String

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:

Equality Matching: numericStringMatch

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: 

Substring Matching: numericStringSubstringsMatch

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:  x500UniqueIdentifier 

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: Bit String

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:

Equality Matching: bitStringMatch

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: 






Contact me at alan@roojs.com - especially if you have some work for me :)