- _ - COM VII-R 51-E CCITT\COMVII\RAPP\R051E2.DOC 2. Draft revised Recommendation X.519 Information Technology Ñ Open Systems Interconnection Ñ The Directory: Protocol Specifications Draft Recommendation X.519 ISO/IEC DIS 9594-5 CONTENTS Introduction 1. Scope 2. Normative 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 Directory Information Shadowing Protocol 6.5 Directory Operational Binding Management Protocol 6.6 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 7.5 Versions and the rules for extensibility 8. Mapping onto Used Services 8.1 Application contexts omitting RTSE 8.1.1 Mapping onto ACSE 8.1.2 Mapping onto ROSE 8.2 Application contexts including RTSE 9. Conformance 9.1 Conformance by DUAs 9.2 Conformance by DSAs 9.3 Conformance by a Shadow Supplier 9.4 Conformance by a Shadow Consumer Annex A - DAP in ASN.1 Annex B - DSP in ASN.1 Annex C - DISP in ASN.1 Annex D - DOP in ASN.1 Annex E - Reference Definition of Protocol Object Identifiers Annex F - Directory Operational Binding Types Annex G - Amendments and Corrigenda Introduction This CCITT Recommendation|International Standard, together with the other Recommendations of the series|parts of ISO/IECÊ9594, 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. 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. This Recommendation|International Standard 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. In addition this CCITT Recommendation|International Standard specifies the application service elements and application contexts for the Directory Information Shadowing Protocol (DISP) and the Directory Operational Binding Management Protocol (DOP). The DISP provides for the shadowing of information held in one DSA to another DSA. The DOP provides for the establishment, modification and termination of bindings between pairs of DSAs for the administration of relationships between the DSAs (such as for shadowing or hierarchical relationships. Information Technology Ñ Open Systems Interconnection Ñ The Directory: Protocol Specifications 1 Scope This Recommendation|International Standard specifies the Directory Access Protocol and the Directory System Protocol, fulfilling the abstract services specified in CCITT Rec. X.511 | ISO/IECÊ9594-3 and CCITT Rec. X.518 | ISO/IECÊ9594-4. 2 Normative references The following Recommendation|International Standards contain provisions which, through reference in this text, constitute provisions of the Recommendation|International Standard. At the time of publication, the editions indicated were valid. All Recommendation|International Standards are subject to revision, and entities to agreements based on this Recommendation|International Standard are encouraged to investigate the possibility of applying the most recent edition of the Recommendation|International Standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.The CCITT Secretariat maintains a list of currently valid CCITT Recommendations. Ñ CCITT Recommendation X.500 (1992) | ISO/IEC 9594-1:1990, Information Technology Ñ Open Systems Interconnection Ñ The Directory: Overview of Concepts, Models and Services. Ñ CCITT Recommendation X.501 (1992) | ISO/IEC 9594-2:1992, Information Technology Ñ Open Systems Interconnection Ñ The Directory: Models. Ñ CCITT Recommendation X.511 (1992) | ISO/IEC 9594-3:1992, Information Technology Ñ Open Systems Interconnection Ñ The Directory: Abstract Service Definition. Ñ CCITT Recommendation X.518 (1992) | ISO/IEC 9594-4:1992, Information Technology Ñ Open Systems Interconnection Ñ The Directory: Procedures for Distributed Operation. Ñ CCITT Recommendation X.519 (1992) | ISO/IEC 9594-5:1992, Information Technology Ñ Open Systems Interconnection ÑThe Directory: Protocol Specifications. Ñ CCITT Recommendation X.520 (1992) | ISO/IEC 9594-6:1992, Information Technology Ñ Open Systems Interconnection ÑThe Directory: Selected Attribute Types. Ñ CCITT Recommendation X.521 (1992) | ISO/IEC 9594-7:1992, Information Technology Ñ Open Systems Interconnection ÑThe Directory: Selected Object Classes. Ñ CCITT Recommendation X.509 (1992) | ISO/IEC 9594-8:1992, Information Technology Ñ Open Systems Interconnection Ñ The Directory: Authentication Framework. Ñ CCITT Recommendation X.525 (1992) | ISO/IEC 9594-9:1992, Information Technology Ñ Open Systems Interconnection Ñ The Directory: Replication Ñ CCITT Recommendation X.200 (1988) Basic reference Model ISO 7498:1984, Information Processing Systems Ñ Open Systems Interconnection Ñ Basic Reference Model. ISO 7498-2: 1987, Information Processing Systems Ñ Open Systems Interconnection Ñ Basic Reference Model Ñ PartÊ2: Security architecture. Ñ CCITT Recommendation X.217, Open Systems Interconnection Ñ Service Definition. for the Association Control Service Element. ISO 8649:1988, Information Processing Systems Ñ Open Systems Interconnection Ñ Service Definition. for the Association Control Service Element. Ñ CCITT Recommendation X.227, Open Systems Interconnection Ñ Protocol Specification for the Association Control Service Element. ISO 8650:1988, Information Processing Systems Ñ Open Systems Interconnection Ñ Protocol Specification for the Association Control Service Element. ISO/IEC 9072-1:1989, Information Processing Systems Ñ Text Communication Ñ Remote Operations Part 1: Model, Notation and Service Definition. 3 Definitions The definitions contained in this clause make use of the abbreviations defined in clause 4. 3.1 OSI Reference Model Definitions The following terms are defined in CCITT Rec. X.200|ISO 7498, and makes use of the following terms defined therein: a)application-service-element. b)application-protocol-control-information c)application-protocol-data-unit d)application-context e)application-entity f)abstract-syntax. 3.2 Basic Directory Definitions The following terms are defined in CCITT Rec. X.501|ISO/IECÊ9594-2: a)the Directory; b)(Directory) user; c)Directory System Agent (DSA); d)Directory User Agent (DUA). 3.3 Distributed Operation Definitions The following terms are defined in CCITT Rec. X.518|ISO/IECÊ9594-4: a)chaining; b)referral. 4 Abbreviations The following abbreviations are used in this Recommendation|part of ISO/IECÊ9594: 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 DISP Directory Information Shadowing Protocol DOP Directory Operational Binding Management Protocol DSA Directory System Agent DSP Directory System Protocol DUA Directory User Agent ROSE Remote Operations Service Element 5 Conventions This Directory Specification has been prepared according to the "Presentation of CCITT/ISO/IEC common text" guidelines in the Guide for CCITT and ISO/IECÊJTCÊ1 Cooperation, September 1991. Exceptions to these guidelines are described below. The term "Directory Specification" (as in "this Directory Specification") shall be taken to mean CCITT Rec. X.519 | ISO/IEC 9594-5. The term "Directory Specifications" shall be taken to mean the X.500-Series of Recommendations and all parts of ISO/IEC 9594. 6 Protocol Overview 6.1 Directory Protocol Model CCITT Rec. X.511|ISO/IEC 9594-3 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. CCITT Rec. X.518|ISO/IECÊ9594-4 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. FIGURE 1 Directory Interactions 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 clause. The Directory Information Shadowing Protocol (DISP) supports the shadowing of information between a shadow supplier and a shadow consumer. The Directory Operational Binding Management Protocol (DOP) supports the management of operational bindings between two DSAs. The Remote Operations Service Element (ROSE) supports the request/reply paradigm of the operation. 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. Optionally, the Reliable Transfer Service Element (RTSE) may be used to reliably transfer the Application Protocol Data Units (APDUs) of the DISP. 6.2 Directory Access Protocol The Directory Access Protocol (DAP) is used to realize 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 Directory Read operations, the Directory Search operations and the Directory Modify operations as specified by the Directory 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 realize the functionality of distributed operation described in CCITT Rec. X.518|ISO/IECÊ9594-4 It comprises three directory specific ASEs in addition to ROSE and ACSE. These are: chainedReadASE, chainedSearchASE, and chainedModifyASE. They correspond to the Directory Chained Read operations, the Directory Chained Search operations and the Directory Chained Modify operations as specified by the DSA Abstract Service. The directorySystemAC application context identifies the combination of: chainedReadASE, chainedSearchASE, and chainedModifyASE, aCSE, rOSE. 6.4 Directory Information Shadowing Protocol The Directory Information Shadowing Protocol (DISP) is used to realise the functionality of shadowing as described in CCITT Recommendation X.525|ISO/IEC 9594-9. It comprises two directory specific ASEs in addition to ROSE, ACSE and (optionally) RTSE. These are: shadowConsumerASE and shadowSupplierASE. The shadowConsumerASE and shadowSupplierASE correspond to the Directory Information Shadowing Service. The shadowSupplierInitiatedAC application context identifies the combination of: shadowSupplierASE, aCSE, rOSE. The shadowConsumerInitiatedAC application context identifies the combination of: shadowConsumerASE, aCSE, rOSE. The reliableShadowSupplierInitiatedAC application context identifies the combination of: shadowSupplierASE, aCSE, rOSE and rTSE. The reliableShadowConsumerInitiatedAC application context identifies the combination of: shadowConsumerASE, aCSE, rOSE and rTSE. If a DSA supports the DISP, that DSA shall support at least one of the shadow supplier role or shadow consumer role and at least one of the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. If a DSA supports the shadowSupplierInitiatedAC for a particular role, it may also optionally support the reliableShadowSupplierInitiatedAC for the same role. If a DSA supports the shadowConsumerInitiatedAC for a particular role, it may also optionally support the reliableShadowConsumerInitiatedAC for the same role. 6.5 Directory Operational Binding Management Protocol The Directory Operational Binding Management Protocol (DOP) is used to realise the functionality of operational binding management as described in CCITT Recommendation X.501 ISO/IEC 9594-2 It comprises one directory specific ASE, the operationalBindingManagementASE in addition to ROSE and ACSE. The operationalBindingManagementASE corresponds to the establishOperationalBinding, modifyOperationalBinding and terminateOperationalBinding service facilities. The directoryOperationalBindingManagementAC application context identifies the combination of: operationalBindingManagementASE, aCSE, rOSE. 6.6 Use of Underlying Services The DAP, DSP, DOP and DISP protocols make use of underlying services as described below. 6.6.1Use of ROSE Services The Remote Operations Service Element (ROSE) is defined CCITT Rec.ÊX.219 [ISOÊ9072-1]. 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. The remote operations of the DISP must be supported as Class 1 (synchronous) operations and may optionally be supported as Class 2 (asynchronous) operations. The remote operations of the DOP are Class 2 (asynchronous) operations. 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. DOP uses Association Class 1 meaning that only the initiating DSA may invoke operations. The shadowSupplierInitiatedAC and reliableShadowSupplierInitiatedAC of the DISP use Association Class 1. The shadowConsumerInitiatedAC and reliableShadowConsumerInitiatedAC of the DISP use Association Class 2. 6.6.2Use of RTSE services The Reliable Transfer Service Element (RTSE) is defined in CCITT RecommendationÊX.218|ISO/IEC 9066-1. The RTSE provides for the reliable transfer of Application Protocol Data Units (APDUs). The RTSE ensures that each APDU is completely transferred exactly once, or that the sender is warned of an exception. The RTSE recovers from communication and end- system failure and minimizes the amount of retransmission needed for recovery. Alternative application contexts with and without RTSE are defined to support the DISP. The RTSE is used in normal mode. The use of the normal mode of the RTSE implies the use of the normal mode of the ACSE and the normal mode of the Presentation Service. If the RTSE in included in an application context, the DSAShadowBind is the sole users of the RT-OPEN service of the RTSE and the DSAShadowUnbind is the sole user of the RT-CLOSE service of the RTSE. The ROSE is the sole user of the RT-TRANSFER, RT-TURN- PLEASE, RT-TURN-GIVE, RT-P-ABORT and RT-U-ABORT services of the RTSE. 6.6.3Use of ACSE Services The Association Control Service Element (ACSE) is defined in CCITT Rec. X.217 |ISOÊ8649. The ACSE provides for the control (establishment, release, abort) of application-associations between AEs. If the RTSE is included in an application context, the RTSE is the sole user of the A-ASSOCIATE, A-RELEASE, A-ABORT and A-P-ABORT services of the ACSE. If the RTSE is not included in an application context, the Directory Bind and Directory Unbind (or DSA Bind and DSA Unbind, or DOP Bind and DOP Unbind, or DSA Shadow Bind and DSA Shadow Unbind) are the sole users of the A-ASSOCIATE and A-RELEASE services of the ACSE. The application-process is the user of the A-ABORT and A-P- ABORT services of the ACSE. The receipt of an a-abort or a-p-abort on an association supporting the dap terminates all request processing. except for certain conditions described in CCITT Recommendation X.518 |ISO/IEC 9594-4, this is also true for the DSP. It is a Directory user responsibility to confirm if requested modifications to the dib occured. The receipt of an a-abort or a-p-abort on an association supporting the DISP is described in CCITT Recommendation X.525|ISO/IEC 9594-9. The receipt of an a-abort or a-p-abort on an association supporting the dop is described in CCITT Recommendation X.518|ISO/IEC 9594-4. 6.6.4Use of the Presentation Service The presentation-service is defined in CCITT Rec. X.216|ISO 8822. 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. If the RTSE is included in an application context, the RTSE is the sole user of the P-ACTIVITY-START, P-ACTIVITY-END, P-ACTIVITY- INTERRUPT, P-ACTIVITY-DISCARD, P-ACTIVITY-RESUME, P-DATA, P-MINOR- SYNCHRONIZE, P-U-EXCEPTION-REPORT, P-P-EXCEPTION-REPORT, P-TOKEN- PLEASE and P-CONTROL-GIVE services of the Presentation Service. If the RTSE is not included in an application context, the ROSE is the sole user of the P-DATA service of the Presentation Service. Presentation default context, context restoration, and context management are not used. 6.6.5Use of Lower Layer Services (Subclause 6.6.5 applies to CCITT Rec. X.519 only and not to ISO/IEC 9594-5) The session-service is defined in Recommendation X.215. The Session Layer structures the dialogue of the flow of information between the end-systems. If the RTSE is included in an application context, the Kernel, Half-duplex, Exceptions, Minor-synchronize and Activity Management functional units of the Session Service are used by the Presentation Layer. If the RTSE is not included included in the application context, 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 Recommenda-tionÊX.213 is assumed. A network-address is as defined in Recommendation X.121, Recommenda-tionsÊ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-directory-systemAS. The Directory ASE specified in clauses 7.2.7 uses a single abstract syntax id-as- directoryOperationalBindingManagementAS. The Directory ASEs specified in clauses 7.2.8 and 7.2.9 use either the id-as- directoryShadowAS or id-as-directoryReliableShadowingAS, depending on the application context in use. 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 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 Basic ASN.1 encoding rules. 7.2 Directory Application Service Elements This clause 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 application contexts defined in this Specification They are not intended to allow for claims of conformance to individual, or other combinations of, ASEs. 7.2.1Read ASE The readASE supports the Read, Compare, and Abandon operations as defined in CCITT Rec.ÊX.511|ISO/IECÊ9594-3. readASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES {read, compare, abandon} ::= id-ase-readASE read Read ::= 1 compare Compare ::= 2 abandon Abandon ::= 3 7.2.2Chained Read ASE The chainedReadASE supports the ChainedRead, ChainedCompare, and ChainedAbandon operations as defined in CCITT Rec. X.518|ISO/IECÊ9594-4. chainedReadASE APPLICATION-SERVICE-ELEMENT OPERATIONS { chainedRead, chainedCompare, chainedAbandon} ::= id-ase-chainedReadASE chainedRead ChainedRead ::= 1 chainedCompare ChainedCompare ::= 2 chainedAbandon ChainedAbandon ::= 3 7.2.3Search ASE The searchASE supports the List and Search operations as defined in CCITT Rec. X.511| ISO/IECÊ9594-3. searchASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES { list, search} ::= id-ase-searchASE} list List ::= 4 search Search ::= 5 7.2.4Chained Search ASE The chainedSearchASE supports the ChainedList and ChainedSearch operations as defined in CCITT Rec. X.518|ISO/IECÊ9594-4. chainedSearchASE APPLICATION-SERVICE-ELEMENT OPERATIONS { chainedList, chainedSearch} ::= id-ase-chainedSearchASE chainedList ChainedList ::= 4 chainedSearch ChainedSearch ::= 5 7.2.5Modify ASE The modifyASE supports the AddEntry, RemoveEntry, ModifyEntry, and ModifyRDN operations as defined in CCITT Rec. X.511|ISO/IECÊ9594-3. 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.6Chained Modify ASE The chainedModifyASE supports the ChainedAddEntry, ChainedRemoveEntry, ChainedModifyEntry, and ChainedModifyRDN operations as defined in CCITT Rec. X.518|ISO/IECÊ9594-4. chainedModifyASE APPLICATION-SERVICE-ELEMENT OPERATIONS {chainedAddEntry, chainedRemoveEntry, chainedModifyEntry, chainedModifyRDN} ::= id-chainedModifyASE chainedAddEntry ChainedAddEntry ::= 6 chainedRemoveEntry ChainedRemoveEntry ::= 7 chainedModifyEntry ChainedModifyEntry ::= 8 chainedModifyRDN ChainedModifyRDN ::= 9 7.2.7Operational Binding Management ASE The operationalBindingManagementASE supports the establishOperationalBinding, modifyOperationalBinding and terminateOperationalBinding operations of the operationalBindingManagementPort as defined in CCITT Recommendation X.501|ISO/IEC 9594-2. operationalBindingManagementASE APPLICATION-SERVICE-ELEMENT OPERATIONS { establishOperationalBinding, modifyOperationalBinding, terminateOperationalBinding } ::= id-ase-operationalBindingManagementASE establishOperationalBinding EstablishOperationalBinding ::= 100 modifyOperationalBinding ModifyOperationalBinding ::= 102 terminateOperationalBinding TerminateOperationalBinding ::= 101 7.2.8Shadow Consumer ASE The shadowConsumerASE supports the requestShadowUpdate and updateShadow operations as defined in CCITT Recommendation X.525|ISO/IEC 9594-9. shadowConsumerASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES { requestShadowUpdate } SUPPLIER INVOKES { updateShadow } ::= id-ase-shadowConsumerASE requestShadowUpdate RequestShadowUpdate ::= 1 updateShadow UpdateShadow ::= 2 7.2.9Shadow Supplier ASE The shadowSupplierASE supports the coordinateShadowUpdate and updateShadow operations as defined in CCITT Recommendation X.525|ISO/IEC 9594-9. shadowSupplierASE APPLICATION-SERVICE-ELEMENT SUPPLIER INVOKES { coordinateShadowUpdate, updateShadow } ::= id-ase-shadowSupplierASE coordinateShadowUpdate CoordinateShadowUpdate ::= 3 7.3 Directory Application Contexts 7.3.1Directory 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.2Directory 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-as-directorySystemAC 7.3.3Directory Operational Binding Management Application Context The directoryOperationalBindingManagementAC allows DSAs to communicate for the purpose of establishing, modifying or terminating an operational binding. directoryOperationalBindingManagementAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE} BIND DSADOPBind UNBIND DSADOPUnbind REMOTE OPERATIONS {rOSE} OPERATIONS OF { operationalBindingManagementASE } ABSTRACT SYNTAXES { id-as-acse, id-as-directoryOperationalBindingManagementAS } ::= id-ac-directoryOperationalBindingManagementAC 7.3.4Shadow Supplier Initiated Application Context The shadowSupplierInitiatedAC allows a shadow supplier to inform a shadow consumer that updates are available and also to send those updates. This application context allows the shadow consumer to receive updates without initiating a request for them. shadowSupplierInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} RESPONDER CONSUMER OF { shadowSupplierASE } ABSTRACT SYNTAXES { id-as-acse, id-as-directoryShadowAS } ::= id-ac-shadowSupplierInitiatedAC 7.3.5Shadow Consumer Initiated Application Context The shadowConsumerInitiatedAC allows a shadow consumer to request and receive updates from a shadow supplier. This application context allows a shadow supplier to send updates to a shadow consumer, following an explicit request for them. shadowConsumerInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} INITIATOR CONSUMER OF { shadowConsumerASE } ABSTRACT SYNTAXES { id-as-acse, id-as-directoryShadowAS } ::= id-ac-shadowConsumerInitiatedAC 7.3.6Reliable Shadow Supplier Initiated Application Context The reliableShadowSupplierInitiatedAC allows a shadow supplier to, in a reliable manner, inform a shadow consumer that updates are available and also to send those updates. This application context allows the shadow consumer to, in a reliable manner, receive updates without initiating a request for them. reliableShadowSupplierInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE, rTSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} RESPONDER CONSUMER OF {shadowSupplierASE} ABSTRACT SYNTAXES { id-as-acse, id-as-directoryReliableShadowAS } ::= id-ac-reliableShadowSupplierInitiatedAC 7.3.7Reliable Shadow Consumer Initiated Application Context The reliableShadowConsumerInitiatedAC allows a shadow consumer to, in a reliable manner, request and receive updates from a shadow supplier. This application context allows a shadow supplier to, in a reliable manner, send updates to a shadow consumer following an explicit request for them. reliableShadowConsumerInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE, rTSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} INITIATOR CONSUMER OF {shadowConsumerASE} ABSTRACT SYNTAXES { id-as-acse, id-as-directoryReliableShadowAS } ::= id-ac-reliableShadowConsumerInitiatedAC 7.4 Errors Corresponding to each error defined in the Abstract Service is an error value which may be conveyed by the protocol. The assignments follow: abandoned Abandoned ::= 5 abandonFailed AbandonFailed ::= 7 attribute- AttributeError ::= 1 error dSAReferral DSAReferral ::= 9 name-error NameError ::= 2 referral Referral ::= 4 security-error SecurityError ::= 6 service-error ServiceError ::= 3 update-error UpdateError ::= 8 shadowError ShadowError ::= 10 operationalBin OperationalBin ::= 11 dingError dingError 7.5 Versions and the rules for extensibility The Directory may be distributed and more than two Directory Application Entities may interoperate to service a request. The Directory AEs may be implemented conforming to different editions of the Directory specification of the Directory service which may or may not be represented by different protocol version numbers. The version number is negotiated to the highest common version number between two directly binding Directory AEs. Notes 1 for example, a DUA supporting both versions 1 & 2 of the protocol may bind to a DSA supporting only version 1 of the protocol with a resulting agreed version of 1. That DSA may further bind to a version 1 & 2 DSA supporting version 1 & 2 of the prtocol with a resulting agreed version of 1. Even though both the DUA and the remote DSA can support version 2, the negotiated versions are 1. 2 there is currently only one version of the Directory protocol. Version negotiation is used only to support those point to point aspects of communication which must be common between the two directly bound Directory AEs. Note Ñ for example, basic understanding of the PDU exchange paradigm on the point to point connection (e.g., ROSE), common understanding of name resolution between the associated entities, and the point to point operations of the Replication protocol and the Operational Binding would be aspects that would be agreed through version negotiation. A DUA may issue a request as specified in the latest edition of the Directory specifcation to which the DUA was implemented, i.e., the level. Using the rules of extensibility defined below, that request shall be forwarded to the appropriate DSA that will respond to that request, regardless of the level of the intervening DSAs. The responding DSA shall function as defined below. Note Ñ A intermediate DSA only chaining the request may choose to examine only the Directory APDU PCI that is needed to perform its function, e.g., name resolution. 7.5.1DUA to DSA 7.5.1.1 Version negotiation When accepting an association, i.e., binding, utilizing the DAP, the version negotiated shall only effect the point to point aspects of the protocol exchanged between the DUA and the DSA to which it is connected. Subsequent requests or responses on the association shall not be constrained by the version negotiated. Note Ñ there are no point to point aspects of the DAP that are currently indicated by different protocol versions. 7.5.1.2 Request and response processing The DUA may initiate requests using the highest level of the specification of that request it supports. If one or more elements of the request are critical, it shall indicate the extension number(s) in the criticalExtensions parameter. Note Ñ if the information the extension replaced in a choice, enumerated, or integer (used as enumerated) type would be essential for proper operation in a DSA implemented according to an earlier edition of the Specification, it is recommended that the extension be marked critical. When processing a response, a DUA shall: a)not consider the receipt of unknown types and values as a protocol violation (i.e., it shall not issue a ro-u-reject or abort the application association); and b)optionally report the unknown types and values to the user. 7.5.1.3 Extensibility rules for error handling When processing a known error type with unknown indicated problems and parameters, a DUA shall: a)not consider the receipt of unknown indicated problems and parameters as a protocol violation (i.e., it shall not issue a ro-u-reject or abort the application association); and b)optionally report the additional error information to the user. When processing an unknown error type, a DUA shall: a)not consider the receipt of unknown error type as a protocol violation (i.e., it shall not issue a ro-u-reject or abort the application association); and b)optionally report the error to the user. 7.5.2DSA to DSA 7.5.2.1 Version negotiation When establishing or accepting an association, i.e., binding, utilizing the DSP, the version negotiated shall only effect the point to point aspects of the protocol exchanged between the DSAs. Subsequent requests or responses on the association shall not be constrained by the version negotiated. Note Ñ there are no point to point aspects of the DSP that are currently indicated by different protocol versions. When establishing or accepting an association, i.e., binding, utilizing the DISP, the version negotiated shall define all aspects of the protocol exchanged between the DSAs. Subsequent requests or responses on the association shall be constrained by the version negotiated. Note Ñ there is currently only one version of the DISP protocol. When establishing or accepting an association, i.e., binding, utilizing the DOP, the version negotiated shall define all aspects of the protocol exchanged between the DSAs. Subsequent requests or responses on the association shall be constrained by the version negotiated. Note Ñ there is currently only one version of the DOP protocol. 7.5.2.2 Rules of extensibility for operation processing If any DSA performing an operation (after name resolution is completed) detects an extension whose semantic is unknown and indicated as Critical, it shall return an unavailableCriticalExtension (as a serviceError or in PartialOutcomeQualifier). Note Ñ If a criticalExtensions string with one or more zero values is received, this indicates either that the extensions corresponding to the values are not present in the operation or are not critical. The presence of a zero value in a criticalExtensions string shall not be inferred as either the presence or absence of the corresponding extension in the APDU. Otherwise, when processing a Directory PDU a DSA shall: a)ignore all unknown bit name assignments within a bit string; and b)ignore all unknown named numbers in an enumerated type or integer that is being used in the enumerated style; and c)ignore all tag values not defined in the abstract syntaxes contained in the edition of the Directory Specification according to which the DSA was implemented (these may be additional values at the end of a sequence or unknown types within a set or Choice). 7.5.2.3 Rules of extensibility for chaining If the PDU is a request, the DSA shall forward the request containing the unknown types and values to any additional DSAs determined by the name resolution process. If the PDU is a response, the DSA shall process the unknown types and values as it would process known types amd values (see clause on results merging in the Directory Specification on Distributed Operations) and forward to the initiating DSA or DUA. 7.5.2.4 Rules of extensibility for error handling When processing an known error type with unknown indicated problems and parameters, a DSA: a)shall not consider the receipt of unknown indicated problems and parameters as a protocol violation (i.e., it shall not issue a ro-u-reject or abort the application association); and b)may attempt to recover as appropriate to its understanding of just the error type, or may just return the error (and its unknown indicated problems and parameters) to the next appropriate DSA or DUA. When processing an unknown error type, a DSA which is only involved in chaining the request shall: a)not consider the unknown error type as a protocol violation (i.e., it shall not issue a ro-u-reject or abort the application association); and b)not attempt to correct or recover from the error and its indicated problems and parameters; and c)return the unknown error type to the next appropriate DSA or DUA. When processing an unknown error a DSA which is correlating multiple responses shall: a)not consider the unknown error type as a protocol violation (i.e., it shall not issue a ro-u-reject or abort the application association); and b)not attempt to correct or recover from the error and its indicated problems and parameters; and c)put the unknown error in PartialOutcomeQualifier; and d)continue correlating results as usual. 8 Mapping onto Used Services This clause defines the mapping of the DAP, DSP, DOP and DISP onto the used services. Clause 8.1 defines the mapping onto used services of the DAP, DSP and DOP, as well as for the DISP application contexts that omit the RTSE. Clause 8.2 defines the mapping onto used services for the DISP application contexts that use the RTSE. 8.1 Application contexts omitting RTSE This subclause defines the mapping onto used services of the DAP, DSP and DOP application contexts, as well as the DISP application contexts that do not include the RTSE. 8.1.1Mapping onto ACSE This clause defines the mapping of the (DirectoryBind, DSABind, DSAShadowBind or DSADOPBind) and (DirectoryUnbind, DSAUnbind, DSAShadowUnbind or DSADOPUnbind) services onto the services of the ACSE. The ACSE is defined in CCITT Rec. X.217|ISO 8649. 8.1.1.1 Bind onto A-ASSOCIATE The DirectoryBind, DSABind, DSAShadowBind or DSADOPBind 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 subclauses. 8.1.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.1.2 Application Context Name The initiator of the association shall propose one of the following application contexts: a)For the DAP, the directoryAccessAC; b)For the DSP, the directorySystemAC; c)For the DOP, the directoryOperationalBindingManagementAC; d)For the DISP, either the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. 8.1.1.1.3 User Information The mapping of the DirectoryBind or DSABind onto the User Information parameters of the A-ASSOCIATE request primitive is defined in CCITT Rec. X.219|ISO 9072-1. 8.1.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), the DSP abstract syntax (id-as-directorySystemAS), the DOP abstract syntax (id-as- directoryOperationalBindingManagementAS), or the DISP abstract syntax(id-as-directoryShadowAS). 8.1.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.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.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 Continuation Reference. For a DSA establishing an association, this parameter is obtained from its knowledge information, i.e., an external reference. 8.1.1.2 Unbind onto A-RELEASE The DirectoryUnbind, DSAUnbind, DSAShadowUnbind or DSADOPUnbind 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 subclause. 8.1.1.2.1 Result This parameter shall have the value 'affirmative'. 8.1.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.1.2Mapping 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 CCITT Rec. X.219| ISOÊ9072- 1. 8.2 Application contexts including RTSE This subclause defines the mapping onto used services for the DISP application contexts that include the RTSE. Support for this mapping is optional for conformance to this Specification. The RTSE is defined in CCITT Recommendation X.218|ISO/IEC 9066-1. 8.2.1Mapping onto RT-OPEN and RT-CLOSE This subclause defines the mapping of the DSAShadowBind and DSAShadowUnbind services onto the RT-OPEN and RT-CLOSE services of the RTSE. 8.2.1.1 DSAShadowBind onto RT-OPEN The DSAShadowBind sis mapped onto the RT-OPEN service of the RTSE. The use of the parameters of the RT-OPEN service is qualified in the following clauses. 8.2.1.1.1 Mode This parameter shall be supplied by the initiator of the association in the RT-OPEN request primitive, and shall have the value "normal mode". 8.2.1.1.2 Application Context Name The initiator of the association shall propose either the reliableShadowSupplierInitiatedAC application context or the reliableShadowConsumerInitiatedAC application context in the RT- OPEN request primitive. 8.2.1.1.3 User-data The mapping of the bind-operation onto the user-data parameter of the RT-OPEN request primitive is defined in CCITT Recommendation X.219|ISO/IEC 9072-1. 8.2.1.1.4 Presentation Context Definition List The initiator of the association shall supply the Presentation Context Definition List in the RT-OPEN request primitive which shall contain the ACSE abstract-syntax (id-as-acse) and the DISP abstract-syntax that includes the RTSE (id-as- directoryReliableShadowAS). 8.2.1.1.5 Initial turn This parameter shall be supplied by the initiator of the association in the RT-OPEN request primitive, and shall have the value "association-initiator". 8.2.1.1.6 Application Entity Title and Presentation Address These parameters shall be supplied by the initiator and the responder of the association in the RT-OPEN request primitive (Application Entity Title is optionally supplied). 8.2.1.2 DSAShadowUnbind onto RT-CLOSE The DSAShadowUnbind is mapped onto the RT-CLOSE service of the RTSE. 8.2.2Mapping onto ROSE The shadowSupplierASE and the shadowConsumerASE 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 these DISP ASEs onto the ROSE services is as defined in CCITT Recommendation X.219|ISO/IEC 9072-1. ROSE is the user of the RT-TRANSFER, RT-TURN-PLEASE, RT-TURN- GIVE, RT-P-ABORT and RT-U-ABORT services of the RTSE. The use of the RTSE services by the ROSE is defined in CCITT Recommendation X.229|ISO/IEC 9072-2. 8.2.2.1 Managing the turn CCITT Recommendation X.229|ISO/IEC 9072-2 defines the use by the ROSE of the RT-TURN-PLEASE and RT-TURN-GIVE services of the RTSE to manage the turn. The values of the priority parameter of the RT-TURN-PLEASE service used by the ROSE to request the turn are as follows: Ñ Priority zero is the highest priority, and is reserved for the action of releasing the association by the initiator. Ñ Priority one is used by the ROSE to provide the RO-REJECT-U and RO-ERROR services of the ROSE. Ñ Priority two is used by the ROSE to provide the RO-RESULT service of the ROSE. Ñ Priority three is used by the ROSE to provide the RO-INVOKE service of the ROSE. 9 Conformance This clause defines the requirements for conformance to this Directory Specification. 9.1 Conformance by DUAs A DUA implementation claiming conformance to this Specification shall satisfy the requirements specified in 9.1.1 through 9.1.3. 9.1.1Statement 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); c)the extensions listed in the table of clause 7.3.1 of CCITT Recommendation X.511 |ISO/IEC 9594-3, that the DUA is capable of initiating for which conformance is claimed; d)whether conformance is claimed for operational, collective or hierarchical attributes. 9.1.2Static Requirements A DUA shall: a)have the capability of supporting the directoryAccessAC application-context as defined by its abstract syntax in clause 7; b)if conformance is claimed for operational attributes, conform to the extraAttributes extension; c)if conformance is claimed for collective attributes, conform to the subentries extension; d)if conformance is claimed for hierarchical attributes, conform to the extendedFilters extension. 9.1.3Dynamic Requirements A DUA shall: a)conform to the mapping onto used services defined in clause 8; b)shall conform to the rules of extensibility procedures defined in 7.5.1. 9.2 Conformance by DSAs A DSA implementation claiming conformance to this Specification shall satisfy the requirements specified in 9.2.1 through 9.2.3. 9.2.1Statement 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 shall not be claimed to particular operations. b)whether or not the DSA is capable of acting as a first- level DSA, as defined in CCITT Rec. X.518|ISO/IECÊ9594-4; c)if conformance is claimed to the directorySystemAC application-context, whether or not the chained mode of operation is supported, as defined in CCITT Rec. X.518 |ISO/IECÊ9594-4; d)the security-level(s) for which conformance is claimed (none, simple, strong); e)the selected attribute types defined in CCITT Rec. X.520|ISO/IECÊ9594-6, and any other attribute types, for which conformance is claimed; and f)the selected object classes defined in CCITT Rec. X.521|ISO/IECÊ9594-7, and any other object classes, for which conformance is claimed; g)the extensions listed in the table of 7.3.1 of CCITT Recommendation X.511|ISO/IEC 9594-3, that the DSA is capable of responding to for which conformance is claimed; h)whether conformance is claimed for operational, collective or hierarchical attributes; i)whether conformance is claimed for return of alias names as desribed in 7.7.1 of CCITT Recommendation X.511|ISO/IEC 9594-3; j)whether conformance is claimed for indicating that returned entry information is complete, as described in 7.7.6 of CCITT Recommendation X.511|ISO/IEC 9594-3; k)whether conformance is claimed for modifying the auxiliary object class attribute values, as described in 11.3.2 of CCITT Recommendation X.511|ISO/IEC 9594-3; l)whether conformance is claimed to Basic Access Control; m)whether conformance is claimed to Simplified Access Control; n)whether the DSA is capable of administering the subschema for its portion of the DIT, as defined in CCITT Recommendation X.501|ISO/IEC 9594-2; o)the selected name bindings defined in [CCITT Recommendation X.521|ISO/IEC 9594-7 and any other name bindings, for which conformance is claimed; NoteÑThe capability to administer a subschema shall not be divided; specifically, the capability to administer particular subschema definitions shall not be claimed. p)whether the DSA is capable of administering collective attributes, as defined in CCITT Recommendation X.501|ISO/IEC 9594-2. 9.2.2Static 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 clause 7; b)have the capability of supporting the information framework defined by its abstract syntax in CCITT Rec. X.501|ISO/IECÊ9594-2; c)conform to the minimal knowledge requirements defined in CCITT Rec. X.518 |ISO/IECÊ9594-4; d)if conformance is claimed as a first-level DSA, conform to the requirements support of the root context, as defined in CCITT Rec. X.518|ISO/IECÊ9594-4; 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; g)if conformance is claimed for operational attributes, conform to the extraAttributes extension; h)if conformance is claimed for collective attributes, conform to the subentries extension; i)if conformance is claimed for hierarchical attributes, conform to the extendedFilters extension; j)if conformance is claimed to Basic Access Control, have the capability of holding ACI items that conform to the definitions of Basic Access Control; k)if conformance is claimed to Simplified Access Control, have the capability of holding ACI items that conform to the definitions of Simplified Access Control. 9.2.3Dynamic Requirements A DSA shall: a)conform to the mapping onto used services defined in clause 8 of this Specification. b)conform to the procedures for distributed operation of the Directory related to referrals, as defined in CCITT Rec. X.518|ISO/IECÊ9594-4; c)if conformance is claimed to the directoryAccessAC application-context, conform to the procedures of CCITT Rec. X.518|ISO/IECÊ9594-4 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 CCITT Rec. X.518|ISO/IECÊ9594-4; and e)if conformance is claimed to the chained mode of interaction, conform to the chained mode of interaction, as defined in CCITT Rec. X.518|ISO/IECÊ9594-4. Note Ñ Only in this case is it necessary for a DSA to be capable of invoking operations of the directorySystemAC. f)shall conform to the rules of extensibility procedures defined in 7.5.2; g)if conformance is claimed to Basic Access Control, have the capability of protecting information within the DSA in accordance with the procedures of Basic Access Control; h)if conformance is claimed to Simplified Access Control, have the capability of protecting information within the DSA in accordance with the procedures of Simplified Access Control. 9.3 Conformance by a Shadow Supplier A DSA implementation claiming conformance to this Specification in the role of shadow supplier shall satisfy the requirements specified in clauses 9.3.1 through 9.3.3. 9.3.1Statement requirements The following shall be stated: a)the application context(s) for which conformance is claimed as a shadow supplier: directoryOperationalBindingManagementAC, shadowSupplierInitiatedAC, shadowConsumerInitiatedAC, reliableShadowSupplierInitiatedAC and reliableShadowConsumerInitiatedAC. A DSA implementation must, at a minimum, support either the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC. If the DSA supports the shadowSupplierInitiatedAC, it may optionally support the reliableShadowSupplierInitiatedAC. If the DSA supports the shadowConsumerInitiatedAC it may optionally support the reliableShadowConsumerInitiatedAC. Support for the directoryOperationalBindingManagementAC is optional; b)the security-level(s) for which conformance is claimed (none, simple, strong); c)to which degree the UnitOfReplication is supported. Specificially which (if any) of the following optional features are supported: Ñ Entry filtering on ObjectClass; Ñ Selection/Exclusion of attributes via AttributeSelection; Ñ The inclusion of subordinate knowledge in the replicated area; Ñ The inclusion of extended knowledge in addition to subordinate knowledge. 9.3.2Static requirements A DSA shall: a)have the capability of supporting the application- context(s) for which conformance is claimed as defined in their abstract syntax in clause 7; b)support for modifyTimestamp and createTimestamp operational attributes. 9.3.3Dynamic requirements A DSA shall: a)conform to the mapping onto used services defined in clause 8 of this Specification; b)conform to the procedures of CCITT Recommendation X.525|ISO/IEC 9594-9 as they relate to the DISP; c)conform to the procedures of CCITT Recommendation X.525|ISO/IEC 9594-9 and CCITT Recommendation X.501|ISO/IEC 9594-2 as the relate to the DOP. 9.4 Conformance by a Shadow Consumer A DSA implementation claiming conformance to this Specification as a shadow consumer shall satisy the requirments specified in clauses 9.4.1 through 9.4.3. 9.4.1Statement requirements The following shall be stated: a)the application context(s) for which conformance is claimed as a shadow supplier: directoryOperationalBindingManagementAC, shadowSupplierInitiatedAC, shadowConsumerInitiatedAC, reliableShadowSupplierInitiatedAC and reliableShadowConsumerInitiatedAC. A DSA implementation must, at a minimum, support either the shadowSupplierInitiatedAC or the shadowConsumerInitiatedAC;If the DSA supports the shadowSupplierInitiatedAC, it may optionally support the reliableShadowSupplierInitiatedAC. If the DSA supports the shadowConsumerInitiatedAC it may optionally support the reliableShadowConsumerInitiatedAC. Support for the directoryOperationalBindingManagementAC is optional; b)the security-level(s) for which conformance is claimed (none, simple, strong); c)whether the DSA can act as a secondary shadow supplier (i.e. participate in secondary shadowing as an intermediate DSA); d)whether the DSA supports shadowing of overlapping units of replication. 9.4.2Static requirements A DSA shall: a)have the capability of supporting the application- context(s) for which conformance is claimed as defined in their abstract syntax in clause 7; b)provide support for modifyTimestamp and createTimestamp operational attributes if overlapping units of replication is supported. 9.4.3Dynamic requirements A DSA shall: a)conform to the mapping onto used services defined in clause 8 of this Specification; b)conform to the procedures of CCITT Recommendation X.525|ISO/IEC 9594-9 as they relate to the DISP. c)conform to the procedures of CCITT Recommendation X.525|ISO/IEC 9594-9 and CCITT Recommendation X.501|ISO/IEC 9594-2 as they relate to the DOP. Annex A DAP in ASN.1 (This annex forms an integral part of this Recommendation|International Standard) This annex includes all of the ASN.1 type and value definitions contained in this Specification, in the form of the ASN.1 module, "DirectoryAccessProtocol". DirectoryAccessProtocol {joint-iso-ccitt ds(5) modules(1) dap(11)} DEFINITIONS ::= BEGIN -- EXPORTS ALL The types and values defined in this module are exported for use in -- the other ASN.1 modules contained within the Directory Specifications, and for the use of -- other applications which will use them to access Directory services. Other applications may -- use them for their own purposes but this will not constrain extensions and -- modifications needed to maintain or improve the Directory service.-- 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) protocolObjectIdentifier(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 removeEntr RemoveEntr :: 7 y y = modifyEntr ModifyEntr :: 8 y y = modifyRDN ModifyRDN :: 9 = - Remote Errors - - attributeE AttributeE :: 1 rror rror = nameError NameError :: 2 = serviceErr ServiceErr := 3 or or referral Referral :: 4 = abandoned Abandoned :: 5 = securityEr SecurityEr :: 6 ror ror = abandonFai AbandonFai :: 7 led led = updateErro UpdateErro :: 8 r r = END Annex B DSP in ASN.1 (This annex forms an integral part of this Recommendation|International Standard) This Annex includes all of the ASN.1 type and value definitions contained in this Specification, in the form of the ASN.1 module, "DirectorySystemProtocol". DirectorySystemProtocol {joint-iso-ccitt ds(5) modules(1) dsp(12)} DEFINITIONS ::= BEGIN -- EXPORTS ALL The types and values defined in this module are being exported for use in -- the other ASN.1 modules contained within the Directory Specifications, and for the use of -- other applications which will use them to access Directory services. Other applications may -- use them for their own purposes but those uses will not constrain extensions and -- modifications needed to maintain or improve the Directory service.-- 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) protocolObjectIdentifier(4)} Abandoned, AbandonFailed, AttributeError, NameError, 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 = chainedCompa ChainedCompa :: 2 re re = chainedAband ChainedAband :: 3 on on = chainedList ChainedList :: 4 = chainedSearc ChainedSearc :: 5 h h = chainedAddEn ChainedAddEn :: 6 try try = chainedRemov ChainedRemov :: 7 eEntry eEntry = chainedModif ChainedModif :: 8 yEntry yEntry = chainedModif ChainedModif :: 9 yRDN yRDN = - - Remote Errors - - attributeErr AttributeErr :: 1 or or = nameError NameError :: 2 = serviceError ServiceError :: 3 = dsaReferral DSAReferral :: 9 = abandoned Abandoned :: 5 = securityErro SecurityErro :: 6 r r = abandonFaile AbandonFaile :: 7 d d = updateError UpdateError :: 8 = END Annex C DISP in ASN.1 (This annex forms an integral part of this Recommendation|International Standard) This Annex includes all of the relevant ASN.1 type and value definitions contained in this Specification in the form of the ASN.1 module, DirectoryInformationShadowProtocol. DirectoryInformationShadowProtocol {joint-iso-ccitt ds(5) modules(1) DISP(16) version (2) } DEFINITIONS ::= BEGIN -- EXPORTS ALL The types and values defined in this module are being exported for use in -- the other ASN.1 modules contained within the Directory Specifications, and for the use of -- other applications which will use them to access Directory services. Other applications may -- use them for their own purposes but those uses will not constrain extensions and -- modifications needed to maintain or improve the Directory service.-- IMPORTS directoryShadowAbstractService FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0) version (2) } APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE FROM Remote-Operations-Notation-extension {joint-iso-ccitt remoteOperations(4) notation-extension(2) } rTSE FROM { joint-iso-ccitt reliable-transfer (3) apdus (0) } id-ac-shadowConsumerInitiatedAC, id-ac-shadowSupplierInitiatedAC, id-ase-shadowConsumerASE, is-ase-shadowSupplierASE, id-as-directoryShadowAS FROM ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) modules(1) protocolObjectIdentifiers(4) version (2) } DSAShadowBind, DSAShadowUnbind CoordinateShadowUpdate, UpdateShadow, RequestShadowUpdate FROM DirectoryShadowAbstractService directoryShadowAbstractService; -- Application Contexts -- shadowSupplierInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} RESPONDER CONSUMER OF { shadowSupplierASE } ABSTRACT SYNTAXES { id-as-acse, id-as-directoryShadowAS } ::= id-ac-shadowSupplierInitiatedAC shadowConsumerInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} INITIATOR CONSUMER OF { shadowConsumerASE } ABSTRACT SYNTAXES { id-as-acse, id-as-directoryShadowAS } ::= id-ac-shadowConsumerInitiatedAC reliableShadowSupplierInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE, rTSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} RESPONDER CONSUMER OF {shadowSupplierASE} ABSTRACT SYNTAXES { id-as-acse, id-as-directoryReliableShadowAS } ::= id-ac-reliableShadowSupplierInitiatedAC reliableShadowConsumerInitiatedAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE, rTSE} BIND DSAShadowBind UNBIND DSAShadowUnbind REMOTE OPERATIONS {rOSE} INITIATOR CONSUMER OF {shadowConsumerASE} ABSTRACT SYNTAXES { id-as-acse, id-as-directoryReliableShadowAS } ::= id-ac-reliableShadowConsumerInitiatedAC -- ASEs -- shadowConsumerASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES { requestShadowUpdate } SUPPLIER INVOKES { updateShadow } ::= id-ase-shadowConsumerASE requestShadowUpdate RequestShadowUpdate ::= 1 updateShadow UpdateShadow ::= 2 shadowSupplierASE APPLICATION-SERVICE-ELEMENT SUPPLIER INVOKES { coordinateShadowUpdate, updateShadow } ::= id-ase-shadowSupplierASE coordinateShadowUpdate CoordinateShadowUpdate ::= 3 END Annex D DOP in ASN.1 (This annex forms an integral part of this Recommendation|International Standard) This Annex includes all of the relevant ASN.1 type and value definitions contained in this Specification in the form of the ASN.1 module, DirectoryOperationalBindingManagementProtocol. DirectoryOperationalBindingManagementProtocol {joint-iso-ccitt ds(5) modules(1) dop(17) version (2) } DEFINITIONS ::= BEGIN -- EXPORTS ALL The types and values defined in this module are being exported for use in -- the other ASN.1 modules contained within the Directory Specifications, and for the use of -- other applications which will use them to access Directory services. Other applications may -- use them for their own purposes but those uses will not constrain extensions and -- modifications needed to maintain or improve the Directory service.-- IMPORTS directoryOperationalBindingManagementAbstractService FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0) version (2) } APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE FROM Remote-Operations-Notation-extension {joint-iso-ccitt remoteOperations(4) notation-extension(2)} id-ac-directoryOperationalBindingManagementAC, id-ase-operationalBindingManagementASE, id-as-directoryOperationalBindingManagementAS FROM ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) modules(1) protocolObjectIdentifiers(4) version (2) } DSADOPBind, DSADOPUnbind EstablishOperationalBinding, ModifyOperationalBinding, TerminateOperationalBinding FROM DirectoryOperationalBindingManagementAbstractService directoryOperationalBindingManagementAbstractService; -- Application Contexts -- directoryOperationalBindingManagementAC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {aCSE} BIND DSADOPBind UNBIND DSADOPUnbind REMOTE OPERATIONS {rOSE} OPERATIONS OF { operationalBindingManagementASE } ABSTRACT SYNTAXES { id-as-acse, id-as-directoryOperationalBindingManagementAS } ::= id-ac-directoryOperationalBindingManagementAC -- ASEs -- operationalBindingManagementASE APPLICATION-SERVICE-ELEMENT OPERATIONS { establishOperationalBinding, modifyOperationalBinding, terminateOperationalBinding } ::= id-ase-operationalBindingManagementASE establishOperationalBinding EstablishOperationalBinding ::= 100 modifyOperationalBinding ModifyOperationalBinding ::= 102 terminateOperationalBinding TerminateOperationalBinding ::= 101 END Annex E Reference Definition of Protocol Object Identifiers (This annex forms an integral part of this Recommendation|International Standard) This Annex includes all of the ASN.1 Object Identifiers assigned in this Specification, in the form of the ASN.1 module, "ProtocolObjectIdentifiers". ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) modules(1) protocolObjectIdentifiers(4)} DEFINITIONS ::= BEGIN -- EXPORTS ALL The types and values defined in this module are being exported for use in -- the other ANS.1 modules contained within the Directory Specifications, and for the use of -- other applications which will use them to access Directory services. Other applications may -- use them for their own purposes but those uses will not constrain extensions and -- modifications needed to maintain or improve the Directory service.-- IMPORTS id-ac, id-ase, id-as FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0)}; - - Application Contexts - - id-ac-directoryAccessAC OBJECT :: {id-ac IDENTIFIER = 1} id-ac-directorySystemAC OBJECT :: {id-ac IDENTIFIER = 2} id-ac- directoryOperationalBindingM anagementAC OBJECT :: { id-ac 3 IDENTIFIER = } id-ac- OBJECT :: { id-ac 4 shadowConsumerInitiatedAC IDENTIFIER = } id-ac- OBJECT :: { id-ac 5 shadowSupplierInitiatedAC IDENTIFIER = } id-ac- OBJECT :: { id-ac 6 reliableShadowSupplierInitia IDENTIFIER = } tedAC id-ac- OBJECT :: { id-ac 7 reliableShadowConsumerInitia IDENTIFIER = } tedAC - - ASEs - - id-ase-readASE OBJECT :: {id-ase IDENTIFIER = 1} id-ase-searchASE OBJECT :: {id-ase IDENTIFIER = 2} id-ase-modifyASE OBJECT :: {id-ase IDENTIFIER = 3} id-ase-chainedReadASE OBJECT :: {id-ase IDENTIFIER = 4} id-ase-chainedSearchASE OBJECT :: {id-ase IDENTIFIER = 5} id-ase-chainedModifyASE OBJECT :: {id-ase IDENTIFIER = 6} id-ase- operationalBindingManagement ASE OBJECT :: { id-ase IDENTIFIER = 7 } id-ase-shadowConsumerASE OBJECT :: { id-ase IDENTIFIER = 8 } id-ase-shadowSupplierASE OBJECT :: { id-ase IDENTIFIER = 9 } - - ASs - - id-as-directoryAccessAS OBJECT :: {id-as IDENTIFIER = 1} id-as-directorySystemAS OBJECT :: {id-as IDENTIFIER = 2} id-as-acse OBJECT :: IDENTIFIER = {joint-iso-ccitt association-control (2) abstract-syntax (1) apdus (0) version1 (1) } id-as-directoryShadowAS OBJECT :: { id-as 3 IDENTIFIER = } id-as- directoryOperationalBindingM anagementAS OBJECT :: { id-as 4 IDENTIFIER = } id-as- OBJECT { id-as 5 directoryReliableShadowAS IDENTIFIER ::= } END Annex F Directory Operational Binding Types (This annex forms an integral part of this Recommendation|International Standard) DirectoryOperationalBindingTypes {joint-iso-ccitt ds(5) modules (1) operationalBindingTypes (?) version (2) } BEGIN -- EXPORTS ALL The types and values defined in this module are being exported for use in -- the other ASN.1 modules contained within the Directory Specifications, and for the use of -- other applications which will use them to access Directory services. Other applications may -- use them for their own purposes but those uses will not constrain extensions and -- modifications needed to maintain or improve the Directory service.-- IMPORTS operationalBinding FROM UsefulDefinitions { joint-iso-ccitt ds(5) modules (1) usefulDefinitions (0) version (2) }; shadowOperationalBindingID OBJECT IDENTIFIER ::= { operationalBinding 1 } specificHierarchicalBindingID OBJECT IDENTIFIER ::= { operationalBinding 2 } non-speicificHierarchicalBindingID OBJECT IDENTIFIER ::= { operationalBinding 3 } END Annex G Amendments and corrigenda (This annex does not form an integral part of this Recommendation|International Standard) This edition of this Directory Specification includes the following amendments: Ð Amendment 1 for Replication, Schema, and Access Control. This edition of this Directory Specification includes the following technical corrigenda correcting the defects reported in the following defect reports: Ð There were no defect reports against the previous edition of this Directory Specification.