ISO/TR 8509 (Service Conventions) is restricted in scope to the two-party operations used in the Network, Transport, Session and Presentation layers. This annex is modelled on ISO/TR 8509, making minimal changes to it, and defines the service conventions used in JTM.
This annex establishes definitions of terms and conventions for defining the services provided by JTM.
ISO 7498 : 1984,Information processing systems – Open Systems Interconnection – Basic Reference Model.
A.4.1 This annex builds on the concepts developed in ISO 7498 and makes use of the following terms defined in that standard:
A.4.2 For the purpose of this annex the following definitions also apply:
A.4.2.1 service-user: An abstract representation of an entity in a single system that makes use of a service; any one service user can be initiating a service, or can be responding to initiatives from the service provider as a result of earlier initiatives by some other service user or users.
A.4.2.2 service-provider: An abstract machine which models the behaviour of the totality of the entities providing the service, as viewed by a service-user.
A.4.2.3 layer service: A service provided by a layer of the Reference Model.
A.4.2.4 service primitive; primitive: An abstract, implementation-independent element of an interaction between a service-user and the provider.
A.4.2.5 request (primitive): A primitive issued by a service user to invoke a procedure (for a confirmed or non-confirmed service) by the service provider.
A.4.2.6 indication (primitive): A primitive issued by a service provider to invoke some procedure (for a confirmed or non-confirmed service) by a service user.
A.4.2.7 response (primitive): A primitive issued by a service user to complete the procedures associated with a confirmed service.
A.4.2.8 confirm (primitive): A primitive issued by a service-provider to complete the procedures associated with a confirmed service.
A.4.2.9 service element access point: The conceptual point at which interactions occur between the JTM service provider and a JTM agency.
The JTM service is defined in terms of an abstract model (see figure A.1) having the following elements:
Note that the use of the term "service users" for JTM does not imply the existence of a higher layer. It merely provides a convenient notation for describing the interactions with JTM agencies.
Each service-user interacts with the service provider by issuing or receiving service primitives. The service defines relations between interactions with one service user and consequential interactions with one or more other service-users.
The use of primitives does not preclude any specific implementation of a service in terms of interface primitives. The following comments apply to this definition technique based on service primitives:
Two types of service are identified:
The occurrence of a service primitive is a logically separate and indivisible event. The event occurs at a logically separate instant, which cannot be interrupted by another event.
A service primitive has a direction which is either
One or more parameters can be associated with a service primitive and each of these parameters has a defined range of values. Parameter values associated with a service primitive are passed in the direction of the service primitive.
The name of each service primitive contains three elements:
The occurrence of a group of service primitives is not a logically instantaneous and indivisible event. The intervals between the constituent service primitives can be non-disruptively interspersed with other service primitives.
A group of primitives which includes primitives mapping to the CCR primitives is called a commitment group, but is otherwise named as for a primitive, e.g.
J-INITIATE commitment-group
J-DISPOSE commitment-group
Time sequence diagrams indicate
Each diagram contains one or more vertical lines representing the interaction between the service provider and a service user (a service element access point); for the initiating or master (commitment) user, the left of the line represents the service user, and the right of the line the service provider; in the other cases the service provider is on the left of the line, and the service user on the right.
Arrows, placed in the areas representing the service-user, indicate the direction of propagation of the primitives. The angle of the arrow in the fields has no significance.
Necessary sequence relations between the interactions are indicated by a horizontal dashed line. Where no time-relationships exists, there will be no dashed line. In this case all the primitives for one interaction can occur following or before all those for some other interaction, or interleaved with them.
The dashed line can contain an arrow tail or an arrow head at each service element access point. All interactions above all arrow tails necessarily occur before any interactions beneath any arrow head.
The sequences in figure A.2 are all possible.
The sequences in figure A.3 are all possible; note that in the second case the service-provider takes responsibility for completion of the service, and verifies that some error reporting mechanism is available, typically involving a further indication to the same or a different service-user.
The following initials are used to indicate services provided by the layers of the OSI model:
F FTAM service;
J JTM service;
V VT service;
C CCR service;
A Other application-services;
P Presentation service;
S Session service;
T Transport service;
N Network service;
DL Data Link service;
Ph Physical service;
NOTE -- The use of N to signify the Network service is not to be confused with the use of (N) – to signify a particular but unspecified layer of the model.
A single word or a hyphenated word (usually consisting of the infinitive form of a verb) is used for the generic name e.g. INITIATE, DISPOSE, END-SIGNAL.
The specific name consists of one of the following (indicating the type of the primitive or a primitive group):
The initial is represented in the form given in A.8.1. The generic name is written in capital letters and the specific name is written in lower case letters.
The initial and the generic name are separated by a hyphen. The generic and specific names are separated by a space.
The following are examples of parameter names which use these conventions:
An enterprise can wish to establish a document type register for private use, or to register a document type in the ISO Register of Document Types.
This annex defines the information which is required by JTM for a Register Entry supporting document types carried by JTM.
The purpose of the entry is to provide
The document type is identified by an ASN.1 OBJECT DENTIFIER and by an ASN.1 ObjectDescriptor assigned according to the rules of ISO/IEC 8824.
The semantics which are standardised can be very complete, as is the case of document types defined to support JTM displays. For other document types, the semantics can be only partly standardised. An example of this is the "Simple ISO text document" document type (see ISO/IEC 8832) which is standardised only to the extent of saying that it consists of lines of graphic characters.
Document types with highly defined semantics can form a special case of documents with a lesser definition. In this case they could share the same transfer syntax.
The abstract syntax of a datatype supporting the transfer of the document type semantics is defined and named in accordance with the requirements of ISO 8822 for naming abstract syntaxes.
If communication is to be possible, there has to be agreement on the transfer syntax to be used for each type of document. This agreement can be bilateral, enterprise-specific, or expressed as an International Standard.
The register entry defines, either directly or by reference to encoding rules, the precise set of bits which are to be used to transfer the single presentation service data value (see ISO 8822) which is to carry the document semantics (for Basic Class transfers) and the precise sets of bits which are to be used to transfer the series of presentation service data values when extended implementations provide transfer.
NOTE -- Neither JTM nor the presentation service restricts the form of specification or encoding for abstract and transfer syntaxes, except that in Basic Class only a single set of bits are transferred for each document.
The transfer syntax for the document type is named in accordance with the requirements of ISO 8822for naming transfer syntaxes.
NOTE -- The above text has assumed a single abstract syntax name for all the data values used in forming a document type, and a single transfer syntax for that abstract syntax. This restriction is recommended, but is not required by JTM. The full generality of the presentation layer for using different abstract syntaxes for each data value, and for having embedded data values from different abstract syntaxes is available, as is the ability to select from a number of transfer syntaxes supporting each abstract syntax.
It is possible (but unlikely) for two totally different abstract syntaxes, and associated with totally different semantics, to produce identical bit patterns for transfer through the use of different encoding rules.
It is also possible (and more likely) for two totally different document types, with different semantics, to share a common abstract syntax.
Thus it is not possible, in general, to deduce the abstract syntax from the transfer syntax, nor to deduce the document semantics (the document type) from the abstract or transfer syntax.
Given a document type, however, it is possible to deduce (from the register entry), one or more possible abstract syntaxes, and from these to deduce one or more transfer syntaxes.
Correct interpretation of a received string of bits (transfer syntax) requires knowledge of the encoding rules which were used to generate the bits. Correct interpretation of an abstract syntax similarly requires knowledge of the semantics being carried.
The JTM protocol explicitly carries the document type name with each document, thus defining all standardised aspects of the semantics. The use of a particular transfer syntax, if there is more than one available, is negotiated using the Presentation Service.
The JTM protocol is defined using the abstract syntax notation ASN.1, but such a restriction is not imposed on document types.
Each document is carried as a separate presentation data value, and all problems of delimiting documents and octet alignment are resolved by the Presentation Service.
Each Register Entry contains the information defined in the following sub-clauses.
This is an ASN.1 OBJECT IDENTIFIER value and an ASN.1 ObjectDescriptor value.
The definition (either directly or by reference to another standard) of those parts of the total semantics which are standardised for this document type.
The definition (either directly or by reference to another standard) of one or more transfer syntaxes (possibly via one or more abstract syntaxes and encoding rules) which will support the document semantics.
Where multiple transfer syntaxes are specified then one of them is selected as a minimum implementation requirement for conforming systems which claim to support this document type.
Abstract and transfer syntax names to support the transfer of the document as one (for JTM Basic Class) or more (extended) presentation service data values (see ISO 8822).
A statement of which document types can be involved in the concatenation operation:
A concatenate B to give C
and the definition of the operation in each case.
NOTE -- The common case will be where A, B, and C are all the same document type.
Additional information can be needed if the document type is to be used in other protocols, but is not required by JTM.