Section 1 : General

1.1 Scope

This International Standard specifies the behaviour to be exhibited by an implementation claiming to conform to this International Standard.

It specifies both dynamic conformance and static conformance. It can be referenced by other OSI Standards (using the notation defined in the JTM Service Definition) to invoke the procedures specified in this International Standard.

This International Standard is to be applied by an implementor in developing a conforming implementation, and can also be referenced when the requirements for an implementation are specified.

The facilities provided by a JTM implementation are applicable to any field of activity in which asynchronous movement of documents is to occur.

This International Standard does not completely determine the transfer syntax to be used in an instance of communication, but does specify a transfer syntax which all implementations are required to support.

This International Standard specifies

• the application-context name to be used to reference the procedures of this International Standard in application-context negotiation;
• the abstract syntax name to used be to reference the abstract syntax of a JTM Transfer Element, CCR user data and JTM-defined documents, specified in this International Standard by use of ASN.1;
• the transfer syntax name to be used to reference the transfer syntax obtained by applying the ASN.1 Basic Encoding Rules to the abstract syntax specified using ASN.1;

This International Standard defines a set of local management functions which are needed in order to support the operation of a JTM implementation. These local management functions are invoked by the JTM Application Service Element. They are not modelled as operations within the application entity, nor do they form part of the normal services provided by or assumed by the JTM Application Service Element. They form a means of specifying the degree of flexibility which is permitted to or required of implementations conforming to this International Standard.

1.2 Normative references

The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.

ISO 2375:1985 , Data processing - Procedures for the registration of escape sequences.

ISO 8571-3:1988,Information processing systems - Open systems interconnection - File Transfer, Access and Management - Part 3 : File Service definition.

ISO 8571-4:1988,Information processing systems - Open systems interconnection - File Transfer, Access and Management - Part 4 : File Protocol Specification.

ISO 8649:1988,Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element.

ISO 8650:1988,Information processing systems - Open Systems Interconnection - Protocol specification for the Association Control Service Element.

ISO 8822:1988,Information processing systems - Open Systems Interconnection - Connection-oriented presentation service definition.

ISO/IEC 8824:1990,Information technology - Open Systems Interconnection - Specification of 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).

ISO/IEC 8831:1992,Information technology - Open Systems Interconnection - Job transfer and manipulation concepts and services.

ISO/IEC 9804:1990,Information technology - Open Systems Interconnection - Service definition for the Commitment, Concurrency and Recovery service element.

ISO/IEC 9805:1990,Information technology - Open Systems Interconnection - Protocol specification for the Commitment, Concurrency and Recovery service element.

1.3 Definitions

For the purposes of this International Standard, the definitions given in ISO/IEC 8831 and ISO 8649 and the following definitions apply.

1.3.1 static conformance: A statement of the requirement for support by an implementation of a valid set of features from among those defined by this International Standard.

1.3.2 dynamic conformance: A statement of the requirement for an implementation to adhere to the behaviour prescribed by this International Standard in an instance of communication.

1.3.3 transfer element: Part of the JTM PDU which is used to transfer the JTM information (semantics) contained in a work specification between open systems.

1.3.4 initial processing: The procedures carried out by a JTM implementation before offering commitment to an atomic action which generated a work specification at the open system.

1.3.5 deferred processing: The procedures carried out by a JTM implementation on a work specification (held as secure data) after the implementation has taken responsibility for it.

1.3.6 primitive type: A name for a set of values.

1.3.7 abstract syntax (of the JTM transfer element or of a document): A data type definition, produced using a repertoire of primitive types and means for combining them, that specify the set of possible values of the transfer element or document in a way which does not completely determine the representation of the transfer element or document during transfer.

1.3.8 notation for abstract syntax definition: A set of rules for defining an abstract syntax.

1.3.9 oriented octet: An octet whose end-bits are named and distinguished, usually by the terms most significant bit and least significant bit.

1.3.10 transfer syntax (of the JTM transfer element or of a document): The representation of the JTM transfer element or document during transfer, expressed as the value of a sequence of oriented octets.

NOTE -- The representation of a sequence of oriented octets on parallel or serial communication lines is specified by lower layer standards, and is not in the scope of JTM.

1.3.11 encoding rules: A set of rules, associated with a notation for abstract syntax definition, that enable a transfer syntax to be derived for any datatype whose abstract syntax is specified using that notation.

1.3.12 application-context name: A name which unambiguously references the (Standards defining the) complete set of abstract syntax definitions (and their semantics) to be used during an application association, and the procedures to be followed in sending or receiving them.

1.3.13 abstract syntax name: Name which unambiguously references the abstract syntax of an identified set of datatype definitions.

1.3.14 transfer syntax name: A name which unambiguously references an encoding for an abstract syntax.

1.3.15 local management functions: Functions (whose internal details are not standardised) which return values which determine the value of certain work specification fields or which select between protocol options. (See annex A for a complete list.)

1.3.16 human-readable text: Text which clarifies a fully-defined diagnostic code, and which is expected to be read and understood by a human being.

NOTE -- The language in which the human-readable text is expressed is not defined in this International Standard. An implementation may be configurable to produce text in any one of several languages, using different character sets. Fields of CCR primitives are used to specify the character set and hence indicate the preferred language; text is tagged with the identification of the character set used.

1.3.17 JTM Application Service Element: An abstract representation of those parts of an open system which perform the procedures specified in this International Standard.

1.4 Abbreviations

ASN.1          Abstract Syntax Notation One
CCR          Commitment, Concurrency, and Recovery
JTM          Job Transfer and Manipulation
PDU          Protocol Data Unit
ASE          Application Service Element
ACSE          Association Control Service Element

1.5 Relation of JTM to other services

1.5.1 JTM architecture

This International Standard specifies the operation of the JTM Application Service Element.

This ASE can operate as part of an application-entity which contains only the JTM ASE, the CCR ASE, and the ACSE ASE. It can provide its services directly to the User Element.

The JTM agencies are a conceptual model of the structures and operation of the User Element.

The JTM ASE can also operate as part of an application entity which contains other ASEs which make use of the JTM services. It is not visible to the JTM ASE whether it is providing services directly to the user element or to some other ASE.

This International Standard specifies static conformance requirements for the situation where the JTM ASE provides services directly to the user element. Where the JTM ASE is used by some other ASE, the static conformance requirements are specified by the standard specifying the ASE which is using the JTM services.

1.5.2 JTM ASEs and agencies

The JTM service provider is represented by a collection of JTM ASEs in application-entities. Each application-entity contains zero, one or more conceptual JTM agencies and a single JTM ASE. (Reference to a single JTM (static) ASE does not preclude the simultaneous operation of multiple (dynamic) instances of this ASE to handle independent JTM transfers.) A real computer system may support several application-entities with a JTM ASE, and a single application entity may model the operation of several real computers. The real-world equivalent of the JTM agencies is specified by the implementation, which also specifies the real-world events (which may be geographically distributed) corresponding to the issue of JTM service primitives. In this way, the issue of JTM service primitives in an implementation becomes visible and testable.

NOTE -- Where the implementation conforms to some other standard which references this International Standard, then the JTM service primitives might only be visible through effects defined by the other standard.

The JTM ASEs jointly progress a work-specification (created as a result of J-INITIATE, of reporting, or of spawning). The responsibility for progressing a work specification always resides with exactly one JTM ASE. This responsibility is passed by sending a "Transfer-element" (the work specification in a defined syntactic form) from one JTM ASE to another as an atomic action.

A JTM ASE having responsibility for a work specification holds enough information as secure data to completely define the work specification. Note that a work specification is a semantic construct, and may be held in a local system in any manner which is desired.

1.5.3 Use of the Presentation Service

The communication between the JTM ASEs uses a datatype called a "Transfer-element", whose abstract syntax and semantics is completely defined by this International Standard. This is transferred using a transfer syntax determined by presentation layer negotiation.

In Basic Class, the entire transfer element, together with any associated documents, is transferred using a single P-DATA primitive. In full JTM, an indefinite number of P-DATA primitives can be used. The P-DATA primitives are issued on an application association. The service primitives to establish and use an application association are defined in ISO 8649 and in ISO 8822 and their use is specified in section 5.

It should be noted that, apart from the use of CCR for ensuring reliability and returning diagnostics, the JTM transfer in Basic Class is of a simplex nature. It involves a single P-DATA, in one direction only.

1.5.4 Use of the ACSE ASE

The ACSE ASE is used to begin and end the use of an application association in either "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context".

The service primitives to perform this operation are specified in ISO 8649 and their use is specified in section 5.

When an extended JTM implementation initiates an application association, it may propose use of "ISO JTM Full Application-context". If the responding implementation is Basic Class, the negotiation specified in section 5 will result in the establishment of "ISO JTM Basic Class Application-context". If the responder is an extended JTM implementation, "ISO JTM Full Application-context" will be established.

Local scheduling requirements may cause abandonment of the JTM application-context (or of the underlying presentation connection). Later recovery (resynchronisation) is performed by use of C-RECOVER within a new "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context", as appropriate established between the same application-entities.

On completion of JTM activity on an association, the association is relinquished by use of ACSE ASE primitives.

1.5.5 Use of the CCR ASE

The JTM ASE uses the CCR ASE for communication to

1. other JTM ASEs, using the Presentation Service with CCR service primitives; and
2. JTM agencies, using the J-service primitives which include CCR semantics.

At any time, at most one of these communications is to the JTM ASE's CCR superior, and the rest are to its CCR subordinates. The CCR procedures (defined in terms of all the CCR primitives received or issued) are applied to the entire activity of the JTM ASE.

The application of the CCR procedures, through the use of the CCR Common Application Service Element, ensures reliable transfer of responsibility for work specifications and consistency of operation.

The CCR primitives also provide for the return of diagnostic information when initial processing fails. (Following initial processing, diagnostic information on failure is returned by the JTM reporting mechanisms.)

Finally, the CCR primitives provide for the (optional) transmission of information which can be used by an implementation to decide when to retry an attempt to send a transfer-element to another JTM entity .

This International Standard does not require a JTM ASE to provide this timer information to a remote JTM ASE, so that a JTM ASE has to be prepared to adopt a suitable local algorithm in the absence of information.

NOTE -- A suitable algorithm would be to attempt a transfer at exponentially increasing intervals of time over a period of several days, then to consider the attempt to have failed and invoke the JTM error handling procedures.

1.5.6 Service primitives referenced by this International Standard

The service primitives which invoke JTM procedures are

1. a P-DATA indication in the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context" carrying a data value in the JTM presentation-context;
2. a J-INITIATE-WORK request;
3. a J-INITIATE-WORK-MAN request;
4. a J-INITIATE-REPORT-MAN request;
5. a J-INITIATE-TCR-MAN request;
6. a J-END-SIGNAL request;
7. a J-MESSAGE request;
8. J-SPAWN request;
9. all CCR indications and confirms in the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context";
10. A-ASSOCIATE, A-P-ABORT, A-ABORT, and A-RELEASE indications and confirms (see 3.3.4).

The service primitives invoked by JTM procedures are

1. a P-DATA request in "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context";
2. a J-DISPOSE indication and response;
3. a J-GIVE indication and response;
4. a J-ENQUIRE indication and response
5. a J-STATUS indication;
6. a J-KILL indication;
7. a J-STOP indication;
8. a J-HOLD indication;
9. a J-RELEASE indication;
10. all CCR requests and responses;
11. A-ASSOCIATE, A-ABORT, and A-RELEASE requests and responses (see 3.3.4).

1.5.7 Summary of JTM architecture

The JTM architecture is illustrated in figure 1.

Figure 1 — JTM upper layer architecture

Note that in "ISO JTM Basic Class Application-context" and "ISO JTM Full Application-context"

1. P-service primitives carrying data values in CCR presentation context are visible only as C-service primitives; and
2. P-service primitives carrying data values in JTM and document presentation contexts are visible as P-DATA; and
3. P-service primitives carrying data values in ACSE ASE presentation context serve to establish or terminate the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context".

1.6 Conformance

1.6.1 Clause 1.5 above was provided as background. There are no conformance requirements to clause 1.5. Where clause 1.5 is in disagreement with other clauses, the other clauses take precedence.

1.6.2 Dynamic conformance is specified in section 3 and section 5 using the datatype definitions given in section 2.

1.6.3 Static conformance is specified in section 4.