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#|FaHelveticaCourierCourier Bold4PkCQMS PS Jet Plus /800 II QPJPII.PRSPl`D4PkCg2W _a.s|x-HelveticaCourierHelveticaCourierCourier BoldHelvetica BoldmQrrr r  @C2 M.IPw.@ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C"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@H4': 4D4PkC"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`rrrrjrM2 ' x @ ,`H1`D4PkCmQrrr r  @CmQrrrr  `C@H4': 4D4PkC@,dK1dD4p}wC  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  6.5.3H DTAM capability procedure  6.5.3.1H DTAM Capability Procedure mapped onto Presentation Service (Normal Mode) H This procedure is driven by the following events: H a)a DCAPABILITY request primitive from the requestor; H b)a DCPQ APDU as User Data on a PCAPABDATA indication primitive; H c)a DCAPABILITY response primitive from the responder; and H d)a PCAPABDATA confirm primitive (that may contain a DCPR APDU). 6.5.3.1.1 H DCAPABILITY request primitive  6.5.3.1.1.1 H The requesting DTAMPM forms a DCPQ APDU from parameter values of the DCAPABILITY request primitive. It issues a PCAPABDATA request primitive. The User Data parameter of the PCAPABDATA request primitive contains the DCPQ APDU.  6.5.3.1.1.2 H The requesting DTAMPM waits for a primitive from the Presentation serviceprovider, and does not accept any other primitive from the requestor other than a DUABORT request primitive. 6.5.3.1.2 H DCPQ APDU  6.5.3.1.2.1 H The responding DTAMPM receives a DCPQ APDU from its peer as User Data on a PCAPABDATA indication primitive.  6.5.3.1.2.2 H In order that the DCPQ APDU may always be acceptable to the responding DTAMPM, it issues a DCAPABILITY indication primitive to the responder. The DCAPABILITY indication primitive parameters are derived from the DCPQ APDU. The DTAMPM waits for a DCAPABILITY response primitive from the responder and does not accept any other primitives from the responder except for the DUABORT request primitive. 6.5.3.1.3 H DCAPABILITY response primitive  6.5.3.1.3.1 H When the DTAMPM receives the DCAPABILITY response primitive, the Result parameter specifies whether the responder has accepted or rejected the DTAM capability requested. The DTAMPM forms a DCPR APDU using the DCAPABILITY response primitive parameters. The DCPR APDU is sent as the User Data parameter on the PCAPABDATA response primitive.  6.5.3.1.3.2 H If the responder accepted the DTAM capability request, the Capability Result field of the outgoing DCPR APDU also specifies the appropriate acceptance value. The DTAM capability is negotiated.  6.5.3.1.3.3 H If the responder rejected the DTAM capability request, the Result field of the outgoing DCPR APDU contains the appropriate rejection value. The DTAM capability is not established. 6.5.3.1.4 H PCAPABDATA confirm primitive  6.5.3.1.4.1 H The requesting DTAMPM receives a PCAPABDATA confirm primitive. The following situations are possible: H a)the DTAM capability has been accepted; or  H b)the responder has rejected the DTAM capability requested by the requestor.  6.5.3.1.4.2 H If the DTAM capability was accepted, the Capability Result field of the DCPR APDU specifies the appropriate acceptance value. The requesting DTAMPM issues a DCAPABILITY confirm primitive to the requestor based on parameters from the DCPR APDU. The DCAPABILITY confirm primitive Capability Result Parameter specifies the appropriate acceptance value. The DTAM capability is negotiated.  6.5.3.1.4.3 H If the DTAM capability was rejected by the responder, the Capability Result field of the DCPR APDU on the PCAPABDATA confirm primitive indicates the reason for rejection. The requesting DTAMPM issues a DCAPABILITY confirm primitive to the requestor based on parameters from the DCPR APDU. The DCAPABILITY confirm primitive Capability Result parameter contains the appropriate rejection value. The DTAM capability is not established.  6.5.3.2H DTAM capability procedure mapped onto session service (transparent mode) H This procedure is driven by the following events: H a)a DCAPABILITY request primitive from the requestor; % H b)a DCPQ APDU as User Data on an SCAPABDATA indication primitive; H c)a DCAPABILITY response primitive from the responder; and H d)an SCAPABDATA confirm primitive (that may contain a DCPR APDU). 6.5.3.2.1 H DCAPABILITY request primitive  6.5.3.2.1.1 H The requesting DTAMPM forms a DCPQ APDU from parameter values of the DCAPABILITY request primitive, and issues an SCAPAB DATA request primitive. The User Data parameter of the SCAPAB DATA request primitive contains the DCPQ APDU.  6.5.3.2.1.2 H 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.5.3.2.2 H DCPQ APDU  6.5.3.2.2.1 H The responding DTAMPM receives a DCPQ APDU from its peer as User Data on an SCAPAB DATAindication primitive.  6.5.3.2.2.2 H In order that the SCAPAB DATA indication primitive and its DCPQ APDU may always be acceptable to the responding DTAMPM, it issues a DCAPABILITY indication primitive to the responder. The DCAPABILITY indication primitive parameters are derived from the DCPQ APDU. The DTAMPM waits for a DCAPABILITY response primitive from the responder and does not accept any other primitives from the responder except for the DABORT request primitive. 6.5.3.2.3 H DCAPABILITY response primitive  6.5.3.2.3.1 H When the DTAMPM receives the DCAPABILITY response primitive, the parameters specified in its response primitive contain the Application Capabilities available at the responder. There is no way to issue the result of the capability negotiation explicitly. The DTAMPM forms a DCPR APDU using the DCAPABILITY response primitive parameters, and the DCPR APDU is sent as the User Data parameter on the SCAPAB DATA response primitive.  6.5.3.2.3.2 H In this way, the DTAM capability is negotiated by exchanging the Application Capabilities parameters available at the responder. 6.5.3.2.4 H SCAPAB DATA confirm primitive  6.5.3.2.4.1 H The requesting DTAMPM receives an SCAPAB DATA confirm primitive. The DTAM capability is always negotiated by exchanging the Application Capabilities parameters.  6.5.3.2.4.2 H If the DTAM capability was accepted, the requesting DTAMPM issues a DCAPABILITY confirm primitive to the requestor based on parameters from the DCPR APDU. The final decision of DTAM capability used in the transmission of a document will be made by the requesting DTAMPM. 6.5.4H Use of the DCPQ/DCPR APDU fields H The DCPQ APDU and DCPR APDU fields are used as follows. 6.5.4.1H Application capabilities  H This is the Application Capabilities parameter value from the DCAPABILITY request/response primitives. It appears as the Application Capabilities parameter value of the DCAPABILITY indication/confirm primitives respectively. This parameter consists of the following subparameters. 6.5.4.1.1 H Document application profile  H 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.5.4.1.2 H Document architecture class H The value of this parameter is "formatted". 6.5.4.1.3 H Non basic document characteristics  H The value of this parameter is any combination of Non Basic Document Characteristics defined in Recommendation T.414. * 6.5.4.1.4 H Non basic structural characteristics  H The value of this parameter is any combination of Non Basic Structural Characteristics defined in Recommendation T.414. 6.5.4.1.5 H Operational application profile  H The detailed specification of Operational Application Profile is for further study. 6.5.4.1.6 H Storage capacity H See 6.2.4.8. 6.5.4.2H Capability result  H If the DCPQ APDU was rejected by the responder, this field is supplied by the responder and is the Capability Result parameter from the DCAPABILITY response primitive. In this situation, it appears as the Capability Result parameter on the DCAPABILITY confirm primitive. This field can take one of the following:  H  confirmation that all the requested capabilities are available at the DTAM responder;'  H a list of the requested capabilities that are available at the DTAM responder; H a complete list of nonbasic receiving capabilities;  H  an indication that no extended capabilities are available in the DTAM responder, or that none of the capabilities requested by the requestor are available.' 6.5.4.3H User information  H This is the User Information parameter from the DCAPABILITY request and response primitive. It appears as the User Information parameter of the DCAPABILITY indication and confirm primitive, if issued. 6.6H Document bulk transfer 6.6.1H Purpose  6.6.1.1H The document bulk transfer is used to convey the document which contains ODA and Operational Structure to the remote DTAM user. The requestor who requests the remote Document bulk transfer should have a data taken in an appropriate manner. It supports the DTRANSFER services.  6.6.1.2H In this situation, either the Reliable Transfer Mode 1 or Mode 2 may be selected by the negotiation of functional units in the association establishment phase.  6.6.1.3H If the reliable transfer functional unit is not selected, the RTSE service will be used. The use of RTSE is for further study.  6.6.1.4H The Document Bulk Transfer is composed of two different sets of procedures depending on the Reliable Transfer Mode. H 1)Reliable transfer mode 1 H a)Transfer Procedure for transmission of a complete document;'  H b)Transferuserresume Procedure for retransmission of a partial document for resuming purposes. This procedure is controlled by the DTAM user;'  H c)Transferinterrupt Procedure to interrupt the transmission of a document in case of error;'  H d)Transferdiscard Procedure to interrupt the transmission of a document in case of error and indicate that the part of the document already transmitted has to be deleted.'  H In Reliable Transfer Mode 1, the Transferinterrupt and the Transferdiscard Procedures result in a DTRANSFER indication/confirmation to the DTAM user to indicate the failure of the transfer. The user is then responsible for initiating a new transfer (complete or partial document).  H Figures A1/T.433 and A2/T.433 illustrate the basic protocol sequences for the Reliable Transfer Mode 1. 8( H 2)Reliable transfer mode 2 H a)Transfer Procedure (see above, Reliable Transfer, Mode 1);'  H b)Transferresume Procedure for retransmission of a partial document. This procedure is completely controlled by the DTAMPM;' H c)Transferinterrupt Procedure (see above Reliable Transfer, Mode 1); H d)Transferdiscard Procedure (see above Reliable Transfer, Mode 1); H e)Associationrecovery Procedure (for further study).'  H In Reliable Transfer Mode 2, following the Transferinterrupt and Transferdiscard Procedures, the DTAMPM initiates a new Transfer Procedure or a Transferresume Procedure. Attempts to transfer or retransfer the document may not be performed by the DTAMPM after the transfer time is out. The transfer timeout may result to discard the document and to abort the procedure.  H Figures A3/T.433 and A4/T.433 illustrate the basic protocol sequences for the Reliable Transfer Mode 2.  H In the Transparent Mode under Session Service environment, only Reliable Transfer Mode 1 is used.  H In the Normal Mode under the OSI environment, both Reliable Transfer Modes 1 and 2 are available. 6.6.2H APDUs used  6.6.2.1H No APDUs are used in this procedure. The Document Information corresponds to a DTRANSFER request service primitive. There is no DTRANSFER REQ APDU as such.  6.6.2.2H Each Document Information, conveyed in a DTRANSFER request, constitutes an Activity. For each application association, at most one Activity or one interrupted Activity awaiting resumption may exist at any one time.  6.6.2.3H The Document Information, which consists of one or more interchangedataelements as defined in 9.6.1.1 of Recommendation T.432, is segmented and reassembled into/from one or more segments. Each segment consists of one or more groups of interchangedataelements and is transferred by the Presentation/Session data transfer services.  6.6.2.4H A Document Information is transferred as a single User Data of the Presentation/Session data transfer services if checkpointing is not used within the Document Information, otherwise, the Document Information is transferred as a series of Presentation/Session data transfer services primitives. The concatenation of the userdata values of Presentation/Session data transfer services is Document Information. An example of document segmenting mechanism is given in Figure 2/T.433.  AFIGURE 2/T.433 H 3 An example of document segmenting mechanism ă 6.6.3H Transfer procedure H This procedure is used to transfer a complete document. 6.6.3.1H Transfer procedure mapped onto presentation service (normal mode) H This procedure is driven by the following events: H a)a DTRANSFER request primitive from the requestor (sender of document);'  H b)a PACTIVITYSTART indication primitive, followed by one or more interchangedata elements as userdata of PDATA indication primitives each, except the last, followed by a PMINORSYNCHRONZE indication primitive;' H c)a PMINORSYNCHRONIZE confirm primitive;' H d)a PACTIVITYEND indication primitive; H e)a PACTIVITYEND confirm primitive; H f)a Transfer Timeout.  HH NoteIn the case of multiple documents transmission within one association, the above procedure will be applied repeatedly.'H 6.6.3.1.1 H DTRANSFER request primitive  6.6.3.1.1.1 H If the requesting DTAMPM possesses the Data Token and receives a DTRANSFER request from the requestor, Document Information in the DTRANSFER request primitive, which has an abstract form, is segmented by the group (segment) of interchangedataelements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAMPM. The segmented abstract form is then transformed into the User Data in PDATA.   6.6.3.1.1.2 H The parameter "Document Information Type" contained in the DTRANSFER request should indicate "transfer of a document from its beginning", and the requesting DTAMPM issues a PACTIVITYSTART request primitive and may start transmitting the first segment of interchangedata elements in a PDATA request primitive immediately after the PACTIVITYSTART request primitive is issued, since the PACTIVITYSTART service is not a confirmed service.  6.6.3.1.1.3 H If the segment of interchangedataelements transferred is not the last in a series of those segments, the requesting DTAMPM inserts a checkpoint by issuing a PMINORSYNCHRONIZE request primitive. The requesting DTAMPM uses only the "explicit confirmation expected" type of minor synchronization. The requesting DTAMPM may issue further PDATA request primitives and PMINOR SYNCHRONIZE request primitives unless the agreed Windowsize has been reached.  6.6.3.1.1.4 H PMinorSynchronization Points shall be located at the end of each segment of interchangedataelements. Additional Minor Synchronization Point can be requested depending on the evaluation of the storage capacity of the sink and the amount of data to be transmitted. This additional Minor Synchronization Point shall only be located at the end of any interchangedata elements and not within the element.  6.6.3.1.1.5 H If the segment of interchangedataelements is the only one, or the last in a series of segments of interchangedataelements, the requesting DTAMPM issues a PACTIVITYEND request primitive. All data transfer must take place within an activity.  6.6.3.1.2H H PACTIVITYSTART indication primitive, PDATA PDUs, and PMINORSYNCHRONIZE indication primitives'H  6.6.3.1.2.1 H The responding DTAMPM receives a PACTIVITYSTART indication primitive, indicating the start of transfer of Document Information. The responding DTAMPM receives a PMINORSYNCHRONIZE indication primitive. If the responding DTAMPM has secured the segment of interchangedataelements, it issues a PMINORSYNCHRONIZE response primitive. 6.6.3.1.3 H PMINORSYNCHRONIZE confirm primitive  6.6.3.1.3.1 H When the requesting DTAMPM receives a PMINORSYNCHRONIZE confirm primitive, it assumes that the responding DTAMPM has secured the segments of interchangedataelements up to that point.  6.6.3.1.3.2 H The requesting DTAMPM may issue further PDATA request primitives and PMINOR SYNCHRONIZE request primitives unless the agreed Windowsize has been reached. The window is advanced when a PMINORSYNCHRONIZE confirm primitive is received by the requesting DTAMPM.  6.6.3.1.3.3 H When a complete Document Information has been transmitted, the requesting DTAMPM issues a PACTIVITYEND request primitive. 6.6.3.1.4 H PACTIVITYEND indication primitive  6.6.3.1.4.1 H A PACTIVITYEND Indication primitive indicates to the responding DTAMPM that a complete Document Information has been transferred.  6.6.3.1.4.2 H If the responding DTAMPM has secured the complete Document Information, it issues a DTRANSFER indication primitive to the responder, and issues a PACTIVITYEND response primitive.  6.6.3.1.4.3 H The responding DTAMPM records the Sessionconnectionidentifier and the Activity Identifier of the last Document Information which it completely secured for associationrecovery purposes. 6.6.3.1.5 H PACTIVITYEND confirm primitive  6.6.3.1.5.1 H An activity end is an implicit major synchronization point and once successfully confirmed by means of a PACTIVITYEND confirm primitive, it indicates to the requesting DTAMPM that the Document Information has been secured by the responding DTAMPM. The requesting DTAMPM may then delete the transferred Document Information.  6.6.3.1.5.2 H When the requesting DTAMPM receives the PACTIVITYEND confirm primitive, it issues a DTRANSFER confirm primitive with a Result parameter value of "documentinformationtransferred" to the requestor. $ 6.6.3.1.6 H Transfer timeout (only for reliable transfer mode 2)  6.6.3.1.6.1 H If a Document Information has not been transferred within the time specified in the Transfertime parameter of the DTRANSFER request primitive (that is, the requesting DTAMPM has not received the PACTIVITYEND confirm primitive), the requesting DTAMPM performs the transferdiscard procedure (see 6.6.6) followed by the transferabort procedure (see 6.4.3.1.4).  6.6.3.1.6.2 H If during the transferdiscard procedure the requesting DTAMPM does not receive a PACTIVITYDISCARD confirm primitive within a (locally specified) reasonable time, the requesting DTAMPM performs the transferabort procedure followed by the DTAM providerabort procedure. 6.6.3.2H Transfer procedure mapped onto session service (transparent mode) H This procedure is driven by the following events: H a)a DTRANSFER request primitive from the requestor (sender of document);  H b)an SACTIVITYSTART indication primitive, followed by one or more interchangedata elements as userdata of SDATA indication primitives each, except the last, followed by an SMINORSYNCHRONIZE indication primitive;' H c)an SMINORSYNCHRONIZE confirm primitive; H d)an SACTIVITYEND indication primitive; H e)an SACTIVITYEND confirm primitive;  HH NoteIn the case of multiple document transmission within one association, the above procedure will be applied repeatedly.'H 6.6.3.2.1 H DTRANSFER request primitive  6.6.3.2.1.1 H If the requesting DTAMPM possesses the Data Token and receives a DTRANSFER request from the requestor, Document Information in the DTRANSFER request primitive which has an abstract form is segmented by the group (segment) of interchangedataelements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAMPM. The segmented abstract form is then transformed into the User Data in SDATA.  6.6.3.2.1.2 H The parameter "Document Information Type" contained in the DTRANSFER request should indicate the "transfer of a document from its beginning", and the requesting DTAMPM issues an SACTIVITYSTART request primitive and may start transmitting the first segment of interchangedata elements in an SDATA request primitive immediately after the SACTIVITYSTART request primitive is issued, since the SACTIVITYSTART service is not a confirmed service. All data transfer should take place within an activity.  6.6.3.2.1.3 H If the segment of interchangedataelements transferred is not the last in a series of those segments, the requesting DTAMPM inserts a checkpoint by issuing an SMINORSYNCHRONIZE request primitive. The requesting DTAMPM uses only the "explicit confirmation expected" type of minor synchronization. The requesting DTAMPM may issue further SDATA request primitives and SMINOR SYNCHRONIZE request primitives unless the agreed Windowsize has been reached.  6.6.3.2.1.4 H SMinorSynchronization Points shall be located at the end of each segment of interchangedataelements. Additional Minor Synchronization Points can be requested depending on the evaluation of the storage capacity of the sink and the amount of data to be transmitted. This additional Minor Synchronization Points shall only be located at the end of any interchangedata elements and not within the element.  6.6.3.2.1.5 H If the segment of interchangedataelements is the only one, or the last in a series of segments of interchangedataelements, the requesting DTAMPM issues an SACTIVITYEND request primitive. All data transfer must take place within an activity.  6.6.3.2.2H H SACTIVITYSTART indication primitive, SDATA PDUs, and SMINORSYNCHRONIZE indication primitives'H  6.6.3.2.2.1 H The responding DTAMPM receives an SACTIVITYSTART indication primitive, indicating the start of transfer of Document Information. The responding DTAMPM receives an SMINORSYNCHRONIZE indication primitive. If the responding DTAMPM has secured the segment of interchangedataelements, it issues an SMINORSYNCHRONIZE response primitive. p$ 6.6.3.2.3 H SMINORSYNCHRONIZE confirm primitive  6.6.3.2.3.1 H When the requesting DTAMPM receives an SMINORSYNCHRONIZE confirm primitive, it assumes that the responding DTAMPM has secured the segments of interchangedataelements up to that point.  6.6.3.2.3.2 H The requesting DTAMPM may issue further SDATA request primitives and SMINOR SYNCHRONIZE request primitives unless the agreed Windowsize has been reached. The window is advanced when an SMINORSYNCHRONIZE confirm primitive is received by the requesting DTAMPM.  6.6.3.2.3.3 H When a complete Document Information has been transmitted, the requesting DTAMPM issues an SACTIVITYEND request primitive. 6.6.3.2.4 H SACTIVITYEND indication primitive  6.6.3.2.4.1 H An SACTIVITYEND Indication primitive indicates to the responding DTAMPM that a complete Document Information has been transferred.  6.6.3.2.4.2 H If the responding DTAMPM has secured the complete Document Information, it issues a DTRANSFER indication primitive to the responder, and issues an SACTIVITYEND response primitive. 4.6.3.2.5 H SACTIVITYEND confirm primitive  6.6.3.2.5.1 H An activity end is an implicit major synchronization point and once successfully confirmed by means of an SACTIVITYEND confirm primitive, it indicates to the requesting DTAMPM that the Document Information has been secured by the responding DTAMPM. The requesting DTAMPM may then delete the transferred Document Information.  6.6.3.2.5.2 H When the requesting DTAMPM receives the SACTIVITYEND confirm primitive, it issues a DTRANSFER confirm primitive with a Result parameter value of "documentinformationtransferred" to the requestor. 6.6.4H Transferuserresume procedure  H This procedure is used to resume transferring the part of the document which has not been transferred at the previous transmission.  6.6.4.1H Transferuserresume procedure mapped onto presentation service (normal mode) H This procedure is driven by the following events: H a)a DTRANSFER request primitive from the requestor (sender of document);  H b)a PACTIVITYRESUME indication primitive, followed by one or more interchangedata elements as userdata of PDATA indication primitives each, except the last, followed by a PMINORSYNCHRONIZE indication primitive;' H c)a PMINORSYNCHRONIZE confirm primitive; H d)a PACTIVITYEND indication primitive; H e)a PACTIVITYEND confirm primitive. 6.6.4.1.1 H DTRANSFER request primitive  6.6.4.1.1.1 H If the requesting DTAMPM possesses the Data Token and receives a DTRANSFER request from the requestor, Document Information in the DTRANSFER request primitive, which has an abstract form, is segmented by the group (segment) of interchangedataelements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAMPM. The segmented abstract form is then transformed into the User Data in PDATA.  6.6.4.1.1.2 H The parameter "Document Information Type" contained in the DTRANSFER request should indicate "transfer of a document from a synchronization point", and the requesting DTAMPM issues a PACTIVITYRESUME request primitive and may continue the transfer procedure by issuing a PDATA request primitive for the segment of interchangedataelements following the last confirmed checkpoint. The checkpoint information is from the parameter "Synchronization Point" in the DTRANSFER request primitive.  6.6.4.1.1.3 H Another detailed procedure is followed by the 6.6.3.1.1.3, 6.6.3.1.1.4 and 6.6.3.1.1.5. %  6.6.4.1.2H H PACTIVITYRESUME indication primitive, PDATA PDUs, and PMINORSYNCHRONIZE indication primitives'H  6.6.4.1.2.1 H The responding DTAMPM receives a PACTIVITYRESUME indication primitive, indicating the start of transfer of Document Information. The responding DTAMPM receives a PMINORSYNCHRONIZE indication primitive. If the responding DTAMPM has secured the segment of interchangedataelements, it issues a PMINORSYNCHRONIZE response primitive. 6.6.4.1.3 H PMINORSYNCHRONIZE confirm primitive  6.6.4.1.3.1 H The detailed procedure is followed by the 6.6.3.1.3.1, 6.6.3.1.3.2 and 6.6.3.1.3.3. 6.6.4.1.4 H PACTIVITYEND indication primitive  6.6.4.1.4.1 H The detailed procedure is followed by the 6.6.3.1.4.1, 6.6.3.1.4.2 and 6.6.3.1.4.3. 6.6.4.1.5 H PACTIVITYEND confirm primitive  6.6.4.1.5.1 H The detailed procedure is followed by the 6.6.3.1.5.1 and 6.6.3.1.5.2.  6.6.4.2H Transferuserresume procedure mapped session service (transparent mode) H This procedure is driven by the following events: H a)a DTRANSFER request primitive from the requestor (sender of document);  H b)an SACTIVITYRESUME indication primitive, followed by one or more interchangedata elements as userdata of SDATA indication primitives each, except the last, followed by an SMINORSYNCHRONIZE indication primitive;' H c)an SMINORSYNCHRONIZE confirm primitive; H d)an SACTIVITYEND indication primitive; H e)an SACTIVITYEND confirm primitive. 6.6.4.2.1 H DTRANSFER request primitive  6.6.4.2.1.1 H If the requesting DTAMPM possesses the Data Token and receives a DTRANSFER request from the requestor, Document Information in the DTRANSFER request primitive, which has an abstract form, is segmented by the group (segment) of interchangedataelements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAMPM. The segmented abstract form is then transformed into the User Data in PDATA.  6.6.4.2.1.2 H The parameter "Document Information Type" contained in the DTRANSFER request should indicate the "transfer of a document from a synchronization point", and the requesting DTAMPM issues an SACTIVITYRESUME request primitive and may continue the transfer procedure by issuing a SDATA request primitive for the segment of interchangedataelements following the last confirmed checkpoint. The checkpoint information is from the parameter "Synchronization Point" in the DTRANSFER request primitive.  6.6.4.2.1.3 H Another detailed procedure is followed by the 6.6.3.2.1.3, 6.6.3.2.1.4 and 6.6.3.2.1.5.  6.6.4.2.2H H SACTIVITYRESUME indication primitive, SDATA PDUs, and SMINORSYNCHRONIZE indication primitives'H  6.6.4.2.2.1 H The responding DTAMPM receives an SACTIVITYRESUME indication primitive, indicating the start of transfer of Document Information. The responding DTAMPM receives an SMINOR SYNCHRONIZE indication primitive. If the responding DTAMPM has secured the segment of interchange dataelements, it issues an SMINORSYNCHRONIZE response primitive. 6.6.4.2.3 H SMINORSYNCHRONIZE confirm primitive  6.6.4.2.3.1 H The detailed procedure is followed by the 6.6.3.2.3.1, 6.6.3.2.3.2 and 6.6.3.2.3.3. 6.6.4.2.4 H SACTIVITYEND indication primitive  6.6.4.2.4.1 H The detailed procedure is followed by the 6.6.3.2.4.1 and 6.6.3.2.4.2. 6.6.4.2.5 H SACTIVITYEND confirm primitive  6.6.4.2.5.1 H The detailed procedure is followed by the 6.6.3.2.5.1 and 6.6.3.2.5.2.