home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-08-17 | 42.2 KB | 2,389 lines |
- C:\WINWORD\CCITTREC.DOT
-
- 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-ASSOCI-
- ATE 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 speci-
- fied 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/indica-
- tion
-
- AARQ
-
- P-CONNECT request/indica-
- tion
-
- A-ASSOCIATE response/con-
- firm
-
- AARE
-
- P-CONNECT response/con-
- firm
-
- A-RELEASE request/indica-
- tion
-
- RLRQ
-
- P-RELEASE request/indica-
- tion
-
- A-RELEASE response/confirm
-
- RLRE
-
- P-RELEASE response/confirm
-
- A-ABORT request/indication
-
- ABRT
-
- P-U-ABORT request/indica-
- tion
-
- 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 ser-
- vice. Association establishment takes place concurrently with the establish-
- ment 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 primi-
- tive. 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 indi-
- cates that the accepting ACPM is to operate in the normal mode for this
- association. The Mode parameter of the A-ASSOCIATE indication primi-
- tive 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 primi-
- tive.
-
- Note - The requesting and accepting ACPMs are aware of the presen-
- tation context which contains their abstract syntax by a local mech-
- anism.
-
- 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-connec-
- tion 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 nor-
- mal 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 primi-
- tive (i.e., ╗affirmative½ or ╗negative½). This value indicates to the presenta-
- tion 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 simul-
- taneously with the abnormal release of the underlying presentation-connec-
- tion.
-
- 8.3.1 Use of P-U-ABORT request and indication parameters
-
- The User Data parameter of the P-U-ABORT request and indication primi-
- tives 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 ser-
- vice.
-
- 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 oper-
- ate 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 indi-
- cation 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 (perma-
- nent)
-
- 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 primi-
- tives:
-
- 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 { ver-
- sion1 },
-
- 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 { ver-
- sion1 },
-
- 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 IDENTI-
- FIER, applies to the ACSE abstract-syntax-definition specified in this sec-
- tion.
-
- { 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 Rec-
- ommendation 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 Recom-
- mendations 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-initi-
- ator, 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 abbrevi-
- ations of the above Tables.
-
- TABLE A-1/X.227
-
- Incoming event list for normal mode
-
-
-
- Abbrevia
- ted 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 indica-
- tion
-
- AARE+
-
- AC-peer
-
- A-ASSOCIATE-RESPONSE APDU
-
- (Result = ╗accepted½)
-
- The AARE+ is user data on a P-CONNECT con-
- firm primitive
-
- (Result = ╗acceptance½)
-
- AARE-
-
- AC-peer
-
- A-ASSOCIATE-RESPONSE APDU
-
- (Result = ╗reject (permanent)½ or ╗rejected (tran-
- sient)½)
-
- The AARE- is user data on a P-CONNECT con-
- firm primitive
-
- (Result = ╗user-rejection½)
-
- P-CON-
- cnf-
-
- PS-pro-
- vider
-
- 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 indica-
- tion primitive
-
- RLRE+
-
- AC-peer
-
- A-RELEASE-RESPONSE APDU
-
- The RLRE+ is user data on a P-RELEASE con-
- firm 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 indica-
- tion primitive
-
- P-PAB-
- ind
-
- PS-pro-
- vider
-
- 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 indi-
- cation implies its existence.
-
- TABLE A-2/X.227
-
- ACPM states for normal mode
-
-
-
- Abbrevia
- ted 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
-
-
-
- Abbrevia
- ted Name
-
- Target
-
- Name and Description
-
- A-
- ASCind
-
- AC-user
-
- A-ASSOCIATE indication primitive
-
- A-ASC-
- cnf+
-
- AC-user
-
- A-ASSOCIATE confirm primitive
-
- (Result = ╗accepted½)
-
- A-ASC-
- cnf-
-
- 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-CON-
- NECT request primitive
-
- AARE+
-
- AC-peer
-
- A-ASSOCIATE-RESPONSE APDU
-
- (Result = ╗accepted½)
-
- The AARE+ is sent as user data on a P-CON-
- NECT+ 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-CON-
- NECT-response primitive
-
- (Result = ╗user-rejection½)
-
- A-RLS-
- ind
-
- 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 ser-
- vice-provider½)
-
- ABRT a)
-
- AC-peer
-
- A-ABORT APDU
-
- (Source = ╗ACSE service-user½ or ╗ACSE ser-
- vice-provider½)
-
- The ABRT is sent as user data on a P-U-ABORT
- request primitive
-
- A-PAB-
- ind
-
- 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 connec-
- tion
-
- p2
-
- ACPM originated this association
-
- TABLE A-5/X.227
-
- ACPM state table for normal mode
-
-
-
- STA0
-
- Idle-
-
- Unass
- oc.
-
- STA1
-
- Awaiti
- ng
-
- AARE
-
- STA2
-
- Awaiti
- ng A-
-
- ASCrs
- p
-
- STA3
-
- Awaiti
- ng
-
- RLRE
-
- STA4
-
- Awaiti
- ng A-
-
- RLSrs
- p
-
- STA5
-
- Associ
- ated
-
- STA6
-
- Collisi
- on
-
- associ
- ation
-
- initiat
- or
-
- STA7
-
- Collisi
- on
-
- associ
- ation
-
- respon
- der
-
- A-
- ASCre
- q
-
- p1
-
- AAR
- Q
-
- STA1
-
- A-
- ASCrs
- p+
-
- AARE
- +
-
- STA5
-
- A-
- ASCrs
- p-
-
- AARE
- -
-
- STA0
-
- AAR
- Q
-
- p1
-
- A-
- ASCin
- d
- STA2;
-
- ^p1:
-
- AARE
- -
- STA0
-
- AARE
- +
-
- A-
- ASCc
- nf+
-
- STA5
-
- AARE
- -
-
- A-
- ASCc
- nf-
- STA0
-
- P-
- CONc
- nf-
-
- A-
- ASCc
- nf-
-
- STA0
-
- A-
- RLSre
- q
-
- RLRQ
-
- STA3
-
- A-
- RLSrs
- p+
-
- RLRE
- +
-
- STA0
-
- RLRE
- +
-
- STA3
-
- A-
- RLSrs
- p-
-
- RLRE
- -
-
- STA5
-
- RLRQ
-
- p2
-
- A-
- RLSin
- d
-
- STA6
-
- ^p2
-
- A-
- RLSin
- d
-
- STA7
-
- A-
- RLSin
- d
-
- STA4
-
- RLRE
- +
-
- A-
- RLSc
- nf+
-
- STA0
-
- A-
- RLSc
- nf+
-
- STA4
-
- RLRE
- -
-
- A-
- RLSc
- nf-
-
- STA5
-
- A-
- ABRr
- eq
-
- ABRT
-
- STA0
-
- ABRT
-
- STA0
-
- ABRT
-
- STA0
-
- ABRT
-
- STA0
-
- ABRT
-
- STA0
-
- ABRT
-
- STA0
-
- ABRT
-
- STA0
-
- ABRT
-
- A-
- ABRi
- nd
-
- STA0
-
- A-
- ABRi
- nd
-
- STA0
-
- A-
- ABRi
- nd
-
- STA0
-
- A-
- ABRi
- nd
-
- STA0
-
- A-
- ABRi
- nd
-
- STA0
-
- A-
- ABRi
- nd
-
- STA0
-
- A-
- ABRi
- nd
-
- STA0
-
- P-
- PABin
- d
-
- A-
- PABin
- d
-
- STA0
-
- A-
- PABin
- d
-
- STA0
-
- A-
- PABin
- d
-
- STA0
-
- A-
- PABin
- d
-
- STA0
-
- A-
- PABin
- d
-
- STA0
-
- A-
- PABin
- d
-
- STA0
-
- A-
- PABin
- d
-
- 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 man-
- datory 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 predi-
- cate 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 interac-
- tions 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-ser-
- vice 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/confirma-
- tion 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 omit-
- ted 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 incom-
- ing 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 man-
- datory 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 predi-
- cate 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-ser-
- vice 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
-
-
-
- Abbrevia
- ted Name
-
- Source
-
- Name and description
-
- A-
- ASCreq
-
- AC-user
-
- A-ASSOCIATE request primitive
-
- A-
- ASCrsp+
-
- AC-user
-
- A-ASSOCIATE response primitive
-
- (Result = ╗accepted½)
-
- A-ASC-
- resp-
-
- AC-user
-
- A-ASSOCIATE response primitive
-
- (Result = ╗rejected½)
-
- P-CON-
- ind
-
- AC-peer
-
- P-CONNECT indication
-
- P-CON-
- cnf+
-
- AC-peer
-
- P-CONNECT confirm primitive
-
- (Result = ╗accepted½)
-
- P-CON-
- cnf-
-
- AC-peer
-
- or
-
- PS-pro-
- vider
-
- 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-REL-
- cnf+
-
- AC-peer
-
- P-RELEASE confirm primitiv
-
- (Result = ╗affirmative½)
-
- A-
- ABRreq
-
- AC-user
-
- A-ABORT request primitive
-
- P-UAB-
- ind
-
- AC-peer
-
- P-U-ABORT indication primitive
-
- P-PAB-
- ind
-
- PS-pro-
- vider
-
- P-P-ABORT indication primitive
-
- TABLE B-2/X.227
-
- ACPM states for X.410-1984 mode
-
-
-
- Abbrevia
- ted 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
-
-
-
- Abbrevia
- ted Name
-
- Target
-
- Name and description
-
- A-
- ASCind
-
- AC-user
-
- A-ASSOCIATE indication primitive
-
- A-ASC-
- cnf+
-
- AC-user
-
- A-ASSOCIATE confirm primitive
-
- (Result = ╗accepted½)
-
- A-ASC-
- cnf-
-
- AC-user
-
- A-ASSOCIATE confirm primitive
-
- (Result = ╗rejected½)
-
- P-CON-
- req
-
- 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-RLS-
- ind
-
- AC-user
-
- A-RELEASE indication primitive
-
- A-
- RLScnf+
-
- AC-user
-
- A-RELEASE confirm primitive
-
- (Result = ╗affirmative½)
-
- P-REL-
- req
-
- AC-peer
-
- P-RELEASE request primitive
-
- P-REL-
- rsp+
-
- AC-peer
-
- P-RELEASE response primitive
-
- (Result = ╗affirmative½)
-
- ABRind
-
- AC-user
-
- A-ABORT indication primitive
-
- (Source = ╗ACSE service-user½ or ╗ACSE ser-
- vice-provider½)
-
- P-
- UABreq
-
- AC-peer
-
- P-U-ABORT request primitive
-
- (Source = ╗ACSE service-user½ or ACSE service-
- provider½)
-
- A-PAB-
- ind
-
- 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 connec-
- tion
-
- p2
-
- ACPM originated this association
-
- TABLE B-5/X.227
-
- ACPM state table for X.410-1984 mode
-
-
-
- STA0
-
- Idle-
-
- unassoc.
-
- STA1
-
- Await-
- ing
-
- P-CON-
- cnf
-
- STA2
-
- Awaiting
-
- A-
- ASCrsp
-
- STA3
-
- Awaiting
-
- P-REL-
- cnf
-
- STA4
-
- Awaiting
-
- A-
- RLSrsp
-
- STA5
-
- Associat
- ed
-
- A-
- ASCreq
-
- p1
-
- P-
- CONre
-
- STA1
-
- A-
- ASCrsp
- +
-
- P-
- CONrsp
- +
-
- STA5
-
- A-
- ASCrsp-
-
- P-
- CONrsp-
-
- STA0
-
- P-CON-
- ind
-
- p1
-
- A-
- ASCind
-
- STA2;
-
- ^p1:
-
- P-
- CONrsp-
-
- STA0
-
- P-CON-
- cnf+
-
- A-ASC-
- cnf+
-
- STA5
-
- P-CON-
- cnf-
-
- A-ASC-
- cnf-
-
- STA0
-
- A-
- RLSreq
-
- p2
-
- P-REL-
- req
-
- STA3
-
- A-
- RLSrsp+
-
- P-REL-
- rsp+
-
- STA0
-
- P-
- RELind
-
- ^p2
-
- A-RLS-
- ind
-
- STA4
-
- P-REL-
- cnf+
-
- A-
- RLScnf+
-
- STA0
-
- A-
- ABRreq
-
- P-
- UABreq
-
- STA0
-
- P-
- UABreq
-
- STA0
-
- P-
- UABreq
-
- STA0
-
- P-
- UABreq
-
- STA0
-
- P-
- UABreq
-
- STA0
-
- P-UAB-
- ind
-
- A-
- ABRind
-
- STA0
-
- A-
- ABRind
-
- STA0
-
- A-
- ABRind
-
- STA0
-
- A-
- ABRind
-
- STA0
-
- A-
- ABRind
-
- STA0
-
- P-PAB-
- ind
-
- A-PAB-
- ind
-
- STA0
-
- A-PAB-
- ind
-
- STA0
-
- A-PAB-
- ind
-
- STA0
-
- A-PAB-
- ind
-
- STA0
-
- A-PAB-
- ind
-
- STA0
-
- APPENDIX I
-
- (to Recommendation X.227)
-
- Differences between Recommendation X.227 and ISO International Stan-
- dard 8650
-
- Recommendation X.227 and ISO 8650 are technically aligned with the fol-
- lowing exceptions.
-
- I.1 Clause 10 on Conformance of ISO 8650 differs from º 10 on Conform-
- ance in this Recommendation. The text that appears in this Recommenda-
- tion 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-initia-
- tor, 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 mes-
- sage 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.
-