Forward to Annex A : Management functions

Section 5 : JTM transfers

5.1 Application association control

This clause specifies the use of primitives concerned with application association control. For request and response primitives, the parameters shall be as specified in clause 5.2. For indication and confirm primitives, a check shall be made that parameters have values permitted by clause 5.2.

5.1.1 Notation

The procedures are specified by means of a state table that defines the interactions of the JTM application-association control procedures, the procedures for receipt and transmission of a work specification (see clauses 3.3 and 3.7), and the Association Control Service defined in ISO 8649.

5.1.1.1 Tables used

5.1.1.1.1 This clause (5.1) defines a single set of association control procedures by means of a state table. The state table shows the interrelationship between the state of the procedures, the incoming events that might occur in that state, the actions that shall be taken, and finally, the resultant state of the procedures.

5.1.1.1.2 This clause contains the following tables:

table 2 defines the abbreviated name and name/description of each incoming event;
table 3 defines the abbreviated name of each state;
table 4 defines the predicates;
table 5 defines the abbreviated name, and name/description of each outgoing event;
table 6 is the state table and uses the abbreviations of the above tables.

5.1.1.2 Conventions used in the state table (table 6)

5.1.1.2.1 The intersection of an incoming event (row) and a state (column) forms a cell.

5.1.1.2.2 In the state table, a blank cell represents the combination of an incoming event and a state that is not part of the normal operation of this protocol (see 5.1.1.3.2).

5.1.1.2.3 A non-blank cell represents an incoming event and state that is part of the normal operation of this protocol. Such a cell contains one or more action lists. An action list may be either mandatory or conditional. If a cell contains a mandatory action list, it is the only action list in the cell.

5.1.1.2.4 A mandatory action list contains

an outgoing event; and
a resultant state.

5.1.1.2.5 A conditional action list contains

a predicate expression comprising predicates and Boolean operators; and
a mandatory action list. (This mandatory action list is used only if the predicate expression is true.)

5.1.1.3 Actions to be taken

5.1.1.3.1 The state table specifies the action that shall be taken in terms of an outgoing event and the resultant state of the procedures.

5.1.1.3.2 Blank cells indicate an invalid intersection of an incoming event and state. If such an intersection occurs, one of the following actions is taken:

if the incoming event comes from the service-user, any action taken is a local matter, but shall not be externally visible and shall not affect the state of the application-association; (this is equivalent to saying that at the conceptual level such events do not occur);
if the incoming event is a presentation service event, the application association shall be aborted and all subsequent actions follow the rules of CCR.

5.1.1.3.3 If the intersection of the state and incoming event is not blank, one of the following actions is taken:

if the cell contains a single mandatory action list, the actions specified shall be taken;
if the cell contains one or more conditional action lists, for the first predicate expression that is true, the actions specified shall be taken, and the remaining action lists shall be ignored; if none of the predicate expressions are true, the actions shall be as defined in 5.1.1.3.2.

5.1.2 Procedures

Table 2 — Incoming events

Abbreviated Name	Name and/or Description
ASSOgetb	Identification of the need for an association establishment in "ISO JTM Basic Class Application-context", determined by MF16
ASSOgetf	Identification of the need for an association establishment in "ISO JTM Full Application-context", determined by MF16
ASSOrel	Decision to release an association, determined by MF16
A-ASSind	A-ASSOCIATE indication primitive
A-ASScnf+	A-ASSOCIATE confirm primitive (Result = "accepted")
A-ASScnf-	A-ASSOCIATE confirm primitive (Result = "rejected")
A-RELind	A-RELEASE indication primitive
A-RELcnf	A-RELEASE confirm primitive
A-ABOind	A-ABORT indication primitive
A-PABOind	A-P-ABORT indication primitive
TIME	Local implementation dependent timer to control the waiting states STA1 and STA2 (see MF10)
ABNORMAL	Any event not defined in ths standard shall be considered as a protocol violation,and handled as the ABNORMAL event

5.1.2.1 Table 2 lists the events incoming to the JTM application association control procedures, either from the procedures of clause 3.7, from management functions, or from the ACSE.

Table 3 — States of the procedures

Abbreviated Name	Description
STA0	no association
STA1b	awaiting an A-ASSOCIATE confirm (for Basic Class only)
STA1f	awaiting an A-ASSOCIATE confirm
STA2	awaiting an A-RELEASE confirm
STA3	association established

5.1.2.2 Table 3 lists the possible states of the JTM application control procedures.

Table 4 — Predicates

Code	Meaning
p1b	The check of the A-ASSOCIATE indication parameters according to clause 5.2 succeeded, and the Application-context name was {JTM application-context (1) basic (1)}
p1f	The check of the A-ASSOCIATE indication parameters according to clause 5.2 succeeded, and the Application-context name was {JTM application-context (1) full (2)}
p2b	The check of the A-ASSOCIATE confirm (Result = "accepted") parameters according to clause 5.2 succeeded, and the Application-context name was {JTM application-context (1) basic (1)}
p2f	The check of the A-ASSOCIATE confirm (Result = "accepted") parameters according to clause 5.2 succeeded, and the Application-context name was {JTM application-context (1) full (1)}
p3	The JTM procedures are within a CCR atomic action active on the association

5.1.2.3 Table 4 lists the predicates.

Table 5 — Outgoing events

Abbreviated Name	Name and/or Description
ASSOindb	Start of the procedures of clause 3.3 after successful establishment of an (incoming) application association in "ISO JTM Basic Class Application-context"
ASSOindf	Start of the procedures of clause 3.3 after successful establishment of an (incoming) application association in "ISO JTM Full Application-context"
ASSOcnfb+	Return to the procedures of clause 3.7 after successful establishment of an (outgoing) application association in "ISO JTM Basic Class Application-context" via MF16
ASSOcnff+	Return to the procedures of clause 3.7 after successful establishment of an (outgoing) application association in "ISO JTM Full Application-context" via MF16
ASSOcnf-	Return to the procedures of clause 3.7 (via MF16) if the establishment of an association failed. Error information is provided according to 5.1.3
A-ASSreqb	A-ASSOCIATE request primitive with parameters set as specified in clause 5.2, with Application-context name set to {JTM application-context (1) basic (1)}
A-ASSreqf	A-ASSOCIATE request primitive with parameters set as specified in clause 5.2, with Application-context name set to {JTM application-context (1) full (1)}
A-ASSrsp+	A-ASSOCIATE response primitive (Result = "accepted") with parameters set as specified in 5.2
A-ASSrsp-	A-ASSOCIATE response primitive (Result = "rejected ...") with parameters set as specified in 5.2
A-RELreq	A-RELEASE request primitive with parameters set as specified in clause 5.2
A-RELrsp	A-RELEASE response primitive with parameters set as specified in clause 5.2
A-ABOreq	A-ABORT request primitive with parameters set as specified in clause 5.2
CCRF	Communications or application failure as defined in ISO 8649 is signalled

5.1.2.4 Table 5 lists the events outgoing from the JTM application association control procedures to either the procedures of clause 3.3 or clause 3.7, or to the management functions, or to the ACSE.

5.1.2.5 The JTM application-association control procedures state table is given as table 6.

Table 6 — State/event table

State Event	STA0	STA1b	STA1f	STA2	STA3
ASSOgetb	A-ASSreqb STA1b
ASSOgetf	A-ASSreqf STA1f
ASSOrel					A-RELreq STA2
A-ASSind	p1b: A-ASSrsp+ ASSOindb STA3; p1f: A-ASSrsp+ ASSOindf STA3; not (p1b or p1f): A-ASSrsp- STA0
A-ASScnf+		p2b: ASSOcnfb+ STA3; not p2b: A-ABOreq ASSOcnf- (see 5.1.3.2) STA0	p2b: ASSOcnfb+ STA3; p2f: ASSOcnff+ STA3; not (p2b or p2f): A-ABOreq ASSOcnf- (see 5.1.3.2) STA0
A-ASScnf-		ASSOcnf- (see 5.1.3.1) STA0	ASSOcnf- (see 5.1.3.1) STA0
A-RELind					p3: CCRF A-ABOreq STA0; not p3: A-RELrsp STA0
A-RELcnf				STA0
A-ABOind		ASSOcnf- (see 5.1.3.3) STA0	ASSOcnf- (see 5.1.3.3) STA0	STA0	p3: CCRF STA0; not p3: STA0
A-PABOind		ASSOcnf- (see 5.1.3.3) STA0	ASSOcnf- (see 5.1.3.3) STA0	STA0	p3: CCRF STA0; not p3: STA0
TIME		A-ABOreq A-ASSOcnf- (see 5.1.3.4) STA0	A-ABOreq A-ASSOcnf- (see 5.1.3.4) STA0	A-ABOreq STA0
ABNORMAL				A-ABOreq STA0	p3: CCRF A-ABOreq STA0; not p3: A-ABOreq STA0

5.1.3 ASSOcnf-return codes

If an association is being established in order to perform the procedures for transmission of a work specification (see clause 3.7), (via MF16) and any failure occurs, then error information is provided by the ASSOcnf- event (see 5.1.2.4) in the form of return codes. These affect the behaviour of the main JTM procedures in clause 3.7.

5.1.3.1 If the establishment of an association is rejected by an A-ASSOCIATE confirm (Result = "rejected by ...") and the result is "rejected by responder (permanent)" or "rejected by presentation service provider (permanent)", then a NO-RETRY shall be returned with the JTM diagnostic code "sf-transmission-error" and human-readable text supplied by MF1. In all other cases of an A-ASSOCIATE confirm (Result = "rejected ...") a RETRY-LATER shall be returned.

5.1.3.2 If the establishment of an association succeeds by getting an A-ASOCIATE confirm (Result = "accepted"), but the check of the received parameters fails, then an A-ABORT shall be issued and the return code shall be as specified below, taking a) to c) in order of priority:

if the application context name is incorrect, then return RETRY-LATER; otherwise
if the presentation context definition result is incorrect, then return NO-RETRY with the JTM diagnostic code "sf-context-not-available" and human readable text set by MF2; otherwise
(in all other cases) return NO-RETRY with JTM diagnostic code "sf-transmission-error" and human-readable text set by MF1.

5.1.3.3 If waiting for the A-ASSOCIATE confirm is aborted by either an A-ABORT indication or an A-P-ABORT indication, than the return shall be RETRY-LATER.

5.1.3.4 If the event TIME (see table 2) occurs, the return code shall be RETRY-LATER.

5.2 Parameters in Association Control Service Primitives

5.2.1 Parameters in A-ASSOCIATE service primitives

5.2.1.1 Table 7 lists

the parameter values in an A-ASSOCIATE request that shall be set by the JTM initiator; and
the checks that shall be applied to the parameters in an A-ASSOCIATE indication by the JTM responder; and
the ACSE "result" value to be returned if the check fails.
the result value returned if the check succeeds (fixed for a Basic Class implementation).

Table 7 — Parameter values in A-ASSOCIATE request/indication

Parameters	Values in A-ASSOCIATE request primitive	Checks applied by the responder on an A-ASSOCIATE indication	ACSE "result" if check fails
Calling Appplication Entity Title	Set by MF2	MF26 is used to determine acceptability of the association	Rejected by responder (permanent) or (transient) as specified by MF26
Called Application Entity Title	The "JTM-name" from the target of the work specification to be transferred	Compare with the value provided by MF2 (Check fails if the parameter is absent)	Rejected by responder (AETitle not recognised)
Application-context name	If outgoing event is A-ASSreqb then {JTM application-context (1) basic (1)} otherwise {JTM application-context (1) full (2)}	Check this is either {JTM application-context (1) basic (1)} or {JTM application-context (1) full (2)}	Rejected by responder (application-context not supported)
User Information	Absent	All values accepted and ignored	Not applicable
Calling Presentation Address	Set by MF23	MF26 is used to determine the acceptability of the association	Rejected by responder (permanent)
Called Presentation Address	Set by MF16	All values accepted	Not applicable
Single Presentation Context	Absent	Must be absent	Rejected by Responder (permanent)
Presentation Context-Definition List	This shall be set to request the presentation contexts (in any order) for the abstract syntax names {jtm abstract-syntax (2)} and {iso-ccr abstract syntax (1)} (specified in ISO 9805) and for all abstract syntaxes (if any) required to transfer the document (if any) associated with the work specification whose transfer needs caused the application-association to be created. No other request shall be made	Must include contexts for {jtm abstract-syntax (2)} and {iso-ccr abstract-syntax (1)} and may include any others	Rejected by responder (permanent)
Presentation Context Definition Result	Not applicable	All values accepted	Not applicable
Default Presentation Context Name	Absent	Shall be missing	Rejected by responder (permanent)
Default Presentation Context Result	Not applicable	All values accepted	Not applicable
Quality of Service	The quality of service shall be set so as to require extended control, and such that: (i) the undetected error rate is acceptable to the enterprise; (ii) the frequency of provider-generated application-context aborts is comparable to the frequency of application failures NOTE — Aborting of the application-context causes retransmission of the entire work specification and all its documents in the Basic Class	Check extended control is requested, otherwise ignore the parameter	Rejected by responder (permanent)
Presentation requirements	Set to request no optional functional units (empty)	All values accepted	Not applicable
Session requirements	Set to request the functional units: � Duplex � Major synchronize � Minor synchronize � Resynchronize � Typed data	Check at least the following are present: Duplex Major synchronize Minor synchronize Resynchronize Typed data (Others are permitted)	Rejected by responder (permanent)
Initial Synchronization Point Serial Number	Set to zero	All values accepted	Not applicable
Initial Assignment of Tokens	Major/activity and minor tokens assigned to calling session service user. No other tokens used	Check major/activity and minor tokens assigned to initiator	Rejected by responder (permanent)
Session-connection identifier	Absent	All values accepted	Not applicable

5.2.1.2 All checks shall be applied. Where several reasons for rejection occur, the priority for inclusion in the response shall be

Rejected by responder (Application context not supported) (top priority);
Rejected by responder (AE title not recognised);
Rejected by responder (permanent);
Rejected by responder (transient) (lowest priority)

NOTE -- Rejected by responder (reason not specified) shall not used by a JTM implementation.

5.2.1.3 Table 8 lists

the parameter values in an A-ASSOCIATE response that shall be set by the JTM responder; and
the checks that shall be applied in an A-ASSOCIATE confirm (with result = "accept") by the JTM initiator.
the result value returned if the check succeeds (fixed for a Basic Class implementation)
NOTE -- 5.1.3.2 specifies the issue of an A-ABORT request when these checks fail.

Table 8 — Parameter values in A-ASSOCIATE response/confirm

Parameter	Values in the A-ASSOCIATE response	Check applied by initiator on an A-ASSOCIATE confirm in case result is ACCEPT
Responding Application Entity Title	Absent	All values accepted
Application Context Name	If the implementation is Basic Class then {jtm application-context (1) basic (1)} otherwise Return the value in the indication	If state is STA1b then must equal {jtm application-context (1) basic (1) } otherwise must be either {jtm application-context (1) basic (1) } or {jtm application-context (1) full (2) }
User Information	Absent	All values accepted
Result	If any check of the request parameters failed, reject as specified, in priority order, otherwise accept (see 5.2.1.2)	See clause 5.1
Responding Presentation Address	Absent	All values accepted
Presentation Context Definition Result List	Accept all contexts which can be supported	Check that all values are "ACCEPTED"
Default Presentation Context Result	Reject if any context is present	All values accepted
Quality of Service	Return the value in the indication	Check that extended control is available
Presentation requirements	Remove all function units	All values accepted
Session requirements	Remove all functional units except Duplex, Major synchronize, Minor synchronize, Resynchronize, and Typed Data	Check Duplex, Major synchronize, Minor synchronize, Resynchronize, and Typed Data are available
Initial Synchronization point serial number	Set to zero	All values accepted
Initial assignment of tokens	Major/activity and minor tokens assigned to initiator	All values accepted
Session connection identifier	Absent	All values accepted

5.2.2 Parameters in A-RELEASE service primitives

Table 9 lists the parameter values in an A-RELEASE request that shall be set by the JTM initiator.

The JTM responder shall accept all values.

Table 9 — A-RELEASE request/indication parameters

Parameter	Value set by initiator
Reason	Set to normal
User Information	Absent

Table 10 lists the values in an A-RELEASE response that shall be set b y the JTM responder. The JTM initiator shall accept all values.

Table 10 — A-RELEASE response/confirm parameters

5.3 P-service parameters

The only P-service primitive directly issued by JTM is P-DATA, with datavalues in JTM presentation-context or in the presentation-context(s) specified by a document type definition.

NOTE -- Other P-service primitives are issued indirectly through the use of CCR service primitives or during establishment of a suitable application-association.

5.3.1 Parameter of P-DATA

The user data parameter of P-DATA in "ISO JTM Basic Class Application-context" is described in 5.3.1.1. The user data parameter of P-DATA in "ISO JTM Full Application-context" is described in 5.3.1.2.

5.3.1.1 The user data parameter of P-DATA shall contain at least one presentation data value. The first shall be the value of a Transfer Element, and the remainder (if present) shall be the values of a complete document forming part of the work specification being transferred, as specified in the document type definition.

NOTE -- In JTM Basic Class only a single document can be transferred, so issues of document delimitation do not arise. Moreover, all datavalues required to transfer the document are carried on a single P-DATA.

5.3.1.2 The user data parameter of each P-DATA shall contain at least one presentation data value. The first value on the first P-DATA shall be the value of a Transfer Element. Any subsequent values, if present, which can be on the same or different P-DATA, at the sender's option, shall be values comprising documents forming part of the work specification, or shall be Document Separators between the documents.

5.3.2 Interruption of P-DATA

Issue of a P-DATA request followed by a C-ROLLBACK request may (architecturally) cause loss of the corresponding P-DATA indication. In implementation terms, the transfer of data related to a P-DATA request and indication can take a very long time; at any time during that transfer, the data flow may be interrupted by a C-ROLLBACK (or A-P-ABORT). Such an interruption is seen architecturally as loss of the P-DATA indication.

5.4 C-service parameters

5.4.1 C-BEGIN and J-BEGIN request and indication

5.4.1.1 Master's name

The master's name shall be set to a "JTM-name" allocated to the application-entity containing the JTM ASE if the JTM ASE or one of its agencies is the commitment master, otherwise it shall be the value provided by the superior as specified in ISO/IEC 9804 (CCR Service).

5.4.1.2 Atomic action suffix

This shall unambiguously identify the atomic action within all atomic actions for which the same master's name is used if the JTM ASE or one of its agencies is the commitment master, otherwise it shall be the value provided by the superior as specified in ISO/IEC 9804 (CCR Service).

5.4.1.3 Superior's name

This shall be the local "JTM-name" used in the establishment of the application-association (MF2).

5.4.1.4 Branch suffix

This shall unambiguously identify this branch of the atomic action within all branches with the same master's name, atomic action suffix, and superior's name.

5.4.1.5 User data - commitment level

This shall be set to 1 (PROVIDER ACCEPTANCE) for all atomic actions for which the JTM ASE or any of its agencies is the master, except that the J-INITIATE atomic action may specify a value of 1 (PROVIDER ACCEPTANCE) or 2 (AGENCY ACCEPTANCE) or, except when the J-INITIATE is used in a Basic Class implementation, 3 (COMPLETION).

When the JTM ASE is a subordinate, the commitment level shall be set to the value specified by the superior.

If a commitment level in excess of 2 is requested in a C-BEGIN indication received by a Basic Class implementation over a connection from another JTM ASE, it shall be rejected as specified in 3.3.8.1 b).

5.4.1.6 User data - diagnostic code indicator

This parameter shall be set as specified in the body of this International Standard.

5.4.2 C-READY and J-READY request and indication

5.4.2.1 User data - commitment level

A commitment level of 3 (COMPLETION) shall be given if the activity is completed and all resources released.

A commitment level of 2 (AGENCY ACCEPTANCE) shall be given if the agency has secured the material, signalling completion with J-END-SIGNAL at a later time.

A commitment level of 1 (PROVIDER ACCEPTANCE) shall be given if the work specification has not progressed to AGENCY ACCEPTANCE.

The commitment level on the C-READY request shall equal or exceed that on the C-BEGIN indication.

5.4.2.2 User data - warnings

The setting of the warnings parameter shall be as specified in the body of this International Standard.

5.4.2.3 User data - accounting information

This shall be absent when the request is issued at a Basic Class implementation and shall be ignored when an indication is issued at a Basic Class implementation.

When the request is issued at an extended implementation, other than a request issued by a JTM ASE to an initiation agency or to an execution agency following J-END-SIGNAL, the accounting information shall be a SET OF "Charging-information" including any "Charging-information" values received in the accounting information received in J-READY, C-READY, J-ROLLBACK or C-ROLLBACK indications from subordinates in the atomic action together with any "Charging-information" values generated by the implementation relating to charges incurred at the implementation in the processing of the atomic action.

When the request is issued by a JTM ASE to an initiation agency or to an execution agency following J-END-SIGNAL, the accounting information shall be absent.

NOTE -- Any "Charging-information" received in these cases will be placed in accounting-data reports (if these are selected) by the procedures of 3.2.10 or 3.13.3.

When the indication is issued at an extended implementation, the accounting information shall either be absent or shall be a SET OF "Charging-information".

5.4.3 C-ROLLBACK and J-ROLLBACK request and indication

5.4.3.1 User data - diagnostic

The "code" and "reason" shall be set as specified throughout this International Standard. The "generator" shall be set to one of the "JTM-name"s assigned to the application-entity containing the JTM ASE. Where the JTM ASE is a submaster, the diagnostics provided by the subordinates shall be passed to the superior unchanged.

5.4.3.2 User data - accounting information

This shall be absent when the request is issued at a Basic Class implementation and shall be ignored when an indication is issued at a Basic Class implementation.

When the request is issued by a JTM ASE to an initiation agency or to an execution agency following J-END-SIGNAL, the accounting information shall be absent.

NOTE -- Any "Charging-information" received in these cases will be placed in accounting-data reports (if these are selected) by the procedures of 3.2.10 or 3.13.3.

When the indication is issued at an extended implementation, the accounting information shall either be absent or shall be a SET OF "Charging-information".

5.4.4 C-RECOVER and J-RECOVER

This shall be used as specified in ISO/IEC 9804 (CCR Service) no further requirements are added by this Standard. 263 done

Parameter	Value set by initiator
Reason	Set to normal
User Information	Absent
Result	Set to "affirmative"