WPCL 2BJ|x H    6p&6p& I  X   c4 P  Rec. X.217 PAGE1 nI     c4 P PAGE2 Rec. X.217 n  p` 0 X`h     c4 P  Recommendation X.217    c4 P ASSOCIATION CONTROL SERVICE DEFINITION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS c4 P q   ЁЍ c4 P  Recommendation X.217 and ISO 8649 [Information processing systems Open Systems Interconnection Service definition for the Association Control Service Element] were developed in close collaboration and are technically aligned, except for the differences noted in Appendix I. q c4 P  U c4 P  (Melbourne, 1988) pThe CCITT, considering  p(a) 0 that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT Applications; p(b) 0 that Recommendation X.210 defines the Open System Interconnection (OSI) Layer Service Definition Conventions; p(c) 0 that Recommendation X.215 defines the Session Service Definition for Open Systems Interconnection for CCITT Applications; p(d) 0 that Recommendation X.216 defines the Presentation Service Definition of Open Systems Interconnection for CCITT Applications; p(e) that Recommendation X.220 specifies the use of X.200 series protocols in CCITT Applications; p( f)0 that Recommendation X.227 specifies the Association Control Protocol Specification for Open Systems interconnection for CCITT Applications; p(g) that Recommendation X.4101984 specifies the protocol for Remote Operation and Reliable Transfer Server for Message Handling Systems; and p(h) that there is a need for common Association Control to support various applications, unanimously declares  pthat this Recommendation defines the Association Control Service of Open Systems Interconnection for CCITT Applications as given in the Scope and Field of Application. Z c4 P  CONTENTS  c4 P 0 pIntroduction 1 pScope and field of application 2 pReferences 3 pDefinitions p3.1 0 Reference model definitions p3.2 0 Naming and addressing definitions p3.3 0 Service conventions definitions p3.4 0 Presentation service definitions p3.5 0 ACSE service definitions 4 pAbbreviations 5 pConventions 6 pBasic concepts 7 pService overview 8 pRelationship with other ASEs and lower layer services p8.1 0 Other applicationserviceelements p8.2 0 Presentationservice p8.3 0 Sessionservice 9 pService definition p9.1 0 AASSOCIATE service p9.2 0 ARELEASE service p9.3 0 AABORT service p9.4 0 APABORT service 10 pSequencing Information p10.1 0 AASSOCIATE p10.2 0 ARELEASE p10.3 0 AABORT p10.4 0 APABORT p` 0 X`h X  Annex A Usage of ACSE services to achieve compatibility with CCITT Recommendation X.4101984, 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.4101984 A.3.1 0 AASSOCIATE A.3.2 0 ARELEASE A.3.3 0 AABORT A.3.4 0 APABORT A.3.5 0 State Table Appendix I Differences between Recommendation X.217 and ISO International Standard 8649. p` 0 X`h Ђ 0 pIntroduction 0.1 pThis 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 pThe goal of Open Systems Interconnection is to allow, with a minimum of technical agreement outside the interconnection recommendations, the interconnection of information processing systems: p  from different manufacturers; p  under different managements; p  of different levels of complexity; and p  of different technologies. 0.3 pThis Recommendation recognizes that applicationprocesses 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 applicationserviceelement defined herein provides such services. 0.4 pThis Recommendation defines services provided by the application service element for applicationassociation control: the Association Control Service Element (ACSE). The ACSE provides basic facilities for the control of an applicationassociation between two applicationentities which communicate by means of a presentationconnection. 0.5 pThe use of services defined in this Recommendation is also governed by the use of the presentationservice (X.216) and the sessionservice (X.215). 0.6 pIt is recognized that, with respect to ACSE Quality of Services (QOS), described in S 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 pScope and field of application pThis Recommendation defines ACSE services for applicationassociation 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 presentationservice (X.216). The ACSE services assume as a minimum the use of the presentationservice Kernel functional unit. pThis Recommendation does not specify individual implementations or products nor does it constrain the implementation of entities and interfaces within a computer system. pNo requirement is made for conformance to this Recommendation. 2 pReferences  p` h h0  0  ` p Recommendation X.200 !X%Reference Model of Open Systems Interconnection for CCITT applications. (See also ISO 74981) Recommendation X.210 !X%%*OSI layer service definition conventions. (See also ISO TR8509)  p` h h0  0  ` p Recommendation X.215 X%Session service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8326 and ISO 8326 Addendum 2).  p` h h0  0  ` p Recommendation X.216 !X%Presentation service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8822).  p` h h0  0  ` p Recommendation X.225 !X%Session protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8327 and ISO 8327 Addendum 2).  p` h h0  0  ` p Recommendation X.227 X%Association Control protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8650).  p` h h0  0  ` p Recommendation X.4101984 &*CCITT Recommendation X.410: Message Handling Systems: Remote Operation and Reliable Transfer Server.    p` h h0  0  ` p ISO 74983 0  X%%*Information processing systems Open Systems Interconnection Basic Reference Model Part 3: Naming and Addressing. 3 pDefinitions 3.1 pReference model definitions This Recommendation is based on the concepts developed in X.200 and makes use of the following terms defined in it: pa)  Application Layer; pb)  applicationprocess; pc)  applicationentity; pd)  applicationserviceelement; pe)  applicationprotocoldataunit; pf ) 0 applicationprotocolcontrolinformation; pg)  presentationservice; ph)  presentationconnection; pi)  sessionservice; pj ) 0 sessionprotocol; pk)  sessionconnection. 3.2 pNaming and addressing definitions  pThis Recommendation makes use of the following terms defined in ISO 74983; pa)  applicationprocess title; pb)  applicationentity qualifier; pc)  applicationentity title c4 P P  Ѝ c4 P  As defined in ISO 74983, an applicationentity title is composed of an applicationprocess title and an applicationentity qualifier. The ACSE provides for the transfer of an applicationentity title value by the transfer of its component values. P c4 P ; pd)  applicationprocess invocationidentifier; pe)  applicationentity invocationidentifier; and pf ) 0 presentation address. 3.3 pService conventions definitions pThis Recommendation makes use of the following terms defined in X.210: pa)  serviceprovider; pb)  serviceuser; pc)  confirmed service; pd)  nonconfirmed service; pe)  providerinitiated service; pf ) 0 primitive; pg)  request (primitive); ph)  indication (primitive); pi)  response (primitive); and pj ) 0 confirm (primitive). 3.4 pPresentation service definitions pThis Recommendation makes use of the following terms defined in Recommendation X.216: pa)  abstract syntax; pb)  abstract syntax name; pc)  default context; pd)  defined context set; pe)  functional unit [presentation]; pf ) 0 normal mode [presentation]; pg)  presentation context; ph)  presentation data value; and pi)  X.4101984 mode [presentation]. 3.5 pACSE service definitions pFor the purpose of this Recommendation, the following definitions apply:  p 3.5.1 `  applicationassociation; association pA cooperative relationship between two applicationentities, formed by their exchange of applicationprotocolcontrolinformation through their use of presentationservices.  p 3.5.2 `  application context pAn explicitly identified set of applicationserviceelements, related options and any other necessary information for the interworking of applicationentities on an applicationassociation. pNote ĩ This definition is subject to refinement as a result of ongoing work in the area of the Application Layer structure.  p 3.5.3 `  Association Control Service Element pThe particular applicationserviceelement defined in this Recommendation.  p 3.5.4 `  ACSE serviceuser pThe part of the applicationentity which makes use of ACSE services.  p 3.5.5 `  ACSE serviceprovider pAn abstraction of the totality of those entities which provide _( ACSE services to peer ACSE serviceusers.  p 3.5.6 `  requestor pThe ACSE serviceuser which issues the request primitive for a particular ACSE service. For a confirmed service, it also receives the confirm primitive.  p 3.5.7 `  acceptor ffor a particular ACSE service. For a confirmed service, it also issues the response primitive.  p 3.5.8 ` associationinitiator pThe ACSE serviceuser which initiates a particular association, i.e. the requestor of the AASSOCIATE service which establishes the association.  p 3.5.9 ` associationresponder pThe ACSE serviceuser which is not the initiator of a particular association, i.e. the acceptor of the AASSOCIATE service which establishes the association.  p 3.5.10  normal mode pThe mode of ACSE operation which results in the transfer of ACSE semantics, using the presentationservice.  p 3.5.11  X.4101984 mode pThe mode of ACSE operation which allows ACSE serviceusers to interwork using the protocol specified in CCITT Recommendation X.4101984. The use of this mode results in no transfer of ACSE semantics.  p 3.5.12  disrupt pA 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 pAbbreviations pThe following abbreviations are used in this Recommendation. pACSE 0 Association Control Service Element pAE  0 applicationentity pASE 0 applicationserviceelement pOSI 0  Open Systems Interconnection pQOS 0 Quality of Service 5 pConventions 5.1 pThis 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. pblank 0 not applicable pC  0 conditional pM  0 mandatory pP  0 subject to conditions defined in X.216 pU  0 user option iis semantically equal to the value to its left in the table. 6 pBasic concepts 6.1 pThe reference model (X.200) represents communication between a pair of applicationprocesses (APs) in terms of communication between their applicationentities (AEs) using the presentationservice. The functionality of an AE is factored into a number of applicationserviceelements (ASEs). The interaction between AEs is described in terms of the use of their ASEs' services. 6.2 pThis Recommendation introduces the additional modelling concepts of applicationassociation and application context. 6.3 pAn applicationassociation 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 applicationprotocolcontrolinformation between the applicationentities through their use of presentationservices. 6.4 An application context is an explicitly identified set of applicationserviceelements, related options and any other necessary information for the interworking of applicationentities on an application association. 7 pService overview 7.1 pThis Recommendation defines the following services for the control of a single association pa)  AASSOCIATE; pb)  ARELEASE; pc)  AABORT; and pd)  APABORT. 7.2 pThe AASSOCIATE service causes the start of use of an association by those ASE procedures identified by the value of Application Context Name parameter. pNote The use of an association by several ASEs is the subject of ongoing work. 7.3 pThe ARELEASE 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 ARELEASE service optionally may be negotiated. 7.4 pThe AABORT service causes the abnormal release of the association with the possible loss of information in transit. 7.5 pThe APABORT service indicates the abnormal release of the association as a result of action by the underlying presentationservice with the possible loss of information in transit. oof the following modes: pa)  normal mode; or pb)  X.4101984 mode. 7.7 pThe normal mode of operation allows the ACSE serviceuser to take full advantage of the functionality provided by both ACSE and the presentationservice (X.216). In this mode the ACSE serviceprovider transfers its semantics using the normal mode of the presentationservice. 7.8 pThe X.4101984 mode of operation allows the ACSE serviceuser to interwork with a peer using the protocol specified by the CCITT Recommendation X.4101984. In this mode, the ACSE serviceprovider does not transfer any semantics of its own and uses the X.4101984 mode of the presentationservice. 8 pRelationship with other ASEs and lower layer services 8.1 pOther applicationserviceelements 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 presentationservice in a coordinated manner. 8.2 pPresentationservice 8.2.1 ` A onetoone correspondence exists between an applicationassociation and a presentationconnection. 8.2.2 ` The ACSE services require access to the PCONNECT, PRELEASE, PUABORT and PPABORT services. The ACSE services neither use nor constrain the use of any other presentation service. 8.2.3 ` The requestor and acceptor of the AASSOCIATE service determine the mode, the default presentation context, and the initial defined context set of the underlying presentationconnection using the following AASSOCIATE parameter: p Mode; p Presentation Requirements; .,Ԍ p Presentation Context Definition List; p Presentation Context Definition Result List; p Default Presentation Context Name; and p Default Presentation Context Result. p` 0 x`h spe specified in X.227 for the ACSE applicationprotocoldataunits. p` 0 X`h  pNote The ACSE serviceprovider 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.4101984+ for the Mode parameter, the ACSE serviceprovider does not transfer ACSE semantics and therefore does not require a presentation context for its abstract syntax. Any user information which the ACSE serviceprovider transfers for its serviceuser uses the unnamed default presentation context for the X.4101984 mode of the presentationservice (X.216). pNote Table 2/X.217 indicates the AASSOCIATE service parameters which are not used in the X.4101984 mode. None of the presentation context related parameters are used. 8.3 pSessionservice 8.3.1 ` Using the Session Requirements parameter, the AASSOCIATE service requestor and acceptor determine the functional units for the underlying sessionservice (X.215). 8.3.2 ` The rules and parameter value length restrictions of the underlying sessionservice affect ACSE services. The ACSE serviceuser must be aware of these constraints. pNote Some examples of these constraints are:  p` p pa)  Version 1 of the sessionprotocol (X.225) imposes user data length restrictions which affect ACSE primitive parameters. Some special considerations apply to the AABORT services (see ' 9.3).  p` p pb) 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 pService definition pThe ACSE services are listed in Table 1/X.217. XTABLE 1/X.217 XACSEservices ҇p` 0 X c4 P Service @0Type  p @0 c4 P ш p  c4 P ҇p` 0 X c4 P AASSOCIATE @0Confirmed  p  c4 P ш p  c4 P ҇p` 0 X c4 P ARELEASE @0Confirmed  p  c4 P ш p  c4 P ҇p` 0 X c4 P AABORT @0Nonconfirmed  p  c4 P ш p  c4 P ҇p` 0 X c4 P APABORT   @0Providerinitiated  p  c4 P ш  p` 0 X`h  p9.1 0 AASSOCIATE Service  x  pThe AASSOCIATE service is used to cause the beginning of the use of an association; it is a confirmed service.  p 9.1.1 ` AASSOCIATE Parameters  pTable 2/X.217 lists the AASSOCIATE service parameters. In addition, groups of parameters are defined for reference by other ASEs as follows:  p` p pa)  Calling AE Title is the composite of the Calling AP Title and the Calling AE Qualifier parameters;    p` p pb)  Called AE Title is the composite of the Called AP Title and the Called AE Qualifier parameters;  p` p pc)  Responding AE Title is the composite of the Responding AP Title and the Responding AE Qualifier parameters; pThe two components of the AE title (AP title and AE qualifier) are defined in ISO 74983. Table 2/X.217 [T2.217], p. X c4 P TABLE 2/X.217 S AASSOCIATE parameters  c4 P PX (#҇p` 0 X W c4 P Parameter name P@ ZRequest X  [Indicat \ion [Respons ]e [Confirm [ation  X H X  c4 P ш X H  c4 P PX (#҇p` 0 XX  c4 P Mode P@X E!U X E!M (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Application context name  c4 P a) c4 P  P@X E(#M X E(#M (=) E(#M E(#M (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Calling AP title  c4 P a)  P@X E(# c4 P U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Calling AE qualifier  c4 P a)  P@X E(# c4 P U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Calling AP invocationidentifier  c4 P a) c4 P  P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Calling AE invocationidentifier  c4 P a)  P@X E(# c4 P U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Called AP title  c4 P a)  P@X E(# c4 P U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Called AE qualifier  c4 P a)  P@X E(# c4 P U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Called AP invocationidentifier a) P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Called AE invocationidentifier a) P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Responding AP title a) P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Responding AE qualifier a) P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Responding AP invocationidentifier a) P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Responding AE invocationidentifier a) P@X E(#U X E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P User information P@X E(#U E(#C (=) E(#U E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇p` 0 XX  c4 P Result P@X  E!M E!M (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Result source P@X  E(#M  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Diagnostic a) P@X E(#U E(#C (=)  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Calling presentation address P@X E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Called presentation address P@X E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Responding presentation address P@X  E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Presentation context definition list a) P@X E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Presentation context definition result list a) P@X  E(#P E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Default presentation context name a) P@X E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Default presentation context result a) P@X  E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Quality of service P@X E(#P E(#P E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Presentation requirements a) P@X E(#P E(#P E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Session requirements P@X E(#P E(#P E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Initial synchronization point serial number P@X E(#P E(#P E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Initial assignment of tokens P@X E(#P E(#P E(#P E(#P  X H  c4 P ш X H  c4 P PX (#҇ X p` 0 XX  c4 P Sessionconnection identifier a) P@X E(#P E(#P E(#P E(#P  X H  c4 P ш  p` 0 X`h Ёa) Not used in X.4101984 mode.  p 9.1.1.1 Mode    pThis parameter specifies the mode in which the ACSE services will operate for this association. It takes one of the following symbolic values: p normal; or p X.4101984. pIf 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.  p 9.1.1.2  Application Context Name  pThis 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. pNote ĩ 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 AABORT request primitive.  p 9.1.1.3  Calling AP Title  pThis parameter identifies the AP which contains the requestor of the AASSOCIATE service.  p 9.1.1.4  Calling AE Qualifier  pThis parameter identifies the particular AE of the AP which contains the requestor of the AASSOCIATE service.  p 9.1.1.5  Calling AP Invocationidentifier  pThis parameter identifies the AP invocation which contains the requestor of the AASSOCIATE service.  p 9.1.1.6  Calling AE Invocationidentifier  pThis parameter identifies the AE invocation which contains the requestor of the AASSOCIATE service.  p 9.1.1.7  Called AP Title  pThis parameter identifies the AP which contains the intended acceptor of the AASSOCIATE service.  p 9.1.1.8  Called AE Qualifier  pThis parameter identifies the particular AE of the AP which contains the intended acceptor of the AASSOCIATE service.  p 9.1.1.9  Called AP Invocationidentifier  pThis parameter identifies the AP invocation which contains the intended acceptor of the AASSOCIATE service.  p 9.1.1.10  Called AE Invocationidentifier  pThis parameter identifies the AE invocation which contains the intended acceptor of the AASSOCIATE service.  p 9.1.1.11  Responding AP Title  pThis parameter identifies the AP which contains the actual acceptor of the AASSOCIATE service.  p 9.1.1.12  Responding AE Qualifier  pThis parameter identifies the particular AE of the AP which contains the actual acceptor of the AASSOCIATE service.  p 9.1.1.13  Responding AP Invocationidentifier  pThis parameter identifies the AP invocation which contains the actual acceptor of the AASSOCIATE service.  p 9.1.1.14  Responding AE Invocationidentifier  pThis parameter identifies the AE invocation which contains the actual acceptor of the AASSOCIATE service.  p 9.1.1.15  User Information  pEither the requestor or the acceptor may optionally include user information. Its meaning depends on the application context which accompanies the primitive. pNote ĩ 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.  p 9.1.1.16  Result c4 P q  Ѝ c4 P  It is recognized that, with respect to this parameter, work is still in progress to provide an integrated treatment across all layers of the OSI Reference Model. As a consequence, a change may be made to this Recommendation at a later time which reflects further developments and integration. q c4 P   pThis parameter is provided by either the acceptor, by the ACSE serviceprovider, or by the presentation serviceprovider. It indicates the result of using the AASSOCIATE service. It takes one of the following symbolic values: p accepted; p rejected (permanent); or p rejected (transient).  p 9.1.1.17  Result Source  pThe value of the parameter is supplied by the ACSE serviceprovider. It identifies the creating source of the Result parameter and the Diagnostic parameter, if present. It takes one of the following symbolic values: p ACSE serviceuser; p ACSE serviceprovider; or p presentation serviceprovider. pIf the Result parameter has the value accepted, the value of this parameter is ACSE serviceuser.  p 9.1.1.18  Diagnostic  pThis 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 AASSOCIATE service. pIf the Result Source parameter has the value ACSE serviceprovider, it takes one of the following symbolic values: p no reason given; or p no common ACSE version. pIf the Result Source parameter has the value ACSE serviceuser, it takes one of the following symbolic values: p no reason given; p application context name not supported; p calling AP title not recognized; p calling AE qualifier not recognized; p calling AP invocationidentifier not recognized; p calling AE invocationidentifier not recognized; p called AP title not recognized; p called AE qualifier not recognized; p called AP invocationidentifier not recognized; or p called AE invocationidentifier not recognized.  p 9.1.1.19  Calling Presentation Address  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.20  Called Presentation Address  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.21  Responding Presentation Address  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.22  Presentation Context Definition List  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.23  Presentation Context Definition Result List  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.24  Default Presentation Context Name  pThis parameter corresponds to the Default Context Name parameter defined in Recommendation X.216. 'Ԍ p 9.1.1.25  Default Presentation Context Result  pThis parameter corresponds to the Default Context Result parameter defined in Recommendation X.216.  p 9.1.1.26  Quality of Service  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.27  Presentation Requirements  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.28  Session Requirements  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.29  Initial Synchronization Point Serial Number  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.30  Initial Assignment of Tokens  pThis parameter is as defined in Recommendation X.216.  p 9.1.1.31  Session Connection Identifier  pThis parameter is as defined in Recommendation X.216.  p 9.1.2 ` AASSOCIATE service procedure 9.1.2.1  The AASSOCIATE service procedure has a onetoone correspondence with the PCONNECT service defined in Recommendation X.216. When the AASSOCIATE service is used, the association is created simultaneously with the creation of the underlying presentationconnection. 9.1.2.2  An ACSE serviceuser which desires to establish an association issues an AASSOCIATE request primitive. The called AE is identified by parameters of the request primitive. The requestor cannot issue any primitives except an AABORT request primitive until it receives an AASSOCIATE confirm primitive.   9.1.2.3  The ACSE serviceprovider issues an AASSOCIATE indication primitive to the acceptor. 9.1.2.4  The acceptor accepts or rejects the association by sending an AASSOCIATE response primitive with an appropriate Result parameter. ACSE serviceprovider issues an AASSOCIATE confirm primitive having the same Result parameter. The Result Source parameter is assigned the symbolic value of ACSE serviceuser. 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 AASSOCIATE). 9.1.2.6  If the acceptor rejects the association, the association is not established. 9.1.2.7  The ACSE serviceprovider may not be capable of supporting the requested association. In this situation, it returns an AASSOCIATE confirm primitive to the requestor with an appropriate RESULT parameter. The Result Source parameter is appropriately assigned either the symbolic value of ACSE serviceprovider or presentation serviceprovider. The indication primitive is not issued. The association is not established. 9.1.2.8  A requestor in either AE may disrupt the AASSOCIATE service procedure by issuing an AABORT request primitive. The acceptor receives an AABORT indication primitive. The association is not established. 9.2 pARelease service  pThe ARELEASE 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 S 8.3.2). This causes the unsuccessful completion of the ARELEASE service and the continuation of the association without loss of information in transit.  p 9.2.1 ` ARELEASE parameters  pTable 3/X.217 lists the ARELEASE parameters. X c4 P TABLE 3/X.217 T ARELEASE parameters  c4 P p  ҇p` 0  W c4 P Parameter name ZRequest YIndication ZResponse YConfirmatio ]n p` 0  p` h h0 = c4 P ш   p` h h0 = c4 P p  ҇ c4 P Reason  c4 P a) c4 P  p` h h0 = X(=xU X%h%(h((++--= =xC (=) X%h%(h((++--= =xU X%h%(h((++--= =xC (=)    X%h%(h((++--= c4 P ш   X%h%(h((++--= c4 P p  ҇ x p` 0  p` h h0 = c4 P User information  c4 P a) c4 P  p` h h0 = X(=xU X%h%(h((++--= =xC (=) X%h%(h((++--= =xU X%h%(h((++--= =xC (=)    X%h%(h((++--= c4 P ш   X%h%(h((++--= c4 P p  ҇p` 0  c4 P Result  p` h h0 = X( X%h%(h((++--= X%h%(h((++--= =xM X%h%(h((++--= =xM (=) X%h%(h((++--= c4 P ш  p` 0 X`h  p` h h0  X X%X%*X*/X/`4X499=a) Not used in X.4101984 mode.  p` h h0  X X%X%*X*/X/`4X499=  X  pL` L` L` L` L` L` L` L` L` L` 9.2.1.1 E FReason   ppppppppppp=hCWhen used on the request primitive, this parameter identifies the    p` h h0  X X%X%*X*/X/`4X499=general level of urgency of the request. It takes one of the following  X  p` h h0  X X%X%*X*/X/`4X499=symbolic values:  X  p` h h0  X X%X%*X*/X/`4X499==hC normal;    p` h h0  X X%X%*X*/X/`4X499==hC urgent; or    p` h h0  X X%X%*X*/X/`4X499==hC user defined.    p` h h0  X X%X%*X*/X/`4X499==hCNote ĩ For example, if the session Negotiated Release functional    p` h h0  X X%X%*X*/X/`4X499= unit was selected for the association, the value urgent may be    p` h h0  X X%X%*X*/X/`4X499=used on the request primitive when the requestor desires to urgently    p` h h0  X X%X%*X*/X/`4X499=release the association.    p` h h0  X X%X%*X*/X/`4X499==hCWhen used on the response primitive, this parameter identifies informatio    p` h h0  X X%X%*X*/X/`4X499=n about why the acceptor accepted or rejected the release request.    p` h h0  X X%X%*X*/X/`4X499=It takes one of the following symbolic values:  X  p` h h0  X X%X%*X*/X/`4X499==hC normal;    p` h h0  X X%X%*X*/X/`4X499==hC not finished; or    p` h h0  X X%X%*X*/X/`4X499==hC user defined.    p` h h0  X X%X%*X*/X/`4X499==hCNote ĩ For example, if the session Negotiated Release functional    p` h h0  X X%X%*X*/X/`4X499= unit was not selected for the association, the value not finished    p` h h0  X X%X%*X*/X/`4X499=may be used on the response primitive when the acceptor is forced to    p` h h0  X X%X%*X*/X/`4X499=release the association but wishes to give a warning that it has    p` h h0  X X%X%*X*/X/`4X499=additional information to send or receive.    pV` V` V` V` V` V` V` V` V` V` 9.2.1.2 E FUser information   ppppppppppp=hCEither the requestor or acceptor may optionally include user ., informatio    p` h h0  X X%X%*X*/X/`4X499=n on the request or response primitive. Its meaning depends on the    p` h h0  X X%X%*X*/X/`4X499=application context which is in effect.  X  pL` L` L` L` L` L` L` L` L` L` 9.2.1.3 E FResult   }p}p}p}p}p}p}p}p}p}p}p=hCThis parameter is used by the acceptor to indicate if the request    p` h h0  X X%X%*X*/X/`4X499=to release the association normally is acceptable. It takes one of    p` h h0  X X%X%*X*/X/`4X499=the following symbolic values:    p` h h0  X X%X%*X*/X/`4X499==hC affirmative; or  h  p` h h0  X X%X%*X*/X/`4X499==hC negative.    p_` _` _` _` _` _` _` _` _` _` 9.2.2 CDARELEASE service procedure   wpwpwpwpwpwpwpwpwpwpwp9.2.2.1 E FThe ARELEASE service procedure has a onetoone correspond    p` h h0  X X%X%*X*/X/`4X499=ence with the PRELEASE service defined in Recommendation X.216.    p` h h0  X X%X%*X*/X/`4X499=When the ARELEASE service is used, the association is released    p` h h0  X X%X%*X*/X/`4X499=simultaneously with the release of the underlying presentati    p` h h0  X X%X%*X*/X/`4X499=onconnection.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.2 E FAn ACSE serviceuser which desires to release the associatio    p` h h0  X X%X%*X*/X/`4X499=n issues an ARELEASE request primitive. This requestor cannot    p` h h0  X X%X%*X*/X/`4X499=issue any further primitives other than an AABORT request primitive    p` h h0  X X%X%*X*/X/`4X499=until it receives an ARELEASE confirm primitive.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.3 E FIn order to issue an ARELEASE request primitive, the requestor    p` h h0  X X%X%*X*/X/`4X499=is required to meet all the requirements for issuing a PRELEASE    p` h h0  X X%X%*X*/X/`4X499=request (see S 8.2).    p` h h0  X X%X%*X*/X/`4X499=9.2.2.4 E FThe ACSE serviceprovider issues an ARELEASE indication primitive    p` h h0  X X%X%*X*/X/`4X499=to the acceptor. The acceptor then cannot issue any ACSE primitives    p` h h0  X X%X%*X*/X/`4X499= other than an ARELEASE response primitive or an AABORT request primitive.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.5 E FThe acceptor replies to the ARELEASE indication primitive by    p` h h0  X X%X%*X*/X/`4X499=issuing an ARELEASE response primitive with a Result parameter which has    p` h h0  X X%X%*X*/X/`4X499=a value of affirmative or negative. The acceptor may give a    p` h h0  X X%X%*X*/X/`4X499=negative response only if the session Negotiated Release functional    p` h h0  X X%X%*X*/X/`4X499= unit was selected for the association (see S 8.3).    p` h h0  X X%X%*X*/X/`4X499=9.2.2.6 E FIf the acceptor gives a negative reponse, it may once again use any    p` h h0  X X%X%*X*/X/`4X499=service provided by the ASEs included in the application context    p` h h0  X X%X%*X*/X/`4X499=which in effect (with the exception of the AASSOCIATE service).    p` h h0  X X%X%*X*/X/`4X499=If it gave a positive response, it cannot issue any further primitives    p` h h0  X X%X%*X*/X/`4X499= for the association.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.7 E FThe ACSE serviceprovider issues an ARELEASE confirm primitive    p` h h0  X X%X%*X*/X/`4X499=with an affirmative or negative value for the Result parameter.    p` h h0  X X%X%*X*/X/`4X499= If the value is negative, the requestor may once again use any    p` h h0  X X%X%*X*/X/`4X499=of the services provided by the ASEs of the application context    p` h h0  X X%X%*X*/X/`4X499=which is in effect (with the exception of AASSOCIATE).    p` h h0  X X%X%*X*/X/`4X499=9.2.2.8 E FIf the value of the Result parameter is affirmative, the associatio    p` h h0  X X%X%*X*/X/`4X499=n and the underlying presentationconnection have been released.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.9 E FA requestor in either AE may disrupt the ARELEASE service procedure    p` h h0  X X%X%*X*/X/`4X499=by issuing an AABORT request. The acceptor receives an AABORT    p` h h0  X X%X%*X*/X/`4X499=indication. The association is released with the possible loss of    p` h h0  X X%X%*X*/X/`4X499=information in transit.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.10 FH!GAn ARELEASE service procedure collision results when requestors    p` h h0  X X%X%*X*/X/`4X499= in both AEs simultaneously issue an ARELEASE service primitive.    p` h h0  X X%X%*X*/X/`4X499= This can occur only when no session tokens are available on the    p` h h0  X X%X%*X*/X/`4X499=association (see S 8.3). In this situation, both ACSE serviceusers    p` h h0  X X%X%*X*/X/`4X499=receive an unexpected ARELEASE indication primitive. The following    p` h h0  X X%X%*X*/X/`4X499=sequence then occurs to complete the normal release of the associatio n.    p` h h0  X X%X%*X*/X/`4X499==hCa) FH!GThe associationinitiator issues an ARELEASE response primitive.    p`          =hCb) FH!GThe associationresponder waits for an ARELEASE confirm primitive from its peer. When it receives one, it then issues an ARELEASE response primitive.   ~p~p~p~p~p~p~p~p~p~p~p=hCc) FH!GThe associationinitiator receives an ARELEASE confirm primitive.    p` h h0  X X%X%*X*/X/`4X499=9.2.2.11 FH!GThe association is released when both ACSE serviceusers have    p` h h0  X X%X%*X*/X/`4X499=received an ARELEASE confirm primitive.    pR` R` R` R` R` R` R` R` R` R` 9.3 AhCAABORT service   ~p~p~p~p~p~p~p~p~p~p~p=hCThe AABORT service is used by a requestor in either AE to cause the    p` h h0  X X%X%*X*/X/`4X499=abnormal release of the association. It is a nonconfirmed service.    p` h h0  X X%X%*X*/X/`4X499=However, because of the possibility of an AABORT service procedure    p` h h0  X X%X%*X*/X/`4X499=collision (see S 10.3.5), the delivery of the indication primitive    p` h h0  X X%X%*X*/X/`4X499=is not guaranteed. However, both AEs are aware that the associatio    p` h h0  X X%X%*X*/X/`4X499=n has been released.    pV` V` V` V` V` V` V` V` V` V` 9.3.1 CDAABORT parameters   npnpnpnpnpnpnpnpnpnpnp=hCTable 4/X.217 lists the AABORT parameters.  H  p` h h0  X X%X%*X*/X/`4X499=‚= c4 P TABLE 4/X.217 .,ƌ   p` h h0  X X%X%*X*/X/`4X499== AABORT parameters  p` h h0  X X%X%*X*/X/`4X499= c4 P @҇ X p` 0  p` h h0   $ $= c4 P Parameter name  p` h h0   $ $= Request  p` h h0   $ $=  8  p` h h0   $ $=Indication  0 p` 0  c4 P ш 0  c4 P @҇ p  c4 P Abort source  c4 P a)   c4 P M  0  c4 P ш 0  c4 P @҇   c4 P User information U C (=)  0  c4 P ш  p` 0 X`h Ё pa)  Not used in X.4101984 mode.  p 9.3.1.1  Abort Source  h  pThis parameter, whose value is supplied by the ACSE serviceprovider, indicates the initiating source of this abort. It takes one of the following symbolic values: p ACSE serviceuser; or p ACSE serviceprovider.  p 9.3.1.2  User Information  pThe requestor may optionally include user information on the request primitive. Its meaning depends on the application context which is in effect. pNote ĩ When ACSE is supported with version 1 of the sessionprotocol (X.225), this parameter is subject to length restrictions mentioned in S 8.3. For use with version 1, the AABORT 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 AABORT indication primitive always indicates ACSE serviceuser.  p 9.3.2 ` AABORT service procedure 9.3.2.1  The AABORT service procedure has a onetoone correspondence with the PUABORT service defined in Recommendation X.216. When the AABORT service is used, the association is abnormally released simultaneously with the abnormal release of the underlying presentationconnection. 9.3.2.2 An ACSE serviceuser which desires to abnormally release the association issues the AABORT request primitive. This requestor cannot issue any further primitives for the association. 9.3.2.3 The ACSE serviceprovider issues an AABORT indication primitive to the acceptor. The ACSE serviceprovider assigns the value of ACSE serviceuser for the Abort Source parameter. The association and the underlying presentationconnection have been released. 9.3.2.4  The ACSE serviceprovider may itself cause the abnormal release of the association because of internal errors detected by it. In this case, the ACSE serviceprovider issues AABORT indication primitives to acceptors in both AEs. The ACSE serviceprovider assigns the value of ACSE serviceprovider to the Abort Source parameter. The User Information parameter is not used. 9.4 pAPABORT service  pThe APABORT service is used by the ACSE serviceprovider 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. APABORT is a providerinitiated service.  p 9.4.1 ` APABORT parameter  pTable 5/X.217 lists the APABORT parameter. T c4 P TABLE 5/X.217 R APABORT parameter  c4 P P҇p` 0 X T c4 P Parameter name VIndication   p` 0 X c4 P ш   c4 P P҇   c4 P Provider reason P(aP    c4 P ш  p` 0 X`h Ё  pProvider Reason: This parameter is as defined in Recommendation X.216.  p 9.4.2 ` APABORT service procedure  h  pWhen the ACSE serviceprovider detects an error reported by the underlying presentationservice, it issues APABORT 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 hpSequencing information pThis clause defines the interaction among the ACSE service procedures for a particular association.  p 10.1 ` AASSOCIATE  p 10.1.1  Type of service  pAASSOCIATE is a confirmed service.  p 10.1.2  Usage restrictions  pThe AASSOCIATE service is not used on an established association.  p 10.1.3  Disrupted service procedures  pThe AASSOCIATE service procedure does not disrupt any other service procedure.  p 10.1.4  Disrupting service procedures  pThe AASSOCIATE service procedure is disrupted by the AABORT service procedures.  p 10.1.5  Collisions  pAn AASSOCIATE service procedure collision results when requestors in both AEs simultaneously issue an AASSOCIATE request primitive for each other. Both ACSE serviceusers are issued AASSOCIATION indication primitives which represent distinct associations. Both can choose to accept or reject the indicated association by issuing an AASSOCIATE response primitive with the appropriate value for its Result parameter. This will result in the establishment of none, one or two associations. pNote ĩ If an AE has several concurrent associations, a local mechanism is needed to distinguish between them.  p 10.2 ` ARELEASE  p 10.2.1  Type of service  pARELEASE is a confirmed service.  p 10.2.2  Usage restrictions  pThe ARELEASE service is only used on an established association.  p 10.2.3  Disrupted service procedures  pThe ARELEASE service procedure does not disrupt any other service procedure, except that an AABORT indication is suppressed following issuance of an ARELEASE response, and that an APABORT indication is suppressed following issuance of an ARELEASE response or confirm.  p 10.2.4  Disrupting service procedures    pThe ARELEASE service procedure is disrupted by the AABORT or APABORT service procedures.  p 10.2.5  Collisions  pAn ARELEASE service procedure collision results when requestors in both AEs simultaneously issue an ARELEASE request primitive. The processing of ARELEASE service procedure collisions is described in S 9.2.2. 10.2.6 Further sequencing information The use of the ARELEASE service is subject to the constraints on the SRELEASE service defined in ., Recommendation X.215 (see S 8.3).  p 10.3 ` AABORT  p 10.3.1  Type of service  pAABORT is a nonconfirmed service.  p 10.3.2  Usage restrictions  pThe AABORT 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.  p 10.3.3  Disrupted service procedures  pThe AABORT service procedure disrupts the AASSOCIATE, ARELEASE and APABORT service procedures.  p 10.3.4  Disrupting service procedures  pThe AABORT service procedure is disrupted by the APABORT service procedure and by the issuance of an ARELEASE response.  p 10.3.5  Collisions  pAn AABORT service procedure collision results when requestors in both AEs simultaneously issue the AABORT request primitive. The collision processing is governed by the PUABORT service defined in Recommendation X.216. In this situation, neither AABORT indication primitive is issued.  p 10.3.6  Further sequencing information  pAny use of the AABORT service results in the abnormal release of the association, or the abnormal termination of the AASSOCIATE service procedure or the ARELEASE service procedure with possible loss of information.  p 10.4 ` APABORT  p 10.4.1  Type of service  pAPABORT is a providerinitiated service.  p 10.4.2  Usage restrictions  pNo restrictions are placed on the occurrence of this service.  p 10.4.3  Disrupted service procedures  pThe APABORT service procedure disrupts all other service procedures.  p 10.4.4  Disrupting service procedures  pThe APABORT service procedure is disrupted by the AABORT service procedure and by the issuance of an ARELEASE response or confirm. [ c4 P ANNEX A R c4 P (to Recommendation X.217) Usage of ACSE services to achieve compatibility with CCITT Recommendation X.4101984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations A.1 pCompatibility requirements  pRecommendation 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. pIt is essential that the systems following Recommendation X.4101984 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. pThis Annex shows how the ACSE service is to be used to achieve compatibility with Recommendation X.4101984, and to support the basic facilities of the 1988 Message Handling series of CCITT Recommendations. pReference 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.4101984. A.2 pPrinciples for ensuring compatibility  pThe ACSE X.4101984 mode of operation can be activated resulting in full encoding alignment with X.4101984 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). pThe 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:  p` p pa)  The functions and the corresponding protocol elements of X.4101984 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.  p` p pb) The additional functions and protocol elements of X.4101984 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.4101984). They are passed transparently by the ACSE serviceprovider during association establishment and release by making direct use of the Presentation services. A.3 pUsage of Association Control services to ensure compatibility with Recommendation X.4101984  pThe following Association Control services are used: pAASSOCIATE pARELEASE pAABORT pAPABORT pThe use of these services is explained in SS A.3.1A.3.5. pNote ĩ RTORQ, RTOAC, RTORJ and RTAB are names given to APDUs generated by the RTSE protocol machine.  p A.3.1 ` AASSOCIATE  pAn association is established and the X.4101984 mode of ACSE operation is activated with the following combination of AASSOCIATE service parameters: pa)  Mode parameter must be set to X.4101984 on request primitive; pb)  Presentation Requirements parameter must specify the kernel. pc)  Session Requirements parameter must be set according to X.4101984; and pd)  User Information:  p` h ` p p` 1) 0 On the request and indication primitives, this parameter must contain an RTORQ APDU.  p` h ` p p` 2) 0 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.  p` h ` p p` 3) 0 If the ACSE serviceprovider has rejected the request, then this parameter is not used. pAll other AASSOCIATE parameters must be absent or as defined by the Presentation Service and its Annex concerning its use for X.4101984 compatibility (Recommendation X.216). pFollowing the occurrence of an AABORT or APABORT service event, the initiating RTSE may use the AASSOCIATE 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 RTOPEN service.  p A.3.2 ` ARELEASE  pThe association is released by the use of this service with only the Result parameter present. The rules governing the use of ARELEASE .,  are as in the main body of this document and are identical to those for PRELEASE.  p A.3.3 ` AABORT  pEither ACSE serviceuser may signal to its peer that it has a problem and attempt to force the release of an association by using AABORT 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 AASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures.  p A.3.4 ` APABORT  pEither ACSE serviceprovider 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 APABORT service as defined in Recommendation X.216. The association is released, and the initiating RTSE may use the AASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures.  p A.3.5 ` State Table  pThe state table which governs the operation of the ACSE in X.4101984 mode is given in Annex B of Recommendation X.227. Y c4 P APPENDIX I R c4 P (to Recommendation X.217) Differences between Recommendation X.217 and ISO International Standard 8649 I.1pRecommendation X.217 and ISO 8649 are technically aligned, with the following minor exceptions: I.2pIn S 10 on Sequencing Information this Recommendation states that the AABORT and APABORT services are mutually disruptive, when they collide (see SS 10.3.3 and 10.4.4). ISO 8649 states that APABORT cannot be disrupted (see SS 10.3.3 and 10.4.4). I.3pIn S 10 on Sequencing Information this Recommendation states that an AABORT indication is suppressed following issuance of an ARELEASE response, and that an APABORT indication is suppressed following issuance of an ARELEASE response or confirm (see SS 10.2.3, 10.3.4 and 10.4.4). ISO 8649 states that the ARELEASE service procedure does not disrupt any other service procedure (see SS 10.2.3, 10.3.4 and 10.4.4). I.4pThis 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.4101984 and to support the basic facilities of the 1988 message handling services of CCITT Recommendations (the X.400 series). I.5pThere is no equivalent of this Appendix I in ISO 8649.