ISO/IEC 9072-2:1989
(Main)Information processing systems — Text communication — Remote Operations — Part 2: Protocol specification
Information processing systems — Text communication — Remote Operations — Part 2: Protocol specification
La présente partie de l'ISO/CEI 9072 spécifie le protocole (syntaxe abstraite) et les procédures applicables à l'élément de service d'opérations distantes (partie 1 de cette Norme internationale). Les services ROSE sont fournis en liaison avec les services de l'élément de service de contrôle d'association (ACSE) (ISO 8649) et avec le protocole ACSE (ISO 8650), optionnellement avec les services de l'élément de service de transfert fiable (RTSE) (ISO/CEI 9066-1) et avec le protocole RTSE (ISO/CEI 9066-2), ainsi qu'avec le service de présentation (ISO 8822). Les procédures ROSE sont définies sous la forme a) des interactions entre machines protocole ROSE homologues par l'emploi des services RTSE ou du service de présentation ; b) des interactions entre la machine protocole ROSE et son utilisateur de service. La présente partie de l'ISO/CEI 9072 spécifie les conditions de conformité applicables aux systèmes qui mettent en oeuvre ces procédures.
Systèmes de traitement de l'information — Communication de texte — Opérations à distance — Partie 2: Spécification du protocole
General Information
Relations
Standards Content (Sample)
INTERNATIONAL lSO/IEC
9072-2
STANDARD
First edition
1989-11-15
Information processing systems - Text
Remote Operations -
communication -
Part 2 :
Protocol specification
S ysthmes de traitement de l’information - Communication de texte - Ophations
a distance -
Partie 2 : Spkification du protocole
---
_-.-
-
-
-
=. -&
=
E
=
= =
= =
=
=
I
E
5
2
=
g
E
=
E
Reference number
=
s
s
s -
:@
ISO/IEC 9072-2 : 1989 (E)
---------------------- Page: 1 ----------------------
ISOAEC 9072-2: 1989 (E)
Page
Contents
...
ill
Foreword .
iv
Introduction .
1
1 Scope .
1
2 Normative references .
2
3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.*.
5 Conventions
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Overview of the protocol
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Elements of procedure
12
.....................................
8 Mapping to used services
14
.........................
9 Abstract syntax definition of APDUs
17
. .*.*.*.
10 Conformance
Annexes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A ROPM State tables
B Differences between this part of ISO/IEC 9072 and
. . . . . . . . . . . . . . . . . . . . . . . . . 27
CCITT Recommendation X.410 - 1984
. . . . . . . . . . . . . . . . . 28
C Summary of assigned object identifier values
0 ISO/IEC 1989
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in
writing from the publisher.
ISO/lEC Copyright Office l Case postale 56 l CH-1211 Gen&ve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
ISOAEC 9072-2: 1989 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) together form a system for worldwide standardization as
a whole. National bodies that are members of IS0 or IEC participate in the develop-
ment of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. IS0 and IEC
technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with IS0 and IEC, also
take part in the work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISOAEC JTC 1. Draft International Standards adopted by the joint
technical committee are circulated to national bodies for approval before their accep-
tance as International Standards. They are approved in accordance with procedures re-
quiring at least 75 % approval by the national bodies voting.
International Standard ISO/IEC 9072-2 was prepared by Joint Technical
Committee ISO/IEC JTC 1, information technology.
. . .
III
---------------------- Page: 3 ----------------------
This page intentionally left blank
---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD IS0 / IEC 9072-2: 1989 (E)
Information processing systems -Text communication -
Remote Operations - Part 2:
Protocol specification
ISO/IEC 7498: 1984, Inform&on processing
1 Scope
systems - Open Systems interconnection - Basic
Reference Model.
This part of ISO/IEC 9072 specifies the protocol
(abstract syntax) and procedures for the Remote
ISO/TR 8509: 1987, Information processing
Operation Service Element (part 1 of this
systems - Open Systems lnterconn.ection - Service
International Standard). The ROSE services are
Conventions.
provided in conjunction with the Association
Control Service Element (ACSE) services (IS0 IS0 8649: 1988, Information processing systems -
8649) and the ACSE protocol (IS0 8650), Open Systems Interconnection - Service definition
optionally the Reliable Transfer Service Element for the Association Control Service Element.
(RTSE) services (ISO/IEC 9066-l) and the RTSE
IS0 8650: 1988, Information processing systems -
protocol (ISO/IEC 9066-2), and the presentation-
Open Systems Interconnection - Protocol
service (IS0 8822 j.
specification for the Association Control Service
Element.
The ROSE procedures are defined in terms of
IS0 8822: 1988, Information processing systems -
a) the interactions between peer ROSE
Open Systems Interconnection - Connection
protocol machines through the use of
orientedbresentation service definition.
RTSE services or the presentation-service;
IS0 8824: 1987, Information processing systems -
b) the interactions between the ROSE
Open Systems Interconnection - Specification of
protocol machine and its service-user.
Abstract Syntax Notation One (ASN.1).
This part of ISO/IEC 9072 specifies conformance IS0 8825: 1987, Information processing systems -
requirements for systems implementing these Open Systems Interconnection - Specification of
basic encoding rules for Abstract Syntax Notation
procedures.
One (ASN.1).
2
Normative references
ISO/IEC 9066-l: 1989, Informa.tion processing
systems - Text communication - Reliable Transfer
The following standards contain provisions which,
- Part 1: Model and service definition. *,
through reference in this text, constitute
ISOIIEC 9066-2: 1989, Information processing
provisions of this part of ISO/IEC 9072. At the
systems - Text communication - Reliable Transfer
time of publication, the editions were valid. All
-Part 2: Protocol specification.
Standards are subject to revision, and parties to
agreement based on this part of ISO/IEC 9072 are
ISO/IEC 9072-l: 1989, Information processing
encouraged to investigate the possibility of
Text communication - Remote
systems -
applying the most recent editions of the standards
Part 1: Model, notation and service
Operations -
listed below. Members of IS0 and IEC maintain
definition.
Registers of currently valid International
Standards.
---------------------- Page: 5 ----------------------
ISO/IEC 9072-2: 1989 (E)
34 . Association control definitions
3 Definitions
This part of ISO/IEC 9072 makes use of the
31 . Reference Model definitions
following terms defined in IS0 8649:
This part of ISO/IEC 9072 is based on the concepts
application-association; association;
a)
developed in ISO/IEC 7498 and makes use of the
b) application context;
following terms defined in it:
Association Control Service Element.
Application Layer; c)
a)
b) application-process;
3.5 Reliable Transfer definitions
application-entity;
c)
This part of ISO/IEC 9072 makes use of the
following terms defined in ISO/IEC 9066-l:
d) application-service-element;
Reliable Transfer Service Element.
application-protocol-data-unit; a)
e)
application-protocol-control-information;
f)
3.6 ROSE service definitions
g) presentation-service;
This part of ISO/IEC 9072 makes use of the
following terms defined in ISO/IEC 9072-l:
h) presentation-connection;
association-initiating-application-entity;
a)
session-service;
8
association-init.iator;
.
session-connection;
J)
b) association-responding-application-
k) transfer syntax; and
entity; association-responder;
user-element.
1)
invoking-application-entity; invoker;
cl
d) performing-application-entity; performer;
3.2 Service conventions definitions
requestor;
This part of ISO/IEC 9072 makes use of the 4
following terms defined in ISO/TR 8509:
f) acceptor;
service-provider;
a)
linked-operations;
g)
b) service-user;
h) parent-operation;
confirmed service;
c)
child-operation;
8
.
non-confirmed service;
d)
RO-notation;
J)
provider-initiated service;
4
Remote Operation Service Element;
k)
f) primitive;
ROSE-provider;
1)
request (primitive);
g)
m) ROSE-user;
h) indication (primitive);
RTSE-user;
d
response (primitive); and
9
Remote Operations.
0)
.
confirm (primitive).
J)
Remote Operation protocol
37 .
specification definitions
33 . Presentation service definitions
For the purpose of this part of ISO/IEC 9072 the
This part of ISO/IEC 9072 makes use of the
following definitions apply:
following terms defined in IS0 8822:
abstract syntax;
a)
3.7.1 remote-operation-protocol-machine:
The protocol machine for the Remote Operation
b) abstract syntax name;
Service Element specified in this part of ISO/IEC
presentation context.
cl
9072.
2
---------------------- Page: 6 ----------------------
ISOAEC 9072-2: 1989 (E)
3.7.2 requesting-remote-operation- 5 Conventions
protocol-machine: The remote-operation-
protocol-machine whose service-user is the This part of ISO/IEC 9072 employs a tabular
presentation of its APDU fields. In clause 7, tables
requestor of a particular Remote Operation
are presented for each ROSE APDU. Each field is
Service Element service.
summarized using the following notation:
3.7.3 accepting-remote-operation-protocol-
M presence is mandatory
machine: The remote-operation-protocol-
U presence is a ROSE-user option
machine whose service-user is the acceptor for a
particular Remote Operation Service Element
source is related request primitive
req
service.
ind sink is related indication primitive
4 Abbreviations
source is related response primitive
resp
sink is related confirm primitive
41 . Data units conf
source or sink is the ROPM
APDU application-protocol-data-unit
SP
4.2 Types of application-protocol-data- The structure of each ROSE APDU is specified in
units clause 9 using the abstract syntax notation of
ISO/IEC 8824.
The following abbreviations have been given to
the application-protocol-data-units defined in this
6 Overview of the protocol
part of ISO/IEC 9072.
ROIV RO-INVOKE application-protocol- 61 . Service provision
data-unit
The protocol specified in this part of ISO/IEC 9072
RORS RO-RESULT application-protocol- provides the ROSE services defined in ISO/IEC
data-unit 9072-l. These services are listed in table 1.
RO-ERROR application-protocol-data-
ROER
unit
Table 1 - ROSE services summary
RO-REJECT application-protocol-
RORJ
data-unit
Service
Type
I I
43 . Other abbreviations
RO-IXVOKE Non-confirmed
The following abbreviations are used in this part
RO-RESULT LNon-confirmed
of ISO/IEC 9072.
RO-ERROR Non-confirmed
RO-REJECT-C’ Non-confirmed
AE Application Entity
RO-REJECT-P Provider-initiated
ACSE Association Control Service
Element
6.2 Use of services
ASE Application Service Element
The ROSE protocol specified in this part OI
RO (or ROS) Remote Operations
ISO/IEC 9072 needs a transfer service to pass
ROPM Remote Operations Protocol
information in the form of ROSE APDUs between
Machine
peer application-entities (AEs).
ROSE Remote Operations Service
Two transfer services may be used alternatively:
Element
a) the RTSE services, if the RTSE is
RT Reliable Transfer
included in the application-context, or
Reliable Transfer Service Element
RTSE
the presentation-service, if the RTSE is
b
not included in the application-context.
3
---------------------- Page: 7 ----------------------
ISO/IEC 9072-2: 1989 (E)
issues indication primitives to its service-user,
In both cases an existing application-association,
and request primitives on the used RTSE services,
established and released by means of the ACSE
or the presentation-service. If the RTSE is
services, is assumed.
included in the application-context, the RT-
TRANSFER indication, RT-TRANSFER request
6.2.1 Use of the RTSE services
and RT-TRANSFER confirm primitives are used.
If the RTSE is included in the application-context,
In the case of an application-context excluding
this part of ISO/IEC 9072 assumes that the ROPAM
RTSE, the presentation-service P-DATA request,
is the sole user of the RT-TRANSFER service and
and P-DATA indication primitives are used. In
the RT-TURN-GIVE service.
this case the transfer is not confirmed.
The initiating AE may only request the release of
The reception of a ROSE service primitive, or of a
the application-association by means of the RT-
RTSE service or of a presentation-service
CLOSE service if it possesses the Turn. Therefore
primitive, and the generation of dependent
the RTSE-user and the ROPM are the user of the
actions are considered to be indivisible.
RT-TURN-PLEASE service.
During the exchange of APDUs, the existence of
The ROPM is the user of the RT-U-ABORT and
both, the association-initiating AE and the
RT-P-ABORT services.
association-responding AE is presumed. How
these AEs are created is beyond the scope of this
6.2.2 Use of the presentation-service
part of ISO/IEC 9072.
If the RTSE is not included in the
application-context, the ROPM is a user of the P- During the execution of operations, the existence
DATA service. of an application-association between the peer
How this application-
AEs is presumed.
63 . Model association is established and released is beyond
the scope of this part of ISO/IEC 9072 (see
The remote-operation-protocol-machine (ROPM)
ISO/IEC 9072-1, IS0 8649, IS0 8650, ISO/IEC
communicates with its service-user by means of
9066-l and ISO/IEC 9066-Z).
primitives defined in ISO/IEC 9072-L Each
invocation of the ROPM controls a single
NOTE Each application-association may be identified in an
application-association.
end system by an internal, implementation
dependent mechanism so that the ROSE service-user
The ROPM is driven by ROSE service request
and the ROPE can refer to it.
primitives from its service-user, and by indicatifm
and confirm primitives of the RTSE services, or
the presentation-service. The ROPM, in turn,
4
---------------------- Page: 8 ----------------------
ISOAEC 9072-2: 1989 (E)
b) a ROIV APDU as user-data of a transfer
7 Elements of procedure
indication primitive.
The ROSE protocol consists of the following
7.1.3.1 RO-INVOKE request primitive
elements of procedure:
a) invocation
Table 2 - RON APDCr fields
b) return-result
return-error
d
Pre-
user-reject
d) Field name Source Sink
sence
prov ,ider-reject.
e)
Invoke-ID M ind
req
In the following clauses, a summary of each of
Linked-ID U ind
req
these elements of procedure is presented. This
Operation-value M ind
req
consists of a summary of the relevant APDUs, and
Argument U ind
req
a high-level overview of the relationship between
the ROSE service primitives, the APDUs
involved, and the transfer service that is used.
The requesting ROPM forms a ROIV APDU from
the parameter values of the RO-INVOKE request
The generic terms transfer service, transfer
primitive. It issues a transfer request primitive.
service-provider, transfer request, and transfer
The user-data parameter of the transfer request
indication are used in the context of clause 7.
primitive contains the ROIV APDU.
Clause 8 describes how these generic service
primitives are mapped either on to the RTSE
The requesting ROPM waits either for a transfer
services or the presentation-service.
indication primitive from the transfer service-
provider or any other. primitive from the
In clause 9 a detailed specification of the ROSE
requestor.
APDUs is given using the notation defined in IS0
8824.
7.1.3.2 ROIV APDtJ
The accepting ROPM receives a ROIV APDU from
71 . Invocation
its peer as user-data on a transfer indication
7.1.1 Purpose
primitive. If any of the fields of the ROIV APDU
are unacceptable to this ROPM, the provider-
The invocation procedure is used by one AE (the
reject procedure is performed, and no RO-
invoker) to request an operation to be performed
INVOKE indication primitive is issued by the
by the other AE (the performer).
ROPM.
7.1.2 APDUs used
If the ROIV APDU is acceptable to the accepting
The invocation procedure uses the RO-INVOKE
ROPM, it issues a RO-INVOKE indication
(ROIV) APDU.
primitive to the acceptor. The RO-INVOKE
indication primitive parameters are derived from
The fields of the ROIV APDU are listed in table 2.
the ROW APDU.
7.1.3 Invocation procedure
The accepting ROPM waits either for a transfer
This procedure is driven by the fol lowing events: indication primitive from the transfer service-
provider or any other primitive from the acceptor.
a) a RO-INVOKE request pr imitive from the
requestor
---------------------- Page: 9 ----------------------
ISOAEC 9072-2: 1989 (E)
7.1.4 7.2.2 APDUs used
Use of the ROW APDU fields
The return-result procedure uses the RO-
The ROW fields are used as follows.
RESULT (RORS) APDU.
7.1.4.1
Invoke-ID
The fields of the RORS APDU are listed in table 3.
This is the invoke-ID parameter value of the RO-
INVOKE request primitive. It appears as the
Return-result procedure
7.2.3
invoke-ID parameter value of the RO-INVOKE
This procedure is driven by the following events:
indication primitive.
a) a RO-RESULT request primitive from the
The value of this field is transparent to the
requestor;
ROPM, however the value may be used in the
b) a RORS APDU as user-data of a transfer
provider reject procedure.
indication primitive.
7.1.4.2 Linked-ID
RO-RESULT Request Primitive
7.2.3.1
This is the linked-ID parameter value of the RO-
INVOKE request primitive. It appears as the
linked-ID parameter value of the RO-INVOKE Table 3 - RORS APDU fields
indication primitive.
The value of this field is transparent to the
Pre-
Source Sink
Field name
ROPM.
sence
7.1.4.3 Operation-value
Invoke-ID M ind
req
T
This is the operation-value parameter value of the
Operation-value IJ ind
req
RO-INVOKE request primitive. It appears as the
Result U ind
req
operation-value parameter value of the RO-
INVOKE indication primitive.
The requesting ROP&1 forms a RORS APDU from
The value of this field is transparent to the
the parameter values of the RO-RESULT request
ROPM.
primitive. It issues a transfer request primitive.
The user-data parameter of the transfer request
7.1.4.4 Argument
primitive contains the RORS APDU.
This is the argument parameter value of the RO-
The requesting ROPM waits either for a transfer
INVOKE request primitive. It appears as the
indication primitive from the transfer service-
argument parameter value of the RO-INVOKE
provider or any other primitive from the
indication primitive.
requestor.
The value of this field is transparent to the
7.2.3.2 RORS APDU
ROPM.
The accepting ROPE receives a RORS APDU
72 . Return-result
from its peer as user-data on a transfer indication
primitive. If any of the fields of the RORS APDU
7.2.1 Purpose
are unacceptable to this ROPM, the provider-
The return-result procedure is used by one AE
reject procedure is performed, and no RO-
(the performer) to request the transfer of the
RESULT indication primitive is issued by the
result of a successfully performed operation to the
ROPM.
other AE (the invoker).
I
6
---------------------- Page: 10 ----------------------
ISO/lEC 9072-2: 1989 (E)
If the RORS APDU is acceptable to the accepting 7.3.2 APDUs used
ROPM, it issues a RO-RESULT indication
The return-error procedure uses the RO-ERROR
primitive to the acceptor. The RO-RESULT
(ROER) APDU.
indication primitive parameters are derived from
the RORS APDU.
The fields of the ROER APDU are listed in table 4.
The accepting ROPM waits either for a transfer
primitive from the transfer service-provider or
Table 4 - ROER APDU fields
any other primitive from the acceptor.
7.2.4 Use of the RORS APDU fields
Pre-
Field name Source Sink
The RORS fields are used as follows.
sence
Invoke-ID
7.2.4.1
Invoke-ID M ind
req
Error-value M ind
This is the invoke-ID parameter value of the RO-
req
Error-parameter U ind
RESULT request primitive. It appears as the
req
invoke-ID parameter value of the RO-RESULT
indication primitive.
7.3.3 Return-error procedure
The value of this field is transparent to the
This procedure is driven by the following events:
ROPM, however the value may be used in the
a) a RO-ERROR request primitive from the
provider-reject procedure.
requestor;
7.2.4.2 Operation-value
b) a ROER APDC as user-data of a transfer
indication primitive.
This is the operation-value parameter value of the
RO-RESULT request primitive. It appears as the
RO-ERROR request primitive
operation-value parameter of the RO-RESULT 7.3.3.1
indication primitive.
The requesting ROPM forms a ROER APDU from
the parameter values of the RO-ERROR request
The value of this field is transparent to the
primitive. It issues a transfer request primitive.
ROPK
The user-data parameter of the transfer request
primitive contains the ROER APDU.
This field shall be present only if the result field is
present.
The requesting ROPM waits either for a transfer
primitive from the transfer service-provider or
. 7.2.4.3 Result
any other primitive from the requestor.
This is the result parameter value of the RO-
RESULT request primitive. It appears as the 7.3.3.2 ROER APDU
result parameter value of the RO-RESULT
The accepting ROPM receives a ROER APDU
indication primitive.
from its peer as user-data on a transfer indication
primitive. If any of the fields of the ROER APDU
The value of this field is transparent to the
are unacceptable to this ROPM, the provider-
ROPM.
reject procedure is performed, and no RO-ERROR
indication primitive is issued by the ROPM.
Return-error
73 .
If the ROER APDU is acceptableto the accepting
7.3.1 Purpose
ROPM, it issues a RO-ERROR indication
The return-error procedure is used by one AE (the
primitive to the acceptor. The RO-ERROR
performer) to request the transfer of the the error
indication primitive parameters are derived from
information in the case of an unsuccessfully
the ROER APDU.
performed operation to the other AE (the invoker).
---------------------- Page: 11 ----------------------
ISO/lEC 9072-2: 1989 (E)
The accepting ROPM waits either for a transfer 7.4.3 User-reject procedure
indication primitive from the transfer service-
This procedure is driven by the following events:
provider or any other primitive from the acceptor.
a) a RO-REJECT-U request primitive from
7.3.4 Use of the ROER APDU fields the requestor
The ROER fields are used as follows. b) a RORJ APDU as user-data of a transfer
indication primitive.
7.3.4.1 Invoke-ID
7.4.3.1 RO-REJECT-U request primitive
This is the invoke-ID parameter value of the RO-
ERROR request primitive. It appears as the The requesting ROPM forms a RORJ APDU from
invoke-ID parameter value of the RO-ERROR the parameter values of the RO-REJECT-U
indication primitive. request primitive. It issues a transfer request
primitive. The user-data parameter of the transfer
The value of this field is transparent to the request primitive contains the RORJ APDU.
ROPM, however the value may be used in the
provider reject procedure. The requesting ROPM waits either for a transfer
indication primitive from the transfer service-
7.3.4.2 Error-value provider or any other primitive from the
requestor.
This is the error-value parameter value of the RO-
ERROR request primitive. It appears as the error-
7.4.3.2 RORJ APDU
value parameter value of the RO-ERROR
indication primitive. The accepting ROPbI receives a RORJ APDU
from its peer as user-data on a transfer indication
The value of this field is transparent to the primitive. If any of the fields of the RORJ APDU
ROPM.
are unacceptable to this ROPSI, no RO-REJECT-
U indication primitive is issued by the ROPM.
7.3.4.3 Error-parameter
If the RORJ APDU is acceptable to the accepting
This is the error-parameter parameter value of
ROPM and the fields of the RORJ APDU indicates
the RO-ERROR request primitive. It appears as
a user reject (i.e. invoke-problem, return-result-
the error-parameter parameter value of the RO-
problem, or return-error-problem), it issues an
ERROR indication primitive.
RO-REJECT-U indication primitive to the
acceptor. The RO-REJECT-U indication primitive
The value of this field is transparent to the
parameters (invoke-ID and reject-reason) are
ROPM.
derived from the RORJ APDU.
74 . User-reject
The accepting ROPM waits either for a transfer
7.4.1 Purpose indication primitive from the transfer service-
provider or any other primitive from the acceptor.
The user-reject procedure is used by one AE to
reject the request (invocation) or reply (result or
7.4.4 Use of the RORJ APDU fields
error) of the other AE .
The RORJ fields are used as follows.
7.4.2 APDUs used
7.4.4.1 Invoke-ID
The user-reject procedure uses the RO-REJECT
This is the invoke-ID parameter value of the RO-
(RORJ) APDU. This RORJ APDU is used in
REJECT-U request primitive. It appears as the
addition by the provider-reject procedure.
invoke-ID parameter value of the RO-REJECT-U
The fields of the RORJ APDU used for the user- indication primitive.
reject procedure are listed in table 5.
The value of this field is transparent to the
ROPM.
---------------------- Page: 12 ----------------------
ISO/IEC 9072-2: 1989 (E)
Table 5 - RORJ APDU fields used for user-reject
Field name Presence Source Sink
1
Invoke-ID M ind
req
Problem (choice of): M ind
req
Invoke-problem
Return-result-problem
Return-error-problem
7.4.4.2 Problem - unexpected-child-operation: signifies that
the invoked child-operation is not one that
This is the problem parameter value of the RO-
the invoked parent-operation referred to
REJECT-U request primitive. It appears as the
by the linked-ID allows.
problem parameter value of the RO-REJECT-U
indication primitive. b) Return-result-problem: user-reject of a
RO-RESULT indication primitive with
The values used by the user-reject procedure are values:
- unrecognized-invocation: signifies that no
a) Invoke-problem: user-reject of a RO-INVOKE
indication primitive with values: operation with the specified invoke-ID is
in progress;
- duplicate-invocation: signifies that the
- result-response-unexpected: signifies that
invoke-ID parameter violates the
the invoked operation does not report a
assignment rules of ISO/IEC 9072- 1;
result;
- unrecognized-operation: signifies that the
operation is not one of those agreed - mistyped-result: signifies that the type of
between the ROSE-users; the result parameter supplied is not that
agreed between the ROSE-users.
- mistyped-argument: signifies that the
c) Return-error-problem: user-reject of a RO-
type of the operation argument supplied is
ERROR indication primitive with values:
not that agreed between the ROSE-users;
- resource-limitation: the performing - unrecognized-invocation: signifies that no
operation with the specified invoke-ID is
ROSE-user is not able to perform the
invoked operation due to resource in progress;
limitation;
- error-response-unexpected: signifies that
- initiator-releasing: the association- the invoked operation does not report
initiator is not willing to perform the failure;
invoked operation because it is about to
- unrecognized-error: signifies that the
attempt to release the application-
reported error is not one of those agreed
association;
between the ROSE-users;
- unrecognized-linked-ID: signifies that
- unexpected-error: signifies that the
there is no operation in progress with an
reported error is not one that the invoked
invoke-ID equal to the specified linked-ID;
operation may report;
- linked-response-unexpected: signifies that
- mistyped-parameter: signifies that the
the invoked operation referred to by the
type of the error parameter supplied is not
linked-ID is not a parent-operation;
that agreed between the ROSE-users.
---------------------- Page: 13 ----------------------
lSO/IEC 9072-2: 1989 (E)
If the received unacceptable APDU is a RORJ
75 . Provider-reject
APDU no new RORJ APDU is formed and
7.5.1 Purpose
transferred. In this case, or after the rejection of a
locally specified number of APDUs, the
The provider-reject procedure is used to inform
application-association is released abnormally.
the ROSE user and the peer ROPM, if an ROPM
detects a problem.
If the application-association is not released
7.5.2 APDUs used abnormally, the receiving ROPM waits either for
a transfer indication primitive from the transfer
The provider-reject procedure uses the RO-
service-provider or any other primitive from the
REJECT (RORJ) APDU. This RORJ APDU is
requestor.
used in addition by the user-reject procedure.
7.5.3.2 RORJ APDU
The fields of the RORJ APDU used for the
provider-reject procedure are listed in table 6. The receiving ROPM receives a RORJ APDU from
its peer as user-data on a transfer indication
primitive. If any of the fields of the RORJ APDU
Table 6 - RORJ APDC fields used for provider-reject are unacceptable to this ROPM, the provider-
reject procedure for an unacceptable APDU is
performed.
Pre-
Field name Source Sink
If the RORJ APDU is acceptable to the accepting
sence
ROPM and the problem field of the RORJ APDU
indicates a general-problem, it issues an RO-
Invoke-ID M ind
SP
REJECT-P indication primitive to the acceptor.
ind
Problem (choice of): M
SP
The RO-REJECT-P indication primitive
General-problem
parameters (invoke-ID and reject-reason) are
derived from the RORJ APDU.
The receiving ROPM
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.