6.5.3	DTAM capability procedure

6.5.3.1	DTAM Capability Procedure mapped onto Presentation Service (Normal Mode)

This procedure is driven by the following events:

a)	a D-CAPABILITY request primitive from the requestor;

b)	a DCPQ APDU as User Data on a P-CAPAB-DATA indication primitive;

c)	a D-CAPABILITY response primitive from the responder; and

d)	a P-CAPAB-DATA confirm primitive (that may contain a DCPR APDU).

6.5.3.1.1	D-CAPABILITY request primitive

6.5.3.1.1.1	The requesting DTAM-PM forms a DCPQ APDU from parameter values of the D-CAPABILITY request primitive. It issues a P-CAPAB-DATA request primitive. The User Data parameter of the P-CAPAB-DATA request primitive contains the DCPQ APDU.

6.5.3.1.1.2	The requesting DTAM-PM waits for a primitive from the Presentation service-provider, and does not accept any other primitive from the requestor other than a D-U-ABORT request primitive.

6.5.3.1.2	DCPQ APDU

6.5.3.1.2.1	The responding DTAM-PM receives a DCPQ APDU from its peer as User Data on a P-CAPAB-DATA indication primitive.

6.5.3.1.2.2	In order that the DCPQ APDU may always be acceptable to the responding DTAM-PM, it issues a D-CAPABILITY indication primitive to the responder. The D-CAPABILITY indication primitive parameters are derived from the DCPQ APDU. The DTAM-PM waits for a D-CAPABILITY response primitive from the responder and does not accept any other primitives from the responder except for the D-U-ABORT request primitive.

6.5.3.1.3	D-CAPABILITY response primitive

6.5.3.1.3.1	When the DTAM-PM receives the D-CAPABILITY response primitive, the Result parameter specifies whether the responder has accepted or rejected the DTAM capability requested. The DTAM-PM forms a DCPR APDU using the D-CAPABILITY response primitive parameters. The DCPR APDU is sent as the User Data parameter on the P-CAPAB-DATA response primitive.

6.5.3.1.3.2	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	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	P-CAPAB-DATA confirm primitive

6.5.3.1.4.1	The requesting DTAM-PM receives a P-CAPAB-DATA confirm primitive. The following situations are possible:

a)	the DTAM capability has been accepted; or

b)	the responder has rejected the DTAM capability requested by the requestor.

6.5.3.1.4.2	If the DTAM capability was accepted, the Capability Result field of the DCPR APDU specifies the appropriate acceptance value. The requesting DTAM-PM issues a D-CAPABILITY confirm primitive to the requestor based on parameters from the DCPR APDU. The D-CAPABILITY confirm primitive Capability Result Parameter specifies the appropriate acceptance value. The DTAM capability is negotiated.

6.5.3.1.4.3	If the DTAM capability was rejected by the responder, the Capability Result field of the DCPR APDU on the P-CAPAB-DATA confirm primitive indicates the reason for rejection. The requesting DTAM-PM issues a D-CAPABILITY confirm primitive to the requestor based on parameters from the DCPR APDU. The D-CAPABILITY confirm primitive Capability Result parameter contains the appropriate rejection value. The DTAM capability is not established.

6.5.3.2	DTAM capability procedure mapped onto session service (transparent mode)

This procedure is driven by the following events:

a)	a D-CAPABILITY request primitive from the requestor;

b)	a DCPQ APDU as User Data on an S-CAPAB-DATA indication primitive;

c)	a D-CAPABILITY response primitive from the responder; and

d)	an S-CAPAB-DATA confirm primitive (that may contain a DCPR APDU).

6.5.3.2.1	D-CAPABILITY request primitive

6.5.3.2.1.1	The requesting DTAM-PM forms a DCPQ APDU from parameter values of the D-CAPABILITY request primitive, and issues an S-CAPAB DATA request primitive. The User Data parameter of the S-CAPAB DATA request primitive contains the DCPQ APDU.

6.5.3.2.1.2	The requesting DTAM-PM waits for a primitive from the Session service-provider, and does not accept any other primitive from the requestor other than a D-U-ABORT request primitive.

6.5.3.2.2	DCPQ APDU

6.5.3.2.2.1	The responding DTAM-PM receives a DCPQ APDU from its peer as User Data on an S-CAPAB DATA indication primitive.

6.5.3.2.2.2	In order that the S-CAPAB DATA indication primitive and its DCPQ APDU may always be acceptable to the responding DTAM-PM, it issues a D-CAPABILITY indication primitive to the responder. The D-CAPABILITY indication primitive parameters are derived from the DCPQ APDU. The DTAM-PM waits for a D-CAPABILITY response primitive from the responder and does not accept any other primitives from the responder except for the D-ABORT request primitive.

6.5.3.2.3	D-CAPABILITY response primitive

6.5.3.2.3.1	When the DTAM-PM receives the D-CAPABILITY 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 DTAM-PM forms a DCPR APDU using the D-CAPABILITY response primitive parameters, and the DCPR APDU is sent as the User Data parameter on the S-CAPAB DATA response primitive.

6.5.3.2.3.2	In this way, the DTAM capability is negotiated by exchanging the Application Capabilities parameters available at the responder.

6.5.3.2.4	S-CAPAB DATA confirm primitive

6.5.3.2.4.1	The requesting DTAM-PM receives an S-CAPAB DATA confirm primitive. The DTAM capability is always negotiated by exchanging the Application Capabilities parameters.

6.5.3.2.4.2	If the DTAM capability was accepted, the requesting DTAM-PM issues a D-CAPABILITY 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 DTAM-PM.

6.5.4	Use of the DCPQ/DCPR APDU fields

The DCPQ APDU and DCPR APDU fields are used as follows.

6.5.4.1	Application capabilities

This is the Application Capabilities parameter value from the D-CAPABILITY request/response primitives. It appears as the Application Capabilities parameter value of the D-CAPABILITY indication/confirm primitives respectively. This parameter consists of the following sub-parameters.

6.5.4.1.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.5.4.1.2	Document architecture class

The value of this parameter is "formatted".

6.5.4.1.3	Non basic document characteristics

The value of this parameter is any combination of Non Basic Document Characteristics defined in Recommendation T.414.

6.5.4.1.4	Non basic structural characteristics

The value of this parameter is any combination of Non Basic Structural Characteristics defined in Recommendation T.414.

6.5.4.1.5	Operational application profile

The detailed specification of Operational Application Profile is for further study.

6.5.4.1.6	Storage capacity

See § 6.2.4.8.

6.5.4.2	Capability result

If the DCPQ APDU was rejected by the responder, this field is supplied by the responder and is the Capability Result parameter from the D-CAPABILITY response primitive. In this situation, it appears as the Capability Result parameter on the D-CAPABILITY confirm primitive. This field can take one of the following:

-	confirmation that all the requested capabilities are available at the DTAM responder;

-	a list of the requested capabilities that are available at the DTAM responder;

-	a complete list of non-basic receiving capabilities;

-	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.3	User information

This is the User Information parameter from the D-CAPABILITY request and response primitive. It appears as the User Information parameter of the D-CAPABILITY indication and confirm primitive, if issued.

6.6	Document bulk transfer

6.6.1	Purpose

6.6.1.1	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 D-TRANSFER services.

6.6.1.2	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.3	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.4	The Document Bulk Transfer is composed of two different sets of procedures depending on the Reliable Transfer Mode.

1)	Reliable transfer mode 1

a)	Transfer Procedure for transmission of a complete document;

b)	Transfer-user-resume Procedure for retransmission of a partial document for resuming purposes. This procedure is controlled by the DTAM user;

c)	Transfer-interrupt Procedure to interrupt the transmission of a document in case of error;

d)	Transfer-discard 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.

In Reliable Transfer Mode 1, the Transfer-interrupt and the Transfer-discard Procedures result in a D-TRANSFER 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).

Figures A-1/T.433 and A-2/T.433 illustrate the basic protocol sequences for the Reliable Transfer Mode 1.

2)	Reliable transfer mode 2

a)	Transfer Procedure (see above, Reliable Transfer, Mode 1);

b)	Transfer-resume Procedure for retransmission of a partial document. This procedure is completely controlled by the DTAM-PM;

c)	Transfer-interrupt Procedure (see above Reliable Transfer, Mode 1);

d)	Transfer-discard Procedure (see above Reliable Transfer, Mode 1);

e)	Association-recovery Procedure (for further study).

In Reliable Transfer Mode 2, following the Transfer-interrupt and Transfer-discard Procedures, the DTAM-PM initiates a new Transfer Procedure or a Transfer-resume Procedure. Attempts to transfer or retransfer the document may not be performed by the DTAM-PM after the transfer time is out. The transfer time-out may result to discard the document and to abort the procedure.

Figures A-3/T.433 and A-4/T.433 illustrate the basic protocol sequences for the Reliable Transfer Mode 2.

In the Transparent Mode under Session Service environment, only Reliable Transfer Mode 1 is used.

In the Normal Mode under the OSI environment, both Reliable Transfer Modes 1 and 2 are available.

6.6.2	APDUs used

6.6.2.1	No APDUs are used in this procedure. The Document Information corresponds to a D-TRANSFER request service primitive. There is no D-TRANSFER REQ APDU as such.

6.6.2.2	Each Document Information, conveyed in a D-TRANSFER 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.3	The Document Information, which consists of one or more interchange-data-elements 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 interchange-data-elements and is transferred by the Presentation/Session data transfer services.

6.6.2.4	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 user-data values of Presentation/Session data transfer services is Document Information. An example of document segmenting mechanism is given in Figure 2/T.433.

FIGURE 2/T.433

An example of document segmenting mechanism

6.6.3	Transfer procedure

This procedure is used to transfer a complete document.

6.6.3.1	Transfer procedure mapped onto presentation service (normal mode)

This procedure is driven by the following events:

a)	a D-TRANSFER request primitive from the requestor (sender of document);

b)	a P-ACTIVITY-START indication primitive, followed by one or more interchange-data- elements as user-data of P-DATA indication primitives each, except the last, followed by a P-MINOR-SYNCHRONZE indication primitive;

c)	a P-MINOR-SYNCHRONIZE confirm primitive;

d)	a P-ACTIVITY-END indication primitive;

e)	a P-ACTIVITY-END confirm primitive;

f)	a Transfer Time-out.

Note - In the case of multiple documents transmission within one association, the above procedure will be applied repeatedly.

6.6.3.1.1	D-TRANSFER request primitive

6.6.3.1.1.1	If the requesting DTAM-PM possesses the Data Token and receives a D-TRANSFER request from the requestor, Document Information in the D-TRANSFER request primitive, which has an abstract form, is segmented by the group (segment) of interchange-data-elements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAM-PM. The segmented abstract form is then transformed into the User Data in P-DATA.

6.6.3.1.1.2	The parameter "Document Information Type" contained in the D-TRANSFER request should indicate "transfer of a document from its beginning", and the requesting DTAM-PM issues a P-ACTIVITY-START request primitive and may start transmitting the first segment of interchange-data- elements in a P-DATA request primitive immediately after the P-ACTIVITY-START request primitive is issued, since the P-ACTIVITY-START service is not a confirmed service.

6.6.3.1.1.3	If the segment of interchange-data-elements transferred is not the last in a series of those segments, the requesting DTAM-PM inserts a checkpoint by issuing a P-MINOR-SYNCHRONIZE request primitive. The requesting DTAM-PM uses only the "explicit confirmation expected" type of minor synchronization. The requesting DTAM-PM may issue further P-DATA request primitives and P-MINOR- SYNCHRONIZE request primitives unless the agreed Window-size has been reached.

6.6.3.1.1.4	P-Minor-Synchronization Points shall be located at the end of each segment of interchange-data-elements. 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 interchange-data- elements and not within the element.

6.6.3.1.1.5	If the segment of interchange-data-elements is the only one, or the last in a series of segments of interchange-data-elements, the requesting DTAM-PM issues a P-ACTIVITY-END request primitive. All data transfer must take place within an activity.

6.6.3.1.2	P-ACTIVITY-START indication primitive, P-DATA PDUs, and P-MINOR-SYNCHRONIZE indication primitives

6.6.3.1.2.1	The responding DTAM-PM receives a P-ACTIVITY-START indication primitive, indicating the start of transfer of Document Information. The responding DTAM-PM receives a P-MINOR-SYNCHRONIZE indication primitive. If the responding DTAM-PM has secured the segment of interchange-data-elements, it issues a P-MINOR-SYNCHRONIZE response primitive.

6.6.3.1.3	P-MINOR-SYNCHRONIZE confirm primitive

6.6.3.1.3.1	When the requesting DTAM-PM receives a P-MINOR-SYNCHRONIZE confirm primitive, it assumes that the responding DTAM-PM has secured the segments of interchange-data-elements up to that point.

6.6.3.1.3.2	The requesting DTAM-PM may issue further P-DATA request primitives and P-MINOR- SYNCHRONIZE request primitives unless the agreed Window-size has been reached. The window is advanced when a P-MINOR-SYNCHRONIZE confirm primitive is received by the requesting DTAM-PM.

6.6.3.1.3.3	When a complete Document Information has been transmitted, the requesting DTAM-PM issues a P-ACTIVITY-END request primitive.

6.6.3.1.4	P-ACTIVITY-END indication primitive

6.6.3.1.4.1	A P-ACTIVITY-END Indication primitive indicates to the responding DTAM-PM that a complete Document Information has been transferred.

6.6.3.1.4.2	If the responding DTAM-PM has secured the complete Document Information, it issues a D-TRANSFER indication primitive to the responder, and issues a P-ACTIVITY-END response primitive.

6.6.3.1.4.3	The responding DTAM-PM records the Session-connection-identifier and the Activity Identifier of the last Document Information which it completely secured for association-recovery purposes.

6.6.3.1.5	P-ACTIVITY-END confirm primitive

6.6.3.1.5.1	An activity end is an implicit major synchronization point and once successfully confirmed by means of a P-ACTIVITY-END confirm primitive, it indicates to the requesting DTAM-PM that the Document Information has been secured by the responding DTAM-PM. The requesting DTAM-PM may then delete the transferred Document Information.

6.6.3.1.5.2	When the requesting DTAM-PM receives the P-ACTIVITY-END confirm primitive, it issues a D-TRANSFER confirm primitive with a Result parameter value of "document-information-transferred" to the requestor.

6.6.3.1.6	Transfer time-out (only for reliable transfer mode 2)

6.6.3.1.6.1	If a Document Information has not been transferred within the time specified in the Transfer-time parameter of the D-TRANSFER request primitive (that is, the requesting DTAM-PM has not received the P-ACTIVITY-END confirm primitive), the requesting DTAM-PM performs the transfer-discard procedure (see § 6.6.6) followed by the transfer-abort procedure (see § 6.4.3.1.4).

6.6.3.1.6.2	If during the transfer-discard procedure the requesting DTAM-PM does not receive a P-ACTIVITY-DISCARD confirm primitive within a (locally specified) reasonable time, the requesting DTAM-PM performs the transfer-abort procedure followed by the DTAM provider-abort procedure.

6.6.3.2	Transfer procedure mapped onto session service (transparent mode)

This procedure is driven by the following events:

a)	a D-TRANSFER request primitive from the requestor (sender of document);

b)	an S-ACTIVITY-START indication primitive, followed by one or more interchange-data- elements as user-data of S-DATA indication primitives each, except the last, followed by an S-MINOR-SYNCHRONIZE indication primitive;

c)	an S-MINOR-SYNCHRONIZE confirm primitive;

d)	an S-ACTIVITY-END indication primitive;

e)	an S-ACTIVITY-END confirm primitive;

Note - In the case of multiple document transmission within one association, the above procedure will be applied repeatedly.

6.6.3.2.1	D-TRANSFER request primitive

6.6.3.2.1.1	If the requesting DTAM-PM possesses the Data Token and receives a D-TRANSFER request from the requestor, Document Information in the D-TRANSFER request primitive which has an abstract form is segmented by the group (segment) of interchange-data-elements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAM-PM. The segmented abstract form is then transformed into the User Data in S-DATA.

6.6.3.2.1.2	The parameter "Document Information Type" contained in the D-TRANSFER request should indicate the "transfer of a document from its beginning", and the requesting DTAM-PM issues an S-ACTIVITY-START request primitive and may start transmitting the first segment of interchange-data- elements in an S-DATA request primitive immediately after the S-ACTIVITY-START request primitive is issued, since the S-ACTIVITY-START service is not a confirmed service. All data transfer should take place within an activity.

6.6.3.2.1.3	If the segment of interchange-data-elements transferred is not the last in a series of those segments, the requesting DTAM-PM inserts a checkpoint by issuing an S-MINOR-SYNCHRONIZE request primitive. The requesting DTAM-PM uses only the "explicit confirmation expected" type of minor synchronization. The requesting DTAM-PM may issue further S-DATA request primitives and S-MINOR- SYNCHRONIZE request primitives unless the agreed Window-size has been reached.

6.6.3.2.1.4	S-Minor-Synchronization Points shall be located at the end of each segment of interchange-data-elements. 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 interchange-data- elements and not within the element.

6.6.3.2.1.5	If the segment of interchange-data-elements is the only one, or the last in a series of segments of interchange-data-elements, the requesting DTAM-PM issues an S-ACTIVITY-END request primitive. All data transfer must take place within an activity.

6.6.3.2.2	S-ACTIVITY-START indication primitive, S-DATA PDUs, and S-MINOR-SYNCHRONIZE indication primitives

6.6.3.2.2.1	The responding DTAM-PM receives an S-ACTIVITY-START indication primitive, indicating the start of transfer of Document Information. The responding DTAM-PM receives an S-MINOR-SYNCHRONIZE indication primitive. If the responding DTAM-PM has secured the segment of interchange-data-elements, it issues an S-MINOR-SYNCHRONIZE response primitive.

6.6.3.2.3	S-MINOR-SYNCHRONIZE confirm primitive

6.6.3.2.3.1	When the requesting DTAM-PM receives an S-MINOR-SYNCHRONIZE confirm primitive, it assumes that the responding DTAM-PM has secured the segments of interchange-data-elements up to that point.

6.6.3.2.3.2	The requesting DTAM-PM may issue further S-DATA request primitives and S-MINOR- SYNCHRONIZE request primitives unless the agreed Window-size has been reached. The window is advanced when an S-MINOR-SYNCHRONIZE confirm primitive is received by the requesting DTAM-PM.

6.6.3.2.3.3	When a complete Document Information has been transmitted, the requesting DTAM-PM issues an S-ACTIVITY-END request primitive.

6.6.3.2.4	S-ACTIVITY-END indication primitive

6.6.3.2.4.1	An S-ACTIVITY-END Indication primitive indicates to the responding DTAM-PM that a complete Document Information has been transferred.

6.6.3.2.4.2	If the responding DTAM-PM has secured the complete Document Information, it issues a D-TRANSFER indication primitive to the responder, and issues an S-ACTIVITY-END response primitive.

4.6.3.2.5	S-ACTIVITY-END confirm primitive

6.6.3.2.5.1	An activity end is an implicit major synchronization point and once successfully confirmed by means of an S-ACTIVITY-END confirm primitive, it indicates to the requesting DTAM-PM that the Document Information has been secured by the responding DTAM-PM. The requesting DTAM-PM may then delete the transferred Document Information.

6.6.3.2.5.2	When the requesting DTAM-PM receives the S-ACTIVITY-END confirm primitive, it issues a D-TRANSFER confirm primitive with a Result parameter value of "document-information-transferred" to the requestor.

6.6.4	Transfer-user-resume procedure

This procedure is used to resume transferring the part of the document which has not been transferred at the previous transmission.

6.6.4.1	Transfer-user-resume procedure mapped onto presentation service (normal mode)

This procedure is driven by the following events:

a)	a D-TRANSFER request primitive from the requestor (sender of document);

b)	a P-ACTIVITY-RESUME indication primitive, followed by one or more interchange-data- elements as user-data of P-DATA indication primitives each, except the last, followed by a P-MINOR-SYNCHRONIZE indication primitive;

c)	a P-MINOR-SYNCHRONIZE confirm primitive;

d)	a P-ACTIVITY-END indication primitive;

e)	a P-ACTIVITY-END confirm primitive.

6.6.4.1.1	D-TRANSFER request primitive

6.6.4.1.1.1	If the requesting DTAM-PM possesses the Data Token and receives a D-TRANSFER request from the requestor, Document Information in the D-TRANSFER request primitive, which has an abstract form, is segmented by the group (segment) of interchange-data-elements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAM-PM. The segmented abstract form is then transformed into the User Data in P-DATA.

6.6.4.1.1.2	The parameter "Document Information Type" contained in the D-TRANSFER request should indicate "transfer of a document from a synchronization point", and the requesting DTAM-PM issues a P-ACTIVITY-RESUME request primitive and may continue the transfer procedure by issuing a P-DATA request primitive for the segment of interchange-data-elements following the last confirmed checkpoint. The checkpoint information is from the parameter "Synchronization Point" in the D-TRANSFER request primitive.

6.6.4.1.1.3	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.2	P-ACTIVITY-RESUME indication primitive, P-DATA PDUs, and P-MINOR-SYNCHRONIZE indication primitives

6.6.4.1.2.1	The responding DTAM-PM receives a P-ACTIVITY-RESUME indication primitive, indicating the start of transfer of Document Information. The responding DTAM-PM receives a P-MINOR-SYNCHRONIZE indication primitive. If the responding DTAM-PM has secured the segment of interchange-data-elements, it issues a P-MINOR-SYNCHRONIZE response primitive.

6.6.4.1.3	P-MINOR-SYNCHRONIZE confirm primitive

6.6.4.1.3.1	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	P-ACTIVITY-END indication primitive

6.6.4.1.4.1	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	P-ACTIVITY-END confirm primitive

6.6.4.1.5.1	The detailed procedure is followed by the §§ 6.6.3.1.5.1 and 6.6.3.1.5.2.

6.6.4.2	Transfer-user-resume procedure mapped session service (transparent mode)

This procedure is driven by the following events:

a)	a D-TRANSFER request primitive from the requestor (sender of document);

b)	an S-ACTIVITY-RESUME indication primitive, followed by one or more interchange-data- elements as user-data of S-DATA indication primitives each, except the last, followed by an S-MINOR-SYNCHRONIZE indication primitive;

c)	an S-MINOR-SYNCHRONIZE confirm primitive;

d)	an S-ACTIVITY-END indication primitive;

e)	an S-ACTIVITY-END confirm primitive.

6.6.4.2.1	D-TRANSFER request primitive

6.6.4.2.1.1	If the requesting DTAM-PM possesses the Data Token and receives a D-TRANSFER request from the requestor, Document Information in the D-TRANSFER request primitive, which has an abstract form, is segmented by the group (segment) of interchange-data-elements. The segmenting unit (e.g. page, block) depends upon the characteristics of the DTAM-PM. The segmented abstract form is then transformed into the User Data in P-DATA.

6.6.4.2.1.2	The parameter "Document Information Type" contained in the D-TRANSFER request should indicate the "transfer of a document from a synchronization point", and the requesting DTAM-PM issues an S-ACTIVITY-RESUME request primitive and may continue the transfer procedure by issuing a S-DATA request primitive for the segment of interchange-data-elements following the last confirmed checkpoint. The checkpoint information is from the parameter "Synchronization Point" in the D-TRANSFER request primitive.

6.6.4.2.1.3	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.2	S-ACTIVITY-RESUME indication primitive, S-DATA PDUs, and S-MINOR-SYNCHRONIZE indication primitives

6.6.4.2.2.1	The responding DTAM-PM receives an S-ACTIVITY-RESUME indication primitive, indicating the start of transfer of Document Information. The responding DTAM-PM receives an S-MINOR- SYNCHRONIZE indication primitive. If the responding DTAM-PM has secured the segment of interchange- data-elements, it issues an S-MINOR-SYNCHRONIZE response primitive.

6.6.4.2.3	S-MINOR-SYNCHRONIZE confirm primitive

6.6.4.2.3.1	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	S-ACTIVITY-END indication primitive

6.6.4.2.4.1	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	S-ACTIVITY-END confirm primitive

6.6.4.2.5.1	The detailed procedure is followed by the §§ 6.6.3.2.5.1 and 6.6.3.2.5.2.