Understanding ISO/IEC 13712‑1:2000 – Remote Operations: Concepts, Model, and Notation

1. Scope and Introduction

ISO/IEC 13712‑1:2000 (adopted as CAN CSA ISO IEC 13712‑1‑00) is the first part of the multi‑part standard Information technology – Remote Operations. It defines the fundamental concepts, the reference model, and the abstract notation used to describe remote operations in open distributed systems. The standard is technically aligned with ITU‑T Recommendations X.219 (Remote Operations Model) and X.229 (Remote Operations Protocol).

The core of the standard is the Remote Operations Service Element (ROSE), an application‑layer service element that enables a user to invoke an operation on a remote system and receive results or errors. ROSE follows a client‑server paradigm where the operation, argument, result, and error are specified using ASN.1 notation. The standard does not prescribe a specific transfer protocol; it focuses on the abstract service definition and the notation that can be mapped onto different transport mechanisms.

ISO/IEC 13712‑1:2000 is part of a three‑part series:

• Part 1: Concepts, Model, and Notation
• Part 2: Protocol Specification
• Part 3: Abstract Test Suite and Implementation Conformance Statement

This article covers only Part 1, emphasizing the conceptual framework that all ROSE‑based implementations rely upon.

2. Technical Requirements and Model

2.1 The Remote Operations Model

The standard defines a remote operation as an action performed by one application entity (the operation performer) on behalf of another (the operation invoker). Each operation is characterized by:

• Operation name – a unique identifier.
• Argument – data sent from invoker to performer.
• Result – data returned from performer to invoker (if the operation is successful).
• Error – data returned when the operation fails.

The model supports three types of operations:

• Operations with result (reply expected) – synchronous or asynchronous.
• Operations without result (fire‑and‑forget) – no reply is sent.
• Linked operations – a performer can initiate a new operation while processing a previous one.

2.2 ASN.1 Notation for Operations

Operations are described using the OPERATION macro (in the 1988/1992 ASN.1 syntax) or the newer OPERATION information object class (as specified in ITU‑T X.208 and X.681). The notation captures:

• Argument type and optionality
• Result type and optionality
• Error types and their associated data
• Whether the operation is synchronous or asynchronous

2.3 Service Elements and Association

ROISE provides the following service primitives:

• RO‑INVOKE – to request the start of an operation
• RO‑RESULT – to deliver the result of a successful operation
• RO‑ERROR – to report an error
• RO‑REJECT‑U / RO‑REJECT‑P – to reject an operation (user‑initiated or provider‑initiated)

These primitives are exchanged within an application association established by the Association Control Service Element (ACSE). The standard assumes a reliable, ordered transport, typically provided by the OSI presentation and session layers.

2.4 Abstract Syntax and Transfer Syntax

The standard defines the remote operation abstract syntax in ASN.1. This abstract syntax can be encoded using any transfer syntax agreed upon by the communicating peers (e.g., Basic Encoding Rules – BER, Distinguished Encoding Rules – DER, or Packed Encoding Rules – PER). The choice of encoding is specified during association establishment.

3. Implementation Highlights

3.1 ROSE Protocol Stack Mappings

While ISO/IEC 13712‑1 is independent of the underlying protocol, most implementations rely on the ROSE protocol defined in Part 2 (ISO/IEC 13712‑2:2000), which uses the Presentation Service (ISO 8822) and Session Service (ISO 8326) for data transport. Modern implementations may also map ROSE primitives to TCP/IP using lightweight presentation layer wrappers, but must remain compliant with the abstract service definition.

3.2 Coding Operations with ASN.1

A typical ROSE operation definition looks like this:

 MyOperation OPERATION ::= { ARGUMENT MyArgument RESULT MyResult ERRORS {MyError1, MyError2} CODE local:1 } 

The CODE assignment is used by the ROSE protocol to identify the operation. Implementations must ensure that the integer or object identifier used does not conflict with other operations in the same application context.

3.3 Association and Scoping

ROSE assumes that an application association exists between invoker and performer. The standard does not mandate how associations are established, but typical implementations use ACSE (ISO 8649 / ISO 8650). The ROSE primitives are scoped within an association; an invocation ID is unique only within the association. Implementers must manage the lifecycle of associations and handle abnormal terminations gracefully.

3.4 Evolution and Interworking

Although originally conceived for the OSI protocol stack, the ROSE model has influenced many distributed computing paradigms, including CORBA, Java RMI, and Web Services. The abstract operation model remains relevant, and the standard is cited in many telecommunications protocols (e.g., INAP, MAP) and in the X.500 Directory standards.

4. Compliance Notes

4.1 Conformance Requirements

An implementation claiming conformance to ISO/IEC 13712‑1:2000 must:

• Support the abstract operation model as defined in clauses 6–9 of the standard.
• Provide the ROSE service primitives (RO‑INVOKE, RO‑RESULT, RO‑ERROR, RO‑REJECT) consistent with the abstract definitions.
• Use the identified ASN.1 notation for operation specification.
• Acknowledge the relationship with the supporting layers (ACSE, Presentation, Session) as per the reference model.

The standard does not prescribe a specific encoding rule set, but any encoding used must be capable of representing the abstract syntax completely. Conformance testing can be performed using the test suite defined in Part 3 (ISO/IEC 13712‑3).

4.2 Adoption in Canada – CAN CSA ISO IEC 13712‑1‑00

The Canadian Standards Association (CSA) has adopted ISO/IEC 13712‑1:2000 as a National Standard of Canada under the designation CAN CSA ISO IEC 13712‑1‑00. The Canadian adoption is identical in technical content to the original international standard. There are no national deviations; it is a pure adoption. This means that compliance with the international standard also implies compliance with the Canadian standard, and vice versa.

4.3 Testing and Certification

Conformance testing for ROSE typically involves verifying the behaviour against the abstract service primitives using abstract test methods (as defined in ISO/IEC 9646). Implementers should produce an Implementation Conformance Statement (ICS) that documents which optional features are supported (e.g., linked operations, error codes, multiple associations). Certification bodies (e.g., the Open Group) offer OSI conformance testing that covers ROSE.

Frequently Asked Questions