AKBKHOME Consulting Services Available : Linux, Embedded Linux, PHP and PHP-GTK, just Contact me at alan@akbkhome.com 
LDAP Schema | PHP Code doc | AKBK Home >>> Projects | Phpmole IDE | Diary | Photos  
search for in

Ldap Schema Viewer

Objectclass : organizationalRole

ID: 2.5.6.8

Example:


dn: cn=Directory Manager, o=SWITCH, c=CH
objectClass:top
objectClass:organizationalRole
cn:Directory Manager
description:SWITCH Directory Managers
roleOccupant:CN=Martin Berli, O=SWITCH, C=CH
roleOccupant:CN=Thomas Lenggenhager, O=SWITCH, C=CH
l:Zuerich
l:Zurich
l:{T.61}Z\c8urich
st:Zurich
st:Zuerich
st:ZH
st:{T.61}Z\c8urich
postalAddress:SWITCHdirectory $ SWITCH $
Limmatquai 138 $ CH-8001 Zurich
postalCode:CH-8001
street:Limmatquai 138
telephoneNumber:+41 1 268 1540
facsimileTelephoneNumber:+41 1 268 1568

BNC Syntax: 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description )

rfc1617

Extends objectClass:

Attributes:

Requires :
May Have:


Comments

Your email address:
Add Your comments:

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

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252


Attribute: x121Address

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

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: 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String'

rfc2252

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: 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36

rfc2252

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: 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


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 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address'

rfc2252


Attribute: destinationIndicator

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

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: 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String'

rfc2252

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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

rfc2252

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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


Attribute: preferredDeliveryMethod

Description:


BNC Syntax: 2.5.4.28 NAME 'preferredDeliveryMethod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method'

rfc2256


Attribute: telexNumber

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

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: 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number'

rfc2256


Attribute: teletexTerminalIdentifier

Description:


BNC Syntax: 2.5.4.22 NAME 'teletexTerminalIdentifier' SYNTAX 1.3.6.1.4.1.1466.115.121.1.51

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier'

rfc2256


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 SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32}

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'

rfc2252

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: 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50

rfc2252

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: 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


Attribute: internationaliSDNNumber

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

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: 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String'

rfc2252

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: 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36

rfc2252

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: 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


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 1.3.6.1.4.1.1466.115.121.1.22

rfc1617

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

rfc2252


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

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


Attribute: roleOccupant

(based on attribute distinguishedName)
Description:
The person(s) in that role. This is the Distinguished Name of the entry of the person(s).

Example:

CN=Beverly Pyke, O=ISODE Consortium, C=GB


BNC Syntax: 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName

rfc2256

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


Attribute: preferredDeliveryMethod

Description:


BNC Syntax: 2.5.4.28 NAME 'preferredDeliveryMethod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method'

rfc2256


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 SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128}

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252

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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

rfc2252

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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


Attribute: postOfficeBox

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

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252

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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

rfc2252

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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


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 SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40}

rfc1617

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252

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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

rfc2252

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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


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 SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41

rfc2256

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: 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address'

rfc2252

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: 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41

rfc2252


Attribute: physicalDeliveryOfficeName

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

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252

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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

rfc2252

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

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

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

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252


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 SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}

rfc1617

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: 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

rfc2252

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: 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

rfc2252

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: 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58

rfc2252


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

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: 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38

rfc2252


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