8 	Mapping to the presentation-service
	This clause specifies how the presentation-service primitives are used by the ACPM. This usage depends on the mode selected (see § 6.2) for the association.
	a) 	For the requesting ACPM: The mode for the association is determined by the value of the Mode parameter of the invoking A-ASSOCIATE request primitive. If the Mode parameter is not included on the request primitive, the default value of »normal« is used.
	b) 	For the accepting ACPM: The mode is determined by the value of the Mode parameter of the incoming P-CONNECT indication primitive.
	The usage of the presentation services for the normal mode is specified in §§ 8.1 to 8.3. The usage for the X.410-1984 mode is specified in §§ 8.4 to 8.6. Table 7/X.227 summarizes, for both modes of operation, the mapping of ACSE primitives and their related APDUs (normal mode) to the presentation primitives used.
TABLE 7/X.227 
Mapping overview 
ACSE primitive 	APDU a) 	Presentation Primitive 	
A-ASSOCIATE request/indication 	AARQ 	P-CONNECT request/indication 	
A-ASSOCIATE response/confirm 	AARE 	P-CONNECT response/confirm 	
A-RELEASE request/indication 	RLRQ 	P-RELEASE request/indication 	
A-RELEASE response/confirm 	RLRE 	P-RELEASE response/confirm 	
A-ABORT request/indication 	ABRT 	P-U-ABORT request/indication 	
A-P-ABORT indication	 - 	P-P-ABORT indication 	
a )   ACSE APDUs are not used in the X.410-1984 mode.
8.1	Association establishment (normal mode)
	The association establishment procedure uses the P-CONNECT service. Association establishment takes place concurrently with the establishment of the underlying presentation-connection.
8.1.1	Directly mapped parameters
	For the P-CONNECT primitives: The following parameters are not referenced by the ACPM and are mapped directly onto the corresponding parameters of the A-ASSOCIATE primitives:
	a) 	Calling Presentation Address;
	b) 	Called Presentation Address;
	c) 	Responding Presentation Address;
	d) 	Presentation Context Definition List;
	e) 	Presentation Context Definition Result List;
	f ) 	Default [Presentation] Context Name;
	g) 	Default [Presentation] Context Result;
	h) 	Quality of Service;
	i) 	Presentation Requirement;
	j ) 	Session Requirements;
	k) 	Initial Synchronization Point Serial Number;
	l) 	Initial Assignment of Tokens;
	m) 	Session-connection Identifier.
8.1.2	Use of other P-CONNECT request and indication parameters
	The Mode and User Data parameters of the P-CONNECT request and indication primitives are referenced by the ACPM.
8.1.2.1	Mode
8.1.2.1.1	For the P-CONNECT request primitives: The Mode parameter is set to the value of the Mode parameter of the A-ASSOCIATE request primitive. For the normal mode of ACSE operation, this parameter has the value of »normal«. This indicates to the presentation-service that it is to operate in the normal mode for this presentation-connection.
8.1.2.1.2	For the P-CONNECT indication primitive: This parameter has the value of »normal« for the normal mode of ACSE operation. The value indicates that the accepting ACPM is to operate in the normal mode for this association. The Mode parameter of the A-ASSOCIATE indication primitive is set to the value of »normal«.
8.1.2.2	User data
	For both the P-CONNECT request and indication primitives: The User Data parameter is used to carry the AARQ APDU as specified below.
	a) 	The APCI of the AARQ APDU is expressed using the ACSE abstract syntax of this Recommendation. This abstract syntax must be included as the value of a presentation context definition parameter specified by the requestor on the A-ASSOCIATE request primitive.
		Note - The requesting and accepting ACPMs are aware of the presentation context which contains their abstract syntax by a local mechanism.
	b) 	User information (if any) from the A-ASSOCIATE request primitive is included in the AARQ APDU and is expressed using one or more presentation contexts specified by the requestor on the A-ASSOCIATE request primitive.
8.1.3	Use of other P-CONNECT response and confirm parameters
	The User Data and Result parameters of the P-CONNECT response and confirm primitive are referenced by the ACPM.
8.1.3.1	Result 
8.1.3.1.1	For the P-CONNECT response primitive: The Result parameter is set by the accepting ACPM as specified below.
	a) 	If the accepting ACPM itself rejects the association, it is set as »user-rejection«.
	b) 	If the accepting ACPM accepts the request, the values is set as »acceptance«, or »user-rejection« as determined by the value of the corresponding Result parameter on the A-ASSOCIATE response primitive.
8.1.3.1.2	For the P-CONNECT confirm primitive: The Result parameter is used by the requesting ACPM to determine if the P-CONNECT confirm primitive User Data parameter contains an AARE APDU as specified below.
	a) 	If the Result parameter has the value »provider-rejection«, the request is rejected by the presentation service-provider. The intended accepting ACPM never received the AARQ APDU. The User Data parameter does not contain an AARE APDU.
	b) 	Otherwise, the Result parameter has the value of »acceptance« or »user rejection«. The accepting ACPM received the AARQ APDU and has returned an AARE APDU which is contained in the user data parameter.
8.1.3.2	User data
8.1.3.2.1	The User Data field only has relevance if the presentation-connection is not rejected by the presentation service-provider (see § 8.1.3.1).
8.1.3.2.2	For both the P-CONNECT response and confirm primitives: The User Data parameter is used to carry the AARE APDU as specified below.
	a) 	The APCI of the AARE APDU is expressed using the ACSE abstract syntax of this Recommendation. This abstract syntax must be included as the value of presentation context definition parameter selected by the acceptor on the A-ASSOCIATE response primitive.
	b) 	User information (if any) from the A-ASSOCIATE response primitive is included in the AARE APDU and is expressed using one or more presentation contexts selected by the acceptor on the A-ASSOCIATE response primitive.
8.2	Normal release of an association (normal mode)
	The normal release procedure uses the P-RELEASE service. The normal release of an association takes place simultaneously with the normal release of the underlying presentation-connection.
8.2.1	Use of P-RELEASE request and indication parameters
	The User Data parameter of the P-RELEASE request and indication primitives is referenced by the ACPM. For both the P-RELEASE request and indication primitives: The User Data parameter is used to carry the RLRQ APDU as specified below.
	a) 	The APCI of the RLRQ APDU is expressed using the ACSE abstract syntax of this Recommendation. This abstract syntax must be one of the available presentation contexts.
	b) 	User information (if any) from the A-RELEASE request primitive is included in the RLRQ APDU and is expressed using one or more available presentation contexts.
8.2.2	Use of P-RELEASE response and confirm parameters
	The Result and User Data parameters of the P-RELEASE response and confirm primitives are referenced by the ACPM.
8.2.2.1	Result
8.2.2.1.1	For the P-RELEASE response primitive: The Result parameter is set to the value of the Result parameter of the A-RELEASE response primitive (i.e., »affirmative« or »negative«). This value indicates to the presentation service-provider whether the underlying presentation-connection is to be released or if it is to be continued.
8.2.2.1.2	For the P-RELEASE confirm primitive: The value of the Result parameter on the A-ASSOCIATE confirm primitive is set to the value of the Result parameter. This value indicates to the requesting ACPM whether the association is released or if it continues.
8.2.2.2	User Data
	For both the P-RELEASE response and confirm primitives: The User Data parameter is used to carry the RLRE APDU as specified below.
	a) 	The APCI of the RLRE APDU is expressed using the ACSE abstract syntax of this Recommendation. This abstract syntax must be one of the available presentation contexts.
	b) 	User information (if any) from the A-RELEASE response primitive is included in the RLRE APDU and is expressed using one or more available presentation contexts.
8.3	Abnormal release of an association (normal mode)
	The abnormal release procedure uses the P-U-ABORT and P-P-ABORT services. The abnormal release of an association takes place simultaneously with the abnormal release of the underlying presentation-connection.
8.3.1	Use of P-U-ABORT request and indication parameters
	The User Data parameter of the P-U-ABORT request and indication primitives is referenced by the ACPM. 
	For both the P-U-ABORT request and indication primitives: The User Data parameter is used to carry the ABRT APDU as specified below.
	a) 	The APCI of the APDU is expressed using the ACSE abstract syntax of this Recommendation. This abstract syntax must be one of the available presentation contexts.
	b) 	User information (if any) from the A-ABORT request primitive is expressed using one or more available presentation contexts.
8.3.2	Use of P-P-ABORT indication parameter
	The reason parameter of the provider-initiated P-P-ABORT indication primitive is mapped directly to the corresponding parameter of the A-P-ABORT indication.
8.4	Association establishment (X.410-1984 mode)
	The association establishment procedure uses the P-CONNECT service.
8.4.1	Directly mapped parameters
	The following parameters are not referenced by the ACPM and are mapped directly onto corresponding parameters of the A-ASSOCIATE primitives:
	a) 	User data ;
	b) 	Calling Presentation Address;
	c) 	Called Presentation Address;
	d) 	Responding Presentation Address;
	e) 	Quality of Service;
	f ) 	Session Requirements;
	g) 	Initial Synchronization Point Serial Number;
	h) 	Initial Assignment of Tokens;
	i) 	Session-connection identifier.
8.4.2	Use of other P-CONNECT request and indication parameters
	The Mode parameter of the P-CONNECT request and indication primitives is referenced by the ACPM.
	For the P-CONNECT request primitive: The Mode parameter is set to the value of the Mode parameter of the A-ASSOCIATE request primitive. For the X.410-1984 mode of ACSE operation, this parameter has the value of »X.410-1984«. This indicates to the presentation-service that it is to operate in the X.410-1984 mode for this presentation-connection.
	For the P-CONNECT indication primitive: This parameter has the value of »X.410-1984« for the X.410-1984 mode of ACSE operation. This value indicates that the accepting ACPM is to operate in the X.410-1984 mode for this association. The Mode parameter of the A-ASSOCIATE indication primitive is set to the value of »X.410-1984«.
8.4.3	Use of other P-CONNECT response and confirm parameters
	The Result parameter of the P-CONNECT response and confirm primitives is used by the ACPM when operating in the X.410-1984 mode.
	For the P-CONNECT response primitive: The value of the Result parameter is mapped from the Result parameter of the A-ASSOCIATE Result parameter as shown in Table 8/X.227.
TABLE 8/X.227
Mapping ACSE Result Parameter
A-ASSOCIATE's Result 	P-CONNECT's Result 	
accepted 	acceptance 	
rejected (permanent) 	user-rejection 	
rejected (transient) 	user-rejection 	
	For the P-CONNECT confirm primitive: The Result and Result source parameters of the A-ASSOCIATE confirm primitive are mapped from the Result parameter as shown in Table 9/X.227.
TABLE 9/X.227
Mapping Presentation Result Parameter
P-CONNECT's Result 	A-ASSOCIATE's Result 	A-ASSOCIATE's Result Source	
acceptance 	accepted 	ACSE service-user 	
user-rejection 	rejected (permanent) 	ACSE service-user 	
provider-rejection 	rejected (permanent) 	presentation service-provider 	
8.5	Normal release of an association (X.410-1984 mode)
	The normal release procedure uses the P-RELEASE service.
	The following parameters are not referenced by the ACPM and are mapped directly onto corresponding parameters of the A-RELEASE primitives:
	a) 	Result;
	b) 	User Data.
8.6	Abnormal release of an association (X.410-1984 mode)
	The abnormal release procedure uses the P-U-ABORT and P-P-ABORT services.
8.6.1	Use of P-U-ABORT request and indication parameters
	For both the P-U-ABORT request and indication primitives: The User Data parameter is not referenced by the ACPM and is mapped directly onto the User Information parameter of the corresponding A-ABORT primitives.
8.6.2	Use of P-P-ABORT indication parameter
	For the P-P-ABORT indication primitive: The Reason parameter is not referenced by the ACPM and is mapped directly onto the corresponding parameter of the A-P-ABORT indication primitive.
9 	Structure and encoding of ACSE APDUs
9.1 	The abstract syntax of each of the ACSE APDUs is specified in this section using ASN.1 (Recommendation X.208).
ACSE-1 DEFINITIONS :: =
BEGIN
-- ACSE-1 refers to ACSE version 1
ACSE-apdu :: = CHOICE
	{ 	aarq 	AARQ-apdu, 
		aare 	AARE-apdu, 
		rlrq 	RLRQ-apdu, 
		rlre 	RLRE-apdu, 
		abrt	ABRT-apdu
	}
AARQ-apdu :: = [ APPLICATION 0 ] 		IMPLICIT SEQUENCE
	{ 	protocol-version 	[0] 	IMPLICIT BIT STRING 
				{ version1 (0) } 	DEFAULT { version1 },
		application-context-name 	[1] 	Application-context-name
		called-AP-title 	[2] 	AP-title 	OPTIONAL,
		called-AE-qualifier 	[3] 	AE-qualifier 	OPTIONAL,
		called-AP-invocation-identifier	 [4] 	AP-invocation-identifier 	OPTIONAL,
		called-AE-invocation-identifier 	[5] 	AE-invocation-identifier 	OPTIONAL,
		calling-AP-title 	[6] 	AP-title 	OPTIONAL,
		calling-AE-qualifier 	[7] 	AE-qualifier 	OPTIONAL,
		calling-AP-invocation-identifier 	[8] 	AP-invocation-identifier 	OPTIONAL,
		calling-AE-invocation-identifier 	[9] 	AE-invocation-identifier 	OPTIONAL,
		implementation-information 	[29] 	IMPLICIT Implementation-data 	OPTIONAL,
		user-information 	[30] 	IMPLICIT Association-information 	OPTIONAL
	}
AARE-apdu :: = [ APPLICATION 1 ] IMPLICIT SEQUENCE
		{ protocol-version 	[0] 	IMPLICIT BIT STRING 
				{ version1 (0) } 	DEFAULT { version1 },
		application-context-name 	[1] 	Application-context-name
		result 	[2] 	Associate-result,
		result-source-diagnostic 	[3] 	Associate-source-diagnostic,
		responding-AP-title 	[4] 	AP-title 	OPTIONAL,
		responding-AE-qualifier 	[5] 	AE-qualifier 	OPTIONAL,
		responding-AP-invocation-identifier [6] 	AP-invocation-identifier 	OPTIONAL,
		responding-AE-invocation-identifier [7] 	AE-invocation-identifier 	OPTIONAL,
		implementation-information 	[29] 	IMPLICIT Implementation-data 	OPTIONAL,
		user-information 	[30] 	IMPLICIT Association-information 	OPTIONAL
	}
RLRQ-apdu :: = [ APPLICATION 2 ] IMPLICIT SEQUENCE
	{ 	reason 	[0] 	IMPLICIT Release-request-reason 	OPTIONAL,
		user-information 	[30] 	IMPLICIT Association-information 	OPTIONAL
	}
RLRE-apdu :: = [ APPLICATION 3 ] IMPLICIT SEQUENCE
	{ 	reason 	[0] 	IMPLICIT Release-request-reason 	OPTIONAL,
		user-information 	[30] 	IMPLICIT Association-information 	OPTIONAL
	}
ABRT-apdu :: = [ APPLICATION 4 ] IMPLICIT SEQUENCE
	{ 	abort-source 	[0] 	IMPLICIT ABRT-source,
		user-information 	[30] IMPLICIT Association-information 	OPTIONAL
	}
ABRT-source :: = INTEGER
	{ 	acse-service-user (0), 
		acse-service-provider (1),
	}
Application-context-name :: = OBJECT IDENTIFIER
AP-title :: = ANY
	-- The exact definition and values used for AP-title 
	-- should be chosen taking into account the ongoing work 
	-- in areas of naming, Directories, and registration 
	-- authority procedures for AP-titles, AE-titles and 
	-- AE-Qualifiers
AE-qualifier :: = ANY

	-- The exact definition and values used for AE-qualifier 
	-- should be chosen taking into account the ongoing work 
	-- in areas of naming, Directories, and registration 
	-- authority procedures for AP-titles, AE-titles and 
	-- AE-Qualifiers
	-- As defined in ISO 7498-3, an application-entity title 
	-- is composed of an application-process title and an 
	-- application-entity qualifier.The ACSE protocol provides 
	-- for the transfer of an application-entity title value 
	-- by the transfer of its component values.However, the 
	-- following data type is provided for reference by other 
	-- Recommendations that require a single syntactic structure 
	-- for AE-titles
AE-title :: = SEQUENCE { 	AP-title,
						 AE-qualifier
				}
AE-invocation-identifier :: = INTEGER
AP-invocation-identifier :: = INTEGER
Associate-result :: = INTEGER
	{ 	accepted (0), 
		rejected-permanent (1), 
		rejected-transient (2)
	}
Associate-source-diagnostic :: = CHOICE
	{	acse-service-user [1] INTEGER 
		{ 	null (0), 
			no-reason-given (1), 
			application-context-name-not-supported (2), 
			calling-AP-title-not-recognized (3), 
			calling-AP-invocation-identifier-not-recognized (4), 
			calling-AE-qualifier-not-recognized (5), 
			calling-AE-invocation-identifier-not-recognized (6), 
			called-AP-title-not-recognized (7), 
			called-AP-invocation-identifier-not-recognized (8), 
			called-AE-qualifier-not-recognized (9), 
			called-AE-invocation-identifier-not-recognized (10)
		}
		acse-service-provider [2] INTEGER
		{	null (0), 
			no-reason-given (1), 
			no-common-acse-version (2)
		}
	}
Association-information :: = SEQUENCE OF EXTERNAL
Implementation-data :: = GraphicString
Release-request-reason :: = INTEGER
	{ 	normal (0), 
		urgent (1), 
		user-defined (30)
	}
Release-response-reason :: = INTEGER
	{ 	normal (0), 
		not-finished (1), 
		user-defined (30)
	}
END
9.2 	The following name, that has the ASN.1 type of OBJECT IDENTIFIER, applies to the ACSE abstract-syntax-definition specified in this section.
	{ 	joint-iso-ccitt association-control (2), 
		abstract-syntax (1), 
		apdus (0), 
		version (1)
	}
9.3 	The set of encoding rules named
	{	joint-iso-ccitt asn1 (1),  
		basic-encoding (1) }
and specified in Recommendation X.209 is applicable to the ACSE abstract syntax definition.
10 	Conformance
	A system claiming to implement the procedures specified in this Recommendation shall comply with the requirements in § 10.1 through § 10.3.
	Two modes of conformance are recognized:
	a) 	normal mode; and
	b) 	X.410-1984 mode.
	The X.410-1984 mode exists to allow compatibility with message handling systems implementing the protocol specified in CCITT Recommendations X.410-1984.
10.1	Statement requirements
	The following shall be stated by the implementor:
	a) 	whether the system is capable of acting in the role of association-initiator, or association-responder, or both;
	b) 	that the system supports version 1 of this protocol; and
	c) 	whether the system implements:
		1) 	the normal mode of ACSE protocol;
		2) 	the X.410-1984 mode of ACSE protocol to support a message handling system; or
		3) 	both the normal mode and the X.410-1984 mode for the reason given in item 2) above.
10.2	Static requirements
	The use of the Association Control Service Element is required for an application-entity to meet the minimum requirements for establishing and releasing communication with a peer entity.
10.2.1	Normal mode
	If the normal mode is implemented, the system shall:
	a) 	act as an association-initiator (by sending an AARQ APDU), or an association-acceptor (by responding properly to an AARQ APDU with an appropriate AARE APDU), or both, and
	b) 	support (as a minimum) that encoding which results from applying the basic ASN.1 encoding rules to the ASN.1 specified in § 9 for the purpose of exchanging ACSE APCI.
10.2.2	X.410-1984 mode
	If the X.410-1984 mode is implemented, the system shall act as an initiator, or acceptor, or both.
10.3	Dynamic requirements
10.3.1	Normal mode
	If the normal mode is implemented, the system shall:
	a) 	follow all the procedures specified in § 7 (including the rules for extensibility) and Annex A; and
	b) 	support the mapping onto the Presentation Service defined in § 8.1 to § 8.3
10.3.2	X.410-1984 mode
	If the X.410-1984 mode is implemented, the system shall support the direct mapping of parameters of presentation-service primitives onto the ACSE primitives as specified in § 8.4 to § 8.6 and Annex B.
ANNEX A
(to Recommendation X.227)
ACPM state table for normal mode of operation
	This Annex forms an integral part of this Recommendation.
A.1	General
A.1.1	This annex defines a single Association Control Protocol machine (ACPM) for the normal mode of operation in terms of a state table (Table A-5/X.227). The state table shows the interrelationship between the state of an ACPM, the incoming events that occur in the protocol, the actions taken and, finally, the resultant state of the ACPM.
A.1.2 	The ACPM state table does not constitute a formal definition of the ACPM. It is included to provide a more precise specification of the elements of procedure defined in § 7.
A.1.3 	This annex contains the following tables.
	a) 	Table A-1/X.227 specifies the abbreviated name, source, and name/description of each incoming event. The sources are:
		1) 	ACSE service user (AC-user);
		2) 	peer ACPM (AC-peer); and
		3) 	presentation service-provider (PS-provider).
	b) 	Table A-2/X.227 specifies the abbreviated name of each state.
	c) 	Table A-3/X.227 specifies the abbreviated name, target and name/description of each outgoing event. The targets are:
		1) 	ACSE service-user (AC-user); and
		2) 	peer ACPM (AC-peer).
	d) 	Table A-4/X.227 specifies the predicates.
	e) 	Table A-5/X.227 specifies the ACPM state table using the abbreviations of the above Tables.
TABLE A-1/X.227
Incoming event list for normal mode
Abbreviated Name 	Source 	Name and Description 	
A-ASCreq 	AC-user 	A-ASSOCIATE request primitive 	
A-ASCrsp+ 	AC-user 	A-ASSOCIATE response primitive (Result = »accepted«) 	
A-ASCrsp- 	AC-user 	A-ASSOCIATE response primitive (Result = »rejected (permanent)« or »rejected (transient)«)	
 AARQ 	AC-peer 	A-ASSOCIATE-REQUEST APDU 
The AARQ is user data on a P-CONNECT indication 	
AARE+ 	AC-peer 	A-ASSOCIATE-RESPONSE APDU 
(Result = »accepted«) 
The AARE+ is user data on a P-CONNECT confirm primitive 
(Result = »acceptance«) 	
AARE- 	AC-peer 	A-ASSOCIATE-RESPONSE APDU 
(Result = »reject (permanent)« or »rejected (transient)«) 
The AARE- is user data on a P-CONNECT confirm primitive 
(Result = »user-rejection«) 	
P-CONcnf- 	PS-provider 	P-CONNECT confirm primitive 
(Result = »provider-rejection«) 	
A-RLSreq 	AC-user 	A-RELEASE request primitive 	
A-RLSrsp+ 	AC-user 	A-RELEASE response primitive 
(Result = »affirmative«) 	
A-RLSrsp- 	AC-user 	A-RELEASE response primitive 
(Result = »negative«) 	
RLRQ 	AC-peer 	A-RELEASE-REQUEST APDU 
The RLRQ is user data on a P-RELEASE indication primitive 	
RLRE+ 	AC-peer 	A-RELEASE-RESPONSE APDU 
The RLRE+ is user data on a P-RELEASE confirm primitive 
(Result = »affirmative«) 	
RLRE- 	AC-peer 	A-RELEASE-RESPONSE APDU 
The RLRE- is user data on a P-RELEASE confirm primitive 
(Result = »negative«) 	
A-ABRreq 	AC-user 	A-ABORT request primitive 	
ABRT a) 	AC-peer 	A-ABORT APDU 
The ABRT is user data on a P-U-ABORT indication primitive 	
P-PABind 	PS-provider 	P-P-ABORT indication primitive 	
a) 	When supported by version 1 of the session-protocol (X.225), the A-ABORT APDU has no APCI. The receipt of the P-U-ABORT indication implies its existence.
TABLE A-2/X.227
ACPM states for normal mode
Abbreviated Name 	Description 	
STA0 	idle: unassociated 	
STA1 	awaiting AARE APDU 	
STA2 	awaiting A-ASSOCIATE response 	
STA3 	awaiting RLRE APDU 	
STA4 	awaiting A-RELEASE response 	
STA5 	associated 	
STA6 	awaiting A-RELEASE response (association-initiator) 	
STA7 	awaiting RLRE APDU (association-responder) 	
TABLE A-3/X.227 
Outgoing event list for normal mode 
Abbreviated Name 	Target 	Name and Description 	
A-ASCind 	AC-user 	A-ASSOCIATE indication primitive 	
A-ASCcnf+ 	AC-user 	A-ASSOCIATE confirm primitive 
(Result = »accepted«) 	
A-ASCcnf- 	AC-user 	A-ASSOCIATE confirm primitive 
(Result = »rejected (permanent)« or »rejected (transient)«) 	
AARQ 	AC-peer 	A-ASSOCIATE-REQUEST APDU 
The AARQ is sent as user data on a P-CONNECT request primitive 	
AARE+ 	AC-peer 	A-ASSOCIATE-RESPONSE APDU 
(Result = »accepted«) 
The AARE+ is sent as user data on a P-CONNECT+ response primitive 
(Result = »acceptance«) 	
AARE- 	AC-peer 	A-ASSOCIATE-RESPONSE APDU 
(Result = »rejected (permanent)« or »rejected (transient)«) 
The AARE- is sent as user data on a P-CONNECT-response primitive 
(Result = »user-rejection«) 	
A-RLSind 	AC-user 	A-RELEASE indication primitive 	
A-RLScnf+ 	AC-user 	A-RELEASE confirm primitive 
(Result = »affirmative«) 	
A-RLScnf- 	AC-user 	A-RELEASE confirm primitive 
(Result = »negative«) 	
RLRQ 	AC-peer 	A-RELEASE-REQUEST APDU 
The RLRQ is sent as user data on a P-RELEASE request primitive 	
RLRE+ 	AC-peer 	A-RELEASE-RESPONSE APDU 
The RLRE+ is sent as user data on a P-RELEASE response primitive 
(Result = »affirmative«) 	
RLRE- 	AC-peer 	A-RELEASE-RESPONSE APDU 
The RLRE- is sent as user data on a P-RELEASE response primitive 
(Result = »negative«) 	
A-ABRind 	AC-user 	A-ABORT indication primitive 
(Source = »ACSE service-user« or »ACSE service-provider«) 	
ABRT a) 	AC-peer 	A-ABORT APDU 
(Source = »ACSE service-user« or »ACSE service-provider«) 
The ABRT is sent as user data on a P-U-ABORT request primitive 	
A-PABind 	AC-user 	A-P-ABORT indication primitive 	
a) 	When supported by version 1 of the session-protocol X.225, the A-ABORT APDU has no APCI. The receipt of the subsequent P-U-ABORT indication implies its existence.
TABLE A-4/X.227 
Predicates for normal mode 
Code 	Meaning 	
p1 	ACPM can support requested connection 	
p2 	ACPM originated this association 	
TABLE A-5/X.227
ACPM state table for normal mode
	STA0 
Idle- 
Unassoc.	STA1 
Awaiting 
AARE 	STA2 
Awaiting A-
ASCrsp 	STA3 
Awaiting 
RLRE 	STA4 
Awaiting A-
RLSrsp 	STA5 
Associated 	STA6 
Collision 
association 
initiator 	STA7 
Collision 
association 
responder 	
A-ASCreq 	p1 
AARQ 
STA1 								
A-ASCrsp+ 			AARE+ 
STA5 						
A-ASCrsp- 			AARE- 
STA0 						
AARQ 	p1 
A-ASCind STA2; 
^p1: 
AARE- STA0 								
AARE+ 		A-ASCcnf+ 
STA5 							
AARE- 		A-ASCcnf- STA0 
							
P-CONcnf- 		A-ASCcnf- 
STA0 							
A-RLSreq 						RLRQ 
STA3 			
A-RLSrsp+ 					RLRE+
 STA0 		RLRE+
 STA3 		
A-RLSrsp- 					RLRE- 
STA5 				
RLRQ 				p2
 A-RLSind
 STA6 
^p2 
A-RLSind
 STA7 		A-RLSind 
STA4 			
RLRE+ 				A-RLScnf+
 STA0 				A-RLScnf+
 STA4 	
RLRE- 				A-RLScnf- 
STA5 					
A-ABRreq 		ABRT 
STA0 	ABRT 
STA0 	ABRT 
STA0 	ABRT 
STA0 	ABRT 
STA0 	ABRT 
STA0 	ABRT 
STA0 	
ABRT 		A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	
P-PABind 		A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	
A.2	Conventions
A.2.1	The intersection of an incoming event (row) and a state (column) forms a cell.
A.2.2 	In the state table, a blank cell represents the comibination of an incoming event and a state that is not defined for the ACPM (see § A.3.1).
A.2.3 	A non-blank cell represents an incoming event and state that is defined for the ACPM. 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.
A.2.4 	A mandatory action list contains:
	a) 	an outgoing event; and
	b) 	a resultant state.
A.2.5 	A conditional action list contains:
	a) 	a predicate expression comprising predicates and Boolean operators (ô represents the Boolean NOT); and
	b) 	a mandatory action list, this mandatory action list is used only if the predicate expression is true.
A.3	Actions to be taken by the ACPM
	The ACPM state table defines the action to be taken by the ACPM in terms of an outgoing event and the resultant state of the ACPM.
A.3.1	Invalid intersections
	Blank cells indicate an invalid intersection of an incoming event and state. If such an intersection occurs, one of the following actions is taken.
	a) 	If the incoming event comes from the ACSE service-user, any action taken by the ACPM is a local matter.
	b) 	If the incoming event is related to a received APDU or PS-provider event, the ACPM issues both an A-ABRind outgoing event (to its AC-user) and an ABRT outgoing event (to its peer ACPM).
A.3.2	Valid intersections
	If the intersection of the state and incoming event is valid, one of the following actions is taken.
	a) 	If a cell contains a mandatory action list the ACPM takes the actions specified;
	b) 	If a cell contains one or more conditional action lists, for each predicate expression that is true, the ACPM takes the actions specified. If none of the predicate expressions are ture, the ACPM takes one of the actions defined in § A.3.1.
A.4	Relationship to Presentation and other ASEs
	The ACPM state Table (Table A-5/X.227) only defines the interactions of the ACPM, its ACSE service-user and the presentation-services used by the ACPM.
	Note - The occurrence of the other events from the presentation-service or other application-service-elements is not included in the ACPM state table because they do not affect the ACPM.
ANNEX B 
(to Recommendation X.227) 
ACPM state table for X.410-1984 mode of operation 
B.1	General
	This annex defines a single Association Control Protocol Machine (ACPM) for the X.410-1984 mode of operation in terms of a state table (Table B-5/X.227). The state table shows the interrelationship between the state of an ACPM, the incoming events that occur in the protocol, the actions taken and, finally, the resultant state of the ACPM. 
	For the X.410 mode of operation, the ACPM does not generate its own APDUs, but works transparently in a pass through mode. The state table is derived directly from the state table for normal mode by replacing:
	- 	AARQ outgoing/incoming by P-CONNECT request/indication primitive;
	- 	AARE outgoing/incoming by P-CONNECT response/confirmation primitive;
	- 	RLRQ outgoing/incoming by P-RELEASE request/indication primitive;
	- 	RLRE outgoing/incoming by P-RELEASE response/confirmation primitive; and
	- 	ABRT outgoing/incoming by P-U-ABORT request/indication primitive.
	A-RELEASE response negative, P-RELEASE confirm negative, A-RELEASE confirm negative and P-RELEASE response negative are omitted as they are not permitted to occur in X.410-1984 mode. Also the A-RELEASE collision case cannot occur in X.410-1984 mode, because only the initiator of the association may request the release of the association.
	The initial state of an invocation of an ACPM is state 0 (STA0). Once state 0 has been left, and it is re-entered, the ACPM ceases to exist.
	The ACPM state table does not constitute a formal definition of the ACPM for operation in the X.410-1984 mode. It is included to provide a more precise specification of the elements of procedure defined in § 7.
	This annex contains the following tables.
	a) 	Table B-1/X.227 specifies the abbreviated name, source, and name/description of each incoming event. The sources are:
		1) 	ACSE service user (AC-user);
		2) 	peer ACPM (AC-peer); and
		3) 	presentation service-provider (PS-provider).
	b) 	Table B-2/X.227 specifies the abbreviated name of each state.
	c) 	Table B-3/X.227 specifies the abbreviated name, target and name/description of each outgoing event. The targets are:
		1) 	ACSE service-user (AC-user); and
		2) 	peer ACPM (AC-peer).
	d) 	Table B-4/X.227 specifies the predicates.
	e) 	Table B-5/X.227 specifies the ACPM state table for the normal mode of operation using the abbreviations of the above tables.
B.2	Conventions
	The intersection of an incoming event (row) and a state (column) forms a cell.
	In the state table, a blank cell represents the combination of an incoming event and a state that is not defined for the ACPM (see § B.3.1).
	A non-blank cell represents an incoming event and state that is defined for the ACPM. 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. A mandatory action list contains:
	a) 	an outgoing event; and
	b) 	a resultant state.
	A conditional action list contains:
	a) 	a predicate expression comprising predicates and Boolean operators (ô represents the Boolean NOT); and
	b) 	a mandatory action list, this mandatory action list is used only if the predicate expression is true.
B.3	Actions to be taken by the ACPM
	The ACPM state table defines the action to be taken by the ACPM in terms of an outgoing event and the resultant state of the ACPM.
B.3.1	Invalid intersections
	Blank cells indicate an invalid intersection of an incoming event and state. If such an intersection occurs, one of the following actions is taken.
	a) 	If the incoming event comes from the ACSE service-user, any action taken by the ACPM is a local matter.
	b) 	If the incoming event is related to a PS-provider event, the ACPM issues both an A-ABRind outgoing event (to its AC-user) and a P-UABreq outgoing event (to its peer ACPM).
B.3.2	Valid intersections
	If the intersection of the state and incoming event is valid, one of the following actions is taken.
	a) 	If a cell contains a mandatory action list the ACPM takes the actions specified;
	b) 	If a cell contains one or more conditional action lists, for each predicate expression that is true, the ACPM takes the actions specified. If none of the predicate expressions are true, the ACPM takes one of the actions defined in § B.3.1.
B.4	Relationship to Presentation and other ASEs
	The ACPM state table (Table B-5/X.227) only defines the interactions of the ACPM, its ACSE service-user and the presentation-services used by the ACPM.
	Note - The occurrence of the other events from the presentation-service or other application-service-elements is not included in the ACPM state table because they do not affect the ACPM.
TABLE B-1/X.227 
Incoming event list for X.410-1984 mode 
Abbreviated Name 	Source 	Name and description 	
A-ASCreq 	AC-user 	A-ASSOCIATE request primitive 	
A-ASCrsp+ 	AC-user 	A-ASSOCIATE response primitive 
(Result = »accepted«) 	
A-ASCresp- 	AC-user 	A-ASSOCIATE response primitive
 (Result = »rejected«) 	
P-CONind 	AC-peer 	P-CONNECT indication 	
P-CONcnf+ 	AC-peer 	P-CONNECT confirm primitive
 (Result = »accepted«) 	
P-CONcnf- 	AC-peer 
or
 PS-provider  	P-CONNECT confirm primitive 
(Result = »user-rejection«)
(Result = »provider-rejection«) 	
A-RLSreq 	AC-user 	A-RELEASE request primitive 	
A-RLSrsp+ 	AC-user 	A-RELEASE response primitive
(Result = »affirmative«) 	
P-RELind 	AC-peer 	P-RELEASE indication primitive 	
P-RELcnf+ 	AC-peer 	P-RELEASE confirm primitiv
 (Result = »affirmative«) 	
A-ABRreq 	AC-user 	A-ABORT request primitive 	
P-UABind 	AC-peer 	P-U-ABORT indication primitive 	
P-PABind 	PS-provider 	P-P-ABORT indication primitive 	
TABLE B-2/X.227
ACPM states for X.410-1984 mode
Abbreviated Name 	Description 	
STA0 	idle; unassociated 	
STA1 	awaiting P-CONNECT confirm 	
STA2 	awaiting A-ASSOCIATE response 	
STA3 	awaiting P-RELEASE confirm 	
STA4 	awaiting A-RELEASE response 	
STA5 	associated	
TABLE B-3/X.227
Outgoing event list for X.410-1984 mode
Abbreviated Name 	Target 	Name and description 	
A-ASCind 	AC-user 	A-ASSOCIATE indication primitive 	
A-ASCcnf+ 	AC-user 	A-ASSOCIATE confirm primitive 
(Result = »accepted«) 	
A-ASCcnf- 	AC-user 	A-ASSOCIATE confirm primitive 
(Result = »rejected«) 	
P-CONreq 	AC-peer 	P-CONNECT request primitive 	
P-CONrsp+ 	AC-peer 	P-CONNECT+ response primitive 
(Result = »user = rejected«) 	
P-CONrsp- 	AC-peer 	P-CONNECT- response primitive 
(Result = »user-rejection«) 	
A-RLSind 	AC-user 	A-RELEASE indication primitive 	
A-RLScnf+ 	AC-user 	A-RELEASE confirm primitive 
(Result = »affirmative«) 	
P-RELreq 	AC-peer 	P-RELEASE request primitive 	
P-RELrsp+ 	AC-peer 	P-RELEASE response primitive 
(Result = »affirmative«) 	
ABRind 	AC-user 	A-ABORT indication primitive 
(Source = »ACSE service-user« or »ACSE service-provider«) 	
P-UABreq 	AC-peer 	P-U-ABORT request primitive 
(Source = »ACSE service-user« or ACSE service-provider«) 	
A-PABind 	AC-user 	A-P-ABORT indication primitive 	
TABLE B-4/X.227
Predicates for X.410-1984 mode 
Code 	Meaning 	
p1 	ACPM can support requested connection 	
p2 	ACPM originated this association 	
TABLE B-5/X.227
ACPM state table for X.410-1984 mode 
	STA0 
Idle-
 unassoc.	STA1
 Awaiting 
P-CONcnf 	STA2 
Awaiting 
A-ASCrsp 	STA3 
Awaiting 
P-RELcnf 	STA4 
Awaiting 
A-RLSrsp 	STA5 
Associated 	
A-ASCreq 	p1 
P-CONre
STA1 						
A-ASCrsp+ 			P-CONrsp+ 
STA5 				
A-ASCrsp- 			P-CONrsp-
 STA0 				
P-CONind 	p1 
A-ASCind 
STA2;
 ^p1: 
P-CONrsp- 
STA0 						
P-CONcnf+ 		A-ASCcnf+ 
STA5 					
P-CONcnf- 		A-ASCcnf- 
STA0 					
A-RLSreq 						p2 
P-RELreq 
STA3 	
A-RLSrsp+ 					P-RELrsp+ 
STA0 		
P-RELind 						^p2 
A-RLSind 
STA4 	
P-RELcnf+ 				A-RLScnf+ 
STA0 			
A-ABRreq 		P-UABreq 
STA0 	P-UABreq 
STA0 	P-UABreq 
STA0 	P-UABreq 
STA0 	P-UABreq 
STA0 	
P-UABind 		A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	A-ABRind 
STA0 	
P-PABind 		A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0 	A-PABind 
STA0	
APPENDIX I 
(to Recommendation X.227) 
Differences between Recommendation X.227 and ISO International Standard 8650
	Recommendation X.227 and ISO 8650 are technically aligned with the following exceptions.
I.1 	Clause 10 on Conformance of ISO 8650 differs from § 10 on Conformance in this Recommendation. The text that appears in this Recommendation was agreed in collaboration with ISO, and it is anticipated that the text in ISO 8650 will be amended in due course. The full text of the two sub-clauses in ISO 8650 that are different reads as follows:
»10.0.3 The X.410-1984 mode exists to allow claims of conformance to be made for message handling systems implementing the CCITT X.410-1984 series of Recommendations and, therefore, use the X.410-1984 mode of ACSE.
10.1	Statement requirements
	The following shall be stated by the implementor:
	a) 	whether the system is capable of acting the role of association-initiator, or association-responder, or both;
	b) 	that the system supports version 1 of this protocol; and
	c) 	whether the system implements:
		1) 	the normal mode of ACSE protocol;
		2) 	the X.410-1984 mode of ACSE protocol because it supports a message handling system implementing the CCITT X.400-1984 series of Recommendations; or
		3) 	both the normal mode and the X.410-1984 mode for the reason given in item 2) above.«
I.2	 This Recommendation contains no statement concerning the relative precedence of any Section or Annex. ISO 8650 contains a clause II which provides a definitive precedence statement.
I.3 	This Recommendation contains an Annex B, which has not been included in ISO 8650. Annex B contains the ACPM state table information for use when the X.410-1984 mode is invoked.
I.4 	There is no equivalent of this Appendix I in ISO 8650.
I.5 	This Recommendation contains an Appendix II which has not yet been included in ISO 8650. Appendix II lists the OBJECT IDENTIFIER values assigned in Recommendations X.217 and X.227.
APPENDIX II
(to Recommendation X.227)
Summary of assigned object identifier values 
	This Appendix summarises the OBJECT IDENTIFIER values assigned in Recommendations X.217 and X.227.
	{ 	joint-iso-ccitt association-control (2), 
		abstract-syntax (1), 
		apdus (0), 
		version (1)
	}
-- may be used to reference the abstract syntax 
-- for Association Control defined in 
-- Recommendation X.227, § 9.1.
	Additionally Recommendation X.227 § 9.3 makes reference to the OBJECT IDENTIFIER value assigned in Recommendation X.209 for the basic encoding rules for ASN.1 as the means of specifying a transfer syntax for the abstract syntax defined in Recommendation X.227.