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

ID: 2.5.6.14

No description available

BNC Syntax: 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description )

rfc2256

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

Description:
This attribute contains the serial number of a device.

BNC Syntax: 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64}

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

(based on attribute distinguishedName)
Description:


BNC Syntax: 2.5.4.32 NAME 'owner' 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: 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: o

(based on attribute name)
Description:
This attribute contains the name of an organization (organizationName).

The name of the organisation. Additional names like abbreviations should be used for better search results.

Example:

Uni Lausanne
Universite de Lausanne
Universit\c2e Lausanne (with a T.61 encoded umlaut)
University of Lausanne
unil


BNC Syntax: 2.5.4.10 NAME 'o' SUP name

rfc1617

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