Information Model

The directory is a collection of information about a set of objects. Objects are referenced in entries of the directory service. Entries that are structured recursively in the system are called directories. Information in directory service entries can be used for purposes such as describing resources, location of the referenced resources, and for discovery of operations on objects.

While it is conceivable that a directory service may be built on a general purpose database, the directory service is not conceptually such a database. The distinct characteristics of the directory service information model are best described by the following assumptions:

• The underlying organisational structure is hierarchical.

• Queries are the dominant operations, resulting in a high ratio of look-up operations in comparison to update operations.

• Due to the relatively slow rate of changes, instantaneous reflection of updates is usually not required (that is, the state of transient conditions may be acceptable).

This document, which is the specification of the directory service information model, assumes the existence of the above generic characteristics. However, the specification may be applied to a wide variety of services, ranging from general purpose directory services to very specialised resource managers. Information storage in logical databases is common to all of these, but this specification does not specify the properties (such as insertion and retrieval speed, partitioning, replication) of these information bases. The definition of these properties is subject to service-specific specifications.

Directory entries contain attributes. Attributes are discrete items of separately accessible information associated with a directory object. Each attribute is determined by its type, and its value (or set of values) represents an instance of this class of information. Depending on the specific semantics of directory services, the representation and richness of attributes varies.

The directory service specifications define the possible operations on directory entries. However, the most rudimentary common operations, supported by every directory service, are read, modify, create and delete (on entries and attributes).

Names and Identifiers

A name is a string of characters that refers to an object. Directory entities are identified by names. A name resolves a directory entry unambiguously, but does not provide for uniqueness. Multiple names can reference the same entry, and names can be aliases or soft links. An alias expresses an alternative name of an object, representing a possibly different hierarchical relationship.

An atomic name represents the distinguished value of a particular entry. The ingredients of an atomic name are determined by the directory service's rules and semantics. An atomic name can be:

Untyped

An unambiguous string of characters determined only by its entry's position in the organisational structure; for example, its hierarchy level

Typed

A set of designated attribute type-value pairs, represented by multiple attribute-value-assertions, or AVAs

A relative distinguished name is a typed atomic name describing the distinguished value of an object entry. The relative distinguished name of an object entry is unique (in its context, relative to its parent's name) and must not express an alias.

A sequence of one or more atomic names that represent entries in a particular name service is a compound name. The rules for the composition of compound names are determined by the name service's name syntax. A POSIX pathname, for instance, is a compound name that describes an entry in the file system.

The rules and conventions for the DCE-defined compound names are specified in Name Syntax of this document. The compound names specified there are global compound name and cell compound name.

A compound name consists of distinguished components that are equivalent to atomic names in the global name space (for X.500) and the cell name spaces. Internet DNS names in the global name space consist of exactly one component that is equivalent to the compound name, where a component is a set of . (dot) separated atomic DNS names. The contents and parsing rules for a component are defined by the semantics of the name space of which the component is a member.

Components may represent a single physical directory or a leaf object; they may be typed or untyped; or they may represent complex structures such as attribute-based schemes. The present document only specifies syntax and semantic rules for components in the global and cell name spaces, as outlined in Name Syntax . The semantics and syntax rules for other composite name spaces is outlined in the corresponding documents (see Other Composite Name Spaces for specific references).

A composite name consists of one (non-empty) or multiple consecutive compound names. A composite name may thus represent multiple name services, with possibly distinct syntactic and semantic rules. Composite names adhere to the conventions outlined in Name Syntax .

Entities in the name system are identified by their name context. A name context has an associated name convention, expressed by the semantic and syntax rules of the controlling name service. The scope of a composite name is defined by its initial name context. This document defines the following three initial contexts:

Global context

The single global root of the DCE directory information system.

Cell context

The context of the root of the local cell (refer to DCE Cell for the definition of cell).

File context

The root of the distributed file system within the local cell.

An atomic name is unambiguous only within a given name context (relative to its immediate superior, the parent directory entry). However, a fully-qualified global name characterises an entry unambiguously within the global context. A fully-qualified global name consists of an ordered set of compound names, beginning from the global root.

The distinguished name of a directory service entry is a fully-qualified global name, uniquely identifying the object (no aliases).

The uniqueness of a given directory entry may also be expressed by an identifier. Identifiers are unique in a given context. Contexts are determined by the directory service and the type of identifier used. This document specifies two types of identifiers: the OSI Object Identifier (OID), and the Universal Unique Identifier (UUID).

OIDs (object identifier) are obtained from a hierarchy of allocation authorities, the highest being the International Organisation for Standardization (ISO) and the International Telegraph and Telephone Consultative Committee (CCITT). The printable format of object identifiers is a string of . (dot) separated digits (see also the ASN.1 standard).

The UUID (universal unique identifier) is a fixed size identifier which is guaranteed to be unique across both space and time. A further specification of the UUID can be found in the DCE Remote Procedure Call specification.

Name Spaces

A name space is an organisational model that describes the syntactic and semantic rules within a particular domain. The concrete operations allowed within a name space are provided by one or multiple associated name services that control the name space. Name spaces are hierarchically ordered, and name space boundaries are crossed through next naming system pointers (see Next Naming System Pointers ).

Note:

The notion of name spaces is derived from the conceptual model commonly known as federated naming. Federated naming prescribes a system of heterogeneous naming technologies that are interworking through bilateral cooperation.

The DCE directory information model consists of a set of composite name spaces. Composite name spaces are linked together in a hierarchical order. This document specifies two types of composite name spaces: the global name space and the cell name space (see DCE Name Spaces ).

The global name space is at the top of the hierarchical arrangement of name spaces. The global name space, and therefore implicitly the entire DCE directory information system, is determined by the global context, expressed by the global root.

Particular entries within the global name space identify cell name spaces; these cell name spaces are subordinates of the global name space. Cell name spaces can also be subordinate to other cell name spaces in a configuration called a cell hierarchy. The top-level cell in a cell hierarchy, the parent cell, is always catalogued in the global name space. The name spaces of the child cells are subordinates of the name space of the parent cell.

Cell name spaces, then, are either subordinates of the global name space or of other cell name spaces. The root and attributes of the top-level cell name space are catalogued in the global name space. The root and attributes of child cells are catalogued in the parent cell name space. Either parent cell name spaces or child cell name spaces can be superordinates for other composite name spaces (see Other Composite Name Spaces ).

The entities in both the global and the cell name spaces are hierarchically structured, and together comprise an inverse tree of nodes. These name spaces represent an acyclic directed graph: each entity has exactly one parent at any moment, and no entity is a descendent of its own descendents. This architecture does not impose the structural rules applied to other composite name spaces.

Global Name Space

The global name space, which is the top-level name space of the DCE directory information model, provides for a universally unique root and contains cell name spaces as subordinates. The global name space, as specified here, is represented by two directory services:

• the international standard Directory Service CCITT X.500 or the ISO 9594 standard

• the Internet Domain Name Service (DNS) (see Internet RFC 1101, RFC 1035, RFC 1034 and related documents).

The syntax and semantics of the global name space are in accordance with the standard specifications of these directory services. The conformance requirements are specified in this document.

Cell Name Space

The cell name space consists of hierarchically organised directory service entries of untyped atomic names. Entries are unambiguously identified by their name and position within the hierarchy, and are (optionally) uniquely identified by a UUID. The cell name space rules do not enforce any particular model for organising the entries in the name space.

The cell name space defines three different types of entries¹:

Directory

Directory entries represent nodes in the name space tree which contain arbitrarily many references to subordinate entries (objects, soft links, and pointers to other directories).

References to descendent directories of a particular directory entry are called child pointers. Child pointers link directories together into a rooted tree, in which there is a single path from the root directory through a set of child directories, to the desired named object. Child pointers are created internally by the directory service.

Directories can be empty, not containing any references to subordinate entries.

Every directory entry has exactly one ancestor directory. With one exception, every directory uses a parent pointer to reference its ancestor. The top-level directory entry of the top-level cell is the exception; in that case, the directory entry uses a global pointer to reference the global name space.

Directory entries do not have parent pointers to soft link entries (the directory name to which a parent pointer refers is a fully-qualified global name).

To prevent cycles in the tree structure of the cell name space, a directory must not be a child of any of its descendents.

Object

Object entries represent terminal or leaf nodes in the cell name space.

Note:

These leaf entries usually do not represent the target object of an operation itself but the catalogued name of an object. These entries may control object references and other information on behalf of the target object. DCE uses these object entries for registering the binding information (object references) of servers and subordinate name spaces.

Soft link

A soft link entry is a form of alias or indirect pointer that provides an alternate name for either an object, directory, or another soft link entry. Soft links thus allow a single entry to be reached via more than one name.

The contents of every cell name space entry consist of a set of attributes and their associated values.

Attributes are of two types:

single-valued

A single-valued attribute can have only one value at a time.

set-valued

A set-valued attribute can have more than one value at a time. Its contents consist of a set of unordered values, called members. These values must be distinguishable; hence, set-valued attributes cannot have duplicated members.

From the point of view of usage, attributes can generally be divided into two categories:

operational

Operational attributes are those which are predefined by the Cell Directory Service (CDS).

application-specific

Application-specific attributes are those attributes which can be freely attached to object and directory entries by applications or users, assuming that they have the appropriate access privileges. (Note that soft link entries are excluded from this category.)

The set of these categories of attributes, and their applicability to distinct entries (directory, object, soft link), is service and implementation-specific.

An attribute is identified by an attribute identifier (sometimes referred to as attribute name), which distinguishes it from other attributes. An attribute of a given name can have only one attribute value syntax (data type); it is not possible for a single-valued attribute and a set-valued attribute to have the same name at the same time. Every attribute name has an OID (Object Identifier) associated with it to ensure uniqueness among attributes.

Next Naming System Pointers

Name spaces are linked by next naming system pointers. Next naming system pointers accomplish the concept of obtaining the "next name space" reference.

The protocols used to resolve the next name space reference pointers are not specified in this document (though it is anticipated that such protocols will be supported in the future).

The canonical string representation of DCE names does not make a syntactical distinction between atomic name and compound name separators for the cell name space (both use / (slash) as the separator; see Name Syntax ). The boundaries between cell and subordinate name spaces can only be determined by resolution. Therefore, an (untyped) name of a cell name space entry may collide with a top-level name of a subordinate name space.

To avoid these ambiguities in a composite name, it is recommended that next naming system pointers always be object (leaf) entries in the cell name space, which explicitly associates a name to the name space pointer. These explicit next naming system pointers are called junctions. This specification only supports junctions in the cell name space.

Note:

This restriction does not apply to cell registration in the global name space, which can be catalogued in any node within the global name space (global name spaces controlled by DNS have distinct atomic name separators and those controlled by GDS contain typed names). This permits the use of the same name for both a pointer to another name space and to maintain other descendants within the same name space. These implicit next naming system pointers can only point to a single subordinate name space.

As defined in DCE Composite Names , a composite name may consist of multiple compound names - the global compound name, the cell compound name, and a residual that identifies entities in subordinate composite name spaces. Each of these is a set of one or more name components, separated by a / (slash).

If the rightmost component of a name that resides in the cell name space is not the rightmost component of that composite name, the resolved entry represents a junction. The content of the residual compound names of the composite name is opaque to the cell name space directory service.

Cell name space junctions to subordinate name spaces are catalogued (that is, have a name) in the cell name space. Pointers to and information about the resource manager of a subordinate composite name space are registered in application-specific attributes of the junction entry.

The junction entry represents both the entry in the cell name space and the object of the subordinate name space that this junction is bound to. This bound object is usually the root of that subordinate name space.

This document does not specify how the cell name space junction entry and the bound object can both be unambiguously accessed. Applications may provide programming interfaces that disambiguate the access to these entities that are referred to by the same name. The ACL Editor, for instance, defines a flag in the sec_acl_bind () interface that allows applications to determine the target of the operation (the ACL of the cell name space entry or the ACL of the protected object of a server-supported name space) - see the DCE Security Services specification.

DCE Cell

A DCE cell is an administrative and security domain within the cell name space. Servers of the Cell Directory Service (CDS) and security authorities are instantiated on a cell-wide basis.

A cell is typically a group of users, systems and resources that are centred around a common purpose and which share common DCE services. A minimum cell configuration includes one CDS, one Security Service and one Time Service.

Because cells are administrative units, organisational notations such as the shorthand for the cell root, /.: (see DCE Composite Names ), are related to the cell and not the cell name space. This may not be visible if a cell name space consists of exactly one cell, but if hierarchies of cells are introduced within a cell name space, the cell root always refers to the root of the local cell.

The membership of a cell is determined on a per host basis. How a host obtains information about its cell identity is implementation-specific; for example, the cell name may be stored in a local (host-specific) configuration file. The local cell is the cell defining the environment of the initial user's login session.

Other Composite Name Spaces

This document does not specify the particular semantics and syntax rules for composite name spaces other than the global and the cell name space. However, the DCE Security Services specification specifies the security name space, and the DCE File Services specification specifies the file service name space (also called filespace). Both name spaces are subordinates of the cell name space, and are integrated through junctions.

Within each cell, the actual names for these junctions are not determined by the architecture; they are indirectly identified in the /.:/cell-profile profile entry as having the name associated with the UUID of the junction. However, the recommended names are /.:/sec for the security name space, and /.:/fs for the file service name space.

Other name service or resource manager implementations may be integrated into the DCE name space, in accordance with the rules outlined in this specification.

Name Syntax

Names defined by this syntax consist of strings of characters (elements of a character set). The minimal set of valid characters is defined in the Portable Character Set (PCS) for the DCE directory information system. Valid Characters in CDS, GDS and DNS Names represents this portable character set and its applicability to the name spaces.

The PCS for directory services defines the semantics of names, rather than the actual visual or encoded characters. For example, it specifies that a character with the semantic of backslash (that is, the \ character) must be supported, although in some fonts the backslash glyph may have been replaced with another glyph. Note that a similarity in visual appearance between two glyphs does not necessarily mean that they are in fact the same semantic character.

Characters are internally associated with an opaque encoding; that is, one or more numerical values and bit patterns. Directory service specifications for GDS and CDS specify the internal representation of names (see Parts 3 and 4, and associated appendices).

Neither varying character sets (for example, for native language support), other than the portable character set, nor different visual presentations (such as input through a graphical user interface) are specified in this document.

The syntax applied when interpreting a name is dependent on whether a component refers to an entry in the global name space, the cell name space, or another composite name space. The common characteristics of the syntax are specified as follows:

The characters / (slash) and \ (backslash) have special properties, and are called the metacharacters of the syntax. Additional distinct metacharacters for both the global and the cell name space are defined in respective sections of this document. Their special properties can be cancelled by preceding them with a \ (backslash), an operation called escaping. The sequence of characters consisting of a \ (backslash) followed by an ordinary character (that is, by a non-metacharacter) is reserved, and may be specified in subsequent versions of the following syntax.

DCE Name Syntax

Backus-Naur Format (BNF) of DCE Name Syntax defines the DCE name syntax. The sections that follow the table explain how the syntax is applied to the different DCE name spaces and services. References in the text to elements defined in the BNF are in the form: <element>.

The notations used are as follows:

::=

Is defined to be.

|

Alternatively.

<text>

Non-terminal element.

"

Literal expression.

*

The preceding syntactic unit can appear 0 or more times.

+

The preceding syntactic unit can appear 1 or more times.

{}

The enclosed syntactic units are grouped as a single syntactic unit (can be nested).

Backus-Naur Format (BNF) of DCE Name Syntax

The DCE name syntax is as follows:

PCS	::= { Portable Character Set }
SimpleChar	::= { Subset of symbols from Portable Character Set,
	      intersection of characters supported by
	      GDS, DNS and CDS -
	      a to z, A to Z, 0 to 9, "-" }
AlphaChar	::= { a to z, A to Z }
NumChar	::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

WildChar	::= ? | *
EscapeChar	::= \
ComponentSep	::= /
DotSep	::= .
Quote	::= " | '

GlobalContext	::= <ComponentSep>+ "..."
CellContext	::= <ComponentSep>+ ".:"
FileContext	::= <ComponentSep>+ ":"

DNSChar	::= <SimpleChar>
DNSAtomicName	::= <DNSChar>+
DNSComponent	::= <DNSAtomicName> {<DotSep> <DNSAtomicName>}+
DNSCompoundName	::= <DNSComponent>

GDSAVASep	::= =
GDSMultiAVASep	::= ,
GDSChar	::= <SimpleChar> | <DotSep>
	    | " " | ` | ( | ) | + | : | ?
GDSAttrType	::= {<AlphaChar> {<AlphaChar> | <NumChar>}*}
	    | {<NumChar>+ {<DotSep> <NumChar>+}*}
GDSAttrValue	::= <GDSChar>+ 
	    | {<GDSChar>* <EscapeChar> <PCS> <GDSChar>*}+
	    | <Quote> <PCS>+ <Quote>
GDSAVA	::= <GDSAttrType> <GDSAVASep> <GDSAttrValue>
GDSAtomicName	::= <GDSAVA> {<GDSMultiAVASep> <GDSAVA>}*
GDSComponent	::= <GDSAtomicName>
GDSCompoundName	::= <GDSComponent> {<ComponentSep>+ 
	    <GDSComponent>}*

GlobalCompoundName	::= <DNSCompoundName> | <GDSCompoundName> 
GlobalCompositeName	::= <GlobalContext> <ComponentSep>+ 
	    <GlobalCompoundName> | <GlobalContext> 
	    <ComponentSep>*

CDSChar	::= <GDSChar> | <GDSMultiAVASep> | ! | # | $ | % 
	    | & | ; | < | > | [ | ] | ^ | _ | { | } 
	    | "|" | ~ | *


CDSAtomicName	::= {<CDSChar> | <GDSAVASep>}+ 
	    | {{<CDSChar> | <GDSAVASep>}* <EscapeChar> <PCS> 
	      {<CDSChar> | <GDSAVASep>}*}+
	    | <Quote> <PCS>+ <Quote>
CDSFirstComponent	::= <CDSChar>+ 
	    | {<CDSChar>* <EscapeChar> <PCS> <CDSChar>*}+
	    | <Quote> <PCS>+ <Quote>
CDSComponent	::= <CDSAtomicName> | <CDSFirstComponent>
CDSCompoundName	::= <CDSFirstComponent> 
	    {<ComponentSep>+ <CDSAtomicName>}*

CellCompositeName	::= <CellContext> <ComponentSep>+ <CDSCompoundName>

AtomicName	::= <SimpleChar>+
	    | {<SimpleChar>* <EscapeChar> <PCS> 
	       <SimpleChar>*}+
	    | <Quote> <PCS>+ <Quote>
CompoundName	::= <AtomicName> {<ComponentSep>+ <AtomicName>}*

FullName	::= <GlobalCompositeName> 
	    {<ComponentSep>+ <CDSCompoundName>}* 
	    | <GlobalCompositeName> 
	      <ComponentSep>+ <CDSCompoundName> 
	      {<ComponentSep>+ <CompoundName>}*
CellRelativeName	::= <CDSCompoundName>
	    {<ComponentSep>+ <CompoundName>}*
FileName	::= <FileContext> <ComponentSep>+ <CompoundName>

DCE Composite Names

This section defines the policies that are applied to composite names in DCE.

A DCE composite name is structured as a left-to-right ordered set of compound names, and a compound name is structured as a left-to-right ordered set of components. This ordering is intended to correspond to the top-to-bottom (parent/child, superordinate/subordinate, more-significant/less-significant, big-endian/little-endian) lineage of the named object.

The ordering of compound names is:

 

global compound name, followed by
a cell compound name, followed by
compound names of other composite name spaces (including names of child cells 
within a hierarchical cell configuration).

These compound names represent entries in their associated name spaces.

Multiple compound names and components of compound names are separated by / (slash) characters (BNF element <ComponentSep>).

Note:

The name syntax permits empty component and compound names - multiple consecutive occurrences of the component separator / (slash). A trailing component separator implies a trailing empty component. These empty components, however, will be eliminated during canonicalisation and not further processed (see Canonicalisation of Names ).

Initial contexts are special cases of reserved component names. They are logical entities describing the name context; they do not represent actual entries in the directory services. The initial contexts are separated from the remainder of a composite name by a / (slash). The three defined initial contexts are:

• Global context (BNF element <GlobalContext>)

• Cell context (BNF element <CellContext>)

• File context (BNF element <FileContext>).

A fully-qualified global name (BNF element <FullName>) is a DCE composite name with the global root at the top (left). Hence, the fully-qualified global name is a single path in a hierarchically structured rooted tree of name spaces. The name of the global root is represented by the character string /.... Fully-qualified global names must begin with the substring /....

The name of the cell root is /.:. This is the shorthand form for the fully-qualified global name of the local (or current) cell. If the cell is registered in global name space, /.: resolves into /.../{global compound name}. If the cell is registered in a cell name space (that is, the cell is a child cell within a cell hierarchy), then /.: resolves into /.../{global compound name}/{child cell name}, where {global compound name} refers to the parent cell. The /.: cell context provides a syntactical convenience for establishing a composite name, but does not change the name semantics, except that a given cell compound name (BNF element <CDSCompoundName>):

• when applied to a different cell, may resolve into an object different from that registered in the cell in which the name was meant to be applied

• when applied to a child cell within a cell hierarchy resolves to the cell root of the child cell, not the cell root of the parent cell.

In names specified from the global root, the name for the cell root is always placed to the left of the rest of the cell name, as a prefix to the composite name (BNF elements <CellCompositeName> and <CellRelativeName>).

Similarly to the cell root, the file context is a shorthand form for the cell relative name of the local distributed file service. The name of the file context is /:, which resolves to /.:/<string> (where the recommended name for <string> is fs).

Canonicalisation of Names

The name syntax defines the rules for names that are to be presented to the name service interfaces. Before a name is processed by a name service, and before any of the matching rules specified in Global Name Space Name Syntax are applied, the name is converted to its most primitive, canonical form. This process is called canonicalisation; its successful completion implies that the name is syntactically correct, according to the syntax rules that are outlined below.

Canonicalisation is performed according to the following rules:

1. Multiple successive / (slash) characters are reduced to one slash; that is, empty components are eliminated and will not be processed.

2. Similarly, trailing / (slash) characters are eliminated and will not be processed.

3. If a typed name component, representing an X.500 RDN (Relative Distinguished Name, BNF element <GDSComponent>), is encountered:

   • Multiple successive space characters are reduced to a single space, regardless of the applicable case matching rules, unless the name is quoted.

   • Leading space characters and spaces between an attribute type and an = (equal sign) character are removed.

   • If the matching rules for the attribute type specify the value to be case insensitive, all alphabetic characters in the value string are converted to lower case.

   • If the attribute type is determined to be in object identifier syntax:

     • it is converted into an object identifier representation (that is, a . (dot) separated string of digits; note that the mapping from tag string to object identifier is based on AT Entries ).

     • otherwise, and if the case matching rule for the attribute type is determined to be case insensitive, the attribute type is converted to an all lower-case tag string.

4. If the name component represents an Internet DNS compound name (BNF element <DNSCompoundName>), the component name string is converted entirely to lower case.

Global Name Space Name Syntax

The , (comma) and = (equal sign) characters are metacharacters in the global name space syntax. As with the other valid metacharacter (that is, the / (slash) character), these may be escaped by a preceding \ (backslash) character. Escaping the backslash character itself (that is, having multiple contiguous occurrences of \) within the global compound name is reserved for future use, and is not allowed by the current version of the specification.

The global name syntax specified in this document distinguishes between the two supported global directory services, X.500 and DNS. An X.500 component in a fully-qualified global name is precisely and immediately identified by the occurrence of at least one = (equal sign) character in the first name component after the global root (/...); the equal sign indicates the presence of an attribute-value-assertion (AVA) in a GDS compound name (BNF element <GDSCompoundName>). (See below, X.500 Typed Names .)

If the first component of the global compound name (the descendent of the global root /...) is not identified as an X.500 name (that is, it does not contain a = (equal sign)), and if it contains at least one . (dot) character, it is considered to be a DNS name. Names that are not identified as being either X.500 or DNS are not specified (BNF element <GlobalCompositeName>). Implementations may reject these as unsupported.

X.500 Typed Names

An X.500 global compound name (BNF element <GDSCompoundName>) may consist of arbitrarily many components. Every name component represents a relative distinguished name (RDN) according to the X.500 rules.

A component (BNF element <GDSComponent>) consists of a set of arbitrarily many (but at least one) subcomponents, each of which represents an attribute-value-assertion (AVA). Subcomponents are separated by the , (comma) metacharacter. The ordering of subcomponents is significant for applying the matching rules, but the rules for ordering subcomponents are application determined. Subcomponents within a component need not be distinct. Subcomponents cannot be empty. Multiple successive , (comma) characters are not allowed. Similarly, components cannot end with a comma.

Every subcomponent (BNF element <GDSComponent>) must contain exactly one = (equal sign) character. The substring preceding the = is called the type, and the substring following is called the value. Types and values are non-empty character strings, containing no unescaped metacharacters, and may be arbitrarily long. Since types and values cannot be empty, multiple successive = (equal sign) characters are not allowed. Similarly, components cannot end with an equal sign. In other words, within a component, the number of unescaped equal signs matches exactly the number of comma characters plus 1.

Attribute types (BNF element <GDSAttrType>) must begin with an alphabetic character, can contain alphanumerics, and cannot contain spaces.²

Two global compound names which match each other according to the following rules are interpreted to always name the same object³:

• Two global compound names match if and only if all their components match, in sequence (left-to-right).

• Two components match if and only if they match as ordered sets of subcomponents. The rules for ordering subcomponents are not relevant: two logically equivalent components that refer to the same name service entry do not match if their subcomponents are provided in a different order. Subcomponents may be identical, but they match if and only if their order of occurrence matches.

• Subcomponents match if and only if their attribute types and their attribute values both match.

• Attribute types are matched case insensitively, character by character.

• Attribute values can be matched case exactly or case insensitively, depending on the rule defined for its type at the DSA (Directory Service Agent).

DNS Names

The global compound name in DNS consists of exactly one component, which follows the global root prefix. The full DNS name, formed in accordance with its syntax rules (that is, consisting of domains separated by . (dot) characters, in little-endian ordering, case insensitive, and so on), is represented in this single component (BNF elements <DNSCompoundName> and <GlobalCompoundName>, separated by a / (slash) character).

A global DNS name (BNF element <DNSComponent>) referencing a cell name space must contain at least one . (dot) character (that is, must be more than one level deep), and may consist of multiple domain names, each separated by a . (dot) character.

Two global compound names which match one another according to the following rule are interpreted to always name the same object:

• Two global compound names are matched case insensitively, character by character.

Cell Name Space Name Syntax

The * (asterisk) and ? (question mark) characters are metacharacters (BNF element <WildChar>) for the cell name space syntax. Any valid metacharacter may be escaped by preceding it with a \ (backslash) character.

A component consists of a character string representing the (untyped) atomic name of an entry. The ordering of components (left-to-right) represents the hierarchy (top-to-bottom) of the cell name space organisation (BNF elements <CDSComponent> and <CDSCompoundName>).

The * (asterisk) metacharacter acts as a wildcard character matching zero or more characters. The ? (question mark) metacharacter acts as a wildcard character matching exactly one character. Both * and ? are interpreted as metacharacters only when they occur in the rightmost component of a composite name. The CDS specification determines how operations interpret these wildcard metacharacters. For example, a look-up operation may return only the first matching entry or may return all matching entries; modify operations may reject the request; and so on (see Filters for Enumerate Operations ).

The first component (BNF element <CDSFirstComponent>) in the cell compound name must not contain the = (equal sign) character, unless it is escaped by a preceding \ (backslash) metacharacter.

Two cell compound names which match one another according to the following rules are interpreted to always name the same object:

• The global compound names match (if the cell context /.:) is used, it must resolve to the same cell name space).

• Two cell compound names are matched case exactly, character by character (wildcard matching is implementation-specific).

Hierarchical Cell Names

In all cases, the cell context (/.:) resolves to the fully-qualified global name of the current cell, whether that cell is a parent cell (registered in the global name space) or a child cell (registered in the cell name space of the parent cell). Thus, when resolved from within a child cell, the cell context (/.:) refers to the root of the child not to the root of the parent.

Cell Aliases

Conformance Requirements

To conform to this document, implementations must meet the following requirements:

• Implementations must conform to the rules for naming and syntax specified in this chapter and in Valid Characters for GDS Naming Attributes , Metacharacters , and Additional Rules .

• Implementations must conform to the semantics and data formats specified in Inter-cell Operation .

• XDS implementations must follow the conformance rules specified in XDS Conformance and XOM Conformance .

• XDS implementations must support the character encodings as specified in T.61 Syntax and ISO 8859-1 (Latin-1) Syntax .

• GDS implementations must follow the Protocol Implementation Conformance Statement specified in Conformance Statement for GDS .

• GDS implementations must support the structure rules and the associated object class and attribute tables specified in GDS Structure Rule Table , GDS Object Class Table , and GDS Attribute Table .

• CDS implementations must adhere to the rules and the semantics specified in Name Syntax and Functional Model .

• CDS implementations must support the architected default attributes specified in Architected Default Attributes and CDS Attributes Table .

• CDS implementations must conform to the service primitives specified in Abstract Definitions of CDS Service Primitives .

• CDS implementations must support the protocol operations specified in CDS Protocol Definition and IDL Notation of CDS Operations .

• CDS implementations must conform to the ordering of protocol operations as specified in cds_clerkserver.idl and cds_solicit.idl .

• CDS implementations must support the protocol encodings specified in CDS Protocol Encodings .

• CDS implementations must support the specified size values in Maximum Name and Attribute Sizes .

• CDS implementations must support the status and error code encodings specified in CDS Status and Error Codes .

Footnotes

1.

Note that the meanings of the terms directory and object, as used in this document, vary with the context in which they are used. In the context of a cell name space, the terms refer to particular entries within that name space; in the context of the global name space, a directory represents a set of entities.

2.

An alternative method of specifying attribute types is by OSI Object Identifiers (a string of digit groups, separated by . (dot) characters).

3.

It is important to recognise that the matching rules specified here define an equivalence relation on the name space, which is different from the notion of string equality of names (character-by-character equality). Also, note that these are matching rules for the name syntax itself, not for the named object. In particular, two non-matching names may name the same object in a given implementation.

Please note that the html version of this specification may contain formatting aberrations. The definitive version is available as an electronic publication on CD-ROM from The Open Group.