How to Read the NDS Schema Reference Document: The Attribute Definition Page

Articles and Tips: article

Nancy McLain
Senior Editor
DeveloperNet University
nmclain@novell.com

01 Mar 2001

Takes a look at how to read the attribute definition page in the Novell Directory Services schema document.

Last month, I described how to read the Schema Reference object class definitions page. The Schema Reference defines object classes, attributes, and attribute syntaxes. Every object class definition contains both mandatory and optional attributes. The combination of Attributes that a class definition holds defines the type of object class it is; for example, a printer class has different attributes than a server class.

The values in each attribute specifically define an object. For example, a LaserJet 3 printer would have different attribute values than a LaserJet 4 printer; user Nancy would have different attribute values than user Tom, and so on. The attribute definition page gives the LDAP name of the attribute, the syntax that the attribute value will be in, and the constraints that the attribute operates under.

So this month, let's look at the description of the attribute definition pages.

Reading Attribute Definitions

The schema reference contains two chapters about attributes: "The Operational Attribute Definitions" and "The Base Attribute Definitions." Like the chapters on object classes, both attribute chapters are organized similarly because they both discuss attributes.

The "Operational Attribute Definitions" chapter lists the operational attributes in alphabetic order and documents their definitions.

Operational attributes are those attributes that make up the actual schema. Any attributes other than those described in this chapter actually extend the schema. The "Base Attribute Definitions" chapter lists and defines the base attributes in alphabetic order. Base attributes are those classes that extend the operational schema in a default installation.

Both operational and base attributes have identical page layouts. Figure 1 shows the C attribute (Country Name) definition page. This is a typical attribute definition page that we can examine to find out what information the attribute definitions contain.

C Attribute Definition Page 1

LDAP Name.

In Figure 1, you can see that the attribute name (C) is followed by a brief description of the attribute's purpose. The next piece of information on the C attribute definition page is the LDAP name. If the attribute has the same definition and purpose as any of the LDAP attributes, you can find the names of those LDAP attributes here.

Some attributes in the NDS schema have no corresponding LDAP attributes, while others, such as the Country Name, have more than one corresponding LDAP attributes. This section lists the LDAP attributes to which the NDS attribute is mapped. If the attribute doesn't correspond to any LDAP attributes, this section won't exist on the page.

Syntax.

The next piece of information on the page tells you which attribute syntax this attribute uses. In the on-line version of the document, the Attribute Syntax is a hot-link to the appropriate syntax definition page. I'll describe how to read this page in the next Directory Primer column.

Constraints.

The next section you see in Figure 1 is entitled "Constraints." This section lists any constraints that apply to this attribute. Attribute constraints are flags containing restrictions that affect an attribute value. They can also impose constraints on NDS and NDS client operations. Attributes constraints specify whether the attribute can do the following:

Allows for a single value or for multiple values
Has a range or size limit to the value
Is synchronized immediately, or at the next scheduled interval, or never
Is hidden or is viewable
Is writeable or is considered read-only

The next five lists summarize the attribute constraints that you find listed in this section. These lists show only enough information to help you understand the listed attribute constraint. For more detailed information about the attribute constraints, see the NDS schema documentation that came with the NDK, or view it at http://developer.novell.com .

Reading the Attribute Constraints

The following constraints regulate whether only servers can read the attribute, or whether clients can also read the attribute. Each attribute can have more than one constraint assigned to it.

Name	Description
Hidden Attribute	This is an attribute that only applications running on the NetWare server can use. This constraint is listed if server applications are the only entities that use this attribute. In NetWare 4, this constraint restricts the attribute to NDS only.
Public Read	This is an attribute that anyone can read without having read privileges specifically assigned. You can't use inheritance masks to prevent an object from reading attributes with this constraint. Using this constraint can make access to this attribute extremely efficient because NDS won't look up the ACLs to see who has the rights to read this attribute. This constraint is listed when it doesn't matter what objects can read the attribute.
Server Read	This is an attribute that NCP Server objects can read even though the right to read it has not been inherited or explicitly granted. You can't use inheritance masks to restrict servers from reading attributes with this constraint. This constraint is listed if NCP Server objects are always able read this attribute, regardless of the rights granted in the ACL.

Operational Attribute Constraints.

These constraints regulate whether this attribute is operational.

Name	Description
Nonremovable Attribute	This is an attribute that can't be removed from the schema. In NetWare 5, clients can set this constraint when they create the attribute. In NetWare 4, only NDS can set this constraint. All base schema attributes have the non-removable constraint flag.
Operational	This is an attribute definition that NDS uses internally and is required in order to function correctly.

Modifying the Attribute Constraints.

These constraints regulate who can change the attribute's value.

Name

Description

Read Only Attribute

This is an attribute that is created and maintained by NDS or applications running with NDS. Clients can read the attribute's value, but they can't modify it.

If an attribute has this constraint, clients can't remotely modify this attribute or remotely add a value for this attribute on an object.

Write Managed

This is an attribute that must have explicit rights granted to it before it can be changed.

If an attribute has this constraint, users must have managed rights on the object that contains this attribute before they can change this attribute's value.

Synchronizing the Attribute Constraints.

The following constraints regulate when the attribute's value will be synchronized with the NDS information.

Name	Description
Per Replica	This is an attribute whose information is not synchronized with the other replicas.
Schedule Sync Never	This is an attribute whose values can change without scheduling synchronization. This attribute can wait to propagate any changes until the next regularly scheduled synchronization cycle or until some other event triggers synchronization.
Sync Immediate	This is an attribute whose information must be immediately propagated or changed throughout the NDS tree. If an attribute has this constraint, it will force immediate synchronization with other replicas when this attribute's value changes.

If none of these constraints are listed, NDS synchronizes the data at the "slow synchronization level" set on the server that contains the replica holding the change.

Constraining Attribute Values.

These constraints regulate whether the attribute's value is single or multi-valued, whether it has upper and lower boundaries, and whether the value is a string.

Name	Description
Single Valued Attribute	This attribute has single values, with no order implied. If an attribute has this constraint, it can hold only one value; otherwise, it can hold multiple values.
Sized Attribute	This attribute has an upper and lower boundary, which can be the length for strings or the value for integers. The first number indicates the lower boundary and the second indicates the upper boundary. If an attribute has this constraint, its value has a fixed size.
String Attribute	This attribute's values are string types. If this constraint isn't listed, the attribute isn't a string and cannot be used as a naming attribute.

TheLast Three Sections

ASN.1 ID.

The next piece of information on the page that you see in Figure 1 is the ASN.1 ID. Every attribute in the NDS schema has an ASN.1 ID assigned to it. An ASN.1 ID is an identification that is assigned to object classes and attributes when they are registered. For more information about the ASN1.ID, see last month's Directory Primer column about reading the object class definition page.

Used In.

The next section displayed in Figure 1 is entitled "Used In." This section lists the object class definitions which have this attribute either has a mandatory attribute, or as an optional attribute.

Remarks.

The last section on the C attribute definition page in Figure 1 is the "Remarks" section. This section can include further restrictions, comments about how to use this attribute, and references to related documents.

Conclusion

One of the primary ways an object definition is defined is by the attributes it allows an object to hold. Referring to the attribute definition page in the schema reference document is a good way to understand more about an NDS object.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.