ldap objectclass
AKBK Home :: LDAP
:: ObjectClasses ::
Object Class: country
ID: 2.5.6.2
example:
dn: c=CH
c: CH
objectClass:top
objectClass:c ountry
description:Confoederatio Helvetica
description:Schweiz
description:Suisse
description:Svizzera
description:Switzerland
BNC Syntax: 2.5.6.2 NAME 'country'
SUP top
STRUCTURAL
MAY ( description
$ searchGuid )
MUST ( c )
rfc2256
Extends objectClass:
Attributes:
Attribute: c
(based on attribute name)
Description: Country Name
This attribute contains a two-letter ISO 3166 country code (countryName).
BNC Syntax: 2.5.4.6 NAME 'c'
SUP name
EQUALITY caseIgnoreMatch
ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.
For characters in the PrintableString form, the value is encoded as the string value itself.
If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].
If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.
Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.
Example:
This is a string of DirectoryString containing #!%#@
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
BNC Syntax:
Description:
The Substring Assertion is encoded according to the following BNF:
substring = [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
The production is UTF-8 encoded string. Should the backslash
or asterix characters be present in a production of , they are
quoted as described in section 4.3.
Servers SHOULD be capable of performing the following matching rules,
which are used in substring filters.
BNC Syntax:
Description:
BNC Syntax: NAME 'description
'
Description:
An LDAP server implementation SHOULD recognize the attribute types described in this section. The values of the objectClass attribute describe the kind of object which an entry represents. The objectClass attribute is present in every entry, with at least two values. One of the values is either "top" or "alias".
BNC Syntax: 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
Syntax: OID
ID : 1.3.6.1.4.1.1466.115.121.1.38
Values in the Object Identifier syntax are encoded according to the BNF in section 4.1 for "oid".
Example:
1.2.3.4
cn
BNC Syntax:
Description:
Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value
syntax.
If the client supplies a filter using an objectIdentifierMatch whose
matchValue oid is in the "descr" form, and the oid is not recognized
by the server, then the filter is Undefined.
BNC Syntax:
Description:
BNC Syntax: NAME 'searchGuid'
|
