| (1.3.6.1.4.1.27630.2.1.1 DESC 'attribute' ) |
OID for attributes of openosi.schema for X500 / LDAP directory
Notation
This object identifier (OID) describes attributes of openosi.schema .
ASN1 notation: {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) openosi(27630) identification(2) schema(1) attribute(1)}
URN notation: urn:oid:1.3.6.1.4.1.27630.2.1.1
IETF DOT notation: 1.3.6.1.4.1.27630.2.1.1
BNF notation (RFC822 Backus-Naur form): ( 1.3.6.1.4.1.27630.2.1.1 DESC 'attribute' )
Description: openOSI OID for attributees of openosi.schema
Definition
openOSI attribute contains openosi.schema attributes conforming with RFC4512 specification
. A set of attributes defines an LDAP entry. There MUST be attributes belonging to a STRUCTURAL object class like person and uidObject from core.schema.
Attribute Type Description is defined by the following BNF:
AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other
; AttributeType
[ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
whsp ")"
AttributeUsage =
"userApplications" /
"directoryOperation" /
"distributedOperation" / ; DSA-shared
"dSAOperation" ; DSA-specific, value depends on server
It is a Subschema entry as defined in RFC4512. X501 Subschema mechanism is held in (sub)entries belonging to the subschema auxiliary object class.
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
When an attribute is multi-valued (as opposite of SINGLE-VALUE). The matched values filter apply as defined in RFC3876
 | Warning
Attributes of openosi.schema all belong to auxiliary classes. It is therefore necessary to use complementary common schema like core, cosine and inetOrgperson embedding structural classes to create en entry. |
Usage
The OID specifies the attribute of an entry, which are used in conjunction with the controlling schema to determine the permitted attributes of an entry. Values of this attribute can be modified by clients, but the 'attribute' cannot be removed.
openosi.schema uses aliases NAMES in attributes to handle specific attributes required by address books, contacts and info-cards. Once an alias is created for an attribute name, a user can specify the alias instead of the attribute name in an LDAP operation. In the attribute name list, the first item is recognized as the name (canonical) of the attribute and rest of the items in the list are recognized as attribute aliases.
The following rules apply to attribute aliases:
- An attribute alias name must be unique throughout all the actual attribute names and other attribute aliases across all the schema components. When an attribute is defined, the first value in the attributeTypes definition NAME field must be the actual attribute name. Attribute aliases are defined in the NAME field after the actual attribute name.
- Attribute alias names follow the same syntax rules as attribute names.
Once attribute aliases are defined in the LDAP schema, users can substitute the aliases for attribute names in LDAP operations such as (ldapsearch, ldapadd, mdapmodify, ldapdelete, ldpamoddn ...). But note that OpenLDAP server returns the canonical name (first in attribute name) for any attributeTypes that it recognizes.
Note that in active directory there are some limitations on the use of aliases.
Note that for openLDAP attributes' names are case insensitive but are case sensitive in Novell DS
 | Be careful
The search result will contain the actual canonical attribute names, unless the user explicitly asks for an alias using the required attributes list. Fortunately most LDAP address book clients require explicitly an attribute list. |
Suppose the user specifies the following search, using the aliases organizationalUnit, country, and organization in the base DN and the alias surname in the filter string:
ldapsearch -p 389 -h myhost \
-b "organizationalUnit=dev,country=us,organization=myorg" \
-s sub "surname=brown"
The search will return a result similar to this:
uid=mbrown,ou=dev,c=us,o=myorg
uid=mbrown
sn=Brown
cn=Mark Brown
telephonenumber;office=444006
telephonenumber;mobile=555006
objectclass=organizationalPerson
objectclass=top
objectclass=person
Now suppose the user specifically asks for the aliases surname, commonname, and userid by including them in a required attributes list, like this:
ldapsearch -p 389 -h myhost \
-b "organizationalUnit=dev,country=us,organization=myorg" \
-s sub "surname=brown" surname commonname userid phone
Because the user specifically included the aliases, the search will return a result similar to this:
uid=mbrown,ou=dev,c=us,o=myorg
surname=Brown
commonname=Mark Brown
userid=mbrown
phone;office=444006
phone;mobile=555006
| Warning
An attribute name alias IS NOT an alias for an object entry. An attribute name alias IS NOT the 'alias' Object Class ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName ). An attribute name alias has nothing to do with "alias dereferencing" mechanism. |
XML format
<oid>
<asn1-notation>\{iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) openosi(27630) identification(2) schema(1) attribute(2)\}</asn1-notation>
<description>OID for attributees of openosi.schema for X500 / LDAP directory</description>
<information>More <i>information</i> can be found in <a href="http://openosi.org/osi/display/oid/1.3.6.1.4.1.27630.2.1.2">openOSI OID for attributees of openosi.schema for X500 / LDAP directory</a> </information>
</oid>
