Recommendation X.217
ASSOCIATION CONTROL SERVICE DEFINITION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS 
(Melbourne, 1988) 
	The CCITT,
considering
	(a) 	that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT Applications;
	(b) 	that Recommendation X.210 defines the Open System Interconnection (OSI) Layer Service Definition Conventions;
	(c) 	that Recommendation X.215 defines the Session Service Definition for Open Systems Interconnection for CCITT Applications;
	(d) 	that Recommendation X.216 defines the Presentation Service Definition of Open Systems Interconnection for CCITT Applications;
	(e) that Recommendation X.220 specifies the use of X.200 series protocols in CCITT Applications;
	( f)	that Recommendation X.227 specifies the Association Control Protocol Specification for Open Systems interconnection for CCITT Applications;
	(g)	that Recommendation X.410-1984 specifies the protocol for Remote Operation and Reliable Transfer Server for Message Handling Systems; and
	(h)	that there is a need for common Association Control to support various applications,
unanimously declares
	that this Recommendation defines the Association Control Service of Open Systems Interconnection for CCITT Applications as given in the Scope and Field of Application.
CONTENTS 
0 	Introduction
1 	Scope and field of application
2 	References
3 	Definitions
	3.1 	Reference model definitions
	3.2 	Naming and addressing definitions
	3.3 	Service conventions definitions
	3.4 	Presentation service definitions
	3.5 	ACSE service definitions
4 	Abbreviations
5 	Conventions
6 	Basic concepts
7 	Service overview
8 	Relationship with other ASEs and lower layer services
	8.1 	Other application-service-elements
	8.2 	Presentation-service
	8.3 	Session-service
9 	Service definition
	9.1 	A-ASSOCIATE service
	9.2 	A-RELEASE service
	9.3 	A-ABORT service
	9.4 	A-P-ABORT service
10 	Sequencing Information
	10.1 	A-ASSOCIATE
	10.2 	A-RELEASE
	10.3 	A-ABORT
	10.4 	A-P-ABORT
Annex A - Usage of ACSE services to achieve compatibility with CCITT Recommendation X.410-1984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations
	A.1 	Compatibility requirements
	A.2 	Principles for ensuring compatibility
	A.3 	Usage of Association Control services to ensure compatibility with X.410-1984
	A.3.1 	A-ASSOCIATE
	A.3.2 	A-RELEASE
	A.3.3 	A-ABORT
	A.3.4 	A-P-ABORT
	A.3.5 	State Table
Appendix I - Differences between Recommendation X.217 and ISO International Standard 8649.
0 	Introduction
0.1 	This Recommendation is one of a set of Recommendations produced to facilitate the interconnection of information processing systems. It is related to other Recommendations in the set as defined by the Reference Model for Open Systems Interconnection (X.200). The reference model subdivides the area of standardization for interconnection into a series of layers of specification, each of manageable size.
0.2 	The goal of Open Systems Interconnection is to allow, with a minimum of technical agreement outside the inter-connection recommendations, the interconnection of information processing systems:
	- 	from different manufacturers;
	- 	under different managements;
	- 	of different levels of complexity; and
	- 	of different technologies.
0.3 	This Recommendation recognizes that application-processes may wish to communicate with each other for a wide variety of reasons. However, any communication will require the performance of certain services independent of the reasons for communication. The application-service-element defined herein provides such services.
0.4 	This Recommendation defines services provided by the application service element for application-association control: the Association Control Service Element (ACSE). The ACSE provides basic facilities for the control of an application-association between two application-entities which communicate by means of a presentation-connection. 
0.5 	The use of services defined in this Recommendation is also governed by the use of the presentation-service (X.216) and the session-service (X.215).
0.6 	It is recognized that, with respect to ACSE Quality of Services (QOS), described in § 9, work is still in progress to provide an integrated treatment of QOS across all layers of the OSI Reference Model, and to ensure that the individual treatments in each layer service satisfy overall QOS objectives in a consistent manner. As a consequence, a change may be made to this Recommendation at a later time which reflects further QOS developments and integration.
1 	Scope and field of application
	This Recommendation defines ACSE services for application-association control in an open systems interconnection environment. The ACSE services are provided by the use of the ACSE protocol (X.227) in conjunction with the presentation-service (X.216). The ACSE services assume as a minimum the use of the presentation-service Kernel functional unit.
	This Recommendation does not specify individual implementations or products nor does it constrain the implementation of entities and interfaces within a computer system.
	No requirement is made for conformance to this Recommendation.
2 	References
Recommendation X.200 	Reference Model of Open Systems Interconnection for CCITT applications. (See also ISO 7498-1)
Recommendation X.210 		OSI layer service definition conventions. (See also ISO TR8509)
Recommendation X.215	Session service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8326 and ISO 8326 Addendum 2).
Recommendation X.216 	Presentation service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8822).
Recommendation X.225 	Session protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8327 and ISO 8327 Addendum 2).
Recommendation X.227	Association Control protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8650).
Recommendation X.410-1984 	CCITT Recommendation X.410: Message Handling Systems: Remote Operation and Reliable Transfer Server.
ISO 7498-3 				Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 3: Naming and Addressing.
3 	Definitions
3.1 	Reference model definitions
This Recommendation is based on the concepts developed in X.200 and makes use of the following terms defined in it:
	a) 	Application Layer;
	b) 	application-process;
	c) 	application-entity;
	d) 	application-service-element;
	e) 	application-protocol-data-unit;
	f ) 	application-protocol-control-information;
	g) 	presentation-service;
	h) 	presentation-connection;
	i) 	session-service;
	j ) 	session-protocol;
	k) 	session-connection.
3.2 	Naming and addressing definitions
	This Recommendation makes use of the following terms defined in ISO 7498-3;
	a) 	application-process title;
	b) 	application-entity qualifier;
	c) 	application-entity title; 
	d) 	application-process invocation-identifier;
	e) 	application-entity invocation-identifier; and
	f ) 	presentation address.
3.3 	Service conventions definitions
	This Recommendation makes use of the following terms defined in X.210:
	a) 	service-provider;
	b) 	service-user;
	c) 	confirmed service;
	d) 	non-confirmed service;
	e) 	provider-initiated service;
	f ) 	primitive;
	g) 	request (primitive);
	h) 	indication (primitive);
	i) 	response (primitive); and
	j ) 	confirm (primitive).
3.4 	Presentation service definitions
	This Recommendation makes use of the following terms defined in Recommendation X.216:
	a) 	abstract syntax;
	b) 	abstract syntax name;
	c) 	default context;
	d) 	defined context set;
	e) 	functional unit [presentation];
	f ) 	normal mode [presentation];
	g) 	presentation context;
	h) 	presentation data value; and
	i) 	X.410-1984 mode [presentation].
3.5 	ACSE service definitions
	For the purpose of this Recommendation, the following definitions apply:
3.5.1 	application-association; association
	A cooperative relationship between two application-entities, formed by their exchange of application-protocol-control-information through their use of presentation-services.
3.5.2 	application context
	An explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on an application-association.
	Note - This definition is subject to refinement as a result of ongoing work in the area of the Application Layer structure.
3.5.3 	Association Control Service Element
	The particular application-service-element defined in this Recommendation.
3.5.4 	ACSE service-user
	The part of the application-entity which makes use of ACSE services.
3.5.5 	ACSE service-provider
	An abstraction of the totality of those entities which provide ACSE services to peer ACSE service-users.
3.5.6 	requestor
	The ACSE service-user which issues the request primitive for a particular ACSE service. For a confirmed service, it also receives the confirm primitive.
3.5.7 	acceptor
	The ACSE service-user which receives the indication primitive for a particular ACSE service. For a confirmed service, it also issues the response primitive.
3.5.8 	association-initiator
	The ACSE service-user which initiates a particular association, i.e. the requestor of the A-ASSOCIATE service which establishes the association.
3.5.9 	association-responder
	The ACSE service-user which is not the initiator of a particular association, i.e. the acceptor of the A-ASSOCIATE service which establishes the association.
3.5.10 	normal mode
	The mode of ACSE operation which results in the transfer of ACSE semantics, using the presentation-service.
3.5.11 	X.410-1984 mode
	The mode of ACSE operation which allows ACSE service-users to interwork using the protocol specified in CCITT Recommendation X.410-1984. The use of this mode results in no transfer of ACSE semantics.
3.5.12 	disrupt
	A service procedure is disrupted by another service procedure if the second service results in service primitives not being used as specified for the procedure of the first service.
4 	Abbreviations
	The following abbreviations are used in this Recommendation.
	ACSE 	Association Control Service Element
	AE 		application-entity
	ASE 	application-service-element
	OSI 		Open Systems Interconnection
	QOS 	Quality of Service
5 	Conventions
5.1 	This Recommendation defines services for the ACSE following the descriptive conventions defined in Recommendation X.210. In § 9, the definition of each ACSE service includes a table which lists the parameters of its primitives. For a given primitive, the presence of each parameter is described by one of the following values.
	blank 	not applicable
	C 		conditional
	M 		mandatory
	P 		subject to conditions defined in X.216
	U 		user option
5.2 	In addition, the notation (=) indicates that a parameter value is semantically equal to the value to its left in the table.
6 	Basic concepts
6.1 	The reference model (X.200) represents communication between a pair of application-processes (APs) in terms of communication between their application-entities (AEs) using the presentation-service. The functionality of an AE is factored into a number of application-service-elements (ASEs). The interaction between AEs is described in terms of the use of their ASEs' services.
6.2 	This Recommendation introduces the additional modelling concepts of application-association and application context.
6.3 	An application-association is a cooperative relationship between two AEs. It provides the necessary frame of reference between the AEs in order that they may interwork effectively. This relationship is formed by the exchange of application-protocol-control-information between the application-entities through their use of presentation-services.
6.4 An application context is an explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on an application association.
7 	Service overview
7.1 	This Recommendation defines the following services for the control of a single association
	a) 	A-ASSOCIATE;
	b) 	A-RELEASE;
	c) 	A-ABORT; and
	d) 	A-P-ABORT.
7.2 	The A-ASSOCIATE service causes the start of use of an association by those ASE procedures identified by the value of Application Context Name parameter.
	Note - The use of an association by several ASEs is the subject of ongoing work.
7.3 	The A-RELEASE service, if successful, causes the completion of the use of an association by those ASE procedures identified by the application context which is in effect without loss of information in transit. However, the success of the A-RELEASE service optionally may be negotiated.
7.4 	The A-ABORT service causes the abnormal release of the association with the possible loss of information in transit.
7.5 	The A-P-ABORT service indicates the abnormal release of the association as a result of action by the underlying presentation-service with the possible loss of information in transit.
7.6 	For a particular association, the ACSE service operate in one of the following modes:
	a) 	normal mode; or
	b) 	X.410-1984 mode.
7.7 	The normal mode of operation allows the ACSE service-user to take full advantage of the functionality provided by both ACSE and the presentation-service (X.216). In this mode the ACSE service-provider transfers its semantics using the normal mode of the presentation-service.
7.8 	The X.410-1984 mode of operation allows the ACSE service-user to interwork with a peer using the protocol specified by the CCITT Recommendation X.410-1984. In this mode, the ACSE service-provider does not transfer any semantics of its own and uses the X.410-1984 mode of the presentation-service.
8 	Relationship with other ASEs and lower layer services
8.1 	Other application-service-elements
8.1.1 	The ACSE is intended to be used with other ASEs in order to support a specific information processing task. Therefore, it is expected that the ACSE will be included in all application context specifications.
8.1.2 	The collection of the ACSE and other ASE(s) included in an application context are required to use the facilities of the presentation-service in a coordinated manner.
8.2 	Presentation-service
8.2.1 	A one-to-one correspondence exists between an application-association and a presentation-connection.
8.2.2 	The ACSE services require access to the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services. The ACSE services neither use nor constrain the use of any other presentation service.
8.2.3 	The requestor and acceptor of the A-ASSOCIATE service determine the mode, the default presentation context, and the initial defined context set of the underlying presentation-connection using the following A-ASSOCIATE parameter:
	- Mode;
	- Presentation Requirements;
	- Presentation Context Definition List;
	- Presentation Context Definition Result List;
	- Default Presentation Context Name; and
	- Default Presentation Context Result.
8.2.4 	If the requestor specifies the value »normal« for the Mode parameter, the last five parameters above determine the presentation context facility for the association according to the rules for the normal mode of the presentation-service (X.216). At the conclusion of the A-ASSOCIATE procedure, the requestor and acceptor must have obtained a presentation context which supports the abstract syntax specified in X.227 for the ACSE application-protocol-data-units.
	Note - The ACSE service-provider is aware of the presentation context which contains its abstract syntax by a local mechanism.
8.2.5 	If the requestor specifies the value »X.410-1984« for the Mode parameter, the ACSE service-provider does not transfer ACSE semantics and therefore does not require a presentation context for its abstract syntax. Any user information which the ACSE service-provider transfers for its service-user uses the unnamed default presentation context for the X.410-1984 mode of the presentation-service (X.216).
	Note - Table 2/X.217 indicates the A-ASSOCIATE service parameters which are not used in the X.410-1984 mode. None of the presentation context related parameters are used.
8.3 	Session-service
8.3.1 	Using the Session Requirements parameter, the A-ASSOCIATE service requestor and acceptor determine the functional units for the underlying session-service (X.215).
8.3.2 	The rules and parameter value length restrictions of the underlying session-service affect ACSE services. The ACSE service-user must be aware of these constraints.
	Note - Some examples of these constraints are:
	a) 	Version 1 of the session-protocol (X.225) imposes user data length restrictions which affect ACSE primitive parameters. Some special considerations apply to the A-ABORT services (see § 9.3).
	b)	The choice of session functional units for a particular association affects the rules for the use of ACSE services. For example, the selection of session tokens controls the possibilities of negotiated release and release collisions.
9 	Service definition
	The ACSE services are listed in Table 1/X.217.
TABLE 1/X.217
ACSE-services
Service	Type	
A-ASSOCIATE	Confirmed	
A-RELEASE	Confirmed	
A-ABORT	Non-confirmed	
A-P-ABORT	Provider-initiated	
9.1 	A-ASSOCIATE Service
	The A-ASSOCIATE service is used to cause the beginning of the use of an association; it is a confirmed service.
9.1.1 	A-ASSOCIATE Parameters
	Table 2/X.217 lists the A-ASSOCIATE service parameters. In addition, groups of parameters are defined for reference by other ASEs as follows:
	a) 	Calling AE Title is the composite of the Calling AP Title and the Calling AE Qualifier parameters;
	b) 	Called AE Title is the composite of the Called AP Title and the Called AE Qualifier parameters;
	c) 	Responding AE Title is the composite of the Responding AP Title and the Responding AE Qualifier parameters;
	The two components of the AE title (AP title and AE qualifier) are defined in ISO 7498-3.
Table 2/X.217 [T2.217], p. 
TABLE 2/X.217
A-ASSOCIATE parameters
Parameter name 	Request 	Indication 	Response 	Confirmation 	
Mode 	U 	M (=) 			
Application context name a) 	M 	M (=) 	M 	M (=) 	
Calling AP title a) 	U 	C (=) 			
Calling AE qualifier a) 	U 	C (=)			
Calling AP invocation-identifier a) 	U 	C (=) 			
Calling AE invocation-identifier a) 	U 	C (=) 			
Called AP title a) 	U 	C (=) 			
Called AE qualifier a) 	U 	C (=) 			
Called AP invocation-identifier a)	U	C (=) 			
Called AE invocation-identifier a)	U	C (=) 			
Responding AP title a)	U	C (=) 			
Responding AE qualifier a)	U	C (=) 			
Responding AP invocation-identifier a)	U	C (=) 			
Responding AE invocation-identifier a)	U	C (=) 			
User information 	U 	C (=) 	U 	C (=) 	
Result 			M 	M (=) 	
Result source 				M 	
Diagnostic a)	U	C (=) 			
Calling presentation address 	P 	P 			
Called presentation address 	P 	P 			
Responding presentation address 			P 	P 	
Presentation context definition list a) 	P 	P 			
Presentation context definition result list a) 		P 	P 	P 	
Default presentation context name a) 	P 	P 			
Default presentation context result a) 			P 	P 	
Quality of service 	P 	P 	P 	P 	
Presentation requirements a) 	P 	P 	P 	P 	
Session requirements 	P 	P 	P 	P 	
Initial synchronization point serial number 	P 	P 	P 	P 	
Initial assignment of tokens 	P 	P 	P 	P 	
Session-connection identifier a) 	P 	P 	P 	P 	
a) Not used in X.410-1984 mode.

9.1.1.1 Mode
	This parameter specifies the mode in which the ACSE services will operate for this association. It takes one of the following symbolic values:
	- normal; or
	- X.410-1984.
	If this parameter is not included on the request primitive, the default value of »normal« is used by the ACSE service provider. This parameter is always present on the indication primitive.
9.1.1.2 	Application Context Name
	This parameter identifies the application context proposed by the requestor. The acceptor returns either the same or a different name. The returned name specifies the application context to be used for this association.
	Note - The offer of an alternate application context by the acceptor provides a possible mechanism for limited negotiation. However, the semantics and rules for this exchange are entirely user specific. If the requestor cannot operate in the acceptor's application context, it may issue an A-ABORT request primitive.
9.1.1.3 	Calling AP Title
	This parameter identifies the AP which contains the requestor of the A-ASSOCIATE service.
9.1.1.4 	Calling AE Qualifier
	This parameter identifies the particular AE of the AP which contains the requestor of the A-ASSOCIATE service.
9.1.1.5 	Calling AP Invocation-identifier
	This parameter identifies the AP invocation which contains the requestor of the A-ASSOCIATE service.
9.1.1.6 	Calling AE Invocation-identifier
	This parameter identifies the AE invocation which contains the requestor of the A-ASSOCIATE service.
9.1.1.7 	Called AP Title
	This parameter identifies the AP which contains the intended acceptor of the A-ASSOCIATE service.
9.1.1.8 	Called AE Qualifier
	This parameter identifies the particular AE of the AP which contains the intended acceptor of the A-ASSOCIATE service.
9.1.1.9 	Called AP Invocation-identifier
	This parameter identifies the AP invocation which contains the intended acceptor of the A-ASSOCIATE service.
9.1.1.10 	Called AE Invocation-identifier
	This parameter identifies the AE invocation which contains the intended acceptor of the A-ASSOCIATE service.
9.1.1.11 	Responding AP Title
	This parameter identifies the AP which contains the actual acceptor of the A-ASSOCIATE service.
9.1.1.12 	Responding AE Qualifier
	This parameter identifies the particular AE of the AP which contains the actual acceptor of the A-ASSOCIATE service.
9.1.1.13 	Responding AP Invocation-identifier
	This parameter identifies the AP invocation which contains the actual acceptor of the A-ASSOCIATE service.
9.1.1.14 	Responding AE Invocation-identifier
	This parameter identifies the AE invocation which contains the actual acceptor of the A-ASSOCIATE service.
9.1.1.15 	User Information
	Either the requestor or the acceptor may optionally include user information. Its meaning depends on the application context which accompanies the primitive.
	Note - For example, this parameter may be used to carry the initialization information of other ASEs included in the application context specified by the value of the accompanying Application Context Name parameter.
9.1.1.16 	Result
	This parameter is provided by either the acceptor, by the ACSE service-provider, or by the presentation service-provider. It indicates the result of using the A-ASSOCIATE service. It takes one of the following symbolic values:
	- accepted;
	- rejected (permanent); or
	- rejected (transient).
9.1.1.17 	Result Source
	The value of the parameter is supplied by the ACSE service-provider. It identifies the creating source of the Result parameter and the Diagnostic parameter, if present. It takes one of the following symbolic values:
	- ACSE service-user;
	- ACSE service-provider; or
	- presentation service-provider.
	If the Result parameter has the value »accepted«, the value of this parameter is »ACSE service-user«.
9.1.1.18 	Diagnostic
	This parameter is only used if the Result parameter has the value of »rejected (permanent)« or »rejected (transient)«. Optionally, it can be used to provide diagnostic information about the result of the A-ASSOCIATE service. 
	If the Result Source parameter has the value »ACSE service-provider«, it takes one of the following symbolic values:
	- no reason given; or
	- no common ACSE version.
	If the Result Source parameter has the value »ACSE service-user«, it takes one of the following symbolic values:
	- no reason given;
	- application context name not supported;
	- calling AP title not recognized;
	- calling AE qualifier not recognized;
	- calling AP invocation-identifier not recognized;
	- calling AE invocation-identifier not recognized;
	- called AP title not recognized;
	- called AE qualifier not recognized;
	- called AP invocation-identifier not recognized; or
	- called AE invocation-identifier not recognized.
9.1.1.19 	Calling Presentation Address
	This parameter is as defined in Recommendation X.216.
9.1.1.20 	Called Presentation Address
	This parameter is as defined in Recommendation X.216.
9.1.1.21 	Responding Presentation Address
	This parameter is as defined in Recommendation X.216.
9.1.1.22 	Presentation Context Definition List
	This parameter is as defined in Recommendation X.216.
9.1.1.23 	Presentation Context Definition Result List
	This parameter is as defined in Recommendation X.216.
9.1.1.24 	Default Presentation Context Name
	This parameter corresponds to the Default Context Name parameter defined in Recommendation X.216.
9.1.1.25 	Default Presentation Context Result
	This parameter corresponds to the Default Context Result parameter defined in Recommendation X.216.
9.1.1.26 	Quality of Service
	This parameter is as defined in Recommendation X.216.
9.1.1.27 	Presentation Requirements
	This parameter is as defined in Recommendation X.216.
9.1.1.28 	Session Requirements
	This parameter is as defined in Recommendation X.216.
9.1.1.29 	Initial Synchronization Point Serial Number
	This parameter is as defined in Recommendation X.216.
9.1.1.30 	Initial Assignment of Tokens
	This parameter is as defined in Recommendation X.216.
9.1.1.31 	Session Connection Identifier
	This parameter is as defined in Recommendation X.216.
9.1.2 	A-ASSOCIATE service procedure
9.1.2.1 	The A-ASSOCIATE service procedure has a one-to-one correspondence with the P-CONNECT service defined in Recommendation X.216. When the A-ASSOCIATE service is used, the association is created simultaneously with the creation of the underlying presentation-connection.
9.1.2.2 	An ACSE service-user which desires to establish an association issues an A-ASSOCIATE request primitive. The called AE is identified by parameters of the request primitive. The requestor cannot issue any primitives except an A-ABORT request primitive until it receives an A-ASSOCIATE confirm primitive.
9.1.2.3 	The ACSE service-provider issues an A-ASSOCIATE indication primitive to the acceptor.
9.1.2.4 	The acceptor accepts or rejects the association by sending an A-ASSOCIATE response primitive with an appropriate Result parameter. ACSE service-provider issues an A-ASSOCIATE confirm primitive having the same Result parameter. The Result Source parameter is assigned the symbolic value of »ACSE service-user«.
9.1.2.5 	If the acceptor accepts the association, the association is available for use. Requestors in both AEs may now use any service provided by the ASEs included in the application context which in effect (with the exception of A-ASSOCIATE).
9.1.2.6 	If the acceptor rejects the association, the association is not established.
9.1.2.7 	The ACSE service-provider may not be capable of supporting the requested association. In this situation, it returns an A-ASSOCIATE confirm primitive to the requestor with an appropriate RESULT parameter. The Result Source parameter is appropriately assigned either the symbolic value of »ACSE service-provider« or »presentation service-provider«. The indication primitive is not issued. The association is not established.
9.1.2.8 	A requestor in either AE may disrupt the A-ASSOCIATE service procedure by issuing an A-ABORT request primitive. The acceptor receives an A-ABORT indication primitive. The association is not established.
9.2 	A-Release service
	The A-RELEASE service is used by a requestor in either AE to cause the completion of the use of an association; it is a confirmed service. If the session Negotiated Release functional unit was selected for the association, the acceptor may respond negatively (see § 8.3.2). This causes the unsuccessful completion of the A-RELEASE service and the continuation of the association without loss of information in transit.
9.2.1 	A-RELEASE parameters
	Table 3/X.217 lists the A-RELEASE parameters.
TABLE 3/X.217
A-RELEASE parameters
Parameter name 	Request 	Indication 	Response 	Confirmation 	
Reason a)	U	C (=) 	U 	C (=) 	
User information a)	U	C (=) 	U 	C (=) 	
Result 			M 	M (=) 	
a) Not used in X.410-1984 mode.

9.2.1.1 	Reason
	When used on the request primitive, this parameter identifies the general level of urgency of the request. It takes one of the following symbolic values:
	- normal;
	- urgent; or
	- user defined.
	Note - For example, if the session Negotiated Release functional unit was selected for the association, the value »urgent« may be used on the request primitive when the requestor desires to urgently release the association.
	When used on the response primitive, this parameter identifies information about why the acceptor accepted or rejected the release request. It takes one of the following symbolic values:
	- normal;
	- not finished; or
	- user defined.
	Note - For example, if the session Negotiated Release functional unit was not selected for the association, the value »not finished« may be used on the response primitive when the acceptor is forced to release the association but wishes to give a warning that it has additional information to send or receive.
9.2.1.2 	User information
	Either the requestor or acceptor may optionally include user information on the request or response primitive. Its meaning depends on the application context which is in effect.
9.2.1.3 	Result
	This parameter is used by the acceptor to indicate if the request to release the association normally is acceptable. It takes one of the following symbolic values:
	- affirmative; or
	- negative.
9.2.2 	A-RELEASE service procedure
9.2.2.1 	The A-RELEASE service procedure has a one-to-one correspondence with the P-RELEASE service defined in Recommendation X.216. When the A-RELEASE service is used, the association is released simultaneously with the release of the underlying presentation-connection.
9.2.2.2 	An ACSE service-user which desires to release the association issues an A-RELEASE request primitive. This requestor cannot issue any further primitives other than an A-ABORT request primitive until it receives an A-RELEASE confirm primitive.
9.2.2.3 	In order to issue an A-RELEASE request primitive, the requestor is required to meet all the requirements for issuing a P-RELEASE request (see § 8.2).
9.2.2.4 	The ACSE service-provider issues an A-RELEASE indication primitive to the acceptor. The acceptor then cannot issue any ACSE primitives other than an A-RELEASE response primitive or an A-ABORT request primitive.
9.2.2.5 	The acceptor replies to the A-RELEASE indication primitive by issuing an A-RELEASE response primitive with a Result parameter which has a value of »affirmative« or »negative«. The acceptor may give a negative response only if the session Negotiated Release functional unit was selected for the association (see § 8.3).
9.2.2.6 	If the acceptor gives a negative reponse, it may once again use any service provided by the ASEs included in the application context which in effect (with the exception of the A-ASSOCIATE service). If it gave a positive response, it cannot issue any further primitives for the association.
9.2.2.7 	The ACSE service-provider issues an A-RELEASE confirm primitive with an »affirmative« or »negative« value for the Result parameter. If the value is »negative«, the requestor may once again use any of the services provided by the ASEs of the application context which is in effect (with the exception of A-ASSOCIATE).
9.2.2.8 	If the value of the Result parameter is »affirmative«, the association and the underlying presentation-connection have been released.
9.2.2.9 	A requestor in either AE may disrupt the A-RELEASE service procedure by issuing an A-ABORT request. The acceptor receives an A-ABORT indication. The association is released with the possible loss of information in transit.
9.2.2.10 	An A-RELEASE service procedure collision results when requestors in both AEs simultaneously issue an A-RELEASE service primitive. This can occur only when no session tokens are available on the association (see § 8.3). In this situation, both ACSE service-users receive an unexpected A-RELEASE indication primitive. The following sequence then occurs to complete the normal release of the association.
	a) 	The association-initiator issues an A-RELEASE response primitive.
	b) 	The association-responder waits for an A-RELEASE confirm primitive from its peer. When it receives one, it then issues an A-RELEASE response primitive.
	c) 	The association-initiator receives an A-RELEASE confirm primitive.
9.2.2.11 	The association is released when both ACSE service-users have received an A-RELEASE confirm primitive.
9.3 	A-ABORT service
	The A-ABORT service is used by a requestor in either AE to cause the abnormal release of the association. It is a non-confirmed service. However, because of the possibility of an A-ABORT service procedure collision (see § 10.3.5), the delivery of the indication primitive is not guaranteed. However, both AEs are aware that the association has been released.
9.3.1 	A-ABORT parameters
	Table 4/X.217 lists the A-ABORT parameters.
TABLE 4/X.217
A-ABORT parameters
Parameter name 	Request 	Indication 	
Abort source a) 		M	
User information 	U 	C (=) 	
	a) 	Not used in X.410-1984 mode.

9.3.1.1 	Abort Source
	This parameter, whose value is supplied by the ACSE service-provider, indicates the initiating source of this abort. It takes one of the following symbolic values:
	- ACSE service-user; or
	- ACSE service-provider.
9.3.1.2 	User Information
	The requestor may optionally include user information on the request primitive. Its meaning depends on the application context which is in effect.
	Note - When ACSE is supported with version 1 of the session-protocol (X.225), this parameter is subject to length restrictions mentioned in § 8.3. For use with version 1, the A-ABORT service procedure does not transfer any of its own semantics, thus allowing the maximum possible length for presentation data value(s) of the User Information parameter. In this situation, the Abort Source parameter of the A-ABORT indication primitive always indicates »ACSE service-user«.
9.3.2 	A-ABORT service procedure
9.3.2.1 	The A-ABORT service procedure has a one-to-one correspondence with the P-U-ABORT service defined in Recommendation X.216. When the A-ABORT service is used, the association is abnormally released simultaneously with the abnormal release of the underlying presentation-connection.
9.3.2.2	An ACSE service-user which desires to abnormally release the association issues the A-ABORT request primitive. This requestor cannot issue any further primitives for the association.
9.3.2.3	The ACSE service-provider issues an A-ABORT indication primitive to the acceptor. The ACSE service-provider assigns the value of »ACSE service-user« for the Abort Source parameter. The association and the underlying presentation-connection have been released.
9.3.2.4 	The ACSE service-provider may itself cause the abnormal release of the association because of internal errors detected by it. In this case, the ACSE service-provider issues A-ABORT indication primitives to acceptors in both AEs. The ACSE service-provider assigns the value of »ACSE service-provider« to the Abort Source parameter. The User Information parameter is not used.
9.4 	A-P-ABORT service
	The A-P-ABORT service is used by the ACSE service-provider to signal the abnormal release of the association due to problems in services below the Application Layer. This occurrence indicates the possible loss of information in transit. A-P-ABORT is a provider-initiated service.
9.4.1 	A-P-ABORT parameter
	Table 5/X.217 lists the A-P-ABORT parameter.
TABLE 5/X.217 
A-P-ABORT parameter
Parameter name 	Indication 	
Provider reason 	P	

	Provider Reason: This parameter is as defined in Recommendation X.216.
9.4.2 	A-P-ABORT service procedure
	When the ACSE service-provider detects an error reported by the underlying presentation-service, it issues A-P-ABORT indication primitives to acceptors in both AEs. The association is abnormally released. Requestors in both AEs cannot issue any further primitives for the association.
10 	Sequencing information
	This clause defines the interaction among the ACSE service procedures for a particular association.
10.1 	A-ASSOCIATE
10.1.1 	Type of service
	A-ASSOCIATE is a confirmed service.
10.1.2 	Usage restrictions
	The A-ASSOCIATE service is not used on an established association.
10.1.3 	Disrupted service procedures
	The A-ASSOCIATE service procedure does not disrupt any other service procedure.
10.1.4 	Disrupting service procedures
	The A-ASSOCIATE service procedure is disrupted by the A-ABORT service procedures.
10.1.5 	Collisions
	An A-ASSOCIATE service procedure collision results when requestors in both AEs simultaneously issue an A-ASSOCIATE request primitive for each other. Both ACSE service-users are issued A-ASSOCIATION indication primitives which represent distinct associations. Both can choose to accept or reject the indicated association by issuing an A-ASSOCIATE response primitive with the appropriate value for its Result parameter. This will result in the establishment of none, one or two associations.
	Note - If an AE has several concurrent associations, a local mechanism is needed to distinguish between them.
10.2 	A-RELEASE
10.2.1 	Type of service
	A-RELEASE is a confirmed service.
10.2.2 	Usage restrictions
	The A-RELEASE service is only used on an established association.
10.2.3 	Disrupted service procedures
	The A-RELEASE service procedure does not disrupt any other service procedure, except that an A-ABORT indication is suppressed following issuance of an A-RELEASE response, and that an A-P-ABORT indication is suppressed following issuance of an A-RELEASE response or confirm.
10.2.4 	Disrupting service procedures
	The A-RELEASE service procedure is disrupted by the A-ABORT or A-P-ABORT service procedures.
10.2.5 	Collisions
	An A-RELEASE service procedure collision results when requestors in both AEs simultaneously issue an A-RELEASE request primitive. The processing of A-RELEASE service procedure collisions is described in § 9.2.2. 10.2.6 Further sequencing information The use of the A-RELEASE service is subject to the constraints on the S-RELEASE service defined in Recommendation X.215 (see § 8.3).
10.3 	A-ABORT
10.3.1 	Type of service
	A-ABORT is a non-confirmed service.
10.3.2 	Usage restrictions
	The A-ABORT service has effect only when used on an association in the process of establishment, on an established association, or on an association in the process of being released.
10.3.3 	Disrupted service procedures
	The A-ABORT service procedure disrupts the A-ASSOCIATE, A-RELEASE and A-P-ABORT service procedures.
10.3.4 	Disrupting service procedures
	The A-ABORT service procedure is disrupted by the A-P-ABORT service procedure and by the issuance of an A-RELEASE response.
10.3.5 	Collisions
	An A-ABORT service procedure collision results when requestors in both AEs simultaneously issue the A-ABORT request primitive. The collision processing is governed by the P-U-ABORT service defined in Recommendation X.216. In this situation, neither A-ABORT indication primitive is issued.
10.3.6 	Further sequencing information
	Any use of the A-ABORT service results in the abnormal release of the association, or the abnormal termination of the A-ASSOCIATE service procedure or the A-RELEASE service procedure with possible loss of information.
10.4 	A-P-ABORT
10.4.1 	Type of service
	A-P-ABORT is a provider-initiated service.
10.4.2 	Usage restrictions
	No restrictions are placed on the occurrence of this service.
10.4.3 	Disrupted service procedures
	The A-P-ABORT service procedure disrupts all other service procedures.
10.4.4 	Disrupting service procedures
	The A-P-ABORT service procedure is disrupted by the A-ABORT service procedure and by the issuance of an A-RELEASE response or confirm.
ANNEX A
(to Recommendation X.217)
Usage of ACSE services to achieve compatibility with CCITT Recommendation X.410-1984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations 
A.1 	Compatibility requirements
	Recommendation X.410, which was adopted by CCITT in 1984, has been used in a number of Recommendation X.400 Message Handling products available or under development.
	It is essential that the systems following Recommendation X.410-1984 be able to interwork with OSI systems. This principle has been guiding the development of the OSI ACSE and Presentation service and protocol, which has been conducted in very close cooperation between CCITT and ISO.
	This Annex shows how the ACSE service is to be used to achieve compatibility with Recommendation X.410-1984, and to support the basic facilities of the 1988 Message Handling series of CCITT Recommendations.
	Reference is also made to a companion Annex attached to the OSI Presentation service (Recommendation X.216) which shows how OSI Presentation service is to be used in order to achieve compatibility with Recommendation X.410-1984.
A.2 	Principles for ensuring compatibility
	The ACSE X.410-1984 mode of operation can be activated resulting in full encoding alignment with X.410-1984 at the session user data level. Its effect is to suppress the generation of explicit ACSE APDUs while maintaining an active ACPM state machine (see Recommendation X.227, Annex B).
	The layered structure of both protocols, which conforms with the OSI Reference Model, makes it possible to distinguish the Presentation Layer functions and parameters from those of the Application Layer. Based on this layering, the following principles are used to ensure the required compatibility:
	a) 	The functions and the corresponding protocol elements of X.410-1984 which belong to the Presentation Layer are integrated into the OSI Presentation protocol, which remains consistent and satisfies the requirements of the whole set of OSI applications.
	b)	The additional functions and protocol elements of X.410-1984 are placed in the Application Layer. They are generated by the Reliable Transfer Service Element (RTSE, see Recommendations X.218 and X.228 also Recommendation X.410-1984). They are passed transparently by the ACSE service-provider during association establishment and release by making direct use of the Presentation services.
A.3 	Usage of Association Control services to ensure compatibility with Recommendation X.410-1984
	The following Association Control services are used:
	A-ASSOCIATE
	A-RELEASE
	A-ABORT
	A-P-ABORT
	The use of these services is explained in §§ A.3.1-A.3.5.
	Note - RTORQ, RTOAC, RTORJ and RTAB are names given to APDUs generated by the RTSE protocol machine.
A.3.1 	A-ASSOCIATE
	An association is established and the X.410-1984 mode of ACSE operation is activated with the following combination of A-ASSOCIATE service parameters:
	a) 	Mode parameter must be set to »X.410-1984« on request primitive;
	b) 	Presentation Requirements parameter must specify the kernel.
	c) 	Session Requirements parameter must be set according to X.410-1984; and
	d) 	User Information:
		1) 	On the request and indication primitives, this parameter must contain an RTORQ APDU.
		2) 	On the response and confirmation primitives, it must contain a RTOAC APDU if the association has been accepted, or a RTORJ APDU if the association has been rejected.
		3) 	If the ACSE service-provider has rejected the request, then this parameter is not used.
	All other A-ASSOCIATE parameters must be absent or as defined by the Presentation Service and its Annex concerning its use for X.410-1984 compatibility (Recommendation X.216).
	Following the occurrence of an A-ABORT or A-P-ABORT service event, the initiating RTSE may use the A-ASSOCIATE service an implementation dependent number of times to attempt recovery. This use of the service has all parameters absent except for Presentation User Data which must contain the recovery data from the RT-OPEN service.
A.3.2 	A-RELEASE
	The association is released by the use of this service with only the Result parameter present. The rules governing the use of A-RELEASE are as in the main body of this document and are identical to those for P-RELEASE.
A.3.3 	A-ABORT
	Either ACSE service-user may signal to its peer that it has a problem and attempt to force the release of an association by using A-ABORT service with all parameters absent except for the Presentation User data parameter, which must contain an RTAB APDU. The association is released, and the initiating RTSE may use the A-ASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures.
A.3.4 	A-P-ABORT
	Either ACSE service-provider may signal that it has a problem (internally or with the services which underlie it) to its peer and force the release of an association by using the A-P-ABORT service as defined in Recommendation X.216. The association is released, and the initiating RTSE may use the A-ASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures.
A.3.5 	State Table
	The state table which governs the operation of the ACSE in X.410-1984 mode is given in Annex B of Recommendation X.227.
APPENDIX I
(to Recommendation X.217)
Differences between Recommendation X.217 and ISO International Standard 8649
I.1	Recommendation X.217 and ISO 8649 are technically aligned, with the following minor exceptions:
I.2	In § 10 on Sequencing Information this Recommendation states that the A-ABORT and A-P-ABORT services are mutually disruptive, when they collide (see §§ 10.3.3 and 10.4.4). ISO 8649 states that A-P-ABORT cannot be disrupted (see §§ 10.3.3 and 10.4.4).
I.3	In § 10 on Sequencing Information this Recommendation states that an A-ABORT indication is suppressed following issuance of an A-RELEASE response, and that an A-P-ABORT indication is suppressed following issuance of an A-RELEASE response or confirm (see §§ 10.2.3, 10.3.4 and 10.4.4). ISO 8649 states that the A-RELEASE service procedure does not disrupt any other service procedure (see §§ 10.2.3, 10.3.4 and 10.4.4).
I.4	This Recommendation contains an Annex A, which has not been included in ISO 8649. Annex A shows how the OSI Association Control service is to be used in order to achieve compatibility with Recommendation X.410-1984 and to support the basic facilities of the 1988 message handling services of CCITT Recommendations (the X.400 series).
I.5	There is no equivalent of this Appendix I in ISO 8649.