ISO/IEC 9596-1:1998
(Main)Information technology — Open Systems Interconnection — Common management information protocol — Part 1: Specification
Information technology — Open Systems Interconnection — Common management information protocol — Part 1: Specification
This Recommendation | International Standard specifies a protocol which is used by application layer entities to exchange management information. This Recommendation | International Standard specifies: ? procedures for the transmission of management information between application entities; ? the abstract syntax of the Common Management Information Protocol (CMIP) and the associated encoding rules to be applied; ? procedures for the correct interpretation of protocol control information; ? the conformance requirements to be met by implementation of this Recommendation | International Standard. This Recommendation | International Standard does not specify: ? the structure or meaning of the management information that is transmitted by means of CMIP; ? the manner in which management is accomplished as a result of CMIP exchanges; ? the interactions which result in the use of CMIP.
Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Protocole commun d'information de gestion — Partie 1: Spécification
La presente Recommandation ( Norme intemationale specific un Application pour transferer des informations de gestion. protocole qui est utilise par des entites de la couche. Application pour transférer des informations de gestion. La presente Recommendation 1 Norme intemationale specifie -les procédures de transmission des informations de gestion entre entités d'application ; - la syntaxe information abstraite protocol) du protocole commun d'information et les règles de codage associees a appl de gestion (CMIP, common management iquer; - les procédures d'interprétation des informations de controle de protocole; - les conditions de conformité ;à remplir par des mises en ceuvre de la presente Recommandation 1 Norme intemationale. La présente Recommandation / Norme intemationale ne spécifie pas - la structure ou la signification des informations de gestion qui sont transmises au moyen du protocole CMIP; - la facon dont la gestion est exercee, comme resultat de transferts par protocole CMIP; - les interactions qui resultent de l'utilisation du protocole CMIP.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 9596-1
Third edition
1998-10-15
Information technology — Open Systems
Interconnection — Common management
information protocol —
Part 1:
Specification
Technologies de l'information — Interconnexion de systèmes ouverts
(OSI) — Protocole commun d'information de gestion —
Partie 1: Spécification
Reference number
B C
ISO/IEC 9596-1 : 1998 (E)
Contents Page
1 Scope . 1
2 Normative references. 1
2.1 Identical Recommendations | International Standards . 1
2.2 Paired Recommendations | International Standards equivalent in technical content . 2
3 Definitions . 2
3.1 Basic Reference Model definitions. 2
3.2 Management Framework definitions . 2
3.3 Remote Operations definitions . 2
3.4 CMIS definitions . 3
3.5 ACSE definitions. 3
3.6 Presentation definitions . 3
4 Symbols and abbreviations . 3
5 Overview. 4
5.1 Service provided. 4
5.2 Underlying services . 4
5.3 Management information definitions. 5
5.4 Protocol version. 5
6 Elements of procedure . 5
6.1 Association establishment . 5
6.2 Remote operations. 5
6.3 Event reporting procedure . 6
6.4 Get procedure . 6
6.5 Set procedure. 8
6.6 Action procedure . 8
6.7 Create procedure . 9
6.8 Delete procedure . 10
6.9 Association orderly release. 10
6.10 Association abrupt release. 10
7 Abstract syntax . 11
7.1 Conventions. 11
7.2 Correspondence between CMISE primitives and CMIP operations. 11
7.3 ACSE user data . 12
7.4 CMIP data units. 13
7.5 Definition of abstract syntax for CMIP . 20
8 Conformance. 21
8.1 Static requirements . 21
8.2 Dynamic requirements. 22
© ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
utilized in any form or by any means, electronic or mechanical, including photocopying and micro-
film, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
©
ISO/IEC ISO/IEC 9596-1 : 1998 (E)
Annex A – Association rules for CMISE. 23
A.1 ACSE, session and presentation requirements. 23
A.2 Association initialization rules . 23
A.3 Association release rules . 24
A.4 Association abort rules . 24
Annex B – Expanded ASN.1 syntax . 26
Annex C – Examples of CMISE ROSE APDUs. 34
Annex D – Directory abstract syntax . 35
iii
©
ISO/IEC 9596-1 : 1998 (E) ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 9596-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 33, Distributed application services, in collaboration with ITU-T. The identical text is
published as ITU-T Recommendation X.711.
This third edition cancels and replaces the second edition (ISO/IEC 9596-1:1991), which has been technically revised. It
also incorporates Technical Corrigendum 1:1992, Technical Corrigendum 2:1992, Technical Corrigendum 3:1992,
Technical Corrigendum 4:1993 and Technical Corrigendum 5:1994.
ISO/IEC 9596 consists of the following parts, under the general title Information technology — Open Systems
Interconnection — Common management information protocol :
— Part 1: Specification
— Part 2: Protocol Implementation Conformance Statement (PICS) proforma
Annexes A to D of this part of ISO/IEC 9596 are for information only.
iv
ISO/IEC 9596-1 : 1998 (E)
INTERNATIONAL STANDARD
ISO/IEC 9596-1 : 1998 (E)
ITU-T Rec. X.711 (1997 E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – OPEN SYSTEMS INTERCONNECTION –
COMMON MANAGEMENT INFORMATION PROTOCOL: SPECIFICATION
1 Scope
This Recommendation | International Standard specifies a protocol which is used by application layer entities to exchange
management information.
This Recommendation | International Standard specifies:
– procedures for the transmission of management information between application entities;
– the abstract syntax of the Common Management Information Protocol (CMIP) and the associated
encoding rules to be applied;
– procedures for the correct interpretation of protocol control information;
– the conformance requirements to be met by implementation of this Recommendation | International
Standard.
This Recommendation | International Standard does not specify:
– the structure or meaning of the management information that is transmitted by means of CMIP;
– the manner in which management is accomplished as a result of CMIP exchanges;
– the interactions which result in the use of CMIP.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition
of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently valid
International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid
ITU-T Recommendations.
2.1 Identical Recommendations | International Standards
– ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1:1994, Information technology – Open Systems
Interconnection – Basic Reference Model: The Basic Model.
– ITU-T Recommendation X.215 (1995) | ISO/IEC 8326:1996, Information technology – Open Systems
Interconnection – Session service definition.
– ITU-T Recommendation X.216 (1994) | ISO/IEC 8822:1994, Information technology – Open Systems
Interconnection – Presentation service definition.
– ITU-T Recommendation X.217 (1995) | ISO/IEC 8649:1996, Information technology – Open Systems
Interconnection – Service definition for the Association Control Service Element.
– ITU-T Recommendation X.226 (1994) | ISO/IEC 8823-1:1994, Information technology – Open Systems
Interconnection – Connection-oriented presentation protocol: Protocol specification.
– ITU-T Recommendation X.227 (1995) | ISO/IEC 8650-1:1996, Information technology – Open Systems
Interconnection – Connection-oriented protocol for the Association Control Service Element: Protocol
specification.
ITU-T Rec. X.711 (1997 E) 1
ISO/IEC 9596-1 : 1998 (E)
– ITU-T Recommendation X.710 (1997) | ISO/IEC 9595:1998, Information technology – Open Systems
Interconnection – Common management information service.
– CCITT Recommendation X.712 (1992) | ISO/IEC 9596-2:1993, Information technology – Open Systems
Interconnection – Common management information protocol: Protocol Implementation Conformance
Statement (PICS) proforma.
2.2 Paired Recommendations | International Standards equivalent in technical content
– CCITT Recommendation X.208 (1988), Specification of Abstract Syntax Notation One (ASN.1).
ISO/IEC 8824:1990, Information technology – Open Systems Interconnection – Specification of Abstract
Syntax Notation One (ASN.1).
– CCITT Recommendation X.209 (1988), Specification of basic encoding rules for Abstract Syntax
Notation One (ASN.1).
ISO/IEC 8825:1990, Information technology – Open Systems Interconnection – Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
– CCITT Recommendation X.219 (1988), Remote operations: Model, notation and service definition.
ISO/IEC 9072-1:1989, Information processing systems – Text communication – Remote Operations –
Part 1: Model, notation and service definition.
– CCITT Recommendation X.229 (1988), Remote operations: Protocol specification.
ISO/IEC 9072-2:1989, Information processing systems – Text communication – Remote Operations –
Part 2: Protocol specification.
– CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSI)
for CCITT applications.
ISO/IEC 7498-4:1989, Information processing systems – Open Systems Interconnection – Basic
Reference Model – Part 4: Management framework.
3 Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply.
3.1 Basic Reference Model definitions
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.200 |
ISO/IEC 7498-1:
a) application-service-element;
b) application-process;
c) real open system;
d) systems-management.
3.2 Management Framework definitions
This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.700 |
ISO/IEC 7498-4:
a) managed object;
b) management information;
c) management information base;
d) systems management application-entity.
3.3 Remote Operations definitions
This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.219 |
ISO/IEC 9072-1:
a) association-initiator;
b) association-responder;
2 ITU-T Rec. X.711 (1997 E)
ISO/IEC 9596-1 : 1998 (E)
c) linked-operations;
d) Remote Operations;
e) Remote Operation Service Element;
f) invoker;
g) performer;
h) Association Class;
i) Operation Class.
3.4 CMIS definitions
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.710 |
ISO/IEC 9595:
a) attribute;
b) common management information service element;
c) common management information services;
d) CMISE-service-provider;
e) CMISE-service-user;
f) invoking CMISE-service-user;
g) performing CMISE-service-user.
3.5 ACSE definitions
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.217 |
ISO/IEC 8649:
a) application context;
b) application-association;
c) association.
3.6 Presentation definitions
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.216 |
ISO/IEC 8822:
a) abstract syntax;
b) transfer syntax.
4 Symbols and abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
ACSE Association Control Service Element
APDU Application Protocol Data Unit
ASE Application Service Element
ASN.1 Abstract Syntax Notation One
CMIP Common Management Information Protocol
CMIPM Common Management Information Protocol Machine
CMIS Common Management Information Services
CMISE Common Management Information Service Element
DCS Defined Context Set
PCI Protocol Control Information
PDU Protocol Data Unit
ITU-T Rec. X.711 (1997 E) 3
ISO/IEC 9596-1 : 1998 (E)
PICS Protocol Implementation Conformance Statement
RO Remote Operations
ROSE Remote Operations Service Element
SMAE Systems Management Application-Entity
5 Overview
The Common Management Information Protocol (CMIP) specifies protocol elements that may be used to provide the
operation and notification services described in ITU-T Rec. X.710 | ISO/IEC 9595, which defines the Common
Management Information Services (CMIS).
5.1 Service provided
The protocol specified in this Recommendation | International Standard supports the services defined in
ITU-T Rec. X.710 | ISO/IEC 9595. These services are summarized in Table 1.
Table 1 – Common management information services
Service Type
M-CANCEL-GET confirmed
M-EVENT-REPORT confirmed/non-confirmed
M-GET confirmed
M-SET confirmed/non-confirmed
M-ACTION confirmed/non-confirmed
M-CREATE confirmed
M-DELETE confirmed
5.2 Underlying services
This Recommendation | International Standard uses the RO-INVOKE, RO-RESULT, RO-ERROR and RO-REJECT-U
services of the Remote Operations Service Element (ROSE) defined in CCITT Rec. X.219 | ISO/IEC 9072-1. ROSE
assumes the use of the presentation service defined in ITU-T Rec. X.216 | ISO/IEC 8822. The confirmed operations of
CMIP are operation class 2 (asynchronous) or operation class 1 (synchronous) as required by the application. The choice
of operation class is a local matter. The unconfirmed operations of CMIP are operation class 5 (asynchronous, outcome
not reported). CMIP uses association class 3.
If the extended service functional unit is successfully negotiated, ROSE APDUs may be mapped on to presentation
services other than the P-DATA service.
NOTE – For example, it may be necessary to modify the presentation Defined Context Set (DCS) when the CMIP operation is
sent to the peer CMISE-service-user. In this case, the ROSE APDU which carries the CMIP operation will be mapped onto the
P-ALTER-CONTEXT service which is also used to perform the changes to the DCS.
Details of which other presentation services are required and how they are used, are described in the description of the
application context in use on the association.
5.2.1 Service assumed from the ACSE
This Recommendation | International Standard assumes the use of the A-ASSOCIATE, A-RELEASE, A-ABORT, and
A-P-ABORT services of the Association Control Service Element.
5.2.2 Service assumed from the presentation layer
CCITT Rec. X.229 | ISO/IEC 9072-2 assumes the use of the P-DATA service of the presentation layer for the transfer of
the RO-INVOKE, RO-RESULT, RO-ERROR and RO-REJECT APDUs.
4 ITU-T Rec. X.711 (1997 E)
ISO/IEC 9596-1 : 1998 (E)
5.3 Management information definitions
This Recommendation | International Standard defines the abstract syntax of the Common Management Information
Protocol. The definitions of management information to be carried by the protocol are not specified in this
Recommendation | International Standard.
5.4 Protocol version
This Recommendation International Standard defines version 2 of CMIP. Version 2 replaces version 1. This
Recommendation | International Standard does not define any interworking between version 2 and version 1.
6 Elements of procedure
This clause provides definition for the procedural elements of the CMIP. The procedures define the transfer of CMIP
PDUs whose structure, coding and relationship with the CMIS service primitives is specified in clause 7.
The Common Management Information Protocol Machine (CMIPM) accepts CMIS request and response service
primitives, and issues CMIP PDUs initiating specific elements of procedure as specified in this clause.
A CMIPM shall accept any well-formed CMIP PDU, and pass it to the performing CMISE-service-user for processing,
by means of CMIS indication and confirmation service primitives. If the received PDU is not well formed or does not
contain a supported notification or operation, a PDU is returned indicating that the received PDU has been rejected.
The procedures indicate only how to interpret the various fields in the CMIP PDU, not what an invoking CMISE-service-
user should do with the information it requests nor how a performing CMISE-service-user should process the invocation.
6.1 Association establishment
The establishment of an association involves two CMISE-service-users, one that is the association-initiator and one that is
the association-responder.
A CMISE-service-user may initiate an association establishment by using the A-ASSOCIATE service of
ITU-T Rec. X.217 | ISO/IEC 8649.
The application context specifies, among other things, the rules required for the coordination of initialization information
corresponding to different ASEs. The association rules for CMISE are specified in Annex A.
6.2 Remote operations
6.2.1 RO elements of procedure
The CMIP elements of procedure rely on the following underlying remote operations elements of procedure:
a) invocation;
b) return-result;
c) return-error;
d) user-reject;
e) provider-reject.
These elements of procedure are described fully in CCITT Rec. X.229 | ISO/IEC 9072-2.
Table 2 specifies the correspondence between CMIS and ROSE parameters.
Table 2 – Correspondence between CMIS
and ROSE parameters
CMIS parameter ROSE parameter
Invoke identifier InvokeID
Linked identifier Linked-ID
The correspondence between other CMIS and ROSE parameters is specified in clause 7.
ITU-T Rec. X.711 (1997 E) 5
ISO/IEC 9596-1 : 1998 (E)
6.2.2 RO-Reject problem parameters
The RO-Reject problem parameters are mapped or processed as follows.
6.2.2.1 RO-Reject-User.Invoke-problem mapping to CMIS error codes is specified in Table 3.
Table 3 – Mapping RO-Reject-User.Invoke-problem
to CMISE error codes
RO-REJECT parameter CMISE error code
duplicate-invocation duplicate invocation
mistyped-argument mistyped argument
resource-limitation resource limitation
unrecognized-operation unrecognized operation
Other Invoke-problem parameters are a local matter.
6.2.2.2 Other RO-Reject parameters will be handled as a local matter.
6.3 Event reporting procedure
6.3.1 Invocation
The event reporting procedures are initiated by the M-EVENT-REPORT request primitive.
On receipt of the M-EVENT-REPORT request primitive, the CMIPM shall:
a) in the confirmed mode, construct an APDU requesting the m-EventReport-Confirmed operation,
otherwise, construct an APDU requesting the m-EventReport operation;
b) send the APDU using the RO-INVOKE procedure.
6.3.2 Receipt
On receipt of an APDU requesting either the m-EventReport or m-EventReport-Confirmed operation, the CMIPM shall,
if the APDU is well formed, issue an M-EVENT-REPORT indication primitive to the CMISE-service-user with the mode
parameter indicating whether or not confirmation is requested, otherwise, construct an APDU containing notification of
the error and send it using the RO-REJECT-U procedure.
6.3.3 Response
In the confirmed mode, the CMIPM shall accept an M-EVENT-REPORT response primitive and shall:
a) construct an APDU confirming the M-EVENT-REPORT notification;
b) if the parameters in the M-EVENT-REPORT response primitive indicate that the notification was
accepted, send the APDU using the RO-RESULT procedure, otherwise, send the APDU using the
RO-ERROR procedure.
6.3.4 Receipt of response
On receipt of an APDU responding to an M-EVENT-REPORT notification, the CMIPM shall, if the APDU is well
formed, issue an M-EVENT-REPORT confirmation primitive to the CMISE-service-user, thus completing the
notification procedure, otherwise, construct an APDU containing notification of the error and send it using the
RO-REJECT-U procedure.
6.4 Get procedure
6.4.1 Invocation
The Get procedures are initiated by the M-GET request primitive.
On receipt of the M-GET request primitive, the CMIPM shall:
a) construct an APDU requesting the m-Get operation;
b) send the APDU using the RO-INVOKE procedure.
6 ITU-T Rec. X.711 (1997 E)
ISO/IEC 9596-1 : 1998 (E)
6.4.2 Receipt
On receipt of an APDU requesting the m-Get operation, the CMIPM shall, if the APDU is well formed, issue an M-GET
indication primitive to the CMISE-service-user, otherwise, construct an APDU containing notification of the error and
send it using the RO-REJECT-U procedure.
6.4.3 Response
The CMIPM shall:
a) accept zero or more M-GET response primitives containing a linked-ID followed by a single M-GET
response primitive without a linked-ID;
b) for each M-GET response primitive containing a linked-ID:
– construct an APDU requesting the m-Linked-Reply operation with LinkedReplyArgument set
appropriately as either getListError, getResult or processingFailure;
– send each APDU using the RO-INVOKE procedure;
c) for the M-GET response primitive not containing a linked-ID:
– construct an APDU confirming the m-Get operation;
– if the parameters in the M-GET response primitive indicate that the operation was performed
correctly, send the APDU using the RO-RESULT procedure. If the parameters in the M-GET
response primitive indicate that the operation was performed with partial success or was not
performed because of an error, the CMIPM shall send the APDU using the RO-ERROR procedure.
6.4.4 Receipt of response
On receipt of an APDU responding to an m-Get operation, the CMIPM shall:
a) if the APDU included a linked-ID and is well formed, issue an M-GET confirmation primitive to the
CMISE-service-user;
b) if the APDU is the last response (i.e. not containing a linked-ID) and is well formed, issue an M-GET
confirmation primitive to the CMISE-service-user, thus completing the M-GET procedure;
c) if the APDU is not well formed, construct an APDU containing notification of the error and send it using
the RO-REJECT-U procedure.
6.4.5 CancelGet procedure
6.4.5.1 Invocation
The CancelGet procedures are initiated by the M-CANCEL-GET request primitive.
On receipt of the M-CANCEL-GET request primitive, the CMIPM shall:
a) construct an APDU requesting the m-CancelGet operation;
b) send the APDU using the RO-INVOKE procedure.
6.4.5.2 Receipt
On receipt of an APDU requesting the m-CancelGet operation, the CMIPM shall, if the APDU is well formed, issue an
M-CANCEL-GET indication primitive to the CMISE-service-user, otherwise, construct an APDU containing notification
of the error and send it using the RO-REJECT-U procedure.
6.4.5.3 Response
The CMIPM shall:
a) construct an APDU confirming the m-CancelGet operation;
b) if the parameters in the M-CANCEL-GET response primitive indicate that the operation was performed
correctly, send the APDU using the RO-RESULT procedure otherwise, send the APDU using the
RO-ERROR procedure. If the m-CancelGet operation is successful, the performing CMISE-service-user
shall cease from sending linked replies to the m-Get operation and shall issue an M-GET response
primitive which shall contain the “operation cancelled” error.
ITU-T Rec. X.711 (1997 E) 7
ISO/IEC 9596-1 : 1998 (E)
6.4.5.4 Receipt of response
On receipt of an APDU responding to an m-CancelGet operation, the CMIPM shall, if the APDU is well formed, issue an
M-CANCEL-GET confirmation primitive to the CMISE-service-user, otherwise, construct an APDU containing
notification of the error and send it using the RO-REJECT-U procedure.
6.5 Set procedure
6.5.1 Invocation
The Set procedures are initiated by the M-SET request primitive.
On receipt of the M-SET request primitive, the CMIPM shall:
a) in the confirmed mode, construct an APDU requesting the m-Set-Confirmed operation, otherwise,
construct an APDU requesting the m-Set operation;
b) send the APDU using the RO-INVOKE procedure.
6.5.2 Receipt
On receipt of an APDU requesting the m-Set or m-Set-Confirmed operation, the CMIPM shall, if the APDU is well
formed, issue an M-SET indication primitive to the CMISE-service-user, with the mode parameter indicating whether or
not confirmation is requested, otherwise, construct an APDU containing notification of the error and send it using the
RO-REJECT-U procedure.
6.5.3 Response
In the confirmed mode, the CMIPM shall:
a) accept zero or more M-SET response primitives containing a linked-ID followed by a single M-SET
response primitive without a linked-ID;
b) for each M-SET response primitive containing a linked-ID:
– construct an APDU requesting the m-Linked-Reply operation with LinkedReplyArgument set
appropriately as either setListError, setResult or processingFailure;
– send each APDU using the RO-INVOKE procedure;
c) for the M-SET response primitive not containing a linked-ID:
– construct an APDU confirming the m-Set operation;
– if the parameters in the M-SET response primitive indicate that the operation was performed
correctly, send the APDU using the RO-RESULT procedure. If the parameters in the M-SET
response primitive indicate that the operation was performed with partial success or was not
performed because of an error, the CMIPM shall send the APDU using the RO-ERROR procedure.
6.5.4 Receipt of response
On receipt of an APDU responding to an m-Set-Confirmed operation, the CMIPM shall:
a) if the APDU included a linked-ID and is well formed, issue an M-SET confirmation primitive to the
CMISE-service-user;
b) if the APDU is the last response (i.e. not containing a linked-ID) and is well formed, issue an M-SET
confirmation primitive to the CMISE-service-user, thus completing the M-SET procedure;
c) if the APDU is not well formed, construct an APDU containing notification of the error and send it using
the RO-REJECT-U procedure.
6.6 Action procedure
6.6.1 Invocation
The Action procedures are initiated by the M-ACTION request primitive.
On receipt of the M-ACTION request primitive, the CMIPM shall:
a) in the confirmed mode, construct an APDU requesting the m-Action-Confirmed operation otherwise,
construct an APDU requesting the m-Action operation;
b) send the APDU using the RO-INVOKE procedure.
8 ITU-T Rec. X.711 (1997 E)
ISO/IEC 9596-1 : 1998 (E)
6.6.2 Receipt
On receipt of an APDU requesting the m-Action or m-Action-Confirmed operation, the CMIPM shall, if the APDU is
well formed, issue an M-ACTION indication primitive to the CMISE-service-user, with the mode parameter indicating
whether or not confirmation is requested, otherwise, construct an APDU containing notification of the error and send it
using the RO-REJECT-U procedure.
6.6.3 Response
In the confirmed mode, the CMIPM shall:
a) accept zero or more M-ACTION response primitives containing a linked-ID followed by a single
M-ACTION response primitive without a linked-ID;
b) for each M-ACTION response primitive containing a linked-ID:
– construct an APDU requesting the m-Linked-Reply operation with LinkedReplyArgument set
appropriately as either actionError, actionResult or processingFailure;
– send each APDU using the RO-INVOKE procedure;
c) for the M-ACTION response primitive not containing a linked-ID:
– construct an APDU confirming the m-Action operation;
– if the parameters in the M-ACTION response primitive indicate that the operation was performed
correctly, send the APDU using the RO-RESULT procedure, otherwise, send the APDU using the
RO-ERROR procedure.
6.6.4 Receipt of response
On receipt of an APDU responding to an m-Action-Confirmed operation, the CMIPM shall:
a) if the APDU included a linked-ID and is well formed, issue an M-ACTION confirmation primitive to the
CMISE-service-user;
b) if the APDU is the last response (i.e. not containing a linked-ID) and is well formed, issue an M-ACTION
confirmation primitive to the CMISE-service-user, thus completing the M-ACTION procedure;
c) if the APDU is not well formed, construct an APDU containing notification of the error and send it using
the RO-REJECT-U procedure.
6.7 Create procedure
6.7.1 Invocation
The Create procedures are initiated by the M-CREATE request primitive.
On receipt of the M-CREATE request primitive, the CMIPM shall:
a) construct an APDU requesting the m-Create operation;
b) send the APDU using the RO-INVOKE procedure.
6.7.2 Receipt
On receipt of an APDU requesting the m-Create operation, the CMIPM shall, if the APDU is well formed, issue an
M-CREATE indication primitive to the CMISE-service-user, otherwise, construct an APDU containing notification of the
error and send it using the RO-REJECT-U procedure.
6.7.3 Response
The CMIPM shall accept an M-CREATE response primitive and shall:
a) construct an APDU confirming the m-Create operation;
b) if the parameters in the M-CREATE response primitive indicate that the operation was performed
correctly, send the APDU using the RO-RESULT procedure, otherwise, send the APDU using the
RO-ERROR procedure.
6.7.4 Receipt of response
On receipt of an APDU responding to an m-Create operation, the CMIPM shall, if the APDU is well formed, issue an
M-CREATE confirmation primitive to the CMISE-service-user, thus completing the M-CREATE procedure, otherwise,
construct an APDU containing notification of the error and send it using the RO-REJECT-U procedure.
ITU-T Rec. X.711 (1997 E) 9
ISO/IEC 9596-1 : 1998 (E)
6.8 Delete procedure
6.8.1 Invocation
The Delete procedures are initiated by the M-DELETE request primitive.
On receipt of the M-DELETE request primitive, the CMIPM shall:
a) construct an APDU requesting the m-Delete operation;
b) send the APDU using the RO-INVOKE procedure.
6.8.2 Receipt
On receipt of an APDU requesting the m-Delete operation, the CMIPM shall, if the APDU is well formed, issue an
M-DELETE indication primitive to the CMISE-service-user, otherwise, construct an APDU containing notification of the
error and send it using the RO-REJECT-U procedure.
6.8.3 Response
The CMIPM shall:
a) accept zero or more M-DELETE response primitives containing a linked-ID followed by a single
M-DELETE response primitive without a linked-ID;
b) for each M-DELETE response primitive containing a linked-ID:
– construct an APDU requesting the m-Linked-Reply operation with LinkedReplyArgument set
appropriately as either deleteError, deleteResult or processingFailure;
– send each APDU using the RO-INVOKE procedure;
c) for the M-DELETE response primitive not containing a linked-ID:
– construct an APDU confirming the m-Delete operation;
– if the parameters in the M-DELETE response primitive indicate that the operation was performed
correctly, send the APDU using the RO-RESULT procedure, otherwise, send the APDU using the
RO-ERROR procedure.
6.8.4 Receipt of response
On receipt of an APDU responding to an m-Delete operation, the CMIPM shall:
a) if the APDU included a linked-ID and is well formed, issue an M-DELETE confirmation primitive to the
CMISE-service-user;
b) if the APDU is the last response (i.e. not containing a linked-ID) and is well formed, issue an M-DELETE
confirmation primitive to the CMIS-service-user, thus completing the M-DELETE procedure;
c) if the APDU is not well formed, construct an APDU containing notification of the error and send it using
the RO-REJECT-U procedure.
6.9 Association orderly release
Either CMISE-service-user may initiate an orderly release of the association by using the A-RELEASE service of
ITU-T Rec. X.217 | ISO/IEC 8649.
NOTE – This specification is different from the ROSE use of the BIND operation in which only the association-initiator may use
the A-RELEASE procedure.
6.10 Association abrupt release
Either CMISE-service-user may initiate an abrupt release of the association using the A-ABORT service of
ITU-T Rec. X.217 | ISO/IEC 8649.
The CMISE-service-user may receive an indication of the abrupt release of the association via the A-ABORT or
A-P-ABORT services of ITU-T Rec. X.217 | ISO/IEC 8649.
10 ITU-T Rec. X.711 (1997 E)
ISO/IEC 9596-1 : 1998 (E)
1)
7 Abstract syntax
This clause specifies the abstract syntax for the CMIP PDUs.
7.1 Conventions
The abstract syntax is defined using the notation specified in CCITT Rec. X.208 | ISO/IEC 8824. The ASN.1 MACRO
productions used or referenced by this Recommendation | International Standard do not exercise the ambiguous aspects
of the grammar.
For each of the CMISE service parameters which is to be transferred by a CMIP PDU, there is a PDU field (an ASN.1
NamedType) with the same name as the corresponding service parameter (see ITU-T Rec. X.710 | ISO/IEC 9595), except
for the differences required by the use of ASN.1, which are that blanks between words are removed and the first letter of
the following word is capitalized, e.g. “managed object class” becomes “managedObjectClass”. To make some of the
names shorter, some words are abbreviated as follows:
ack acknowledgement
arg argument
id identifier
info information
sync synchronization
7.2 Correspondence between CMISE primitives and CMIP operations
Table 4 – Correspondence between CMISE primitives and CMIP operations
CMIS primitive Mode Linked-ID CMIP operation
M-CANCEL-GET req/ind Confirmed Not applicable m-Cancel-Get-Confirmed
M-CANCEL-GET rsp/conf Not applicable Not applicable m-Cancel-Get-Confirmed
M-EVENT-REPORT req/ind Non-confirmed Not applicable m-EventReport
M-EVENT-REPORT req/ind Confirmed Not applicable m-EventReport-Confirmed
M-EVENT-REPORT rsp/conf Not applicable Not applicable m-EventReport-Confirmed
M-GET req/ind Confirmed Not applicable m-Get
M-GET rsp/conf Not applicable Absent m-Get
M-GET rsp/conf Not applicable Present m-Linked-Reply
M-SET req/ind Non-confirmed Not applicable m-Set
M-SET req/ind Confirmed Not applicable m-Set-Confirmed
M-SET rsp/conf Not applicable Absent m-Set-Confirmed
M-SET rsp/conf Not applicable Present m-Linked-Reply
M-ACTION req/ind Non-confirmed Not applicable m-Action
M-ACTION req/ind Confirmed Not applicable m-Action-confirmed
M-ACTION rsp/conf Not applicable Absent m-Action-confirmed
M-ACTION rsp/conf Not applicable Present m-Linked-Reply
M-CREATE req/ind Confirmed Not applicable m-Create
M-CREATE rsp/conf Not applicable Not applicable m-Create
M-DELETE req/ind Confirmed Not applicable m-Delete
M-DELETE rsp/conf Not applicable Absent m-Delete
M-DELETE rsp/conf Not applicable Present m-Linked-Reply
NOTE – The mapping from the OPERATION and ERROR macros to ROSE is defined in CCITT Rec. X.219 | ISO/IEC 9072-1.
_______________
1)
Users of this Recommendation | International Standard may freely reproduce the abstract syntax definitions in the clause so that
they may be used for their intended purpose.
ITU-T Rec. X.711 (1997 E) 11
ISO/IEC 9596-1 : 1998 (E)
7.3 ACSE user data
The ACSE protocol (see ITU-T Rec. X.227 | ISO/IEC 8650-1) is described using ASN.1. The “user information” is
defined using the EXTERNAL data type.
7.3.1 A-ASSOCIATE user data
The encoding of the CMIP user information to be passed to A-ASSOCIATE in the “user information” parameter is
defined as follows:
CMIP-A-ASSOCIATE-Information {joint-iso-itu-t ms(9) cmip(1) modules(0) aAssociateUserInfo(1)}
DEFINITIONS ::= BEGIN
FunctionalUnits ::= BIT STRING {
multipleObjectSelection (0),
filter (1),
multipleReply (2),
extendedService (3),
cancelGet (4)
}
-- Functional unit i is supported if and only if bit i is one
-- Information carried in user-information parameter of A-ASSOCIATE
CMIPUserInfo ::= SEQUENCE {
protocolVersion [0] IMPLICIT ProtocolVersion DEFAULT { version1 },
functionalUnits [1] IMPLICIT FunctionalUnits DEFAULT {},
accessControl [2] EXTERNAL OPTIONAL,
userInfo [3] EXTERNAL OPTIONAL
}
ProtocolVersion ::= BIT STRING {
version1 (0),
version2 (1)
}
END
The encoding of other “user information” supplied by the CMISE-service user is not defined by this Recommendation |
International Standard.
7.3.2 A-ABORT user data
The encoding of the CMIP user information to be passed to A-ABORT in the “user information” parameter is defined as
follows:
CMIP-A-ABORT-Information {joint-iso-itu-t ms(9) cmip(1) modules(0) aAbortUserInfo(2)}
DEFINITIONS ::= BEGIN
-- Information carried in user-information parameter of A-ABORT
CMIPAbortInfo ::= SEQUENCE {
abortSource [0] IMPLICIT CMIPAbortSource,
userInfo [1] EXTERNAL OPTIONAL
}
CMIPAbortSource ::= ENUMERATED {
cmiseServiceUser (0),
cmiseServiceProvider (1)
}
END
The encoding of other “user information” supplied by the CMISE-service user is not defined by this Recommendation |
International Standard.
12 ITU-T Rec. X.711 (1997 E)
ISO/IEC 9596-1 : 1998 (E)
7.4 CMIP data units
The protocol is described in terms of Common Management Information Protocol Data Units exchanged between the
peer CMISEs. The PDUs are specified using ASN.1 and the Remote Operations Protocol OPERATION and ERROR
external macros defined in CCITT Rec. X.219 | ISO/IEC 9072-1.
-- Common Management Information Protocol (CMIP)
CMIP-1 {joint-iso-itu-t ms(9) cmip(1) modules(0) protocol(3)}
DEFINITIONS ::= BEGIN
-- Remote Operations definitions
IMPORTS OPERATION, ERROR FROM Remote-Operation-Notation {joint-iso-ccitt remote-operations(4) notation(0)}
-- Remote Operations Service definitions
InvokeIDType FROM Remote-Operations-APDUs {joint-iso-ccitt remote-operations(4) apdus(1)}
-- Directory Service definitions
-- This Recommendation | International Standard imports abstract syntax from CCITT Rec. X.501 (1988) |
-- ISO/IEC 9594-2:1990. Annex D to this Recommendation | International Standard provides an extract
-- from CCITT Rec. X.501 (1988) | ISO/IEC 9594-2:1990, sufficient to meet the needs of CMIP.
DistinguishedName, RDNSequence
FROM InformationFramework {joint-iso-ccitt ds(5) modules(1) informationFramework(1)};
-- CMISE operations
-- in the following operations, the argument type is mandatory in the corresponding ROSE APDU
-- Action operations (M-ACTION)
m-Action OPERATION
ARGUMENT ActionArgument
::= localValue : 6
m-Action-Confirmed OPERATION
ARGUMENT ActionArgument
RESULT ActionResult -- this result is conditional; for conditions see 8.3.3.2.9 of ITU-T Rec. X.710 |
-- ISO/IEC 9595
ERRORS { accessDenied, classInstanceConflict, complexityLimitation, invalidScope,
invalidArgumentValue, invalidFilter, noSuchAction, noSuchArgument, noSuchObjectClass,
noSuchObjectInstance, processingFailure, syncNotSupported }
LINKED { m-Linked-Reply }
::= localValue : 7
m-CancelGet OPERATION
ARGUMENT
getInvokeId InvokeIDType
RESULT
ERRORS { mistypedOperation, noSuchInvokeId, processingFailure }
::= localValue : 10
-- Create operation (M-CREATE)
m-Create OPERATION
ARGUMENT CreateArgument
RESULT CreateResult -- this result is conditional; for conditions see 8.3.4.1.3 of ITU-T Rec. X.710 |
-- ISO/IEC 9595
ERRORS { accessDenied, classInstanceConflict, duplicateManagedObjectInstance,
invalidAttributeValue, invalidObjectInstance, missingAttributeValue, noSuchAttribute,
noSuchObjectClass, noSuchObjectInstance, noSuchReferenceObject, processingFailure }
::= localValue : 8
-- Delete operation (M-DELETE)
m-Delete OPERATION
Argument DeleteArgument
RESULT DeleteResult
-- this result is conditional; for conditions see 8.3.5.2.8 of ITU-T Rec. X.710 |
-- ISO/IEC 9595
ERRORS { accessDenied, classInstanceConflict, complexityLimitation, invalidFilter,
InvalidScope, noSuchObjectClass, noSuchObjectInstance, processingFailure, syncNotSupported }
ITU-T Rec. X.711 (1997 E) 13
ISO/IEC 9596-1 : 1998 (E)
LINKED { m-Linked-Reply }
::= localValue : 9
-- Event Reporting operations (M-EVENT-REPORT)
m-EventReport OPERATION
ARGUMENT EventReportArgument
::= localValue : 0
m-EventReport-Confirmed OPERATION
ARGUMENT EventReportArgument
RESULT EventReportResult -- optional
ERRORS { invalidArgumentValue, noSuchArgument, noSuchEventType, noSuchObjectClass,
noSuchObjectInstance, processingFailure }
::= localValue : 1
-- Get operation (M-GET)
m-Get OPERATION
ARGUMENT GetArgument
RESULT GetResult -- this result is conditional; for conditions see 8.3.1.2.
...
ISO/CEl
NORME
9596-l
INTERNATI
Troisieme kdition
1998-l O-l 5
Technologies de I’information -
lnterconnexion de syst&mes ouverts
(OSI) - Protocole commun d’information
de gestion -
Partie 1:
Spkification
lnforma tion technology - Open Systems Interconnection - Common
management information protocol -
Part 1: Specification
Numhro de rkfkrence
ISO/CEl 9596-1:1998(F)
0 ISO/CEI 1998
ISOKEI 9596-l :1998(F)
PDF - Exoneration de responsabilith
Le present fichier PDF peut contenir des polices de caracteres integrees. Conformement aux conditions de licence d’Adobe, ce fichier peut
etre imprim ou visualise, mais ne doit pas etre modifie a moins que I’ordinateur employe 8 cet effet ne beneficie d’une licence autorisant
l’utilisation de ces polices et que celles-ci y soient installees. Lors du telechargement de ce fichier, les parties concernees acceptent de fait la
responsabilite de ne pas enfreindre les conditions de licence d’Adobe. Le Secretariat central oe I’ISO decline toute responsabilite en la
matiere.
Adobe est une marque deposee d’Adobe Systems Incorporated.
Les details relatifs aux prod& logici& utilises pour la creation du present fichier PDF sont disponibles dans la rubrique General Info du
fichier; les parametres de creation PDF ont ete optimises pour I’impression. Toutes les mesures ont ete prises pour garantir l’exploitation de
ce fichier par les comites membres de l’lS0. Dans le cas peu probable ou surviendrait un probleme d’utilisation, veuillez en informer le
Secretariat central a I’adresse donnee ci-dessous.
0 ISO/CEI 1998
Droits de reproduction reserves. Sauf prescription differente, aucune par-tie de cette publication ne peut etre reproduite ni utilisee sous quelque
forme que ce soit et par aucun procede, electronique ou mecanique, y compris la photocopie et les microfilms, sans I’accord ecrit de I’ISO a
l’adresse ci-apres ou du comite membre de I’ISO dans le pays du demandeur.
IS0 copyright office
Case postale 56 l CH-121 I Geneva 20
Tel. + 41 22 749 01 11
Fax. +41 227341079
E-mail copyright @ iso.ch
Web www.iso.ch
Version francaise parue en 2000
Imprime en Suisse
ii 0 ISOKEI 1998 - Tous droits reserves
ISOKEI 9596-l : 1998 (F)
Sommaire
Page
. . . . . . . . . . . . . . . . . . . . . . . . . . .~.
1 Domaine d’application
...................................................................................................................................
2 References normatives
...................................................................... 1
Recommandations 1 Normes internationales identiques
2.1
.......
Paires de Recommandations 1 Norrnes intemationales equivalentes par leur contenu technique
2.2
Definitions ,.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definitions relatives au modele de reference de base
3.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definitions relatives au cadre general de gestion
3.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Definitions relatives aux operations distantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Definitions relatives au service CMIS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
3.5 Definitions relatives aux elements ACSE
Definitions relatives a la presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
3.6
Symboles et abreviations . . . . . . . . . . . . . . . . . . . . . . .~.
.....................................................................................................................................
5 Presentation &n&ale
...................................................................................................................................
5.1 Services foumis
Services sous-j acents .
5.2
...............................................................................
5.3 Definitions relatives aux informations de gestion
...........................................................................................................................
5.4 Version du protocole
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Elements de procedure
Etablissement d’association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
6.1
. . . . . . . . . . . . . . . .*.
6.2 Operations distantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Procedure de notification d’evenement
Procedure d’obtention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4
6.5 Procedure d’affectation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Procedure d’action
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 Procedure de creation
Procedure de suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9 Terminaison normale d’association
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.10 Terminaison brusque d’association
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Syntaxe abstraite
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1
7.2 Correspondance entre les primitives de l’element CMISE et les operations du protocole CMIP . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Don&es d’utilisateur d’element ACSE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Unites de don&es CMIP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Definition de syntaxe abstraite pour le protocole CMIP
. . .
III
ISOKEI 9596-1 : 1998 (F)
0 ISCKEI
8 . 22
Conformit
Conditions de conformitk statique . 22
8.1
Conditions de conformit dynamique . 23
8.2
Annexe A - Rkgles d’association pour l’&ment CMISE .
.................................................... 24
A. 1 Prescriptions relatives aux services ACSE, session et prkentation
................................................................................................. 24
A.2 Rkgles d’initialisation de l’association
.................................................................................................... 25
A.3 Rkgles de terminaison d’association
A.4 Ritgles de rupture d’association .
............................................................................................................. 27
Annexe B - Extension de la syntaxe ASN. 1
Annexe C - Exemples de donnkes APDU d’&ment ROSE du service CMISE . 35
Annexe D - Syntaxe abstraite d’annuaire . 36
iv
o ISOICEI
ISOKEI 9596-l : 1998 (F)
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CEI (Commission
electrotechnique internationale) forment ensemble un systeme consacre a la
normalisation internationale consideree comme un tout. Les organismes nationaux
membres de 1’ISO ou de la CEI participent au developpement de Normes inter-
nationales par l’intermediaire des comites techniques trees par l’organisation
concernee afin de s’occuper des differents domaines particuliers de l’activite
technique. Les comites techniques de 1’ISO et de la CEI collaborent dans des
domaines d’interet commun. D’autres organisations internationales, gouverne-
mentales et non gouvernementales, en liaison avec I’ISO et la CEI participent
egalement aux travaux.
Dans le domaine des technologies de I’information, I’ISO et la CEI ont tree un
comite technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adopt& par le comite technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvees conformement aux procedures qui requierent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISO/CEI 9596-l a ete elaboree par le comite technique
mixte ISOICEI JTC 1, Technologies de l’information, sous-comite SC 33, Services
d’applications distribue’es, en collaboration avec l’UIT-T. Le texte identique est
publie en tant que Recommandation UIT-T X.7 11.
Cette troisieme edition annule et remplace la deuxieme edition
(ISOKEI 9596- 1: 199 l), qui a fait l’objet d’une revision technique. Elle incorpore
aussi le Rectificatif technique 1: 1992, le Rectificatif technique 2: 1992, le
Rectificatif technique 3: 1992, le Rectificatif technique 4: 1993 et le Rectificatif
technique 5: 1994.
L’ISOKEI 9596 comprend les parties suivantes, presentees sous le titre general
Technologies de 1 ‘information - Interconnexion de syst?mes ouverts (ON) -
Protocole commun d’information de gestion:
- Partie 1: Spe’cification
- Partie 2: Proformes de de’claration de conformitk de mise en ceuvre du
protocole (PICS)
Les annexes A a D de la presente partie de I’ISOKEI 9596 sont donnees uniquement
a titre d’information.
This page intentionally left blank
ISO/CEI 9596-l : 1998 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTkMES
PROTOCOLE COMMUN D’INFORMATION
OUVERTS (OSI) -
DE GESTION: SPtiCIFICATION
1 Domaine d’application
protocole qui est utilise par des entites de la couche
La presente Recommandation ( Norme intemationale specific un
pour transferer des informations de gestion.
Application
La presente Recommandation 1 Nor-me intemationale specific
-
les procedures de transmission des informations de gestion entre entites d’application;
-
abstraite du protocole commun d’information de gestion (CMIP, common
la syntaxe management
information protocol) et les regles d .e codage associees a appl iquer;
-
les procedures d’interpretation des informations de controle de protocole;
-
les conditions de conformite ;a remplir par des mises en ceuvre de la presente Recommandation 1 Norme
intemationale.
La presente Recommandation 1 Norme intemationale ne specific pas
-
la structure ou la signification des informations de gestion qui sont transmises au moyen du
protocole CMIP;
-
la facon dont la gestion est exercee, comme resultat de transferts par protocole CMIP;
-
les interactions qui resultent de l’utilisation du protocole CMIP.
2 Rkfhrences normatives
Les Recommandations et les Normes intemationales suivantes contiennent des dispositions qui, par suite de la reference
qui y est faite, constituent des dispositions valables pour la presente Recommandation I Norme intemationale. Au
moment de la publication, les editions indiquees etaient en vigueur. Toutes Recommandations et Normes sont sujettes a
revision et les parties prenantes aux accords fond& sur la presente Recommandation / Norme intemationale sont invitees
a rechercher la possibilite d’appliquer les editions les plus recentes des Recommandations et Normes intemationales
indiquees ci-apres. Les membres de la CEI et de 1’ISO possedent le registre des Normes intemationales en vigueur. Le
Bureau de la normalisation des telecommunications de 1’UIT tient a jour une liste des Recommandations de UIT-T en
vrgueur.
21 . Recommandations 1 Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologies de Z’information -
Interconnexion des systGmes ouverts - ModGZe de rkfkrence de base: le modGle de rkfkrence de base.
-
Recommandation UIT-T X.215 (1995) ) ISO/CEI 8326: 1996, Technologies de Z’infirmation -
Interconnexion des systGmes ouverts - Dkfinition du service de session.
-
Recommandation UIT-T X.216 (1994) I ISOKEI 8822: 1994, Technologies de Z’information -
Interconnexion des systGmes ouverts - Dk!nition du service de prhentation.
-
Recommandation UIT-T X.2 17 (1995) I ISO/CEI 8649: 1996, Technologies de Z’information -
Interconnexion des systGmes ouverts - Dkfinition de service applicable 2 IWment de service de contrhle
d’association.
-
Recommandation UIT-T X.226 (1994) I ISOKEI 8823-l : 1994, Technologies de Z’information -
Interconnexion des systGmes ouverts - Protocole de prksentation en mode connexion: sphfication du
protocole.
Rec. UIT-T X.711 (1997 F) 1
ISOKEI 9596-l : 1998 (F)
-
Recommandation UIT-T X.227 (1995) I ISOKEI 8650-l : 1996, Technologies de l’information -
Interconnexion des systemes ouverts - Protocole en mode connexion applicable a l’element de service de
controle d’association: specification du protocole.
-
Recommandation UIT-T X.710 (1997) I ISOKEI 9595: 1998, Technologies de l’information -
Interconnexion des systemes ouverts - Service commun de transfert d’informations de gestion.
-
Recommandation UIT-T X.712 (1992) 1 ISO/CEI 9596-2: 1993, Technologies de l’information -
Interconnexion des systemes ouverts - Protocole commun de transfert d’informations de gestion.
formulaire de declaration de conformite d’une instance de protocole.
22 . Paires de Recommandations 1 Normes internationales kquivalentes par leur contenu technique
-
Recommandation X.208 du CCITT (1988), Speczfication de la syntaxe abstraite numero un (ASN. I).
ISOKEI 8824: 1990, Technologies de l’information - Interconnexion des systemes ouverts - SpectJication
de la syntaxe abstraite numero un (ASN. 1).
-
Recommandation X.209 du CCITT (1988), Sp&zjkation des rggles de codage de base pour la notation
de syntaxe abstraite numero un (ASN. I).
ISO/CEI 8825: 1990, Technologies de l’information - Interconnexion des systemes ouverts - Specification
des regles de codage de base pour la notation de syntaxe abstraite numero un (ASN. I).
-
Recommandation X.219 du CCITT (1988), Operations distantes: modele, notation et definition du
service.
ISOKEI 9072- 1: 1989, Systemes de traitement de l’information - Communication de texte - Operations a
distance - Partie I: Modele, notation et definition du service.
-
Recommandation X.229 du CCITT (1988), Operations distantes: spectjkation du protocole.
ISOKEI 9072-2: 1989, Systemes de traitement de l’information - Communication de texte - Operations a
distance - Partie 2: Speczfkation du protocole.
-
Recommandation X.700 du CCITT (1992), Cadre de gestion pour l’interconnexion de systemes ouverts
pour les applications du CCITT.
ISOICEI 7498-4: 1989, Systemes de traitement de l’information - Interconnexion de systemes ouverts -
Modele de reference de base - Par
ie 4: Cadre general de gestion.
3 D&Yinitions
Pour les besoins de la prksente Recommandation Norme intemationale, les dkfinitions suivantes s’appliquent.
31 . Dhfinitions relatives au mod&le de rdfkrence de base
La prksente Recommandation ( Norme intemationale utilise les termes suivants, dkfinis dans la Rec. UIT-T X.200 I
ISOKEI 7498-1 :
Gment de service d’application;
a)
processus d’application;
W
systkme ouvert reel;
Cl
gestion-systkmes.
d)
32 . Dkfinitions relatives au cadre g6nkal de gestion
La prksente Recommandation I Norme intemationale utilise les termes suivants, dkfmis dans la Rec. X.700 du CCITT I
ISOKEI 7498-4:
objet g&k;
a)
information de gestion;
b)
c) base d’informations de gestion;
d) entitk d’application de gestion-systkmes.
Rec. UIT-T X.711 (1997 F)
ISO/CEI 9596-l : 1998 (F)
33 . Dkfinitions relatives aux ophations distantes
La presente Recommandation / Norme intemationale utilise les termes suivants, d8inis dans la Rec. X.219 du CCITT 1
ISOKEI 9072- 1:
initiateur d’association;
repondeur d’association;
b)
operations liees;
C>
operations distantes;
d)
element du service d’operations distantes;
e>
invocateur;
f)
executant;
ES>
classe d’associations;
h)
classe d’operations.
. Dbfinitions relatives au service CMIS
La presente Recommandation 1 Norme intemationale utilise les termes suivants, definis dans la Rec. UIT-T X.710 1
ISO/CEI 9595:
attribut;
a>
b) element de service commun d’information de gestion;
services communs d’information de gestion;
c>
d) foumisseur du service CMISE;
utilisateur du service CMISE;
utilisateur invocateur du service CMISE;
g) utilisateur executeur du service CMISE.
35 . Dkfinitions relatives aux blbments ACSE
La presente Recommandation I Norme intemationale utilise les termes suivants, de&is dans la Rec. UIT-T X.217 I
ISO/CEI 8649:
contexte d’application;
association d’application;
b)
association.
36 . Dkfinitions relatives h la prbsentation
La presente Recommandation 1 Norme intemationale utilise les termes suivants, definis dans la Rec. UIT-T X.2 16 1
ISO/CEI 8822:
syntaxe abstraite;
syntaxe de transfert.
b)
Symboles et abrhiations
Pour les besoins de la presente Recommandation ( Norme intemationale, les abreviations suivantes sont utilisees.
ACSE element de service de controle d’association (asswiation control service elemenf)
APDU unite de don&es de protocole d’application (application protocol data unit)
ASE element de service d’application (application service element)
notation de syntaxe abstraite nun-&o un (abstract syntax notation one)
ASN. 1
CMIP protocole commun d’information de gestion (common management infirmation protocol)
CMIPM machine du protocole commun d’information de gestion (common management information
protocol machine)
Rec. UIT-T X.711 (1997 F) 3
ISOKEP 9596-l : 1998 (F)
service commun d’information de gestion (common management information service)
CMIS
element du service commun d’information de gestion (common management information service
CMISE
element)
ensemble des contextes definis (defined context set)
DCS
PCI information de controle du protocole (protocol control information)
PDU unite de donnees de protocole (protocol data unit)
PIGS declaration de conformite d’implementation de protocole (protocol implementation conformance
statement)
operation distante (remote opkration)
RO
ROSE element de service d’operations distantes (remote operations service element)
SMAE entite d’application de gestion-systemes (systems management application entity)
5 Prbsentation ghbrale
Le protocole commun d’information de gestion (CMIP) specific des klkments de protocole qui peuvent etre utilisks pour
foumir les services d’operations et de notifications decrits dans la Rec. UIT-T X.710 I ISOKEI 9595, qui d&nit les
services communs d’informations de gestion (CMIS, common management information service).
51 . Services fournis
Le protocole specific dans la presente Recommandation I Nor-me intemationale assure les services definis dans la
Rec. UIT-T X.710 1 ISO/CEI 9595. Ces services sont resumes dans le Tableau 1.
Tableau 1 - Services communs d’informations de gestion
Service Nature
Type
Confirme
M-CANCEL-GET Extraction, annulation
M-EVENT-REPORT Rapport d’evenement Confkme/non conk-me
M-GET Confirme
--traction
I I I
M-SET Affectation Confirme/non confirme
I -7 I I
Action Confirme/non confirrn6
M-ACTION
I I I I
Confkme
M-CREATE Creation
I I I I
Confirme
1 M-DELETE -Suppression
I I
. Services sous-jacents
La presente Recommandation 1 Nor-me intemationale utilise les services RO-INVOKE (invocation), RO-RESULT
(resultat), RO-ERROR (erreur) et RO-REJECT-U (refk par l’utilisateur) de l’element de service d’operations distantes
(ROSE, remote operations service eZement) qui sont definis dans la Rec. X.2 19 du CCITT I ISOKEI 9072-l. L’element
ROSE suppose l’utilisation du service de presentation defini dans la Rec. UIT-T X.216 I ISO/CEI 8822. Les operations
de type wzonfkme)~ du protocole CMIP sont la classe d’operations 2 (asynchrone) ou la classe d’operations 1 (synchrone)
selon les besoins de l’application. Le choix de la classe d’operations doit etre decide sur le plan local. Les operations de
type <(non confirrne~~ du protocole CMIP sont celles de la classe d’operations 5 (asynchrone, resultat non signale). Le
protocole CMIP utilise la classe d’associations 3.
Si l’unite fonctionnelle d’extension de service est adoptee lors de la negotiation, les unites de donnees de protocole
d’application ROSE (ROSE APDU, application protocol data unit) peuvent etre mappees avec d’autres services de
presentation que le service P-DATA (transfert de don&es de presentation).
NOTE - Par exemple, il peut etre necessaire de modifier l’ensemble des contextes defmis (DCS, defined context set) lorsque
l’operation CMIP est envoyee a l’utilisateur de service CMISE equivalent. Dans ce cas, l’unite APDU d’element ROSE qui
achemine l’operation CMIP sera mappee avec le service P-ALTER-CONTEXT (modification de contextes de presentation) qui
sert kgalement a apporter les modifications a l’ensemble DCS.
Des details sur les autres services de presentation requis et sur la facon de les utiliser sont donnes dans la description du
contexte d’application en vigueur dans le cadre de l’association.
4 Rec. UIT-T X.71 1 (1997 F)
ISO/CEI 9596-l : 1998 (F)
5.2.1 Services suppo&s 6tre fournis par I’ACSE
La presente Recommandation I Norme intemationale suppose l’utilisation des services suivants: A-ASSOCIATE
(association), A-RELEASE (terminaison), A-ABORT (rupture) et A-P-ABORT (rupture par le foumisseur), de l’element
de service de controle d’association (ACSE, association control service element).
5.2.2 Services suppo&s &re fournis par la couche Prbsentation
La Rec. X.229 du CCITT I ISO/CEI 9072-2 suppose l’utilisation du service P-DATA de la couche Presentation pour le
transfer-t des unites de don&es de protocole (PIN, protocol data unit) RO-INVOKE, RO-RESULT, RO-ERROR et
RO-REJECT APDUs.
53 . Dkfinitions relatives aux informations de gestion
La presente Recommandation I Nor-me intemationale definit la syntaxe abstraite du protocole commun de transfer?
d’informations de gestion. Les definitions des informations de gestion a acheminer par ce protocole ne sont pas
specifiees dans la presente Recommandation I Norme intemationale.
54 . Version du protocole
La presente Recommandation I Norme intemationale definit la version 2 du protocole CMIP. Cette version 2 remplace la
version 1. La presente Recommandation I Norme intemationale ne definit aucun interfonctionnement entre la version 2
et la version 1.
6 Elbments de procbdure
Le present article donne la definition des elements de procedure du protocole CMIP. Ces procedures definissent le
le codage et la relation avec les primitives du
transfer-t des unites PDU du protocole CMIP dont la structure,
service CMIS sont specifies a l’article 7.
La machine du protocole commun d’information de gestion (CMIPM, common management information protocol
machine) recoit des primitives de service de dernande et de reponse du service CMIS et envoie des unites PDU du
protocole CMIP en lancant des elements de- procedure specifiques, comme cela est specific dans le present article.
Une machine CMIPM doit accepter toute unite PDU bien formee du protocole CMIP et la communiquer, pour
traitement, a l’utilisateur executeur du service CMISE, au moyen des primitives d’indication et de confirmation du
service CMIS. Si l’unite PDU recue n’est pas bien formee ou ne contient pas d’operation ou de notification acceptee, on
renvoie une PDU en indiquant que l’unite PDU recue a ete refusee.
Les procedures indiquent uniquement comment interpreter les divers champs de l’unite PDU du protocole CMIP mais
non ce, qu’un uttisateur invocateur du service CMISE ferait avec les informations qu’il demande, ni comment un
ut%likateur mecuteur du service CMISE traiterait ces informations.
61 . Etablissement d’association
L’etablissement d’une association implique deux utilisateurs du service CMISE, l’un dans le role d’initiateur et l’autre
dans celui de repondeur d’association.
Un utilisateur du service CMISE peut lancer un etablissement d’association a l’aide du service A-ASSOCIATE de la Rec.
UIT-T X.217 I ISO/CEI 8649.
Le contexte d’application precise, notamment, les regles requises pour la coordination de l’information d’initialisation
correspondant a differents elements ASE. Les regles d’association applicables a l’element CMISE sont specifiees dans
1’Annexe A.
62 . Opkrations distantes
6.2.1 Ekments de prockdure RO
sur les elements
Les elements de procedure du protocole CMIP reposent sous-jacents suivants de la procedure
d .‘operations distantes:
lancement;
a)
resultat positif;
b)
Rec. UIT-T X.711 (1997 F) 5
ISOKEI 9596-1 : 1998 (F)
resultat negatif;
rejet par l’utilisateur;
d)
rejet par le foumisseur.
e>
Ces elements de procedure sont decrits integralement dans la Rec. X.229 du CCITT 1 ISO/CEI 9072-Z.
Le Tableau 2 indique la correspondance entre les parametres CMIS et ROSE.
Tableau 2 - Correspondance entre les paramktres CMIS et R
Paramktre CMIS Paramktre ROSE
I
ID d’invocation
Identificateur d’invocation
I
I I
Identificateur ii6 ID 1%
I I I
La correspondance entre d’autres parametres CMIS et ROSE est indiquee a l’article 7.
6.2.2 Parametres du problkme de rejet d’ophation distante
Les parametres du probleme de rejet d’operation distante (RO-REJECT) sont mappes ou trait& comme suit.
6.2.2.1 Le mappage, avec les codes d’erreur du service CMIS, des parametres du probleme d’invocation du a un rejet
par l’utilisateur (RO-REJECT-U) est indiquee dans le Tableau 3.
Tableau 3 - Mappage des param&tres du probkme d’invocation
RO-REJECT-U avec les codes d’erreur du service CMISE
Paramktres RO-REJECT Code d’erreur CMISE
r I
I
Invocation en double Invocation en double
I
I I
Argument de type errone
Argument de type erronk
I
I I
Limitation de ressources Limitation de ressources
r I
I
Opkation non reconnue Opkration non reconnue
r
I I
Les autres parametres du probleme d’invocation dependent de la realisation locale.
6.2.2.2 Le traitement des autres parametres de rejet d’operation distante depend de la realisation locale.
. Procedure de notification d’hknement
6.3.1 Invocation
Les procedures de notification d’evenement sont lancees par la primitive de demande M-EVENT-REPORT.
Des reception de la primitive de demande M-EVENT-REPORT, la machine CMIPM doit:
a) dans le mode confkme, construire une unit6 APDU demandant l’operation de notification d’evenement de
gestion de type confirme (m-EventReport-Confirmed) ou, sinon, construire une unite APDU demandant
l’operation de notification d’evenement de gestion (m-EventReport);
b) envoyer l’unite APDU en appliquant la procedure RO-INVOKE.
63.2 Rkception
D&s rkeption d’une unit6 APDU demandant une operation de notification d’evenement de gestion ou de notification
d’evenement de gestion de type confirme, la machine CMIPM doit, si l’unite APDU est bien formee, envoyer une
primitive d’indication M-EVENT-REPORT i l’utilisateur du service CMISE dont le parametre de mode indique si la
confirmation est chxmd~e ou non; ou, sinon, construire Lane unite APDU contenant la notification de l’erreur et
l’envoyer en utilisant la procedure RO-RE JECT-U.
Rec. UIT-T X.711 (1997 F)
ISOKEI 9596-l : 1998 (F)
6.3.3 Rkponse
Dans le mode confirme, la machine CMIPM doit accepter une primitive de reponse M-EVENT-REPORT et doit:
a) construire une unite APDU confirmant la notification M-EVENT-REPORT;
si les parametres presents dans la primitive de reponse M-EVENT-REPORT indiquent que la notification
b)
a ete acceptee, envoyer l’unite APDU en utilisant la procedure RO-RESULT, sinon envoyer l’unite APDU
en utilisant la procedure RO-ERROR.
6.3.4 Rkeption d’une rkponse
Des reception d’une unite APDU repondant a une notification M-EVENT-REPORT, la machine CMIPM doit, si l’unite
APDU est bien formee, envoyer une primitive de confirmation M-EVENT-REPORT a l’utilisateur du service CMISE,
terminant ainsi la procedure de notification; ou sinon, construire une unite APDU contenant la notification de l’erreur et
l’envoyer en utilisant la procedure RO-REJECT-U.
64 . Prohdure d’obtention
6.4.1 Invocation
Les procedures d’extraction sont lancees par la primitive de demande M-GET.
Des reception de la primitive de demande M-GET, la machine CMIPM doit:
construire une unite APDU demandant l’operation m-Get;
a)
envoyer l’unite APDU en utilisant la procedure RO-INVOKE.
b)
6.4.2 Rkception
Des reception d’une unite APDU demandant l’operation m-Get, la machine CMIPM doit, si l’unite APDU est bien
formee, envoyer une primitive d’indication M-GET a l’utilisateur du service CMISE; ou, sinon, construire une
unite APDU contenant la notification de l’erreur et l’envoyer en utilisant la procedure RO-REJECT-U.
6.4.3 Rkponse
La machine CMIPM doit:
accepter zero, une ou plusieurs primitives de reponse a une demande M-GET contenant un identificateur
a)
lie (linked-ID), suivies d’une seule primitive de reponse a une demande M-GET sans identificateur lie;
b) pour chaque primitive de reponse a une demande M-GET contenant un identificateur lie:
-
construire une unite APDU demandant l’operation de reponse lice de gestion (m-Linked-Reply) dont
l’argument de reponse lice (Lin~edReplyArgumenl) est mis comme il se doit sur ((erreur de liste
d’extractiom) (getListError), <
(processingFailure);
-
envoyer chaque unite APDU en utilisant la procedure RO-INVOKE;
pour la primitive de reponse a une demande M-GET ne contenant pas d’identificateur lie:
c)
-
construire une unite APDU confirmant l’operation de demande m-Get;
-
si les parametres presents dans la primitive de reponse a une demande M-GET indiquent que
l’operation a ete executee correctement, envoyer l’unite APDU en utilisant la procedure
RO-RESULT. Si les parametres presents dans la primitive de reponse a une demande M-GET
indiquent que l’operation n’a obtenu qu’un succes par-tie1 ou n’a pas ete executee parce qu’il existait
une erreur, envoyer l’unite APDU en utilisant la procedure RO-ERROR.
6.4.4 Rkeption de la rkponse
Des reception d’une unite APDU repondant a une operation m-Get, la machine CMIPM doit:
si l’unite APDU comportait un identificateur lie et qu’elle soit bien formee, envoyer une primitive de
a)
confirmation M-GET a l’utilisateur du service CMISE;
b) si l’unite APDU est la derniere reponse (c’est-a-dire qu’elle ne contient pas d’identificateur lie) et qu’elle
soit bien formee, envoyer une primitive de confirmation M-GET a l’utilisateur du service CMISE,
terminant ainsi la procedure M-GET;
si l’unite APDU n’est pas bien formee, construire une unite APDU contenant la notification de l’erreur et
l’envoyer en utilisant la procedure RO-REJECT-U.
Rec. UIT-T X.711 (1997 F) 7
ISOKEI 9596-l : 1998 (F)
6.4.5 Procedure d’extraction, annulation
6.4.5.1 Invocation
Les procedures d’extraction, annulation sont lancees par la primitive de demande M-CANCEL-GET.
Des reception de la primitive de demande M-CANCEL-GET, la machine CMIPM doit:
a) construire une unite APDU demandant l’operation d’extraction, annulation de gestion (m-Can&-Get);
b) envoyer l’unite APDU en utilisant la procedure RO-INVOKE.
6.4.5.2 Rbception
Des reception d’une unite APDU demandant l’operation d’extraction, annulation de gestion, la machine CMIPM doit, si
l’unite APDU est bien formee, envoyer une primitive d’indication M-CANCEL-GET a l’utilisateur du service CMISE
ou, sinon, construire une unite APDU contenant la notification de l’erreur et l’envoyer en utilisant la procedure
RO-REJECT-U.
6.4.5.3 Rbponse
La machine CMIPM doit:
construire une unite APDU confirmant l’operation d’extraction, annulation de gestion;
a>
b) si les parametres contenus dans la primitive de reponse M-CANCEL-GET indiquent que l’operation a ete
executee correctement, envoyer l’unite APDU en faisant appel a la procedure RO-RESULT, sinon
envoyer l’unite APDU en faisant appel a la procedure RO-ERROR. Si l’operation m-Cancel-Get est bien
executee, l’utilisateur executeur du service CMISE doit cesser d’envoyer des reponses liees vers
l’operation m-Get et doit envoyer une primitive de reponse M-GET contenant l’erreur cooperation
annuleek
6.4.5.4 Rkeption de la rkponse
Des reception d’une unite APDU repondant a une operation d’extraction, annulation de gestion, la machine CMIPM doit,
si l’unite APDU est bien formee, envoyer une primitive de confirmation M-CANCEL-GET a l’utilisateur du service
CMISE ou, sinon, construire une unite APDU contenant la notification de l’erreur et l’envoyer en utilisant la procedure
RO-REJECT-U.
65 . Prockdure d’affectation
6.5.1 Invocation
Les procedures d’affectation sont lancees par la primitive de demande M-SET.
Des reception de la primitive de demande M-SET, la machine CMIPM doit:
a) dans le mode con&me, construire une unite APDU demandant l’operation d’affectation de gestion de type
confkme (m-Set-Confirmed), ou sinon, construire une unite APDU demandant l’operation d’affectation de
gestion (m-Set);
b) envoyer l’unite APDU en utilisant la procedure RO-INVOKE.
Rkception
6.5.2
Des reception d’une unite APDU demandant l’operation d’affectation de gestion ou d’affectation de gestion de type
confirm& la machine CMIPM doit, si l’unite APDU est bien formee, envoyer une primitive d’indication M-SET a
l’utilisateur du service CMISE, dont le parametre de mode indique si une confirmation est demandee ou non; ou, sinon,
construire une unite APDU contenant la notification de l’erreur et l’envoyer en utilisant la procedure RO-REJECT-U.
6.5.3 Rkponse
Dans le mode confirme, la machine CMIPM doit:
accepter zero, une ou plusieurs primitives de reponse M-SET contenant un identificateur lie, suivies d’une
a)
seule primitive de reponse M-SET sans identificateur lie;
b) pour chaque primitive de reponse M-SET contenant un identificateur lie:
-
construire une unite APDU demandant l’operation de reponse like de gestion dont l’argument de
reponse lice est mis comme il se doit sur ((erreur de liste d’affectatiorw
(SetListError), w%ultat
d’affectatiorw (setResult) ou ((defaillance du traitement)) (processingFailure);
-
envoyer chaque unite APDU en utilisant la procedure RO-INVOKE;
Rec. UIT-T X.711 (1997 F)
ISOKEI 9596-l : 1998 (F)
c) pour la primitive de rkponse M-SET ne contenant pas d’identificateur lie:
-
construire une unit6 APDU confirmant l’operation d’affectation de gestion;
-
si les param&-es presents dans la primitive de reponse M-SET indiquent que l’operation a ete
executee correctement, envoyer l’unite APDU en utilisant la procedure RO-RESULT. Si les
parametres presents dans la primitive de reponse M-SET indiquent que l’operation n’a obtenu qu’un
succes partiel ou n’a pas ete executee parce qu’il existait une erreur, envoyer l’unite APDU en
utilisant la procedure RO-ERROR.
6.5.4 Rkeption de la rhponse
Des reception d’une unite APDU repondant a une operation d’affectation de gestion de type confirme, la machine
CMIPM doit:
si l’unite APDU comportait un identificateur lie et qu’elle soit bien formee, envoyer une primitive de
a)
confirmation M-SET a l’utilisateur du service CMISE;
b) si l’unite APDU est la demiere reponse (c’est-a-dire qu’elle ne contient pas d’identificateur lie) et qu’elle
soit bien formee, envoyer une primitive de confirmation M-SET a l’utilisateur du service CMISE,
terminant ainsi la procedure M-SET;
si l’unite APDU n’est pas bien formee, construire une unite APDU contenant la notification de l’erreur et
l’envoyer en utilisant la procedure RO-REJECT-U.
66 . Procbdure d’action
Invocation
6.6.1
Les nrocedures d’action sont lancees nar la nrimitive de demande M-ACTION.
I I I
Des reception de la primitive de demande M-ACTION, la machine CMIPM doit:
dans le mode confirme, construire une unite APDU demandant l’operation d’action de gestion de type
a>
confirme (m-Action-Confzrmed); ou sinon, construire une unite APDU demandant l’operation d’action de
gestion (m-Action);
envoyer l’unite APDU en utilisant la procedure RO-INVOKE.
W
6.6.2 Rkeption
Des reception d’une unite APDU demandant l’operation d’action de gestion ou d’action de gestion de type confkme, la
machine CMIPM doit, si l’unite APDU est bien formee, envoyer une primitive d’indication M-ACTION a l’utilisateur du
service CMISE, le parametre de mode indiquant si une confirmation est demandee ou non ou, sinon, construire une
unite APDU contenant la notification de l’erreur et l’envoyer en utilisant la procedure RO-REJECT-U.
6.6.3 Rbponse
Dans le mode confirme, la machine CMIPM doit:
accepter zero, une ou plusieurs primitives de reponse M-ACTION contenant un identificateur lie, suivies
a>
d’une primitive de reponse M-ACTION sans identificateur lie;
b) pour chaque primitive de reponse M-ACTION contenant un identificateur lie:
-
construire une unite APDU demandant l’operation de reponse lice de gestion, l’argument de reponse
lice etant mis comme il se doit sur ((erreur d’actiom) (actionError), ((resultat d’actiom) (actionResult)
ou c
-
envoyer chaque unite APDU en utilisant la procedure RO-INVOKE;
pour la primitive de reponse M-ACTION ne conten .ant pas d’identificateur lie:
c>
-
construire une unite APDU confirmant l’operation d’action de gestion;
-
si les parametres presents dans la primitive de reponse M-ACTION indiquent que l’operation a ete
executee correctement, envoyer l’unite APDU en utilisant la procedure RO-RESULT, ou sinon,
envoyer l’unite APDU en utilisant la procedure RO-ERROR.
Rec. UIT-T X.711 (1997 F)
ISOKEI 9596-I : I998 (F)
6.6.4 Rbception de la reponse
Des reception dune unite APDU repondant a une operation d’action de gestion de type confirme, la machine CMIPM
doit:
si l’unite APDU comportait un identificateur lie et qu’elle soit bien formee, envoyer une primitive de
a)
confirmation M-ACTION a l’utilisateur du service CMISE;
b) si l’unite APDU est la demiere reponse (c’est-a-dire qu’elle ne contient pas d’identificateur lie) et qu’elle
soit bien formee, envoyer une primitive de confirmation M-ACTION a l’utilisateur du service CMISE,
terminant ainsi la procedure M-ACTION;
si l’unite APDU nest pas bien formee, construire une unite APDU contenant la notification de l’erreur et
l’envoyer en utilisant la procedure RO-REJECT-U.
67 . Procedure de crbation
6.7.1 Invocation
Les procedures de creation sont lancees par la primitive de demande M-CREATE.
Des reception de la primitive de demande M-CREATE, la machine CMIPM doit:
construire une unite APDU demandant l’operation de creation de gestion (m-Create);
a>
b) envoyer l’unite APDU en utilisant la procedure RO-INVOKE.
6.7.2 Rkeption
Des reception d’une unite APDU demandant l’operation de creation de gestion, la machine CMIPM doit, si l’unite APDU
est bien formee, envoyer une primitive d’indication M-CREATE a l’utilisateur du service CMISE ou sinon, construire
une unite APDU contenant la notification de l’erreur et l’envoyer en utilisant la procedure RO-REJECT-U.
6.7.3 Rbponse
La machine CMIPM doit accepter une primitive de reponse M-CREATE et doit:
construire une unite APDU confirmant l’operation de creation de gestion;
b) si les parametres presents dans la primitive de reponse M-CREATE indiquent que l’operation a ete
executee correctement, envoyer l’unite APDU en utilisant la procedure RO-RESULT; ou sinon, envoyer
l’unite APDU en utilisant la procedure RO-ERROR.
6.7.4 Rkeption de la reponse
Des reception d’une unite APDU repondant a une operation de creation de gestion, la machine CMIPM doit, si
l’unite APDU est bien formee, envoyer une primitive de confirmation M-CREATE a l’utilisateur du service CMISE,
terminant ainsi la procedure M-CREATE; ou sinon, construire une unite APDU contenant la notification de l’erreur et
l’envoyer en utilisant la procedure RO-REJECT-U.
68 . Procedure de suppression
6.8.1 Invocation
Les procedures de suppression sont lancees par la primitive de demande de M-DELETE.
Des reception de la primitive de demande M-DELETE, la machine CMIPM doit:
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...