WPC 2%.Bpz W"S^11>bbu"::Dg1:11bbbbbbbbbb11gggbuuuk1Xubuukuuuk111Rb:bbXbb1bb''X'bbbb:X1bXXXX;.;g:=::m:::mmmmm::::::mm:k1mubububububXubububub11111111bbbbbbbbbuXubbkbuXmmmmumububXXXXbububububbmbbbbbb:k:k::=kmmX:uXb'b:b:b:b'bmbbbb:::uXuXuXuXk:k:k:mbbbmbuXkXkXKQmmmm^b:kbbbbmbA@mmbmmbmmmmmmm:b:mmmbbmmmmmmmmmmmmXXmmmmmmmmmmmmmmmmmmcm`m`mm`m:mmmmmm}}}mjjmmmmmmmmmmmmmmm0mm}mmmmmmmmmmmmmmmmmmmmmmm}Mmmmmmmmmmmmmjmmmtmmmmmmmmm`'mmm`mmjmlWmmmmmmmmmmmmmmmmmmmW`mmmmjmM#|xaHelveticaCourierCourier Bold4PkCQMS PS Jet Plus /800 II QPJPII.PRSPl`D4PkCg2W _a.s|x-HelveticaCourierHelveticaCourierCourier BoldHelvetica BoldmQrrr r  @C2M.IzPw@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C"S^1:Sbb1::Dg1:11bbbbbbbbbb::gggkuk1bkuukuuuk:1:gb1bkbkb:kk11b1kkkkDb:kbbbXD1Dg:=::r:::rrrrr::::::rr:k1rbbbbbbubububub11111111kkkkkkkkkubbkkkubrrrrrbbbbbbkububububkrkkkkkk:k:k::=krrb:bk1k:k:k:k1krkkkkDDDububububk:k:k:rkkkrkubkXkXKQrrrrbb:kbbbbrbA@rrbrrbrrrrrrrXb::rrbbrrrrrrrrrrrrkkrrrrrrrrrrrrrrrrrrcr`r`rr`r:rrrrrr}}}rjjrrrrrrrrrrrrrrr0rr}rrrrrrrrrrrrrrrrrrrrrrr}Mrrrrrrrrrrrrjrrrtrrrrrrrrr`'rrr`rrjrlWrrrrrrrrrrrrrrrrrrrW`rrrrjrM@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC2.'  x"S^"55U@ %8 55555555558885a@@EE@;KE0@5PEK@KE@;E@[@@;-5 55055550P5555 050E000  8 " m mmmmm mm ;m@5@5@5@5@5`UE0@5@5@5@5E5K5K5K5K5E5E5E5E5@0@5E5K;K5@0mmmmmm@5@5E0E0E0E0E5@5@5@5@5K5mmK5K5K5K5E5E5 ; ; ";mm0 @055 5 5 5E5mmE5E5K5K5`[E E E @0@0@0@0; ; ; mmE5E5E5mmE5[E@0;0;0K,mmmm45 ;5555m5$#mm5mmLL5mmmmmmm 5` mmm55Ummmmmmmmmmmm00`mmmmmmmmmmmmmmmmmm`cm5m5mm5m mmmmmJmDDDm::mdmmmmmmmmmmmmmmmmDmmmmmmmmmmmm__mmdmmmmmmmmmD*Ommmmmmmmmmmm:mmm?mmmmmmmmm5'mmm5mm:m;/mmmmmmmmmmmmmmmmmmm/H5Jmmmm:m*@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC@H4': 4D4PkC@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@,dK1dD4p}wC@H4': 4D4PkC;,>>> >  @C2  X` hp x (#%'HP ,x--h.    3'3'Standard6'6'StandardC6QMS $=R- :(  x|@  Fascicle VII.7 Rec. T.433 i:- x|@   Fascicle VII.7 Rec. T.433 i   Recommendation T.433  DOCUMENT TRANSFER AND MANIPULATION (DTAM) SERVICES AND PROTOCOLS ă  PROTOCOL SPECIFICATION ă &CONTENTS 0HIntroduction 1HScope and field of application 2HReferences 3HDefinitions and abbreviations 4HConventions 5HOverview of the protocol H5.1  Service provision H5.2  Relationship with other ASEs and lower layer services H5.3  Model of telematic protocol architecture (TPA) 0 6HElements of procedure H6.1  Summary list of DTAM protocol data units H6.2  DTAM association establishment H6.3  Normal termination of a DTAM association H6.4  Abnormal termination of a DTAM association H6.5  Capability H6.6  Document bulk transfer H6.7  Document unconfirmed manipulation H6.8  Document confirmed manipulation H6.9  Typed data transfer H6.10  Remote document access H6.11  Remote document management H6.12  Token control H6.13  Exception report H6.14  Rules for extensibility 7HMapping to the lower layer services H7.1  Mapping to the OSI lower layer services H7.2  Mapping to the Recommendation X.215 session service (Transparent mode) 8HAbstract syntax definition of APDUs H8.1  Abstract syntax definition of APDUs in normal mode H8.2  Abstract syntax definition of APDUs for use of session service 9HConformance AnnexAReliable transfer modes (Informative) AnnexBDTAMPM state tables (Transparent modereliable transfer mode 1) 0 H Introduction  HThis Recommendation specifies the protocol for the services provided by an application serviceelement, 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 applicationserviceelements specifically used by a number of applications.  1 H Scope and field of application  HThis 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 Sessionservice (Recommendation X.215). Depending on the mapping, Recommendation T.62 bis may also apply. HThe DTAM procedures are defined in terms of:  Ha)  the interaction between peer DTAM protocol machines through the use of the ACSEservice and Presentationservice or Sessionservice; and' Hb)  the interactions between the DTAM protocol machine and its serviceuser.'  HThis Recommendation specifies conformance requirements for systems implementing these procedures. HThe use of RTSE and/or ROSE is for further study. 0' 2 H References HReferences are listed in Recommendation T.432. 3 H Definitions and abbreviations  HTerms 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 H Conventions  HThis Recommendation specifies the APDU Fields. In 6, tables are presented for each DTAM APDU. Each field is summarized by the following notation: HM presence is mandatory HU presence is a DTAM serviceuser option Hreq  source is related request primitive Hind  sink is related indication primitive Hrsp  source is related response primitive Hcnf  sink is related confirm primitive Hsp  source or sink is the DTAMPM  HThe structure of each DTAM APDU is specified in 8 using the abstract syntax notation of Recommendation X.208. 5 H Overview of the protocol 5.1HService provision  HThe protocol specified in this Recommendation provides the DTAM services defined in Recommendation T.432. These services are listed in Table 1/T.433. 5.2HRelationship with other ASEs and lower layer services 5.2.1HACSE service (when RTSE is not used)  HThe DTAM services require access to the AASSOCIATE, ARELEASE, AABORT, and APABORT services. The inclusion of the DTAM in an applicationcontext precludes the use of any of the above ACSE services by any other ASE or the useelement. HThe Transparent Mode of DTAM implies that ACSE can pass through it. ( $TABLE 1/T.433 *  DTAM services summary ă   x|@ w      Service  Type      DINITIATE  confirmed        DTERMINATE  confirmed        DPABORT  providerinitiated        DUABORT  unconfirmed        DCAPABILITY  confirmed        DTRANSFER  providerconfirmed        DTYPEDDATA  unconfirmed        DCREATE  unconfirmed        DDELETE  unconfirmed        DMODIFY  unconfirmed        DCALL  unconfirmed        DREBUILD  unconfirmed        DTOKENGIVE  unconfirmed        DCONTROLGIVE  unconfirmed        DTOKENPLEASE  unconfirmed        DPEXCEPTIONREPORT  providerinitiated        DUEXCEPTIONREPORT  unconfirmed      HP ,x--h.Xp$%%p& X NoteDREBUILD service is for further study. 5.2.2XRTSE service XThe use of this ASE is for further study. 5.2.3XROSE service XThe use of this ASE is for further study. 5.2.4XPresentationservice XDTAM services may require access to the PACTIVITYSTART, PDATA, PMINOR SYNCHRONIZE, PACTIVITYEND, PACTIVITYINTERRUPT, PACTIVITYDISCARD, PUEXCEPTIONREPORT, PACTIVITYRESUME, PPEXCEPTIONREPORT, PTOKENPLEASE, PCONTROLGIVE and PTOKENGIVE services. This Recommendation recognizes that the ACSE services require access to the PCONNECT, PRELEASE, PUABORT and PPABORT services. The inclusion of the DTAM in an applicationcontext precludes the use of any of the above, or of any other, presentationservices by any other ASE or the user element. - 5.2.5XRecommendation X.215 sessionservice  XIn 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.  XDTAM services may require access to the SCONNECT, SACTIVITYSTART, SDATA, SMINOR SYNCHRONIZE, SACTIVITYEND, SACTIVITYINTERRUPT, SACTIVITYDISCARD, SUEXCEPTIONREPORT, SACTIVITYRESUME, SPEXCEPTIONREPORT, STOKENPLEASE, SCONTROLGIVE, PTOKENGIVE, SRELEASE, SUABORT and SPABORT services. 5.3XModel of telematic protocol architecture (TPA)  XThe DTAM operates between two DTAM Protocol Machines (DTAMPMs) in the Application layer of the OSI model. Protocol elements are exchanged between DTAMPMs, 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), DTAMSE (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.  XXNoteIn the case of use of the Sessionservice (Transparent Mode), the appropriate'X  XDTAM APDUs are directly mapped to the Sessionservice primitives. t"FIGURE 1/T.433 t) t Telematic protocol architecture (TPA) ă t model in application layer ă 5.3.1XFunctions of DTAM user  XDTAM 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 DTAMSE through the DTAM service defined in Recommendation T.432. The DTAM service is the logical interface between the DTAM user and DTAM serviceprovider for data handling, and is independent of specific hardware and software technique. n  XThe 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.2XFunctions of DTAM serviceprovider  XTo realize singlesource management of document architecture for telematic services, DTAM serviceprovider provides the following communication functions. X1) Association use control (kernel)'  X 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.' X2) DTAM capability  X The DTAM capability is defined by a set of parameters in order to specify the communication features which contains the parameters:' X a) document application profile;' X b) operational application profile; X c) nonbasic document characteristics; X d) nonbasic structural characteristics, etc. X3) Data transmission function  X DTAM provides functions for document bulk transfer, document manipulations and typed data transmission as follows:' X a) Document bulk transfer'  X  DTAM provides a function to transmit the document in bulk under the communications environment negotiated by DINITIATE service and additionally by DCAPABILITY service;' X b) Document manipulations  X  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;' X c) Typed data transmission'  X  DTAM optionally provides a typed data transmission function which is independent of data token control.' X4) Document remote access X For further study. X5) Document remote management X For further study. X6) Token control  X DTAM optionally provides the function of Token control to handle the data token for dialogue.' X7) Reliable transfer (support function)  X DTAM optionally provides the function of reliable transfer to ensure reliable communication. Two Reliable Transfer Modes are introduced (see 6.6.1.4).' X8) Exception report  X DTAM optionally provides the exception reporting function for error control during the DTAM communication.' , X9) Storage capacity negotiation  X DTAM optionally provides the Storage Capacity Negotiation to indicate its own capacity to the peer.' 6 X Elements of procedure  XThis section identifies all the types of protocol data units which constitute the elements of the DTAM protocol between two DTAMprotocolmachines (DTAMPMs). A protocol data unit (PDU) is the smallest quantity of information exchanged between DTAMPMs which has a selfcontained semantic significance.  XWhen 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 (DPDU) are shown in Table 2/T.433.  XIndividual 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, DINITIATEREQ PDU also includes the DTAM protocol version parameter, which is used to negotiate the version of protocol between the DTAMPMs. Note that the DTAM user is not concerned with this DTAM negotiation.  XThe 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. XPDUs 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.1XSummary list of DTAM protocol data units $TABLE 2/T.433 *  DTAM protocol data units ă   w      Functional  PDU  Protocol elements  Reference    Units  abbrev.  (PDU)       DINQ  DINITIATEREQ  6.2          Association  DINR  DINITIATERESP  6.2    use control       (kernel)  DTEQ  DTERMINATEREQ  6.3           DTER  DTERMINATERESP  6.3           DAB  DABORT  6.4      DCPQ  DCAPABILITYREQ  6.5    Capability        DCPR  DCAPABILITYRESP  6.5     Document  None  None  6.6    Bulk transfer        >0   tTABLE 2/T.433 (Cont.) t)   w      Functional  PDU  Protocol elements  Reference    Units  abbrev.  (PDU)       DCR  DCREATE  6.7          Document  DDL  DDELETE  6.7    unconfirmed       manipulation  DMD  DMODIFY  6.7           DCL  DCALL  6.7           DRD  DREBUILD [Further study]  6.7     Document       confirmed   [Further study]  6.8    manipulation        Typed data  DTD  DTYPEDDATA  6.9    transmission        Remote       document   [Further study]  6.10    access        Remote       document   [Further study]  6.11    management       Token control  DTP  DTOKENPLEASE  6.12       None     Exception  None  userexceptionreport     report    6.13      providerexception       report            Reliable      h   transfer  None  None  6.6   (support)        h  6.2XDTAM association establishment 6.2.1XPurpose  XThe DTAM association establishment procedure is used to establish an association of DTAM between two AEs. It supports the DINITIATE service. 6.2.2XAPDUs used  XThe DTAM association establishment procedure uses the DINITIATEREQ (DINQ) and the DINITIATERESP (DINR) APDUs. 6.2.2.1 DINQ APDU XThe fields of the DINQ APDU are listed in Table 3/T.433. F- $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)          Xp$%%p&XHp$%%p& XHNote1These parameters are not applicable in transparent mode. XHNote2The use of this parameter is for further study. 6.2.2.2HDINR APDU XThe fields of the DINR APDU are listed in Table 4/T.433. t#TABLE 4/T.433 t) t! DINR APDU fields ă   XHp$%%p&Xpw      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)          XpXp$%%p& XNoteThese parameters are not applicable in transparent mode. .  6.2.3XDTAM association establishment procedure  6.2.3.1DTAM association establishment procedure mapped onto ACSE service (normal mode: OSI) XThis procedure is driven by the following events: Xa)a DINITIATE request primitive from the requestor; Xb)a DINQ APDU as User Data on an AASSOCIATE indication primitive; Xc)a DINITIATE response primitive from the responder; and Xd)an AASSOCIATE confirm primitive (that may contain a DINR APDU); 6.2.3.1.1  DINITIATE request primitive  6.2.3.1.1.1 The requesting DTAMPM forms a DINQ APDU from parameter values of the DINITIATE request primitive and its stored data in DTAMPM (the Protocol Version field, etc.) It issues an AASSOCIATE request primitive also using information from the DINITIATE request primitive. The User Data parameter of the AASSOCIATE request primitive contains the DINQ APDU.  6.2.3.1.1.2 The requesting DTAMPM waits for a primitive from the ACSE serviceprovider, and does not accept any other primitive from the requestor other than a DUABORT request primitive. 6.2.3.1.2  DINQ APDU  6.2.3.1.2.1 The responding DTAMPM receives a DINQ APDU from its peer as User data on an AASSOCIATE indication primitive. If any of the parameters of the AASSOCIATE indication primitive or the fields in the DINQ APDU are unacceptable to this DTAMPM, it forms a DINR APDU with the appropriate rejecting Result field, and sends the DINR APDU as User Data on an AASSOCIATE response primitive. The Result parameter on the AASSOCIATE response primitive specifies "userrejection". The DTAMPM does not issue a DINITIATE indication primitive to the responder, and the association is not established.  6.2.3.1.2.2 If the AASSOCIATE indication primitive and its DINQ APDU are acceptable to the responding DTAMPM, it issues a DINITIATE indication primitive to the responder. The DINITIATE indication primitive parameters are derived from the DINQ APDU and from the AASSOCIATE indication primitive. The DTAMPM waits for a DINITIATE response primitive from the responder and does not accept any other primitives from the responder except for the DUABORT request primitive. 6.2.3.1.3  DINITIATE response primitive  6.2.2.1.3.1 When the DTAMPM receives the DINITIATE response primitive, the Result parameter specifies whether the responder has accepted or rejected the DTAM association. The DTAMPM forms a DINR APDU using the DINITIATE response primitive parameters. The DINR APDU is sent as the User Data parameter on the AASSOCIATE response primitive.  6.2.3.1.3.2 If the responder accepted the DTAM association request, the Result parameter on the related AASSOCIATE 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 AASSOCIATE response primitive specifies "Result: rejected (permanent or transient)" and "Source: ACSE serviceuser", 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  AASSOCIATE confirm primitive  6.2.3.1.4.1 The requesting DTAMPM receives an AASSOCIATE confirm primitive. The following situations are possible: Xa)the DTAM association has been accepted;  Xb)the responding DTAMPM or the responder has rejected the DTAM association; or Xc)the association serviceprovider has rejected the related association.  6.2.3.1.4.2 If the DTAM association was accepted, the AASSOCIATE confirm primitive 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 DTAMPM issues a DINITIATE confirm primitive to the requestor based on parameters from the A / ԫASSOCIATE confirm primitive and from the DINR APDU. The DINITIATE confirm primitive Result parameter specifies "accepted", and the DTAM association is established.   6.2.3.1.4.3 If the DTAM association was rejected by either the responding DTAMPM or by the responder, the AASSOCIATE confirm primitive Result parameter specifies "Result: rejected (permanent or transient)" and "Source: ACSE serviceuser". The User Data parameter contains a DINR APDU, and the Result field of the DINR APDU indicates the reason for rejection. The requesting DTAMPM issues a DINITIATE confirm primitive to the requestor based on parameters from the AASSOCIATE confirm primitive and from the DINR APDU. The DINITIATE 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 serviceprovider, the AASSOCIATE confirm primitive Result parameter specifies "Result: rejected (permanent or transient)" and "Source: ACSEserviceprovider". In this situation, the User Data field is not used by the requesting DTAMPM. The requesting DTAMPM issues a DINITIATE confirm primitive with the appropriate Result parameter. The DTAM association is not established.  6.2.3.2DTAM association establishment procedure mapped onto session service (transparent mode) XThis procedure is driven by the following events: Xa)a DINITIATE request primitive from the requestor; Xb)a DINQ APDU as User Data on an SCONNECT indication primitive; Xc)a DINITIATE response primitive from the responder; and Xd)an SCONNECT confirm primitive (that may contain a DINR APDU); 6.2.3.2.1  DINITIATE request primitive  6.2.3.2.1.1 The requesting DTAMPM forms a DINQ APDU from parameter values of the DINITIATE request primitive and its stored data in DTAMPM (the Checkpoint Window field, etc.). It issues an SCONNECT request primitive also using information from the DINITIATE request primitive. The User Data parameter of the CONNECT request primitive contains the DINQ APDU.  6.2.3.2.1.2 The requesting DTAMPM waits for a primitive from the Session serviceprovider and does not accept any other primitive from the requestor other than a DUABORT request primitive. 6.2.3.2.2  DINQ APDU  6.2.3.2.2.1 The responding DTAMPM receives a DINQ APDU from its peer as User Data on an SCONNECT indication primitive. If any of the parameters of the SCONNECT indication primitive or the fields in the DINQ APDU are unacceptable to this DTAMPM (e.g.m no Session User Data in the SCONNECT indication,) it issues an SCONNECT response primitive specified "ssuserrejection". In this situation, the responding session serviceprovider issues RSSN (Response Session Start Negative). The DTAMPM does not issue a DINITIATE indication primitive to the responder. The association is not established.  6.2.3.2.2.2 If the SCONNECT indication primitive and its DINQ APDU are acceptable to the responding DTAMPM, it issues a DINITIATE indication primitive to the responder. The DINITIATE indication primitive parameters are derived from the DINQ APDU. The DTAMPM waits for a DINITIATE response primitive from the responder and does not accept any other primitives from the responder except for the DUABORT request primitive. 6.2.3.2.3  DINITIATE response primitive  6.2.3.2.3.1 When the DTAMPM receives the DINITIATE response primitive, the Result parameter specifies whether the responder has accepted or rejected the DTAM association. If the DTAM association is accepted, the DTAMPM forms a DINR APDU using the DINITIATE response primitive parameters. The DINR APDU is sent as the User Data parameter on the SCONNECT response primitive.  6.2.3.2.3.2 If the responder accepted the DTAM association request, the Result parameter on the related SCONNECT 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 SCONNECT response primitive specifies "userrejection" and DTAMPM does not send DINR APDU. :  6.2.3.2.4  SCONNECT confirm primitive  6.2.3.2.4.1 The requesting DTAMPM receives an SCONNECT confirm primitive. The following situations are possible; Xa)the DTAM association has been accepted;  Xb)the responding DTAMPM or the responder has rejected the DTAM association; or Xc)the Session serviceprovider has rejected the related association.  6.2.3.2.4.2 If the DTAM association was accepted, the SCONNECTION confirm primitive Result parameter specifies "accept". The User Data parameter contains a DINR APDU. The requesting DTAMPM issues a DINITIATE confirm primitive to the requestor based on parameters from the SCONNECT confirm primitive and from the DINR APDU. The DINITIATE 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 DTAMPM or by the responder, the SCONNECT confirm primitive Result parameter specifies "userrejection" and there is no User Data (DINR APDU) in this confirm primitive. The requesting DTAMPM issues a DINITIATE confirm primitive to the requestor based on parameters from the SCONNECT confirm primitive. The DINITIATE confirm primitive Result parameter contains the value of "userrejection", and the DTAM association is not established.  6.2.3.2.4.4 If the association was rejected by the session serviceprovider, the SCONNECT confirm primitive Result parameter specifies "providerrejection". In this situation, the User Data field is not used by the requesting DTAMPM. The requesting DTAMPM issues a DINITIATE confirm primitive with the appropriate Result parameter. The DTAM association is not established. 6.2.4XUse of the DINQ/DINR APDU fields XThe DINQ APDU and DINR APDU fields are used as follows. 6.2.4.1Service classes XThe use of this parameter is for further study. 6.2.4.2Telematic requirements  XThis is the Telematic Requirements parameter value from the DINITIATE request/response primitives. It appears as the Telematic Requirements parameter value of DINITIATE 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.3Application capabilities  XThis is the Application Capabilities parameter value from the DINITIATE request/response primitives. It appears as the Application Capabilities parameter value of the DINITIATE indication/confirm primitives respectively. This parameter consists of sets of the following sub parameters. 6.2.4.3.1  Document application profile  XThe 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 XThe value of this parameter is "formatted". 6.2.4.3.3  Non basic document characteristics  XThe value of this parameter is any combination of Non Basic Document Characteristics defined in Recommendation T.414. 6.2.4.3.4  Non basic structural characteristics  XThe value of this parameter is any combination of Non Basic Structural >0 Characteristics defined in Recommendation T.414.  6.2.4.3.5  Operational application profile  XThe detailed specification of the Operational Application Profile is for further study. 6.2.4.4Protocol version  XThis identifies the version of the DTAM protocol in use by the requesting DTAMPM. 6.2.4.5DTAM QOS XDTAM QOS is left for further study. 6.2.4.6Account  XThe account parameter identifies the account to which costs incurred in the DTAM association which is being established are to be charged. XNoteThe use of this parameter is for further study. 6.2.4.7Window size  XThe 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.8Storage capacity  XIn a Normal Mode, this parameter is optionally used by each of two DTAMPMs to indicate its own capacity to the peer. After the negotiation, if the storage capacity of the receiving DTAMPM is smaller than the largest segment of document information (see 6.6) according to the checkpoint rule, the sending DTAMPM shall not transfer the document and DPEXCEPTION indication should be issued to the requesting DTAM user (sender of documents).  XHowever, for some applications under a Transparent Mode, this parameter is used by the sending DTAMPM to indicate a w'required storage capacityw' to the peer machine. The receiving DTAMPM 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.9Result  XIf the DINQ APDU was rejected by the responding DTAMPM (i.e., a DINITIATE indication primitive was not issued to the responder), this field is supplied by the responding DTAMPM, otherwise, this field is the Result parameter from the DINITIATE response primitive. In either situation, it appears as the Result parameter on the DINITIATE RESP (DINR) APDU. This field can take one of the following symbolic values: Xaccepted; Xrejected by responder (reasonnotspecified); Xrejected by responder (protocol Versionnotsupported); Xrejected by responder (DTAMQOSnotsupported); Xrejected by responder (applicationcontextnotsupported); Xrejected by responding DTAMPM. 6.2.4.10User information  XThis is the User Information parameter from the DINITIATE request and response primitive. It appears as the User Information parameter of the DINITIATE indication and >0 confirm primitive respectively, if issued.  6.2.5XCollisions and interactions XFor further study. 6.3XNormal termination of a DTAM association 6.3.1XPurpose  XThis procedure is used for the normal termination of a DTAM association by an AE without loss of information in transit. It supports the DTERMINATE service. 6.3.2XAPDUs used XThe normal termination procedure uses the DTERMINATEREQ (DTEQ) APDU and the DTERMINATERESP (DTER) APDU. 6.3.2.1DTEQ APDU XThe fields of the DTEQ APDU are listed in Table 5/T.433. $TABLE 5/T.433 * " DTEQ APDU fields ă   Xp$%%p&Xpw      Field name  Presence  Source  Sink     User information  U  request  indication    (see Note)          XpXHp$%%p& XHNoteThis parameter is not applicable in transparent mode. 6.3.2.2HDTER APDU XThe fields of the DTER APDU are listed in Table 6/T.433. t#TABLE 6/T.433 t) t! DTER APDU fields ă   XHp$%%p&Xpw      Field name  Presence  Source  Sink     Charging  U  response  confirmation    (see Note)       User information  U  response  confirmation    (see Note)          XpXHp$%%p& XHNoteThese parameters are not applicable in transparent mode. 6.3.3XNormal termination procedure 6.3.3.1HNormal termination procedure mapped onto ACSE service (normal mode) XThis procedure is driven by the following events: Xa)Ha DTERMINATE request primitive from the requestor; Xb)Ha DTEQ APDU as User Data on an ARELEASE indication primitive; Xc)Ha DTERMINATE response primitive from the responder; and Xd)Ha DTER APDU as User Data on an ARELEASE confirm primitive. F- XHp$%%p&Xp$%%p&6.3.3.1.1  DTERMINATE request primitive  6.3.3.1.1.1 When a DTERMINATE request primitive is received, the DTAMPM sends a DTEQ APDU as User Data on an ARELEASE request primitive using the parameters from the DTERMINATE request primitive.  XNoteThe requestor is required to meet the association (presentation and session) requirements in order to issue a DTERMINATE request primitive.  6.3.3.1.1.2 The requesting DTAMPM now waits for a primitive from the association serviceprovider. It does not accept any primitives from the requestor other than a DUABORT request primitive. 6.3.3.1.2  DTEQ APDU  6.3.3.1.2.1 When the responding DTAMPM receives the DTEQ APDU as User Data on an ARELEASE indication primitive, it issues a DTERMINATE indication primitive to the responder. 6.3.3.1.3  DTERMINATE response primitive  6.3.3.1.3.1 The responding DTAMPM forms a DTER APDU from the response primitive parameters. The DTER APDU is sent as User Data on an ARELEASE response primitive. The Result parameter of ARELEASE response has the value "affirmative.  XNoteThe 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 DTAMPM receives an ARELEASE confirm primitive containing a DTER APDU from its peer. The Result parameter on the ARELEASE confirm specifies either that the responder agrees or disagrees that the DTAM association may be terminated. The requesting DTAMPM forms a DTERMINATE confirm primitive from the DTER APDU.  6.3.3.2 Normal termination procedure mapped onto session service (transparent mode) XThis procedure is driven by the following events: Xa) a DTERMINATE request primitive from the requestor; Xb) an SRELEASE indication primitive without sending DTEQ APDU; Xc) a DTERMINATE response primitive from the responder; and Xd) an SRELEASE confirm primitive without sending DTER APDU. 6.3.3.2.1  DTERMINATE request primitive  6.3.3.2.1.1 When a DTERMINATE request primitive is received, the DTAMPM issues an SRELEASE request primitive without any SSuserdata.  XNoteThe requestor is required to meet the association (presentation and session) requirements in order to issue a DTERMINATE request primitive.  6.3.3.2.1.2 The requesting DTAMPM now waits for a primitive from the Session serviceprovider. It does not accept any primitives from the requestor other than a DUABORT request primitive. 6.3.3.2.2  Implicit DTEQ APDU  6.3.3.2.2.1 When the responding DTAMPM receives an SRELEASE indication primitive, it issues a DTERMINATE indication primitive to the responder without any parameters. 6.3.3.2.3  DTERMINATE response primitive  6.3.3.2.3.1 The responding DTAMPM forms an SRELEASE response from the DTERMINATE response primitive parameters. The Result parameter of SRELEASE response has the value "affirmative". 6.3.3.2.4  Implicit DTER APDU  6.3.3.2.4.1 The requesting DTAMPM receives an SRELEASE confirm primitive containing no DTAM APDU from its peer. The Result parameter on the SRELEASE confirm always specifies "affirmative". The requesting DTAMPM forms a DTERMINATE confirm primitive / from the SRELEASE confirm primitive and issues it to the requestor with no parameters.  6.3.4XUse of the DTEQ APDU fields XThe DTEQ APDU fields are used as specified below. 6.3.4.1 User information  XThis is the User Information parameter on the DTERMINATE request primitive. It appears as the User Information parameter of the DTERMINATE indication primitive. 6.3.5XUse of the DTER APDU fields XThe DTER APDU fields are used as specified below. 6.3.5.1 Charging  XThe 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  XThis is the User Information parameter from the DTERMINATE response primitive. It appears as the User Information parameter on the DTERMINATE confirm primitive. 6.3.6XCollisions and interactions 6.3.6.1 DTERMINATE service  XOverlapping attempts by request in both AEs to terminate their DTAM association are governed by the ARELEASE service or SRELEASE Session service. The DTAM association is terminated.  XNoteA Dterminate 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 DTERMINATE request primitive. 6.3.6.2 DUABORT service, DAB APDU or APABORT service  XIf either DTAMPM receives a DUABORT request primitive, a DAB APDU (as User Data on a A(orS)UABORT indication primitive) or a A(orS)PABORT indication primitive, it discontinues the normal DTAM association termination procedure, and instead follows abnormal termination procedure. 6.4XAbnormal termination of a DTAM association 6.4.1XPurpose  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 DTAMPM, by the ACSE serviceprovider or by the Session serviceprovider. It supports the DUABORT, DPABORT and APABORT or SPABORT services. 6.4.1.2 The Abnormal Termination provides the following three procedures: Xa) userabort procedure; Xb) associationproviderabort procedure; Xc) transferabort procedure. 6.4.2XAPDUs used XThe abnormal termination uses the DABORT (DAB) APDU. 6.4.2.1 DAB APDU XThe fields of the DAB APDU are listed in Table 7/T.433. !/ $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)          Xp$%%p&XHp$%%p& XHNoteThese parameters are not applicable in transparent mode. 6.4.3XAbnormal termination procedure 6.4.3.1HAbnormal termination procedure mapped onto ACSE service (normal mode) XThis procedure is driven by the following events: XUserabort procedure XHa DUABORT request primitive from the requestor; XHa DAB APDU as User Data on an AUABORT indication primitive; XAssociationproviderabort procedure XHan APABORT indication primitive from the ACSEservice or XTransferabort procedure XHa severe error detected by a DTAMPM. 6.4.3.1.1  DUABORT request primitive (userabort procedure)  6.4.3.1.1.1 When a DTAMPM receives a DUABORT request primitive, it sends a DABORT (DAB) APDU as User Data on an AUABORT request primitive. The DAB APDU "Abort Source" field is specified as a "requestor". If the User Information parameter was included on the DUABORT 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 DTAMPM receives an AUABORT indication primitive, the User Data parameter contains the DAB APDU. The DTAMPM issues a DUABORT 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 DUABORT indication primitive. The DTAM association is terminated. 6.4.3.1.3  APABORT indication primitive (associationproviderabort procedure)  6.4.3.1.3.1 When a DTAMPM receives an APABORT indication primitive, the DTAMPM issues a DPABORT indication primitive to the DTAM user. The DTAM association is terminated.  6.4.3.1.3.2 An associationproviderabort is indicated to both DTAMPMs by an APABORT indication primitive and may occur at any time. After such an event, when the Reliable Transfer Mode 2 was selected, the associationinitiating DTAMPM starts the associationrecovery procedure. >0Ԍ XNoteThe associationrecovery procedure is for further study.   XHp$%%p&Xp$%%p&6.4.3.1.3.3 If the associationproviderabort procedure was performed during the transfer procedure the requesting DTAMPM starts the transferresumption procedure after the associationrecovery procedure is successfully completed. If the associationrecovery procedure was not successfully completed the requesting DTAMPM performs the transfererror procedure and the providerabort procedure. 6.4.3.1.4  Error detections by a DTAMPM (transferabort procedure)  6.4.3.1.4.1 When a DTAMPM detects severe error situations, it performs the transferabort procedure followed by issuing a DPABORT indication primitive.  6.4.3.1.4.2 The transferabort procedure is performed to send a DAB APDU as User Data on an AUABORT request primitive. The DAB APDU "Abort Source" field is specified as a "DTAM serviceprovider" and additional DAB APDU parameters are specified to inform a peer DTAMPM of the situation of the severe error. Following the transferabort procedure, the DTAMPM issues a DPABORT indication primitive to its serviceuser.  6.4.3.1.4.3 The use of associationrecovery procedure (see 6.6.8) is for further study.  6.4.3.2 Abnormal termination procedure mapped onto session service (transparent mode) XThis procedure is driven by the following events: XUserabort procedure X a DUABORT request primitive from the requestor; X an SUABORT indication primitive without sending a DAB APDU; XAssociationproviderabort procedure X an SPABORT indication primitive from the Sessionservice or XTransferabort procedure X a protocol error detected by a DTAMPM. 6.4.3.2.1  DUABORT request primitive (userabort procedure)  6.4.3.2.1.1 When a DTAMPM receives a DUABORT request primitive, it issues a SUABORT request primitive without sending a DAB APDU. The using of SUABORT 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 DTAMPM receives an SUABORT indication primitive, the DTAMPM issues a DUABORT indication primitive with the Abort Source field as "requestor". The DTAM association is terminated. 6.4.3.2.3  SPABORT indication primitive (associationproviderabort procedure)  6.4.3.2.3.1 When a DTAMPM receives an SPABORT indication primitive, the DTAMPM issues a DUABORT indication primitive to the responder. The DTAM association is terminated. 6.4.3.2.4  Protocol errors (transferabort procedure)  6.4.3.2.4.1 When a DTAMPM detects an invalid condition such as an unexpected APDU, it issues an SUABORT request primitive without DAB APDU as the User Data. The DTAMPM also issues a DPABORT indication primitive to its serviceuser. The DTAM association is terminated. 6.4.4XUse of the ABORT APDU fields XThe ABORT APDU fields are used as specified below. 6.4.4.1 Abort source  XThis is supplied by the requesting DTAMPM. It is included in the resulting DU(orP)ABORT indication primitive. This field can take one of the following symbolic / values: X DTAM serviceprovider; or X requestor. : Xp$%%p&Xp$%%p&6.4.4.2 Abort reason XThis field may contain one of the following values: X localsystemproblem  X invalidparameter$the invalid parameters are specified in the Reflected parameter field' X unrecognizedactivity  X temporaryproblem$no attempt at associationrecovery should be made for a period of time determined by a local rule' X protocolerror$of the DTAMPM  X permanenterror$this value is used solely by the DTAM providerabort procedure in normalmode'  X transfercompleted$the responding DTAMPM could not discard an already completed transfer'  6.4.4.3 Reflectedparameter  XThe ReflectedParameter 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 DTAMPM before the associationabort. 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  XThis is the information parameter from the DUABORT request primitive. It appears as the User Information parameter on the DUABORT indication primitive. 6.4.5XCollisions and interactions  XThe 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 APABORT indication primitive can disrupt the DUABORT exchange with loss of the user information in DUABORT service. Collisions of DAB APDUs are governed by the AU ABORT service.  6.5XCapability 6.5.1XPurpose XIt supports the DCAPABILITY service. 6.5.2XAPDUs used  XThe DTAM capability procedure uses the DCAPABILITYREQ (DCPQ) and the DCAPABILITY RESP (DCPR) APDUS 6.5.2.1 DCPQ APDU XThe fields of the DCPQ APDU are listed in Table 8/T.433. - Xp$%%p&Xp$%%p&$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 XThe fields of the DCPR APDU are listed in Table 9/T.433. t#TABLE 9/T.433 t) t! DCPR APDU fields ă   w        Field name  Presence  Source  Sink     Application capabilities             Document application profile  U  response confirmation          Document architecture class  U  response confirmation          Non basic structural characteristics  U  response confirmation          Non basic document characteristics  U  response confirmation          Operational application profile  U  response confirmation          Storage capacity  U  response confirmation          Capability result  U  response confirmation          User information  U  response confirmation