Recommendation T.433 DOCUMENT TRANSFER AND MANIPULATION (DTAM) - SERVICES AND PROTOCOLS - PROTOCOL SPECIFICATION CONTENTS 0 Introduction 1 Scope and field of application 2 References 3 Definitions and abbreviations 4 Conventions 5 Overview of the protocol 5.1 Service provision 5.2 Relationship with other ASEs and lower layer services 5.3 Model of telematic protocol architecture (TPA) Fascicle VII.7 - Rec. T.433 1 6 Elements of procedure 6.1 Summary list of DTAM protocol data units 6.2 DTAM association establishment 6.3 Normal termination of a DTAM association 6.4 Abnormal termination of a DTAM association 6.5 Capability 6.6 Document bulk transfer 6.7 Document unconfirmed manipulation 6.8 Document confirmed manipulation 6.9 Typed data transfer 6.10 Remote document access 6.11 Remote document management 6.12 Token control 6.13 Exception report 6.14 Rules for extensibility 7 Mapping to the lower layer services 7.1 Mapping to the OSI lower layer services 7.2 Mapping to the Recommendation X.215 session service (Transparent mode) 8 Abstract syntax definition of APDUs 8.1 Abstract syntax definition of APDUs in normal mode 8.2 Abstract syntax definition of APDUs for use of session service 9 Conformance Annex A - Reliable transfer modes (Informative) Annex B - DTAM-PM state tables (Transparent mode-reliable transfer mode 1) 0 Introduction This Recommendation specifies the protocol for the services provided by an application- service-element, the Document Transfer and Manipulation Service Element (DTAM) to support applications in a distributed telematic systems environment. This Recommendation is one of a set of Recommendations specifying the protocols for sets of application- service-elements specifically used by a number of applications. 1 Scope and field of application This Recommendation specifies the protocol and procedures for the Document Transfer and Manipulation Service Element (DTAM). The DTAM services are provided in conjunction with the Association Control Service Element (ACSE) service (Recommendation X.217), and the Presentation- service (Recommendation X.216) or the Session-service (Recommendation X.215). Depending on the mapping, Recommendation T.62 bis may also apply. The DTAM procedures are defined in terms of: a) the interaction between peer DTAM protocol machines through the use of the ACSE-service and Presentation-service or Session-service; and b) the interactions between the DTAM protocol machine and its service-user. This Recommendation specifies conformance requirements for systems implementing these procedures. The use of RTSE and/or ROSE is for further study. 2 Fascicle VII.7 - Rec. T.433 2 References References are listed in Recommendation T.432. 3 Definitions and abbreviations Terms and abbreviations are defined in Recommendation T.431. The definitions of service primitive names given in Recommendation T.432 are used in this Recommendation. 4 Conventions This Recommendation specifies the APDU Fields. In  6, tables are presented for each DTAM APDU. Each field is summarized by the following notation: M presence is mandatory U presence is a DTAM service-user option req source is related request primitive ind sink is related indication primitive rsp source is related response primitive cnf sink is related confirm primitive sp source or sink is the DTAM-PM The structure of each DTAM APDU is specified in  8 using the abstract syntax notation of Recommendation X.208. 5 Overview of the protocol 5.1 Service provision The protocol specified in this Recommendation provides the DTAM services defined in Recommendation T.432. These services are listed in Table 1/T.433. 5.2 Relationship with other ASEs and lower layer services 5.2.1 ACSE service (when RTSE is not used) The DTAM services require access to the A-ASSOCIATE, A-RELEASE, A-ABORT, and A-P-ABORT services. The inclusion of the DTAM in an application-context precludes the use of any of the above ACSE services by any other ASE or the use-element. The Transparent Mode of DTAM implies that ACSE can pass through it. Fascicle VII.7 - Rec. T.433 3 TABLE 1/T.433 DTAM services summary w 旼컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � Service � Type � 쳐컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � D-INITIATE � confirmed � � � � � D-TERMINATE � confirmed � � � � � D-P-ABORT � provider-initiated � � � � � D-U-ABORT � unconfirmed � � � � � D-CAPABILITY � confirmed � � � � � D-TRANSFER � provider-confirmed � � � � � D-TYPED-DATA � unconfirmed � � � � � D-CREATE � unconfirmed � � � � � D-DELETE � unconfirmed � � � � � D-MODIFY � unconfirmed � � � � � D-CALL � unconfirmed � � � � � D-REBUILD � unconfirmed � � � � � D-TOKEN-GIVE � unconfirmed � � � � � D-CONTROL-GIVE � unconfirmed � � � � � D-TOKEN-PLEASE � unconfirmed � � � � � D-P-EXCEPTION-REPORT � provider-initiated � � � � � D-U-EXCEPTION-REPORT � unconfirmed � 읕컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 Note - D-REBUILD service is for further study. 5.2.2RTSE service The use of this ASE is for further study. 5.2.3ROSE service The use of this ASE is for further study. 5.2.4Presentation-service DTAM services may require access to the P-ACTIVITY-START, P-DATA, P-MINOR- SYNCHRONIZE, P-ACTIVITY-END, P-ACTIVITY-INTERRUPT, P-ACTIVITY-DISCARD, P-U-EXCEPTION- REPORT, P-ACTIVITY-RESUME, P-P-EXCEPTION-REPORT, P-TOKEN-PLEASE, P-CONTROL-GIVE and P- TOKEN-GIVE services. This Recommendation recognizes that the ACSE services require access to the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services. The inclusion of the DTAM in an application-context precludes the use of any of the above, or of any other, presentation-services by any other ASE or the user element. 4 Fascicle VII.7 - Rec. T.433 5.2.5Recommendation X.215 session-service In the Transparent Mode of operation APDUs defined in DTAM are directly mapped to the session service defined in Recommendation X.215. When the Transparent Mode is used the procedure described in Recommendation T.62 bis also apply. DTAM services may require access to the S-CONNECT, S-ACTIVITY-START, S-DAT , S- MINOR- SYNCHRONIZE, S-ACTIVITY-EN , S-ACTIVITY-INTERRUPT, S-ACTIVITY-DISCARD, S-U- EXCEPTION-REPORT, S-ACTIVITY-RESUME, S-P-EXCEPTION-REPORT, S-TOKEN-PLEASE, S-CONTROL- GIVE, P-TOKEN-GIVE, S-RELEASE, S-U-ABORT and S-P-ABORT services. 5.3 Model of telematic protocol architecture (TPA) The DTAM operates between two DTAM Protocol Machines (DTAM-PMs) in the Application layer of the OSI model. Protocol elements are exchanged between DTAM-PMs, using the Session service as defined in Recommendation X.215 or the services of ACSE and of the Presentation Layer as defined in Recommendations X.217 and X.216 respectively. The model for Telematic Protocol Architecture (TPA) is illustrated in Figure 1/T.433. This application layer protocol architecture is composed of the ACSE (Association Control Service Element), DTAM-SE (Service Element), and DTAM users. Use of the Reliable Transfer Service Element (RTSE), Remote Operation Service Element (ROSE) and Message Handling Systems (MHS) is for further study. Note - In the case of use of the Session-service (Transparent Mode), the appropriate DTAM APDUs are directly mapped to the Session-service primitives. FIGURE 1/T.433 Telematic protocol architecture (TPA) model in application layer 5.3.1Functions of DTAM user DTAM users have the role of accurately reflecting the actual telematic user (i.e. terminal or system user) intentions in communication, and have functions to perform the applications (Document bulk transfer, document manipulation, document transfer and manipulation etc.) on behalf of the actual user. This mechanism is provided by the use of the DTAM-SE through the DTAM service defined in Recommendation T.432. The DTAM service is the logical interface between the DTAM user and DTAM service-provider for data handling, and is independent of specific hardware and software technique. Fascicle VII.7 - Rec. T.433 5 The DTAM user as an Application Service Element (including the user element) may be capable of interpreting the meaning of the content of an exchanged document. For example, the retrieval command carried during information retrieval is not interpreted by the DTAM, but by the DTAM user. 5.3.2Functions of DTAM service-provider To realize single-source management of document architecture for telematic services, DTAM service-provider provides the following communication functions. 1) Association use control (kernel) DTAM provides the trigger for the use of the association given in ACSE, and controls association use during communication (termination, abort, etc.). Applying the Session- service to the lower layer functions of DTAM, this association use control will be mapped directly onto the session kernel functional unit. 2) DTAM capability The DTAM capability is defined by a set of parameters in order to specify the communication features which contains the parameters: a) document application profile; b) operational application profile; c) non-basic document characteristics; d) non-basic structural characteristics, etc. 3) Data transmission function DTAM provides functions for document bulk transfer, document manipulations and typed data transmission as follows: a) Document bulk transfer DTAM provides a function to transmit the document in bulk under the communications environment negotiated by D-INITIATE service and additionally by D-CAPABILITY service; b) Document manipulations DTAM provides a function partially modifying a document seen by both users, by generating, revising or deleting structures (pages, blocks etc.) of an existing document or to create a new document by generating structure of ODA and Operational Structure; c) Typed data transmission DTAM optionally provides a typed data transmission function which is independent of data token control. 4) Document remote access For further study. 5) Document remote management For further study. 6) Token control DTAM optionally provides the function of Token control to handle the data token for dialogue. 7) Reliable transfer (support function) DTAM optionally provides the function of reliable transfer to ensure reliable communication. Two Reliable Transfer Modes are introduced (see  6.6.1.4). 8) Exception report DTAM optionally provides the exception reporting function for error control during the DTAM communication. 6 Fascicle VII.7 - Rec. T.433 9) Storage capacity negotiation DTAM optionally provides the Storage Capacity Negotiation to indicate its own capacity to the peer. 6 Elements of procedure This section identifies all the types of protocol data units which constitute the elements of the DTAM protocol between two DTAM-protocol-machines (DTAM-PMs). A protocol data unit (PDU) is the smallest quantity of information exchanged between DTAM-PMs which has a self-contained semantic significance. When a DTAM service primitive is received from the DTAM user, DTAM transmits the DTAM primitive data to the opposite DTAM through the DTAM protocol, then the opposite DTAM generates the DTAM service primitives and notifies its DTAM user. The DTAM protocol data units (D-PDU) are shown in Table 2/T.433. Individual parameters of DTAM service primitives are, in principle, all mapped to individual PDU parameters, but there are PDU including parameters other than those specified in service primitives, such as those generated by DTAM itself. For example, D- INITIATE-REQ PDU also includes the DTAM protocol version parameter, which is used to negotiate the version of protocol between the DTAM-PMs. Note that the DTAM user is not concerned with this DTAM negotiation. The PDUs are here identified symbolically with minimal reference to their mapping on to the lower layer service functions which implement them, thus no differentiation is made, in this section, between PDUs which are effected as specific Presentation service primitives and PDUs which are transferred as DTAM PDUs using the Presentation service data transfer functions. Details of PDU mapping and encoding are given in  8. PDUs are given both full names, which should be used outside the context of this Recommendation, and abbreviated names which are used within this Recommendation for brevity. The full names consist of one or two words descriptive for the purpose of the PDU, prefixed by D- and, in the case of request/response pairs of PDUs, suffixed by -REQ or -RESP as appropriate. The abbreviated names are three letters each, with Q or R appended in the case of request/response pairs. 6.1 Summary list of DTAM protocol data units TABLE 2/T.433 DTAM protocol data units w 旼컴컴컴컴컴컴컫컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴� � Functional � PDU � Protocol elements � Reference � � Units � abbrev. � (PDU) � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴� � � DINQ � D-INITIATE-REQ � 6.2 � � � � � � � Association � DINR � D-INITIATE-RESP � 6.2 � � use control � � � � � (kernel) � DTEQ � D-TERMINATE-REQ � 6.3 � � � � � � � � DTER � D-TERMINATE-RESP � 6.3 � � � � � � � � DAB � D-ABORT � 6.4 � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴� � � DCPQ � D-CAPABILITY-REQ � 6.5 � � Capability � � � � � � DCPR � D-CAPABILITY-RESP � 6.5 � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴� Fascicle VII.7 - Rec. T.433 7 � Document � None � None � 6.6 � � Bulk transfer� � � � 읕컴컴컴컴컴컴컨컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴� 8 Fascicle VII.7 - Rec. T.433 TABLE 2/T.433 (Cont.) w 旼컴컴컴컴컴컴컫컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴커 � Functional � PDU � Protocol elements � Reference � � Units � abbrev. � (PDU) � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � � DCR � D-CREATE � 6.7 � � � � � � � Document � DDL � D-DELETE � 6.7 � � unconfirmed � � � � � manipulation � DMD � D-MODIFY � 6.7 � � � � � � � � DCL � D-CALL � 6.7 � � � � � � � � DRD � D-REBUILD [Further study] � 6.7 � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � Document � � � � � confirmed � � [Further study] � 6.8 � � manipulation � � � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � Typed data � DTD � D-TYPED-DATA � 6.9 � � transmission � � � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � Remote � � � � � document � � [Further study] � 6.10 � � access � � � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � Remote � � � � � document � � [Further study] � 6.11 � � management � � � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 쿟oken control � DTP � D-TOKEN-PLEASE � 6.12 � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � � � None � � � Exception � None � - user-exception-report � � � report � � � 6.13 � � � � - provider-exception- � � � � � report � � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴캑 � � � � � � Reliable � � � � � transfer � None � None � 6.6 � � (support) � � � � 읕컴컴컴컴컴컴컨컴컴컴컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴켸 6.2 DTAM association establishment 6.2.1Purpose The DTAM association establishment procedure is used to establish an association of DTAM between two AEs. It supports the D-INITIATE service. 6.2.2APDUs used The DTAM association establishment procedure uses the D-INITIATE-REQ (DINQ) and the D-INITIATE-RESP (DINR) APDUs. 6.2.2.1 DINQ APDU The fields of the DINQ APDU are listed in Table 3/T.433. Fascicle VII.7 - Rec. T.433 9 TABLE 3/T.433 DINQ APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컫컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴� � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컵컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴� � Service classes � (see Note 2) � request � indication � � (see Note 1) � � � � � Telematic requirements � M � request � indication � � (see Note 1) � � � � � Application capabilities � M � request � indication � � Protocol version � U � sp � sp � � (see Note 1) � � � � � DTAM QOS � U � request � indication � � (see Note 1) � � � � � Account � U � request � indication � � (see Note 1) � � � � � Window size � U � request � indication � � Storage capacity � U � request � indication � � User information � U � request � indication � � (see Note 1) � � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컨컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴� Note 1 - These parameters are not applicable in transparent mode. Note 2 - The use of this parameter is for further study. 6.2.2.2DINR APDU The fields of the DINR APDU are listed in Table 4/T.433. TABLE 4/T.433 DINR APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컫컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴� � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컵컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴� � Telematic requirements � U � response � confirmation � � (see Note) � � � � � � � � � � Application capabilities � M � response � confirmation � � � � � � � Protocol version � U � sp � sp � � (see Note) � � � � � DTAM QOS � U � response � confirmation � � (see Note) � � � � � � � � � � Result � M � response � confirmation � � (see Note) � � � � � � � � � � Window size � U � response � confirmation � � � � � � � Storage capacity � U � response � confirmation � � � � � � � User information � U � response � confirmation � � (see Note) � � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컨컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴� Note - These parameters are not applicable in transparent mode. 10 Fascicle VII.7 - Rec. T.433 6.2.3DTAM association establishment procedure 6.2.3.1 DTAM association establishment procedure mapped onto ACSE service (normal mode: OSI) This procedure is driven by the following events: a) a D-INITIATE request primitive from the requestor; b) a DINQ APDU as User Data on an A-ASSOCIATE indication primitive; c) a D-INITIATE response primitive from the responder; and d) an A-ASSOCIATE confirm primitive (that may contain a DINR APDU); 6.2.3.1.1 D-INITIATE request primitive 6.2.3.1.1.1 The requesting DTAM-PM forms a DINQ APDU from parameter values of the D- INITIATE request primitive and its stored data in DTAM-PM (the Protocol Version field, etc.) It issues an A-ASSOCIATE request primitive also using information fr m the D- INITIATE request primitive. The User Data parameter of the A-ASSOCIATE request primitive contains the DINQ APDU. 6.2.3.1.1.2 The requesting DTAM-PM waits for a primiti e from the ACSE service- provider, and does not accept any other primitive from the requestor other than a D-U- ABORT request primitive. 6.2.3.1.2 DINQ APDU 6.2.3.1.2.1 The responding DTAM-PM receives a DINQ APDU from its peer as User data on an A-ASSOCIATE indication primitive. If any of the parameters of the A-ASSOCIATE indication primitive or the fields in the DINQ APDU are unacceptable to this DTAM-PM, it forms a DINR APDU with the appropriate rejecting Result field, and sends the DINR APDU as User Data on an A-ASSOCIATE response primitive. The Result parameter on the A-ASSOCIATE response primitive specifies "user-rejection". The DTAM-PM does not issue a D-INITIATE indication primitive to the responder, and the association is not established. 6.2.3.1.2.2 If the A-ASSOCIATE indication primitive and its DINQ APDU are acceptable to the responding DTAM-PM, it issues a D-INITIATE indication primitive to the responder. The D-INITIATE indication primitive parameters are derived from the DINQ APDU and from the A-ASSOCIATE indication primitive. The DTAM-PM waits for a D-INITIATE response primitive from the responder and does not accept any other primitives from the responder except for the D-U-ABORT request primitive. 6.2.3.1.3 D-INITIATE response primitive 6.2.2.1.3.1 When the DTAM-PM receives the D-INITIATE response primitive, the Result parameter specifies whether the responder has accepted or rejected the DTAM association. The DTAM-PM forms a DINR APDU using the D-INITIATE response primitive parameters. The DINR APDU is sent as the User Data parameter on the A-ASSOCIATE response primitive. 6.2.3.1.3.2 If the responder accepted the DTAM association request, the Result parameter on the related A-ASSOCIATE response primitive specifies "accepted", and the Result field of the outgoing DINR APDU also specifies "accepted". The DTAM association is established. 6.2.3.1.3.3 If the responder rejected the DTAM association request, the Result parameter on the related A-ASSOCIATE response primitive specifies "Result: rejected (permanent or transient)" and "Source: ACSE service-user", and the Result field of the outgoing DINR APDU contains the appropriate rejection value. The DTAM association is not established. 6.2.3.1.4 A-ASSOCIATE confirm primitive 6.2.3.1.4.1 The requesting DTAM-PM receives an A-ASSOCIATE confirm primitive. The following situations are possible: a) the DTAM association has been accepted; b) the responding DTAM-PM or the responder has rejected the DTAM association; or c) the association service-provider has rejected the related association. 6.2.3.1.4.2 If the DTAM association was accepted, the A-ASSOCIATE confirm primitive Fascicle VII.7 - Rec. T.433 11 Result parameter specifies "accepted". The User Data parameter contains a DINR APDU, and the Result field of the DINR APDU also specifies "accepted". The requesting DTAM-PM issues a D-INITIATE confirm primitive to the requestor based on parameters from the A- ASSOCIATE confirm primitive and from the DINR APDU. The D-INITIATE confirm primitive Result parameter specifies "accepted", and the DTAM association is established. 12 Fascicle VII.7 - Rec. T.433 6.2.3.1.4.3 If the DTAM association was rejected by either the responding DTAM-PM or by the responder, the A-ASSOCIATE confirm primitive Result parameter specifies "Result: rejected (permanent or transient)" and "Source: ACSE service-user". The User Data parameter contains a DINR APDU, and the Result field of the DINR APDU indicates the reason for rejection. The requesting DTAM-PM issues a D-INITIATE confirm primitive to the requestor based on parameters from the A-ASSOCIATE confirm primitive and from the DINR APDU. The D-INITIATE confirm primitive Result parameter contains the appropriate rejection value. The DTAM association is not established. 6.2.3.1.4.4 If the association was rejected by the association service-provider, the A-ASSOCIATE confirm primitive Result parameter specifies "Result: rejected (permanent or transient)" and "Source: ACSEservice-provider". In this situation, the User Data field is not used by the requesting DTAM-PM. The requesting DTAM-PM issues a D-INITIATE confirm primitive with the appropriate Result parameter. The DTAM association is not established. 6.2.3.2 DTAM association establishment procedure mapped onto session service (transparent mode) This procedure is driven by the following events: a) a D-INITIATE request primitive from the requestor; b) a DINQ APDU as User Data on an S-CONNECT indication primitive; c) a D-INITIATE response primitive from the responder; and d) an S-CONNECT confirm primitive (that may contain a DINR APDU); 6.2.3.2.1 D-INITIATE request primitive 6.2.3.2.1.1 The requesting DTAM-PM forms a DINQ APDU from parameter values of the D- INITIATE request primitive and its stored data in DTAM-PM (the Checkpoint Window field, etc.). It issues an S-CONNECT request primitive also using information from t e D- INITIATE request primitive. The User Data parameter of the CONNECT request primitive contains the DINQ APDU. 6.2.3.2.1.2 The requesting DTAM-PM waits for a primitive from the Sessi n service- provider and does not accept any other primitive from the requestor other than a D-U ABORT request primitive. 6.2.3.2.2 DINQ APDU 6.2.3.2.2.1 The responding DTAM-PM receives a DINQ APDU from its peer as User Data on an S-CONNECT indication primitive. If any of the parameters of the S-CONNECT indication primitive or the fields in the DINQ APDU are unacceptable to this DTAM-PM (e.g.m no Session User Data in the S-CONNECT indication,) it issues an S-CONNECT response primitive specified "ss-user-rejection". In this situation, the responding session service-provider issues RSSN (Response Session Start Negative). The DTAM-PM does not issue a D-INITIATE indication primitive to the responder. The association is not established. 6.2.3.2.2.2 If the S-CONNECT indication primitive and its DINQ APDU are acceptable to the responding DTAM-PM, it issues a D-INITIATE indication primitive to the responder. The D-INITIATE indication primitive parameters are derived from the DINQ APDU. The DTAM-PM waits for a D-INITIATE response primitive from the responder and does not accept any other primitives from the responder except for the D-U-ABORT request primitive. 6.2.3.2.3 D-INITIATE response primitive 6.2.3.2.3.1 When the DTAM-PM receives the D-INITIATE response primitive, the Result parameter specifies whether the responder has accepted or rejected the DTAM association. If the DTAM association is accepted, the DTAM-PM forms a DINR APDU using the D-INITIATE response primitive parameters. The DINR APDU is sent as the User Data parameter on the S- CONNECT response primitive. Fascicle VII.7 - Rec. T.433 13 6.2.3.2.3.2 If the responder accepted the DTAM association request, the Result parameter on the related S-CONNECT response primitive specifies "accept". The DTAM association is established. 6.2.3.2.3.3 If the responder rejected the DTAM association request, the Result parameter on the related S-CONNECT response primitive specifies "user-rejection" and DTAM-PM does not send DINR APDU. 14 Fascicle VII.7 - Rec. T.433 6.2.3.2.4 S-CONNECT confirm primitive 6.2.3.2.4.1 The requesting DTAM-PM receives an S-CONNECT confirm primitive. The following situations are possible; a) the DTAM association has been accepted; b) the responding DTAM-PM or the responder has rejected the DTAM association; or c) the Session service-provider has rejected the related association. 6.2.3.2.4.2 If the DTAM association was accepted, the S-CONNECTION confirm primitive Result parameter specifies "accept". The User Data parameter contains a DINR APDU. The requesting DTAM-PM issues a D-INITIATE confirm primitive to the requestor based on parameters from the S-CONNECT confirm primitive and from the DINR APDU. The D-INITIATE confirm primitive Result parameter specifies "accepted". The DTAM association is established. 6.2.3.2.4.3 If the DTAM association was rejected by either the responding DTAM-PM or by the responder, the S-CONNECT confirm primitive Result paramet r specifies "user- rejection" and there is no User Data (DINR APDU) in this confirm primitive. The requesting DTAM-PM issues a D-INITIATE confirm primitive to the requestor based on parameters from the S-CONNECT confirm primitive. The D-INITIATE confirm primitive Result parameter contains the value of "user-rejection", and the DTAM association is not established. 6.2.3.2.4.4 If the association was rejected by the session service-provider, the S CONNECT confirm primitive Result parameter specifies "provider-rejection". In this situation, the User Data field is not used by the requesting DTAM-PM. The requesting DTAM-PM issues a D-INITIATE confirm primitive with the appropriate Result parameter. The DTAM association is not established. 6.2.4Use of the DINQ/DINR APDU fields The DINQ APDU and DINR APDU fields are used as follows. 6.2.4.1 Service classes The use of this parameter is for further study. 6.2.4.2 Telematic requirements This is the Telematic Requirements parameter value from the D-INITIATE request/response primitives. It appears as the Telematic Requirements parameter value of D-INITIATE indication/confirm primitives respectively. If the Telematic Requirements proposed by the requestor are not acceptable to the responder, the DTAM association fails to be established. 6.2.4.3 Application capabilities This is the Application Capabilities parameter value from the D-INITIATE request/response primitives. It appears as the Application Capabilities parameter value of the D-INITIATE indication/confirm primitives respectively. This parameter consists of sets of the following sub- parameters. 6.2.4.3.1 Document application profile The value of this parameter is either an Octet String or ASN.1 object identifiers. The Octet String designates the document application profile in line with the Recommendation T.73 (Document Application Profile - T.73). The ASN.1 object identifier must conform to the rules specified in ISO 8824 and designate an application profile defined in accordance with the rules specified in Recommendation T.411 (Document Application Profiles). 6.2.4.3.2 Document architecture class The value of this parameter is "formatted". 6.2.4.3.3 Non basic document characteristics The value of this parameter is any combination of Non Basic Document Characteristics Fascicle VII.7 - Rec. T.433 15 defined in Recommendation T.414. 6.2.4.3.4 Non basic structural characteristics The value of this parameter is any combination of Non Basic Structural Characteristics defined in Recommendation T.414. 16 Fascicle VII.7 - Rec. T.433 6.2.4.3.5 Operational application profile The detailed specification of the Operational Application Profile is for further study. 6.2.4.4 Protocol version This identifies the version of the DTAM protocol in use by the requesting DTAM-PM. 6.2.4.5 DTAM QOS DTAM QOS is left for further study. 6.2.4.6 Account The account parameter identifies the account to which costs incurred in the DTAM association which is being established are to be charged. Note - The use of this parameter is for further study. 6.2.4.7 Window size The requested checkpoint window parameter indicates, for each direction of transmission, the maximum number of checkpoints which may remain unacknowledged. This parameter is conditional upon the recovery or restart procedures under the reliable transfer, in which case it is mandatory. Checkpoints are only inserted by the sender of a document. Values of this parameter may be the reason for subsequent termination. The continued progress of the service is only guaranteed if the entity acting as receiver gives acknowledgments within this limit. The window size is stated independently by each entity as the maximum value for when that entity is the receiving entity. There is no negotiation. The values for each direction of data transfer are not necessarily the same. The parameter is an integer. 6.2.4.8 Storage capacity In a Normal Mode, this parameter is optionally used by each of two DTAM-PMs to indicate its own capacity to the peer. After the negotiation, if the storage capacity of the receiving DTAM-PM is smaller than the largest segment of document information (see  6.6) according to the checkpoint rule, the sending DTAM-PM shall not transfer the document and D-P-EXCEPTION indication should be issued to the requesting DTAM user (sender of documents). However, for some applications under a Transparent Mode, this parameter is used by the sending DTAM-PM to indicate a w'required storage capacityw' to the peer machine. The receiving DTAM-PM uses this parameter to respond whether it is able to provide this storage capacity or not, so as to maintain compatibility with the old implementation based on Recommendation T.73. 6.2.4.9 Result If the DINQ APDU was rejected by the responding DTAM-PM (i.e., a D-INITIATE indication primitive was not issued to the responder), this field is supplied by the responding DTAM-PM, otherwise, this field is the Result parameter from the D-INITIATE response primitive. In either situation, it appears as the Result parameter on the D INITIATE RESP (DINR) APDU. This field can take one of the following symbolic values: - accepted; - rejected by responder (reason-not-specified); - rejected by responder (protocol Version-not-supported); - rejected by responder (DTAMQOS-not-supported); - rejected by responder (application-context-not-supported); - rejected by responding DTAM-PM. Fascicle VII.7 - Rec. T.433 17 6.2.4.10User information This is the User Information parameter from the D-INITIATE request and response primitive. It appears as the User Information parameter of the D-INITIATE indication and confirm primitive respectively, if issued. 18 Fascicle VII.7 - Rec. T.433 6.2.5Collisions and interactions For further study. 6.3 Normal termination of a DTAM association 6.3.1Purpose This procedure is used for the normal termination of a DTAM association by an AE without loss of information in transit. It supports the D-TERMINATE service. 6.3.2APDUs used The normal termination procedure uses the D-TERMINATE-REQ (DTEQ) APDU and the D- TERMINATE-RESP (DTER) APDU. 6.3.2.1 DTEQ APDU The fields of the DTEQ APDU are listed in Table 5/T.433. TABLE 5/T.433 DTEQ APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컫컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴� � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컵컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴� � User information � U � request � indication � � (see Note) � � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컨컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴� Note - This parameter is not applicable in transparent mode. 6.3.2.2DTER APDU The fields of the DTER APDU are listed in Table 6/T.433. TABLE 6/T.433 DTER APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컫컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴� � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컵컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴� � Charging � U � response � confirmation � � (see Note) � � � � � User information � U � response � confirmation � � (see Note) � � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컨컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴� Note - These parameters are not applicable in transparent mode. 6.3.3Normal termination procedure 6.3.3.1Normal termination procedure mapped onto ACSE service (normal mode) This procedure is driven by the following events: a)a D-TERMINATE request primitive from the requestor; b)a DTEQ APDU as User Data on an A-RELEASE indication primitive; c)a D-TERMINATE response primitive from the responder; and d)a DTER APDU as User Data on an A-RELEASE confirm primitive. Fascicle VII.7 - Rec. T.433 19 6.3.3.1.1 D-TERMINATE request primitive 6.3.3.1.1.1 When a D-TERMINATE request primitive is received, the DTAM-PM sends a DTEQ APDU as User Data on an A-RELEASE request primitive using the parameters from t e D- TERMINATE request primitive. Note - The requestor is required to meet the association (presentation and session) requirements in order to issue a D-TERMINATE request primitive. 6.3.3.1.1.2 The requesting DTAM-PM now waits for a primitive from the association service-provider. It does not accept any primitives from the requestor other than a D-U- ABORT request primitive. 6.3.3.1.2 DTEQ APDU 6.3.3.1.2.1 When the responding DTAM-PM receives the DTEQ APDU as User Data on an A- RELEASE indication primitive, it issues a D-TERMINATE indication primitive to the responder. 6.3.3.1.3 D-TERMINATE response primitive 6.3.3.1.3.1 The responding DTAM-PM forms a DTER APDU from the response primitive parameters. The DTER APDU is sent as User Data on an A-RELEASE response primitive. The Result parameter of A-RELEASE response has the value "affirmative. Note - The responder is able to reject the termination request of DTAM association only in the case of selecting a negotiated release session functional unit. The use of this functional unit is for further study. 6.3.3.1.4 DTER APDU 6.3.3.1.4.1 The requesting DTAM-PM receives an A-RELEASE confirm primitive containing a DTER APDU from its peer. The Result parameter on the A-RELEASE confirm specifies either that the responder agrees or disagrees that the DTAM association may be terminated. The requesting DTAM-PM forms a D-TERMINATE confirm primitive from the DTER APDU. 6.3.3.2 Normal termination procedure mapped onto session service (transparent mode) This procedure is driven by the following events: a) a D-TERMINATE request primitive from the requestor; b) an S-RELEASE indication primitive without sending DTEQ APDU; c) a D-TERMINATE response primitive from the responder; and d) an S-RELEASE confirm primitive without sending DTER APDU. 6.3.3.2.1 D-TERMINATE request primitive 6.3.3.2.1.1 When a D-TERMINATE request primitive is received, the DTAM-PM issues an S- RELEASE request primitive without any SS-user-data. Note - The requestor is required to meet the association (presentation and session) requirements in order to issue a D-TERMINATE request primitive. 6.3.3.2.1.2 The requesting DTAM-PM now waits for a primitive from the Session service- provider. It does not accept any primitives from the requestor other than a D-U-ABORT request primitive. 6.3.3.2.2 Implicit DTEQ APDU 6.3.3.2.2.1 When the responding DTAM-PM receives an S-RELEASE indication primitive, it issues a D-TERMINATE indication primitive to the responder without any parameters. 6.3.3.2.3 D-TERMINATE response primitive 6.3.3.2.3.1 The responding DTAM-PM forms an S-RELEASE response from the D-TERMINATE response primitive parameters. The Result parameter of S-RELEASE response has the value "affirmative". 6.3.3.2.4 Implicit DTER APDU 20 Fascicle VII.7 - Rec. T.433 6.3.3.2.4.1 The requesting DTAM-PM receives an S-RELEASE confirm primitive containing no DTAM APDU from its peer. The Result parameter on the S-RELEASE confirm always specifies "affirmative". The requesting DTAM-PM forms a D-TERMINATE confirm primitive from the S-RELEASE confirm primitive and issues it to the requestor with no parameters. Fascicle VII.7 - Rec. T.433 21 6.3.4Use of the DTEQ APDU fields The DTEQ APDU fields are used as specified below. 6.3.4.1 User information This is the User Information parameter on the D-TERMINATE request primitive. It appears as the User Information parameter of the D-TERMINATE indication primitive. 6.3.5Use of the DTER APDU fields The DTER APDU fields are used as specified below. 6.3.5.1 Charging The charging parameter conveys information on the costs attributed to the account during the DTAM association which is being released. The value of this parameter is for further study. The charging parameter if present at the end of a DTAM association, only if the account parameter was present at the beginning of that DTAM association. It is not mandatory to return a charge if that charge is zero. 6.3.5.2 User information This is the User Information parameter from the D-TERMINATE response primitive. It appears as the User Information parameter on the D-TERMINATE confirm primitive. 6.3.6Collisions and interactions 6.3.6.1 D-TERMINATE service Overlapping attempts by request in both AEs to terminate their DTAM association are governed by the A-RELEASE service or S-RELEASE Session service. The DTAM association is terminated. Note - A D-terminate service collision can not occur if session tokens were selected for the association. Only a request in the AE that owns all of the available session tokens can issue the D-TERMINATE request primitive. 6.3.6.2 D-U-ABORT service, DAB APDU or A-P-ABORT service If either DTAM-PM receives a D-U-ABORT request primitive, a DAB APDU (as User Data on a A(or S)-U-ABORT indication primitive) or a A(orS)-P-ABORT indication primitive, it discontinues the normal DTAM association termination procedure, and instead follows abnormal termination procedure. 6.4 Abnormal termination of a DTAM association 6.4.1Purpose 6.4.1.1 The abnormal termination can be used at any time to force the abrupt termination of the DTAM association by a requestor in either DTAM user, by either DTAM- PM, by the ACSE service-provider or by the Session service-provider. It supports the D-U- ABORT, D-P-ABORT and A-P-ABORT or S-P-ABORT services. 6.4.1.2 The Abnormal Termination provides the following three procedures: a) user-abort procedure; b) association-provider-abort procedure; c) transfer-abort procedure. 6.4.2APDUs used The abnormal termination uses the D-ABORT (DAB) APDU. 22 Fascicle VII.7 - Rec. T.433 6.4.2.1 DAB APDU The fields of the DAB APDU are listed in Table 7/T.433. Fascicle VII.7 - Rec. T.433 23 TABLE 7/T.433 DAB APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컫컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴� � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컵컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴� � Abort source � M � sp � indication � � (see Note) � � � � � Abort reason � U � sp � indication � � (see Note) � � � � � Reflect parameter � U � sp � indication � � (see Note) � � � � � User information � U � request � indication � � (see Note) � � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컨컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴� Note - These parameters are not applicable in transparent mode. 6.4.3Abnormal termination procedure 6.4.3.1Abnormal termination procedure mapped onto ACSE service (normal mode) This procedure is driven by the following events: User-abort procedure - a D-U-ABORT request primitive from the requestor; - a DAB APDU as User Data on an A-U-ABORT indication primitive; Association-provider-abort procedure - an A-P-ABORT indication primitive from the ACSE-service or Transfer-abort procedure - a severe error detected by a DTAM-PM. 6.4.3.1.1 D-U-ABORT request primitive (user-abort procedure) 6.4.3.1.1.1 When a DTAM-PM receives a D-U-ABORT request primitive, it sends a D-ABORT (DAB) APDU as User Data on an A-U-ABORT request primitive. The DAB APDU "Abort Source" field is specified as a "requestor". If the User Information parameter was included on the D-U-ABORT request primitive, it is included in the DAB APDU. The DTAM association is terminated. 6.4.3.1.2 DAB APDU 6.4.3.1.2.1 When a DTAM-PM receives an A-U-ABORT indication primitive, the User Data parameter contains the DAB APDU. The DTAM-PM issues a D-U-ABORT indication primitive with the Abort Source field of the DAB APDU. If a User Information field was contained in the DAB APDU, it is included in the D-U-ABORT indication primitive. The DTAM association is terminated. 6.4.3.1.3 A-P-ABORT indication primitive (association-provider-abort procedure) 6.4.3.1.3.1 When a DTAM-PM receives an A-P-ABORT indication primitive, the DTAM-PM issues a D-P-ABORT indication primitive to the DTAM user. The DTAM association is terminated. 6.4.3.1.3.2 An association-provider-abort is indicated to both DTAM-PMs by n A-P- 24 Fascicle VII.7 - Rec. T.433 ABORT indication primitive and may occur at any time. After such an event, when the Reliable Transfer Mode 2 was selected, the association-initiating DTAM-PM starts the association-recovery procedure. Note - The association-recovery procedure is for further study. Fascicle VII.7 - Rec. T.433 25 6.4.3.1.3.3 If the association-provider-abort procedure was performed during the transfer procedure the requesting DTAM-PM starts the transfer-resumption procedure after the association-recovery procedure is successfully completed. If the association-recovery procedure was not successfully completed the requesting DTAM-PM performs the transfer- error procedure and the provider-abort procedure. 6.4.3.1.4 Error detections by a DTAM-PM (transfer-abort procedure) 6.4.3.1.4.1 When a DTAM-PM detects severe error situations, it performs the transfer- abort procedure followed by issuing a D-P-ABORT indication primitive. 6.4.3.1.4.2 The transfer-abort procedure is performed to send a DAB APDU as User Data on an A-U-ABORT request primitive. The DAB APDU "Abort Source" field is specified as a "DTAM service-provider" and additional DAB APDU parameters are specified to inform a peer DTAM-PM of the situation of the severe error. Following the transfer-abort procedure, the DTAM-PM issues a D-P-ABORT indication primitive to its service-user. 6.4.3.1.4.3 The use of association-recovery procedure (see  6.6.8) is for further study. 6.4.3.2 Abnormal termination procedure mapped onto session service (transparent mode) This procedure is driven by the following events: User-abort procedure - a D-U-ABORT request primitive from the requestor; - an S-U-ABORT indication primitive without sending a DAB APDU; Association-provider-abort procedure - an S-P-ABORT indication primitive from the Session-service or Transfer-abort procedure - a protocol error detected by a DTAM-PM. 6.4.3.2.1 D-U-ABORT request primitive (user-abort procedure) 6.4.3.2.1.1 When a DTAM-PM receives a D-U-ABORT request primitive, it issues a S-U ABORT request primitive without sending a DAB APDU. The using of S-U-ABORT service will be interpreted as "Local Terminal Error". The DTAM association is terminated. 6.4.3.2.2 Implicit DAB APDU 6.4.3.2.2.1 When a DTAM-PM receives an S-U-ABORT indication primitive, the DTAM-PM issues a D-U-ABORT indication primitive with the Abort Source field as "requestor". The DTAM association is terminated. 6.4.3.2.3 S-P-ABORT indication primitive (association-provider-abort procedure) 6.4.3.2.3.1 When a DTAM-PM receives an S-P-ABORT indication primitive, the DTAM-PM issues a D-U-ABORT indication primitive to the responder. The DTAM association is terminated. 6.4.3.2.4 Protocol errors (transfer-abort procedure) 6.4.3.2.4.1 When a DTAM-PM detects an invalid condition such as an unexpected APDU, it issues an S-U-ABORT request primitive without DAB APDU as the User Data. The DTAM-PM also issues a D-P-ABORT indication primitive to its service-user. The DTAM association is terminated. 6.4.4Use of the ABORT APDU fields The ABORT APDU fields are used as specified below. 26 Fascicle VII.7 - Rec. T.433 6.4.4.1 Abort source This is supplied by the requesting DTAM-PM. It is included in t e resulting D- U(orP)-ABORT indication primitive. This field can take one of the following symbolic values: - DTAM service-provider; or - requestor. Fascicle VII.7 - Rec. T.433 27 6.4.4.2 Abort reason This field may contain one of the following values: - local-system-problem - invalid-parameter the invalid parameters are specified in the Reflected- parameter field - unrecognized-activity - temporary-problem no attempt at association-recovery should be made for a period of time determined by a local rule - protocol-error of the DTAM-PM - permanent-error this value is used solely by t e DTAM provider- abort procedure in normal-mode - transfer-completed the responding DTAM-PM could not discard an already completed transfer 6.4.4.3 Reflected-parameter The Reflected-Parameter field is a bit string that identifies which parameters are regarded as invalid parameters in the primitive received from the used service by the aborting DTAM-PM before the association-abort. The order of the bits in the bit string is the same as the order of the parameters in the tables of service parameters in Recommendations X.216 and X.217 (i.e. bit 1 represents the first parameter, etc). 6.4.4.4 User information This is the information parameter from the D-U-ABORT request primitive. It appears as the User Information parameter on the D-U-ABORT indication primitive. 6.4.5Collisions and interactions The abnormal termination procedure may be used whenever a DTAM association is established, is in process of being established, or is being normally terminated. This procedure disrupts any other currently active procedure. An A-P-ABORT indication primitive can disrupt the D-U-ABORT exchange with loss of the user information in D-U- ABORT service. Collisions of DAB APDUs are governed by the A-U- ABORT service. 6.5 Capability 6.5.1Purpose It supports the D-CAPABILITY service. 6.5.2APDUs used The DTAM capability procedure uses the D-CAPABILITY-REQ (DCPQ) and the D-CAPABILITY RESP (DCPR) APDUS 6.5.2.1 DCPQ APDU The fields of the DCPQ APDU are listed in Table 8/T.433. 28 Fascicle VII.7 - Rec. T.433 TABLE 8/T.433 DCPQ APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴쩡컴컴컴컴컫컴컴컴 컴컴컴� � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴탠컴컴컴컴컵컴컴컴컴컴컴� � Application capabilities � � � � � � � � � � Document application profile � U � request � indication � � � � � � � Document architecture class � U � request � indication � � � � � � � Non basic structural characteristics � U � request � indication � � � � � � � Non basic document characteristics � U � request � indication � � � � � � � Operational application profile � U � request � indication � � � � � � � Storage capacity � U � request � indication � � � � � � � User information � U � request � indication � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴좔컴컴컴컴컨컴컴컴컴컴컴� 6.5.2.2 DCPR APDU The fields of the DCPR APDU are listed in Table 9/T.433. TABLE 9/T.433 DCPR APDU fields w 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴쩡컴컴컴컴컫컴컴컴 컴컴컴커 � Field name � Presence � Source � Sink � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴탠컴컴컴컴컵컴컴컴컴컴컴캑 � Application capabilities � � � � � � � � � � Document application profile � U � response 쿬onfirmation � � � � � � � Document architecture class � U � response 쿬onfirmation � � � � � � � Non basic structural characteristics � U � response 쿬onfirmation � � � � � � � Non basic document characteristics � U � response 쿬onfirmation � � � � � � � Operational application profile � U � response 쿬onfirmation � � � � � � � Storage capacity � U � response 쿬onfirmation � � � � � � � Capability result � U � response 쿬onfirmation � � � � � � � User information � U � response 쿬onfirmation � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴좔컴컴컴컴컨컴컴컴컴컴컴켸 Fascicle VII.7 - Rec. T.433 29