The drawings contained in this Recommendation have been done in AUTOCAD

Recommendation X.519

THE DIRECTORY - PROTOCOL SPECIFICATIONS )

(Melbourne, 1988)

CONTENTS

0	Introduction

1	Scope

2	References

3	Definitions

3.1	OSI Reference Model Definitions

3.2	Basic Directory Definitions

3.3	Distributed Operation Definitions

4	Abbreviations

5	Conventions

6	Protocol Overview

6.1	Directory Protocol Model

6.2	Directory Access Protocol

6.3	Directory System Protocol

6.4	Use of Underlying Services

7	Directory Protocol Abstract Syntax

7.1	Abstract Syntaxes

7.2	Directory Application Service Elements

7.3	Directory Application Contexts

7.4	Errors

8	Mapping onto Used Services

8.1	Mapping onto ACSE

8.2	Mapping onto ROSE

9	Conformance

9.1	Conformance by DUAs

9.2	Conformance by DSAs

Annex A - DAP in ASN.1

Annex B - DSP in ASN.1

Annex C - Reference Definition of Protocol Object Identifiers

0	Introduction

0.1	This document, together with the others of the series, has been produced to facilitate the interconnection of information processing systems to provide directory services. The set of all such systems, together with the directory information which they hold, can be viewed as an integrated whole, called the Directory. The information held by the Directory, collectively known as the Directory Information Base (DIB), is typically used to facilitate communication between, with or about objects such as application entities, people, terminals, and distribution lists.

0.2	The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum of technical agreement outside of the interconnection standards themselves, the interconnection of information processing systems:

-	from different manufacturers;

-	under different managements;

-	of different levels of complexity; and

-	of different ages.

0.3	This Recommendation specifies the application service elements and application contexts for two protocols - the Directory Access Protocol (DAP) and the Directory System Protocol (DSP). The DAP provides for access to the Directory to retrieve or modify Directory information. The DSP provides for the chaining of requests to retrieve or modify Directory information to other parts of the distributed Directory System where the information may be held.

1	Scope

This Recommendation specifies the Directory Access Protocol and the Directory System Protocol, fulfilling the abstract services specified in Recommendations X.511 and X.518.

2	References

Recommendation X.200 -	Open Systems Interconnection - Basic Reference Model

Recommendation X.208 -	Open Systems Interconnection - Specification of Abstract Syntax Notation (ASN.1)

Recommendation X.209 -	Open Systems Interconnection - Specification of Basic Encoding rules for Abstract Syntax	Notation One (ASN.1)

Recommendation X.500 -	The Directory - Overview of Concepts, Models and Services

Recommendation X.501 -	The Directory - Information Framework

Recommendation X.511 -	The Directory - Abstract Service Definition

Recommendation X.518 -	The Directory - Procedures for Distributed Operation

Recommendation X.520 -	The Directory - Selected Attribute Types

Recommendation X.521 -	The Directory - Selected Object Classes

Recommendation X.219 -	Remote Operations - Model, Notation and Service Definition

Recommendation X.229 -	Remote Operations - Protocol Specification

Recommendation X.217 -	Open Systems Interconnection - Association Control: Service Definition

Recommendation X.227 -	Open Systems Interconnection - Association Control: Protocol Specification

Recommendation X.216 -	Open Systems Interconnection - Presentation Layer Service Definition.

3	Definitions

The definitions contained in this paragraph make use of the abbreviations defined in 4.

3.1	OSI Reference Model definitions

This Recommendation is based on the concepts developed in Recommendation X.200 and makes use of the following terms defined therein:

a)	application-service-element;

b)	application-protocol-control-information;

c)	application-control-data-unit;

d)	application-context;

e)	application-entity;

f)	abstract-syntax.

3.2	Basic Directory definitions

This Recommendation makes use of the following terms defined in Recommendation X.501:

a)	the Directory;

b)	(Directory) user;

c)	Directory System Agent (DSA);

d)	Directory User Agent (DUA).

3.3	Distributed Operation definitions

This Recommendation makes use of the following terms defined in Recommendation X.518:

a)	chaining;

b)	referral.

4	Abbreviations

The following abbreviations are used in this Recommendation:

AC	Application Context

ACSE	Association Control Service Element

AE	Application Entity

APCI	Application Protocol Control Information

APDU	Application Protocol Data Unit

ASE	Application Service Element

DAP	Directory Access Protocol

DSA	Directory System Agent

DSP	Directory System Protocol

DUA	Directory User Agent

ROSE	Remote Operations Service Element.

5	Conventions

The Recommendation makes use of the following conventions:

a)	the abstract syntax definitions in 7 are defined using the abstract syntax notation defined in Recommendation X.208;

b)	the remote operation macros (RO-notation), and the application-service-element and application-context macros are defined in Recommendation X.219;

c)	the words of defined terms and the names and values of service parameters and protocol fields, unless they are proper names, begin with a lower-case letter and are linked by a hyphen thus: defined-term. Proper names begin with an upper case letter and are not linked by a hyphen thus: Proper Name.

6	Protocol Overview

6.1	Directory Protocol Model

Recommendation X.511 defines the abstract service between a DUA and the Directory to support a user accessing Directory services. The Directory is further modelled as being represented by a DSA which supports the particular access point concerned. Recommendation X.518 defines the interactions between a pair of DSAs within the Directory to support user requests which are chained. These concepts are illustrated in Figure 1/X.519.

FIGURE 1/X.519 - T0704650-88

When a DUA is in a different open system from a DSA with which it is interacting, these interactions are supported by the Directory Access Protocol (DAP), which is an OSI application layer protocol. Similarly, when a pair of DSAs which are interacting are in different open systems, the interactions are supported by the Directory System Protocol (DSP), which is also in the application layer.

Both the DAP and the DSP are protocols to provide communication between a pair of application processes. In the OSI environment this is represented as communication between a pair of application- entities (AEs) using the presentation service. The function of an AE is provided by a set of application-service-elements (ASEs). The interaction between AEs is described in terms of their use of the services provided by the ASEs. The two ASEs common to both of the directory protocols are summarized in this paragraph.

The Remote Operations Service Element (ROSE) supports the request/reply paradigm of the abstract operation that occurs at the ports in the abstract model. The Directory ASEs provide the mapping function of the abstract-syntax notation of the directory abstract-service onto the services provided by the ROSE.

The Association Control Service Element (ACSE) supports the establishment and release of an application-association between a pair of AEs. Associations between a DUA and a DSA may be established only by the DUA. Only the initiator of an established association can release it.

6.2	Directory Access Protocol

The Directory Access Protocol (DAP) is used to realise the Directory Abstract Service. It comprises three directory specific ASEs in addition to ROSE and ACSE. These are: readASE, searchASE, and modifyASE. They correspond to the readPort, searchPort, and modifyPort of the abstract service. The directoryAccessAC application context identifies the combination of: readASE, searchASE, and modifyASE, aCSE, rOSE.

6.3	Directory System Protocol

The Directory System Protocol (DSP) is used to realise the functionality of distributed operation described in Recommendation X.518. It comprises three directory specific ASEs in addition to ROSE and ACSE. These are: chainedReadASE, chainedSearchASE, and chainedModifyASE. They correspond to the chainedReadPort, chainedSearchPort, and chainedModifyPort of the abstract service. The directorySystemAC application context identifies the combination of: chainedReadASE, chainedSearchASE, and chainedModifyASE, aCSE, rOSE.

6.4	Use of Underlying Services

The DAP and DSP protocols make use of underlying services as described below.

6.4.1	Use of ROSE services

The Remote Operations Service Element (ROSE) is defined in Recommendation X.219.

The ROSE supports the request/reply paradigm of remote operations.

The Directory ASEs are users of the RO-INVOKE, RO-RESULT, RO-ERROR, RO-REJECT-U and RO-REJECT-P services of the ROSE.

The remote operations of the DAP and the DSP are Class 2 (asynchronous) operations. Note that as the DUA is a consumer of the DAP it may choose to operate in a synchronous manner.

DAP uses Association Class 1. This means that the DSA cannot invoke operations on the DUA. DSP uses Association Class 3. This means that the responding DSA can invoke operations on the initiating DSA and vice versa.

6.4.2	Use of ACSE services

The Association Control Service Element (ACSE) is defined in Recommendation X.217.

The ACSE provides for the control (establishment, release, abort) of application-associations between AEs.

The Directory Bind and Directory Unbind (or DSA Bind and DSA Unbind) are the sole users of the A-ASSOCIATE and A-RELEASE services of the ACSE in normal mode. The application-process is the user of the A-ABORT and A-P-ABORT services of the ACSE.

6.4.3	Use of the Presentation Service

The presentation-service is defined in Recommendation X.216.

The Presentation Layer coordinates the representation (syntax) of the Application Layer semantics that are to be exchanged.

In normal mode, a different presentation-context is used for each abstract-syntax included in the application-context.

The ACSE is the sole user of the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services of the presentation-service.

The ROSE is a user of the P-DATA service of the presentation-service.

6.4.4	Use of Lower Layer Services

The session-service is defined in Recommendation X.215. The Session Layer structures the dialogue of the flow of information between the end-systems.

The Kernel and Duplex functional units of the session-service are used by the Presentation Layer.

The transport-service is defined in Recommendation X.214. The Transport Layer provides for the end-to-end transparent transfer of data over the underlying network connection.

The choice of the class of transport-service used by the Session Layer depends on the requirements for multiplexing and error recovery. Support

for Transport Class 0 (non-multiplexing) is mandatory. Transport Expedited Service is not used.

Support for other classes is optional. A multiplexing class may be used to multiplex the DAP or DSP and other protocols over the same network connection. An error recovery class may be chosen over a network connection with an unacceptable residual error rate.

An underlying network supporting the OSI network-service defined in Recommendation X.213 is assumed.

A network-address is as defined in Recommendation X.121, Recommendations E.163/E.164, or Recommendation X.200 (OSI NSAP-address).

7	Directory Protocol Abstract Syntax

7.1	Abstract Syntaxes

The Directory ASEs specified in 7.2.1, 7.2.3 and 7.2.5 share a single abstract syntax, id- as-directory-AccessAS. Those specified in 7.2.2, 7.2.4 and 7.2.6 also share a single abstract syntax id-as-directorySystemAS. In each case, this defines application-protocol-control-information (APCI) which, when used in conjunction with the ROSE, defines a set of APDUs. The Directory APDUs are defined by the abstract-syntax of the Directory ASEs and ROSE. These plus the abstract-syntax of ACSE form the complete definition of APDUs used during a Directory association.

The ACSE abstract-syntax id-as-acse is needed to establish the associations.

These abstract syntaxes shall (as a minimum) be encoded according to the ASN.1 Basic Encoding Rules.

7.2	Directory Application Service Elements

This paragraph specifies the ASEs which are used as "building blocks" in the construction of the various Directory application contexts in 7.3.

Note - These ASEs are used for the construction of the application contexts defined in this Recommendation. They are not intended to allow for claims of conformance to individual, or other combinations of, ASEs.

7.2.1	Read ASE

The readASE supports the abstract-operations of the readPort, namely Read, Compare, and Abandon, as defined in Recommendation X.511.

readASE

APPLICATION-SERVICE-ELEMENT

CONSUMER INVOKES

{read, compare, abandon}

::=	id-ase-readASE

read	Read	::= 1

compare	Compare	::= 2

abandon	Abandon	::= 3

7.2.2	Chained Read ASE

The chainedReadASE supports the abstract-operation of the ChainedReadPort, i.e. ChainedRead, ChainedCompare and ChainedAbandon, as defined in Recommendation X.518.

chainedReadASE

APPLICATION-SERVICE-ELEMENT

OPERATIONS {

chainedRead,

chainedCompare

chainedAbandon}

::=	id-ase-chainedReadASE

chainedRead	ChainedRead	::= 1

chainedCompare	ChainedCompare	::= 2

chainedAbandon	ChainedAbandon	::= 3

7.2.3	Search ASE

The searchASE supports the abstract-operations of the SearchPort, namely List and Search, as defined in Recommendation X.511.

searchASE

APPLICATION-SERVICE-ELEMENT

CONSUMER INVOKES { list, search}

::=	id-ase-searchASE}

list	List	::= 4

search	Search	::= 5

7.2.4	Chained Search ASE

The chainedSearchASE supports the abstract-operations of the ChainedSearchPort, namely ChainedList and ChainedSearch, as defined in Recommendation X.518.

chainedSearchASE

APPLICATION-SERVICE-ELEMENT

OPERATIONS {

chainedList, chainedSearch}

::= id-ase-chainedSearchASE

chainedList	ChainedList	::= 4

chainedSearch	ChainedSearch	::= 5

7.2.5	Modify ASE

The modifyASE supports the abstract-operations of the ModifyPort, namely AddEntry, RemoveEntry, ModifyEntry, and ModifyRDN, as defined in Recommendation X.511.

modifyASE

APPLICATION-SERVICE-ELEMENT

CONSUMER INVOKES

{addEntry, removeEntry,

modifyEntry, modifyRDN}

::= id-ase-modifyASE

addEntry	AddEntry	::= 6

removeEntry	RemoveEntry	::= 7

modifyEntry	ModifyEntry	::= 8

modifyRDN	ModifyRDN	::= 9

7.2.6	Chained Modify ASE

The chainedModifyASE supports the abstract-operations of the ChainedModifyPort, namely ChainedAddEntry, ChainedRemoveEntry, ChainedModifyEntry and ChainedModifyRDN, as defined in Recommendation X.518.

chainedModifyASE

APPLICATION-SERVICE-ELEMENT

OPERATIONS

{chainedAddEntry,

chainedRemoveEntry,

chainedModifyEntry,

chainedModifyRDN}

::=	id-ase-chainedModifyASE

chainedAddEntry	ChainedAddEntry	::= 6

chainedRemoveEntry	ChainedRemoveEntry	::= 7

chainedModifyEntry	ChainedModifyEntry	::= 8

chainedModifyRDN	ChainedModifyRDN	::= 9

7.3	Directory Application Contexts

7.3.1	Directory Access Application Context

The directoryAccessAC allows the DUA to access the operations of the following ASEs: readASE, searchASE, modifyASE.

directoryAccessAC

APPLICATION-CONTEXT

APPLICATION SERVICE ELEMENTS

{aCSE}

BIND DirectoryBind

UNBIND DirectoryUnbind

REMOTE OPERATIONS {rOSE}

INITIATOR CONSUMER OF {

readASE,

searchASE,

modifyASE}

ABSTRACT SYNTAXES {

id-as-acse,

id-as-directoryAccessAS}

::=	id-ac-directoryAccessAC

7.3.2	Directory System Application Context

The directorySystemAC allows DSAs to communicate for the purpose of chaining operations.

directorySystemAC

APPLICATION-CONTEXT

APPLICATION SERVICE ELEMENTS

{aCSE}

BIND DSABind

UNBIND DSAUnbind

REMOTE OPERATIONS {rOSE}

OPERATIONS OF

{chainedReadASE,

chainedSearchASE,

chainedModifyASE}

ABSTRACT SYNTAXES {

id-as-acse,

id-as-directorySystemAS}

::=	id-ac-directorySystemAC

7.4	Errors

Corresponding to each abstract-error defined in the Abstract Service is an error value which may be conveyed by the protocol. The assignments follow:

abandoned	Abandoned	::= 5

attributeError	AttributeError	::= 1

nameError	NameError	::= 2

referral	Referral	::= 4

securityError	SecurityError	::= 6

serviceError	ServiceError	::= 3

updateError	UpdateError	::= 8

dSAReferral	DSAReferral	::= 9

abandonFailed	AbandonFailed	::= 7

8	Mapping onto Used Services

This paragraph defines the mapping of the DAP and DSP onto the used services.

8.1	Mapping onto ACSE

This paragraph defines the mapping of the abstract-bind (DirectoryBind or DSABind) and abstract-unbind (DirectoryUnbind or DSAUnbind) services onto the services of the ACSE. The ACSE is defined in Recommendation X.217.

8.1.1	Abstract-bind onto A-ASSOCIATE

The abstract-bind service is mapped onto the A-ASSOCIATE service of the ACSE. The use of the parameters of the A-ASSOCIATE service is qualified in the following subparagraphs.

8.1.1.1	Mode

This parameter shall be supplied by the initiator of the association in the A-ASSOCIATE request primitive, and shall have the value "normal mode".

8.1.1.2	Application Context Name

The initiator of the association shall propose either the directoryAccessAC or the directorySystemAC application-context.

8.1.1.3	User information

The mapping of the bind-operation of the abstract-bind service onto the User Information parameters of the A-ASSOCIATE request primitive is defined in Recommendation X.219.

8.1.1.4	Presentation Context Definition List

The initiator of the association shall supply the Presentation Context Definition List in the A-ASSOCIATE request primitive which shall contain the ACSE abstract-syntax (id-as-acse) and either the DAP abstract-syntax (id-as-directoryAccessAS) or the DSP abstract-syntax (id-as- directorySystemAS).

8.1.1.5	Quality of service

This parameter shall be supplied by the initiator of the association in the A-ASSOCIATE request primitive, and by the responder of the association in the A-ASSOCIATE response primitive. The parameters "Extended Control" and "Optimized Dialogue Transfer" shall be set to "feature not desired". The remaining parameters shall be such that default values are used.

8.1.1.6	Session requirements

This parameter shall be set by the initiator of the association in the A-ASSOCIATE request primitive, and by the responder of the association in the

A-ASSOCIATE response primitive. The parameter shall be set to specify the following functional units:

a)	Kernel;

b)	Duplex.

8.1.1.7	Application Entity Title and Presentation Address

These parameters shall be supplied by the initiator and the responder of the association (Application Entity Title is optionally supplied). For a

DUA establishing an association for an initial request, these parameters are obtained from locally held information.

For a DUA (or DSA) establishing an association with a DSA to which it has been referred, these parameters are obtained from the AccessPoint value of

a ContinuationReference. For a DSA establishing an association, this parameter is obtained from its Knowledge Information, i.e. an external reference.

8.1.2	Abstract-unbind onto A-RELEASE

The abstract-unbind service is mapped onto the A-RELEASE service of the ACSE. The use of the parameters of the A-RELEASE service is qualified in the following subparagraph.

8.1.2.1	Result

This parameter shall have the value "affirmative".

8.1.3	Use of A-ABORT and A-P-ABORT services

The application-process is the user of the A-ABORT and A-P-ABORT services of the ACSE.

8.2	Mapping onto ROSE

The Directory ASE services are mapped onto the RO-INVOKE, RO-RESULT, RO-ERROR, RO-REJECT-U and RO-REJECT-P services of the ROSE. The mapping of the abstract-syntax notation of the Directory ASEs onto the ROSE services is as defined in Recommendation X.219.

9	Conformance

This paragraph defines the requirements for conformance to this Recommendation.

9.1	Conformance by DUAs

A DUA implementation claiming conformance to this Recommendation shall satisfy the requirements specified in 9.1.1 to 9.1.3.

9.1.1	Statement requirements

The following shall be stated:

a)	the operations of the directoryAccessAC application-context that the DUA is capable of invoking for which conformance is claimed; and

b)	the security-level(s) for which conformance is claimed (none, simple, strong).

9.1.2	Static requirements

A DUA shall:

a)	have the capability of supporting the directoryAccessAC application-context as defined by its abstract syntax in 7.

9.1.3	Dynamic requirements

A DUA shall:

a)	conform to the mapping onto used services defined in 8.

9.2	Conformance by DSAs

A DSA implementation claiming conformance to this Recommendation shall satisfy the requirements specified in 9.2.1 to 9.2.3.

9.2.1	Statement requirements

The following shall be stated:

a)	the application-contexts for which conformance is claimed: directoryAccessAC, directorySystemAC, or both. If a DSA is such that knowledge of it has been disseminated causing knowledge references to the DSA to be held by other DSA(s) outside of its own DMD, then it shall claim conformance to the directorySystemAC;

Note - An application context shall not be divided, except as stated herein: in particular, conformance may not be claimed to particular ports or operations.

b)	whether or not the DSA is capable of acting as a first-level DSA, as defined in Recommendation X.518;

c)	if conformance is claimed to the directorySystemAC application-context, whether or not the chained mode of operation is supported, as defined in Recommendation X.518;

d)	the security-level(s) for which conformance is claimed (none, simple, strong);

e)	the selected attribute types defined in Recommendation X.520 and any other attribute types, for which conformance is claimed; and

f)	the selected object classes defined in Recommendation X.521 and any other object classes, for which conformance is claimed.

9.2.2	Static requirements

A DSA shall:

a)	have the capability of supporting the application-contexts for which conformance is claimed as defined by their abstract syntax in 7;

b)	have the capability of supporting the information framework defined by its abstract syntax in Recommendation X.501;

c)	conform to the minimal knowledge requirements defined in Recommendation X.518;

d)	if conformance is claimed as a first-level DSA, conform to the requirements for support of the root context, as defined in Recommendation X.518;

e)	have the capability of supporting the attribute types for which conformance is claimed as defined by their abstract syntaxes; and

f)	have the capability of supporting the object classes for which conformance is claimed, as defined by their abstract syntaxes.

9.2.3	Dynamic requirements

A DSA shall:

a)	conform to the mapping onto used services defined in 8 of this Recommendation;

b)	conform to the procedures for distributed operation of the Directory related to referrals, as defined in Recommendation X.518;

c)	if conformance is claimed to the directoryAccessAC application-context, conform to the procedures of Recommendation X.518 as they relate to the referral mode of the DAP;

d)	if conformance is claimed to the directorySystemAC application-context, conform to the referral mode of interaction, as defined in Recommendation X.518;

e)	if conformance is claimed to the chained mode of interaction, conform to the chained mode of interaction, as defined in Recommendation X.518.

Note - Only in this case is it necessary for a DSA to be capable of invoking operations using the directorySystemAC.

ANNEX A

(to Recommendation X.519)

DAP in ASN.1

This Annex is part of the Recommendation.

This Annex includes all of the ASN.1 type and value definitions contained in this Recommendation in the form of the ASN.1 module, DirectoryAccessProtocol.

DirectoryAccessProtocol {joint-iso-ccitt ds(5) modules(1) dap(11)}

DEFINITIONS ::=

BEGIN

EXPORTS

directoryAccessAC, readASE, searchASE, modifyASE;

IMPORTS

abstractService

FROM	UsefulDefinitions

{joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0)}

APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE

FROM	Remote-Operations-Notation-extension

{joint-iso-ccitt remoteOperations(4) notation-extension(2)}

id-ac-directoryAccessAC, id-ase-readASE, id-ase-searchASE,

id-ase-modifyASE, id-as-directoryAccessAS, id-as-acse

FROM	ProtocolObjectIdentifiers

{joint-iso-ccitt ds(5) modules(1)

protocolObjectIdentifiers(4)}

DirectoryBind, DirectoryUnbind, Read, Compare, Abandon, List,

Search, AddEntry, RemoveEntry, ModifyEntry, ModifyRDN, Abandoned, AbandonFailed, AttributeError, NameError, Referral, SecurityError, ServiceError,

UpdateError

FROM	DirectoryAbstractService

directoryAbstractService;

-- Application Contexts --

directoryAccessAC

APPLICATION-CONTEXT

APPLICATION SERVICE ELEMENTS {aCSE}

BIND DirectoryBind

UNBIND DirectoryUnbind

REMOTE OPERATIONS {rOSE}

INITIATOR CONSUMER OF {readASE, searchASE, modifyASE}

ABSTRACT SYNTAXES {

id-as-acse, id-as-directoryAccessAS}

::=	id-ac-directoryAccessAC

-- Read ASE --

readASE

APPLICATION-SERVICE-ELEMENT

CONSUMER INVOKES {read, compare, abandon}

::=	id-ase-readASE

-- Search ASE --

searchASE

APPLICATION-SERVICE-ELEMENT

CONSUMER INVOKES {list, search}

::=	id-ase-searchASE

-- Modify ASE --

modifyASE

APPLICATION-SERVICE-ELEMENT

CONSUMER INVOKES

{addEntry, removeEntry,

modifyEntry, modifyRDN}

::=	id-ase-modifyASE

-- Remote Operations --

read	Read	::= 1

compare	Compare	::= 2

abandon	Abandon	::= 3

list	List	::= 4

search	Search	::= 5

addEntry	AddEntry	::= 6

removeEntry	RemoveEntry	::= 7

modifyEntry	ModifyEntry	::= 8

modifyRDN	ModifyRDN	::= 9

-- Remote Errors --

attributeError	AttributeError	::= 1

nameError	NameError	::= 2

serviceError	ServiceError	::= 3

referral	Referral	::= 4

abandoned	Abandoned	::= 5

securityError	SecurityError	::= 6

abandonFailed	AbandonFailed	::= 7

updateError	UpdateError	::= 8

END

ANNEX B

(to Recommendation X.519)

DSP in ASN.1

This Annex is part of the Recommendation.

This Annex includes all of the ASN.1 type and value definitions contained in this Recommendation in the form of the ASN.1 module, DirectorySystemProtocol.

DirectorySystemProtocol {joint-iso-ccitt ds(5) modules(1) dsp(12)}

DEFINITIONS ::=

BEGIN

EXPORTS

directorySystemAC, chainedReadASE, chainedSearchASE, chainedModifyASE;

IMPORTS

distributedOperations, directoryAbstractService

FROM	UsefulDefinitions

{joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0)}

APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE

FROM	Remote-Operations-Notation-extension

{joint-iso-ccitt remoteOperations(4) notation-extension(2)}

id-ac-directorySystemAC, id-ase-chainedReadASE,

id-ase-chainedSearchASE, id-ase-chainedModifyASE,

id-as-directorySystemAS, id-as-acse;

FROM	ProtocolObjectIdentifiers

{joint-iso-ccitt ds(5) modules(1)

protocolObjectIdentifiers(4)}

Abandoned, AttributeError, AbandonFailed,

NameError, DSAReferral, SecurityError, ServiceError, UpdateError

FROM	DirectoryAbstractService directoryAbstractService

DSABind, DSAUnbind,

ChainedRead, ChainedCompare, ChainedAbandon,

ChainedList, ChainedSearch,

ChainedAddEntry, ChainedRemoveEntry, ChainedModifyEntry,

ChainedModifyRDN, DSAReferral,

FROM	DistributedOperations

distributedOperations;

-- Application Contexts --

directorySystemAC

APPLICATION-CONTEXT

APPLICATION SERVICE ELEMENTS {aCSE}

BIND DSABind

UNBIND DSAUnbind

REMOTE OPERATIONS {rOSE}

OPERATIONS OF {

chainedReadASE, chainedSearchASE, chainedModifyASE}

ABSTRACT SYNTAXES {

id-as-acse, id-as-directorySystemAS}

::=	{id-ac-directorySystemAC}

-- Chained Read ASE --

chainedReadASE

APPLICATION-SERVICE-ELEMENT

OPERATIONS	{chainedRead, chainedCompare, chainedAbandon}

::=	id-ase-chainedReadASE

-- Chained Search ASE --

chainedSearchASE

APPLICATION-SERVICE-ELEMENT

OPERATIONS {chainedList, chainedSearch}

::=	id-ase-chainedSearchASE

-- Chained Modify ASE --

chainedModifyASE

APPLICATION-SERVICE-ELEMENT

OPERATIONS

{chainedAddEntry, chainedRemoveEntry,

chainedModifyEntry, chainedModifyRDN}

::=	id-ase-chainedModifyASE

-- Remote Operations --

chainedRead	ChainedRead	::= 1

chainedCompare	ChainedCompare	::= 2

chainedAbandon	ChainedAbandon	::= 3

chainedlist	ChainedList	::= 4

chainedSearch	ChainedSearch	::= 5

chainedAddEntry	ChainedAddEntry	::= 6

chainedRemoveEntry	ChainedRemoveEntry	::= 7

chainedModifyEntry	ChainedModifyEntry	::= 8

chainedModifyRDN	ChainedModifyRDN	::= 9

-- Remote Errors --

attributeError	AttributeError	::= 1

nameError	NameError	::= 2

serviceError	ServiceError	::= 3

abandoned	Abandoned	::= 5

securityError	SecurityError	::= 6

abandonFailed	AbandonFailed	::= 7

updateError	UpdateError	::= 8

dsaReferral	DSAReferral	::= 9

END

ANNEX C

(to Recommendation X.519)

Reference definition of protocol object identifiers

This Annex is part of the Recommendation.

This Annex includes all of the ASN.1 Object Identifiers assigned in this Recommendation in the form of ASN.1 module, ProtocolObjectIdentifiers.

ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) modules(1) protocolObjectIdentifiers(4)}

DEFINITIONS ::=

BEGIN

EXPORTS

id-ac-directoryAccessAC, id-ac-directorySystemAC, id-ase-readASE, id-ase-searchASE,

id-ase-modifyASE, id-ase-chainedReadASE,

id-ase-chainedSearchASE, id-ase-chainedModifyASE, id-as-acse,

id-as-directoryAccessAS, id-as-directorySystemsAS;

IMPORTS

id-ac, id-ase, id-as

FROM	UsefulDefinitions

{joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0)};

-- Application Contexts --

id-ac-directoryAccessAC	OBJECT IDENTIFIER ::= {id-ac 1}

id-ac-directorySystemAC	OBJECT IDENTIFIER ::= {id-ac 2}

-- ASEs --

id-ase-readASE	OBJECT IDENTIFIER ::= {id-ase 1}

id-ase-searchASE	OBJECT IDENTIFIER ::= {id-ase 2}

id-ase-modifyASE	OBJECT IDENTIFIER ::= {id-ase 3}

id-ase-chainedReadASE	OBJECT IDENTIFIER ::= {id-ase 4}

id-ase-chainedSearchASE	OBJECT IDENTIFIER ::= {id-ase 5}

id-ase-chainedModifyASE	OBJECT IDENTIFIER ::= {id-ase 6}

-- ASs --

id-as-directoryAccessAS	OBJECT IDENTIFIER ::= {id-as 1}

id-as-directorySystemAS	OBJECT IDENTIFIER ::= {id-as 2}

id-as-acse	OBJECT IDENTIFIER ::=

{joint-iso-ccitt association-control(2) abstract-syntax(1) apdus(0)

version1(1)}

END