home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / troff / 8_5_11.tro < prev    next >
Encoding:
Text File  |  1991-12-22  |  78.2 KB  |  3,574 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ X.228\fR 
  25. .RT
  26. .sp 2P
  27. .sp 1P
  28. .ce 1000
  29. \fBRELIABLE TRANSFER:\fR \fBPROTOCOL SPECIFICATION\fR 
  30. .FS
  31. Recommendation\ X.228 and ISO 9066\(hy2 [Information processing systems 
  32. \(em Text 
  33. Communication \(em Reliable Transfer Part\ 2: Protocol Specification] were
  34. developed in close collaboration and are technically aligned.
  35. .FE
  36. .EF '%    Fascicle\ VIII.5\ \(em\ Rec.\ X.228''
  37. .OF '''Fascicle\ VIII.5\ \(em\ Rec.\ X.228    %'
  38. .ce 0
  39. .sp 1P
  40. .ce 1000
  41. \fI(Melbourne, 1988)\fR 
  42. .sp 9p
  43. .RT
  44. .ce 0
  45. .sp 1P
  46. .LP
  47.     The CCITT,
  48. .sp 1P
  49. .RT
  50. .sp 1P
  51. .LP
  52. \fIconsidering\fR 
  53. .sp 9p
  54. .RT
  55. .PP
  56. (a)
  57. that Recommendation X.200 defines the Basic Reference Model of Open Systems 
  58. Interconnection (OSI) for CCITT applications; 
  59. .PP
  60. (b)
  61. that Recommendation X.210 defines the service conventions for describing 
  62. the services of the OSI reference model; 
  63. .PP
  64. (c)
  65. that Recommendation X.216 defines the Presentation Layer
  66. service;
  67. .PP
  68. (d)
  69. that Recommendation X.217 defines the Association Control   service;
  70. .PP
  71. (e)
  72. that Recommendation X.218 defines the Reliable Transfer
  73. service;
  74. .PP
  75. (f
  76. )
  77. that there is a need for common Reliable Transfer
  78. support for various applications;
  79. .sp 1P
  80. .LP
  81. \fIunanimously declares\fR 
  82. .sp 9p
  83. .RT
  84. .PP
  85. that this Recommendation defines the Reliable Transfer protocol of Open 
  86. Systems Interconnection for CCITT Applications as given in the Scope and 
  87. Field of Application. 
  88. .sp 1P
  89. .ce 1000
  90. CONTENTS
  91. .ce 0
  92. .sp 1P
  93. .sp 2P
  94. .LP
  95. 0
  96.     \fIIntroduction\fR 
  97. .sp 1P
  98. .RT
  99. .sp 1P
  100. .LP
  101. 1
  102.     \fIScope and Field of Application\fR 
  103. .sp 9p
  104. .RT
  105. .sp 1P
  106. .LP
  107. 2
  108.     \fIReferences\fR 
  109. .sp 9p
  110. .RT
  111. .sp 1P
  112. .LP
  113. 3
  114.     \fIDefinitions\fR 
  115. .sp 9p
  116. .RT
  117. .sp 1P
  118. .LP
  119. 4
  120.     \fIAbbreviations\fR 
  121. .sp 9p
  122. .RT
  123. .sp 1P
  124. .LP
  125. 5
  126.     \fIConventions\fR 
  127. .sp 9p
  128. .RT
  129. .sp 1P
  130. .LP
  131. 6
  132.     \fIOverview of the Protocol\fR 
  133. .sp 9p
  134. .RT
  135. .sp 1P
  136. .LP
  137. 7
  138.     \fIElements of Procedure\fR 
  139. .sp 9p
  140. .RT
  141. .sp 1P
  142. .LP
  143. 8
  144.     \fIMapping to Used Services\fR 
  145. .sp 9p
  146. .RT
  147. .sp 1P
  148. .LP
  149. 9
  150.     \fIAbstract Syntax Definition of APDUs\fR 
  151. .sp 9p
  152. .RT
  153. .sp 1P
  154. .LP
  155. 10
  156.     \fIConformance\fR 
  157. .sp 9p
  158. .RT
  159. .sp 1P
  160. .LP
  161. \fIAnnex A\fR     \(em
  162.     State Transition Tables
  163. .sp 9p
  164. .RT
  165. .sp 1P
  166. .LP
  167. \fIAnnex B\fR     \(em
  168.      Differences between this Recommendation and\fR Recommendation\ X.410\ 
  169. \(em\ 1984 
  170. .sp 9p
  171. .RT
  172. .sp 1P
  173. .LP
  174. \fIAnnex C\fR     \(em
  175.     Summary of Assigned Object Identifier
  176. Values
  177. .bp
  178. .sp 9p
  179. .RT
  180. .sp 2P
  181. .LP
  182. \fB0\fR     \fBIntroduction\fR 
  183. .sp 1P
  184. .RT
  185. .PP
  186. This Recommendation specifies the protocol for the services
  187. provided by an application\(hyservice\(hyelement\ \(em\ the Reliable Transfer 
  188. Service 
  189. Element (RTSE)\ \(em\ to provide for the Reliable Transfer of Application 
  190. Protocol Data Units (APDUs) between open systems. This Recommendation is 
  191. one of a set of Recommendations specifying the protocols for sets of 
  192. application\(hyservice\(hyelements commonly used by a number of applications.
  193. .PP
  194. Reliable Transfer provides an application\(hyindependent mechanism to
  195. recover from communication and end\(hysystem failure minimizing the amount of
  196. retransmission.
  197. .PP
  198. This Recommendation is technically aligned with ISO 9066\(hy2.
  199. .RT
  200. .sp 2P
  201. .LP
  202. \fB1\fR     \fBScope and Field of Application\fR 
  203. .sp 1P
  204. .RT
  205. .PP
  206. This Recommendation specifies the protocol (abstract syntax) and
  207. procedures for the Reliable Transfer Service Element services (Recommendation 
  208. X.218). The RTSE services are provided in conjunction with the Association 
  209. Control Service Element (ACSE) services (Recommendation X.217) and the ACSE
  210. protocol (Recommendation X.227), and the presentation\(hyservice (Recommendation 
  211. X.216). 
  212. .PP
  213. The RTSE procedures are defined in terms of:
  214. .RT
  215. .LP
  216.     a)
  217.     the interactions between peer RTSE protocol machines
  218. through the use of ACSE and the presentation\(hyservice.
  219. .LP
  220.     b)
  221.     the interactions between the RTSE protocol machine and its  service\(hyuser.
  222. .PP
  223. This Recommendation specifies conformance requirements for systems implementing 
  224. these procedures. 
  225. .sp 2P
  226. .LP
  227. \fB2\fR     \fBReferences\fR 
  228. .sp 1P
  229. .RT
  230. .sp 1P
  231. .LP
  232. Recommendation X.200\ \(em
  233.     Reference Model of Open Systems Interconnection
  234. for CCITT Applications (See also ISO\ 7498)
  235. .sp 9p
  236. .RT
  237. .sp 1P
  238. .LP
  239. Recommendation X.208\ \(em
  240.     Specification of abstract syntax notation (See
  241. also ISO\ 8824).
  242. .sp 9p
  243. .RT
  244. .sp 1P
  245. .LP
  246. Recommendation X.209\ \(em
  247.     Specification of Basic Encoding Rules for the
  248. abstract syntax notation (See also ISO\ 8825).
  249. .sp 9p
  250. .RT
  251. .sp 1P
  252. .LP
  253. Recommendation X.210\ \(em
  254.     Open Systems Interconnection Layer Service
  255. Definition Conventions (See also ISO/TR\ 8509).
  256. .sp 9p
  257. .RT
  258. .sp 1P
  259. .LP
  260. Recommendation X.216\ \(em
  261.      Presentation Service Definition for Open Systems Interconnection for 
  262. CCITT Applications (See also ISO\ 8822). 
  263. .sp 9p
  264. .RT
  265. .sp 1P
  266. .LP
  267. Recommendation X.217\ \(em
  268.      Association Control Service Definition for CCITT Applications (See also 
  269. ISO\ 8649). 
  270. .sp 9p
  271. .RT
  272. .sp 1P
  273. .LP
  274. Recommendation X.218\ \(em
  275.     Reliable Transfer: Model and Service Definition
  276. (See also ISO 9066\(hy1)
  277. .sp 9p
  278. .RT
  279. .sp 1P
  280. .LP
  281. Recommendation X.219\ \(em
  282.     Remote Operations: Model, Notation and Service
  283. Definition (See also ISO\ 9072\(hy1)
  284. .sp 9p
  285. .RT
  286. .sp 1P
  287. .LP
  288. Recommendation X.227\ \(em
  289.     Association Control Protocol Specification for
  290. CCITT Applications (See also ISO\ 8650).
  291. .sp 9p
  292. .RT
  293. .sp 2P
  294. .LP
  295. \fB3\fR     \fBDefinitions\fR 
  296. .sp 1P
  297. .RT
  298. .sp 1P
  299. .LP
  300. 3.1
  301.     \fIReference Model Definitions\fR 
  302. .sp 9p
  303. .RT
  304. .PP
  305. This Recommendation is based on the concepts developed in
  306. Recommendation X. 200 and makes use of the following terms defined in
  307. it:
  308. .RT
  309. .LP
  310.     a)
  311.     Application Layer;
  312. .LP
  313.     b)
  314.     application\(hyprocess;
  315. .LP
  316.     c)
  317.     application\(hyentity;
  318. .bp
  319. .LP
  320.     d)
  321.     application\(hyservice\(hyelement;
  322. .LP
  323.     e)
  324.     application\(hyprotocol\(hydata\(hyunit;
  325. .LP
  326.     f
  327. )
  328.     application\(hyprotocol\(hycontrol\(hyinformation;
  329. .LP
  330.     g)
  331.     presentation\(hyservice;
  332. .LP
  333.     h)
  334.     presentation\(hyconnection;
  335. .LP
  336.     i)
  337.     session\(hyservice;
  338. .LP
  339.     j
  340. )
  341.     session\(hyconnection; and
  342. .LP
  343.     k)
  344.     user\(hyelement
  345. .LP
  346.     l)
  347.     two\(hyway\(hyalternate interaction
  348. .LP
  349.     m)
  350.     transfer syntax.
  351. .sp 1P
  352. .LP
  353. 3.2
  354.     \fIService Conventions Definitions\fR 
  355. .sp 9p
  356. .RT
  357. .PP
  358. This Recommendation makes use of the following terms defined in
  359. Recommendation\ X.210:
  360. .RT
  361. .LP
  362.     a)
  363.     service\(hyprovider;
  364. .LP
  365.     b)
  366.     service\(hyuser;
  367. .LP
  368.     c)
  369.     confirmed service;
  370. .LP
  371.     d)
  372.     non\(hyconfirmed service;
  373. .LP
  374.     e)
  375.     provider\(hyinitiated service;
  376. .LP
  377.     f
  378. )
  379.     primitive;
  380. .LP
  381.     g)
  382.     request (primitive);
  383. .LP
  384.     h)
  385.     indication (primitive);
  386. .LP
  387.     i)
  388.     response (primitive); and
  389. .LP
  390.     j
  391. )
  392.     confirm (primitive).
  393. .sp 1P
  394. .LP
  395. 3.3
  396.     \fIPresentation Service Definitions\fR 
  397. .sp 9p
  398. .RT
  399. .PP
  400. This Recommendation makes use of the following terms defined in
  401. Recommendation\ X.216:
  402. .RT
  403. .LP
  404.     a)
  405.     abstract syntax;
  406. .LP
  407.     b)
  408.     abstract syntax name;
  409. .LP
  410.     c)
  411.     presentation context;
  412. .LP
  413.     d)
  414.     default context.
  415. .sp 1P
  416. .LP
  417. 3.4
  418.     \fIAssociation Control Definitions\fR 
  419. .sp 9p
  420. .RT
  421. .PP
  422. This Recommendation makes use of the following terms defined in
  423. Recommendation\ X.217:
  424. .RT
  425. .LP
  426.     a)
  427.     application\(hyassociation; association;
  428. .LP
  429.     b)
  430.     application context;
  431. .LP
  432.     c)
  433.     Association Control Service Element; and
  434. .LP
  435.     d)
  436.     X.410\(hy1984 mode.
  437. .sp 1P
  438. .LP
  439. 3.5
  440.     \fIRTSE Service Definitions\fR 
  441. .sp 9p
  442. .RT
  443. .PP
  444. This Recommendation makes use of the following terms defined in
  445. Recommendation\ X.218:
  446. .RT
  447. .LP
  448.     a)
  449.     association\(hyinitiating\(hyapplication\(hyentity; association\(hyinitiator;
  450. .LP
  451.     b)
  452.     association\(hyresponding\(hyapplication\(hyentity; association\(hyresponder;
  453. .LP
  454.     c)
  455.     sending\(hyapplication\(hyentity; sender;
  456. .LP
  457.     d)
  458.     receiving\(hyapplication\(hyentity; receiver;
  459. .LP
  460.     e)
  461.     requestor;
  462. .LP
  463.     f
  464. )
  465.     acceptor;
  466. .LP
  467.     g)
  468.     Reliable Transfer Service Element;
  469. .LP
  470.     h)
  471.     RTSE\(hyuser;
  472. .LP
  473.     i)
  474.     RTSE\(hyprovider;
  475. .LP
  476.     j
  477. )
  478.     ACSE\(hyprovider;
  479. .bp
  480. .LP
  481.     k)
  482.     monologue interaction;
  483. .LP
  484.     l)
  485.     syntax\(hymatching\(hyservices;
  486. .LP
  487.     m)
  488.     Reliable Transfer;
  489. .LP
  490.     n)
  491.     X.410\(hy1984 mode; and
  492. .LP
  493.     o)
  494.     normal mode.
  495. .sp 1P
  496. .LP
  497. 3.6
  498.     \fIReliable Transfer Protocol Specification Definitions\fR 
  499. .sp 9p
  500. .RT
  501. .PP
  502. For the purpose of this Recommendation the following definitions
  503. apply:
  504. .RT
  505. .sp 1P
  506. .LP
  507. 3.6.1 
  508.     \fBreliable\(hytransfer\(hyprotocol\(hymachine\fR :
  509. .sp 9p
  510. .RT
  511. .PP
  512. The protocol machine for the Reliable Transfer Service Element
  513. specified in this Recommendation.
  514. .RT
  515. .sp 1P
  516. .LP
  517. 3.6.2
  518.     \fBrequesting\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
  519. .sp 9p
  520. .RT
  521. .PP
  522. The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
  523. requestor of a particular Reliable Transfer Service Element service.
  524. .RT
  525. .sp 1P
  526. .LP
  527. 3.6.3
  528.     \fBaccepting\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
  529. .sp 9p
  530. .RT
  531. .PP
  532. The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
  533. acceptor for a particular Reliable Transfer Service Element service.
  534. .RT
  535. .sp 1P
  536. .LP
  537. 3.6.4
  538.     \fBsending\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
  539. .sp 9p
  540. .RT
  541. .PP
  542. The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
  543. sender.
  544. .RT
  545. .sp 1P
  546. .LP
  547. 3.6.5
  548.     \fBreceiving\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
  549. .sp 9p
  550. .RT
  551. .PP
  552. The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
  553. receiver.
  554. .RT
  555. .sp 1P
  556. .LP
  557. 3.6.6
  558.      \fBassociation\(hyinitiating\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR 
  559. : 
  560. .sp 9p
  561. .RT
  562. .PP
  563. The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is
  564. the association\(hyinitiator.
  565. .RT
  566. .sp 1P
  567. .LP
  568. 3.6.7
  569.      \fBassociation\(hyresponding\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR 
  570. : 
  571. .sp 9p
  572. .RT
  573. .PP
  574. The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is
  575. the association\(hyresponder.
  576. .RT
  577. .sp 2P
  578. .LP
  579. \fB4\fR     \fBAbbreviations\fR 
  580. .sp 1P
  581. .RT
  582. .sp 1P
  583. .LP
  584. 4.1
  585.     \fIData Units\fR 
  586. .sp 9p
  587. .RT
  588. .PP
  589. APDU \ 
  590. application\(hyprotocol\(hydata\(hyunit.
  591. .RT
  592. .sp 1P
  593. .LP
  594. 4.2
  595.     \fITypes of Application\(hyprotocol\(hydata\(hyunits\fR 
  596. .sp 9p
  597. .RT
  598. .PP
  599. The following abbreviations have been given to the
  600. application\(hyprotocol\(hydata\(hyunits defined in this Recommendation.
  601. .RT
  602. .LP
  603.     RTAB
  604.     RT\(hyP\(hyABORT and RT\(hyU\(hyABORT
  605. application\(hyprotocol\(hydata\(hyunit
  606. .LP
  607.     RTORQ
  608.     RT\(hyOPEN\(hyREQUEST application\(hyprotocol\(hydata\(hyunit
  609. .LP
  610.     RTOAC
  611.     RT\(hyOPEN\(hyACCEPT application\(hyprotocol\(hydata\(hyunit
  612. .LP
  613.     RTORJ
  614.     RT\(hyOPEN\(hyREJECT application protocol\(hydata\(hyunit
  615. .LP
  616.     RTTR
  617.     RT\(hyTRANSFER application\(hyprotocol\(hydata\(hyunit
  618. .LP
  619.     RTTP
  620.     RT\(hyTOKEN\(hyPLEASE application\(hyprotocol\(hydata\(hyunit
  621. .bp
  622. .sp 1P
  623. .LP
  624. 4.3
  625.     \fIOther Abbreviations\fR 
  626. .sp 9p
  627. .RT
  628. .PP
  629. The following abbreviations are used in this
  630. Recommendation.
  631. .RT
  632. .LP
  633.     AE
  634.     application\(hyentity
  635. .LP
  636.     ACSE
  637.     Association Control Service Element
  638. .LP
  639.     ASE
  640.     application\(hyservice\(hyelement
  641. .LP
  642.     RTPM
  643.     reliable\(hytransfer\(hyprotocol\(hymachine
  644. .LP
  645.     RT (or RTS)
  646.     Reliable Transfer
  647. .LP
  648.     RTSE
  649.     Reliable Transfer Service Element
  650. .sp 2P
  651. .LP
  652. \fB5\fR     \fBConventions\fR 
  653. .sp 1P
  654. .RT
  655. .PP
  656. This Recommendation employs a tabular presentation of its APDU
  657. fields. In clause\ 7, tables are presented for each RTSE APDU. Each field is
  658. summarized using the following notation:
  659. .RT
  660. .LP
  661.     M
  662.     presence is mandatory
  663. .LP
  664.     U
  665.     presence is a RTSE service\(hyuser option
  666. .LP
  667.     T
  668.     presence is a RTPM option
  669. .LP
  670.     req
  671.     source is related request primitive
  672. .LP
  673.     ind
  674.     sink is related indication primitive
  675. .LP
  676.     resp
  677.     source is related response primitive
  678. .LP
  679.     conf
  680.     sink is related confirm primitive
  681. .LP
  682.     sp
  683.     source or sink is the RTPM
  684. .PP
  685. The structure of each RTSE APDU is specified in clause 9 using the abstract 
  686. syntax notation of Recommendation X.208. 
  687. .sp 2P
  688. .LP
  689. \fB6\fR     \fBOverview of the Protocol\fR 
  690. .sp 1P
  691. .RT
  692. .sp 1P
  693. .LP
  694. 6.1
  695.     \fIService Provision\fR 
  696. .sp 9p
  697. .RT
  698. .PP
  699. The protocol specified in this Recommendation provides the services defined 
  700. in Recommendation\ X.218. These services are listed in 
  701. Table\ 1/X.228.
  702. .RT
  703. .LP
  704. .sp 2
  705. .ce
  706. \fBH.T. [T1.228]\fR 
  707. .ce
  708. TABLE\ 1/X.228
  709. .ce
  710. \fBRTSE Service Summary\fR 
  711. .ps 9
  712. .vs 11
  713. .nr VS 11
  714. .nr PS 9
  715. .TS
  716. center box;
  717. cw(90p) | cw(78p) .
  718. Service    Type
  719. _
  720. .T&
  721. lw(90p) | lw(78p) .
  722. RT\(hyOPEN    Confirmed
  723. .T&
  724. lw(90p) | lw(78p) .
  725. RT\(hyCLOSE    Confirmed
  726. .T&
  727. lw(90p) | lw(78p) .
  728. RT\(hyTRANSFER    Confirmed
  729. .T&
  730. lw(90p) | lw(78p) .
  731. RT\(hyTURN\(hyPLEASE    Non\(hyconfirmed
  732. .T&
  733. lw(90p) | lw(78p) .
  734. RT\(hyTURN\(hyGIVE    Non\(hyconfirmed
  735. .T&
  736. lw(90p) | lw(78p) .
  737. RT\(hyP\(hyABORT    Provider\(hyinitiated
  738. .T&
  739. lw(90p) | lw(78p) .
  740. RT\(hyU\(hyABORT    Non\(hyconfirmed
  741. _
  742. .TE
  743. .nr PS 9
  744. .RT
  745. .ad r
  746. \fBTable [T1.228], p.\fR 
  747. .sp 1P
  748. .RT
  749. .ad b
  750. .RT
  751. .LP
  752. .bp
  753. .sp 2P
  754. .LP
  755. 6.2
  756.     \fIUse of Services\fR 
  757. .sp 1P
  758. .RT
  759. .sp 1P
  760. .LP
  761. 6.2.1
  762.     \fIACSE Services\fR 
  763. .sp 9p
  764. .RT
  765. .PP
  766. The RTPM requires access to the A\(hyASSOCIATE, A\(hyRELEASE, A\(hyABORT 
  767. and A\(hyP\(hyABORT services. This Recommendation assumes that the RTPM 
  768. is the sole user of these services. 
  769. .RT
  770. .sp 1P
  771. .LP
  772. 6.2.2
  773.     \fIUse of the Presentation\(hyservice\fR 
  774. .sp 9p
  775. .RT
  776. .PP
  777. The RTPM requires access to the P\(hyACTIVITY\(hySTART, P\(hyDATA,
  778. P\(hyMINOR\(hySYNCHRONIZE, 
  779. P\(hyACTIVITY\(hyEND, P\(hyACTIVITY\(hyINTERRUPT,
  780. P\(hyACTIVITY\(hyDISCARD,
  781. P\(hyU\(hyEXCEPTION\(hyREPORT, 
  782. P\(hyACTIVITY\(hyRESUME, P\(hyP\(hyEXCEPTION\(hyREPORT,
  783. P\(hyTOKEN\(hyPLEASE
  784. and P\(hyCONTROL\(hyGIVE services. This Recommendation assumes that the 
  785. RTPM is the sole user of the above services. 
  786. .PP
  787. The RTPM requires access to local syntax\(hymatching\(hyservices provided 
  788. by the presentation\(hyservice provider. This syntax\(hymatching\(hyservice 
  789. consists 
  790. of:
  791. .RT
  792. .LP
  793.     a)
  794.     an encoding service enabling the transformation from the
  795. local representation of an APDU value into an encoded\(hyAPDU\(hyvalue 
  796. of type OCTET STRING the value of which is the representation of the APDU 
  797. value specified by the negotiated transfer syntax; 
  798. .LP
  799.     b)
  800.     a decoding service enabling the transformation from an
  801. encoded\(hyAPDU\(hyvalue into the local representation of the APDU value.
  802. .PP
  803. If X.410\(hy1984 mode or simple encoding is used by the Presentation Layer, 
  804. the APDU value is encoded as ASN.1 type ANY. If full encoding is used by 
  805. the Presentation Layer, the APDU value is encoded as ASN.1 type EXTERNAL. 
  806. (For X.410\(hy1984 mode, single encoding and full encoding see Recommendation 
  807. X.226). 
  808. .PP
  809. This Recommendation recognizes that the ACSE services require access to 
  810. the P\(hyCONNECT, 
  811. P\(hyRELEASE, P\(hyU\(hyABORT and P\(hyP\(hyABORT services. This
  812. Recommendation assumes that the ACSE and the RTPM are the sole users of 
  813. any of the above, or of any other, presentation\(hyservices. 
  814. .PP
  815. During the lifetime of an application\(hyassociation, the underlying
  816. presentation\(hyconnections either use a single presentation context or 
  817. multiple presentation contexts as a part of the presentation multiple defined 
  818. context 
  819. facility. The choice is determined by the use of the Single Presentation
  820. Context parameter of the RT\(hyOPEN service as described in clause\ 8.1.1.1.3
  821. and\ 8.1.1.1.4.
  822. .RT
  823. .sp 1P
  824. .LP
  825. 6.3
  826.     \fIModel\fR 
  827. .sp 9p
  828. .RT
  829. .PP
  830. The reliable\(hytransfer\(hyprotocol\(hymachine (RTPM) communicates with 
  831. its service\(hyuser by means of primitives defined in Recommendation X.218. 
  832. Each 
  833. invocation of the RTPM controls a single application\(hyassociation.
  834. .PP
  835. The RTPM is driven by RTSE service request and response primitives
  836. from its service\(hyuser, and by indication and confirm primitives from 
  837. the ACSE services and the presentation\(hyservice. The RTPM, in turn, issues 
  838. indication and confirm primitives to its service\(hyuser and request and 
  839. response primitives on the used ACSE services or presentation\(hyservice. 
  840. .PP
  841. The reception of an RTSE service primitive, or of an ACSE service
  842. primitive, or of a presentation\(hyservice primitive, and the generation of
  843. dependent actions are considered to be indivisible.
  844. .PP
  845. During the use of the RTSE services, the existence of both the
  846. association\(hyinitiating AE and the association\(hyresponding AE is presumed. 
  847. How 
  848. these AEs are created is beyond the scope of this Recommendation.
  849. .PP
  850. During the use of the RTSE services, except RT\(hyOPEN, the existence of 
  851. an application\(hyassociation between the peer AEs is presumed. 
  852. .PP
  853. Note\ \(em\ Each application\(hyassociation may be identified in an end 
  854. system by an internal, implementation dependent mechanism so that the RTSE 
  855. service\(hyuser, and the RTPM, and the ACSE service\(hyprovider can refer to
  856. it.
  857. .bp
  858. .RT
  859. .sp 2P
  860. .LP
  861. \fB7\fR     \fBElements of procedure\fR 
  862. .sp 1P
  863. .RT
  864. .PP
  865. The RTSE protocol consists of the following elements of
  866. procedure:
  867. .RT
  868. .LP
  869.     a)
  870.     association\(hyestablishment
  871. .LP
  872.     b)
  873.     association\(hyrelease
  874. .LP
  875.     c)
  876.     transfer
  877. .LP
  878.     d)
  879.     turn\(hyplease
  880. .LP
  881.     e)
  882.     turn\(hygive
  883. .LP
  884.     f
  885. )
  886.     error reporting:
  887. .LP
  888.     f1)
  889.     user\(hyexception\(hyreport
  890. .LP
  891.     f2)
  892.     provider\(hyexception\(hyreport
  893. .LP
  894.     g)
  895.     error handling:
  896. .LP
  897.     g1)
  898.     transfer\(hyinterrupt
  899. .LP
  900.     g2)
  901.     transfer\(hydiscard
  902. .LP
  903.     g3)
  904.     association\(hyabort
  905. .LP
  906.     g4)
  907.     association\(hyprovider\(hyabort
  908. .LP
  909.     h)
  910.     error recovery:
  911. .LP
  912.     h1)
  913.      transfer\(hyresumption (for recovery from g1), or after successful h3) 
  914. from g3) or g4)) 
  915. .LP
  916.     h2)
  917.     transfer\(hyretry (for recovery from g2))
  918. .LP
  919.     h3)
  920.     association\(hyrecovery (for recovery from g3 or g4))
  921. .LP
  922.     i)
  923.     abort:
  924. .LP
  925.     i1)
  926.     transfer\(hyabort (recovery from g1) or g2) or g3) or
  927. g4) not possible)
  928. .LP
  929.     i2)
  930.     provider\(hyabort (recovery from g1) or g2) or g3) or
  931. g4) not possible)
  932. .LP
  933.     i3)
  934.     user\(hyabort.
  935. .PP
  936. In the following clauses, a summary of each of these elements of procedure 
  937. is presented. This consists of a summary of the relevant APDUs, and a high\(hylevel 
  938. overview of the relationship between the RTSE service primitives and the 
  939. APDUs involved and the used presentation\(hyservice. 
  940. .PP
  941. Clause 8 describes how the service primitives are mapped on the ACSE services, 
  942. and on the presentation\(hyservice. 
  943. .RT
  944. .sp 2P
  945. .LP
  946. 7.1
  947.     \fIAssociation\(hyestablishment\fR 
  948. .sp 1P
  949. .RT
  950. .sp 1P
  951. .LP
  952. 7.1.1
  953.     \fIPurpose\fR 
  954. .sp 9p
  955. .RT
  956. .PP
  957. The association\(hyestablishment procedure is used to establish an
  958. application\(hyassociation.
  959. .RT
  960. .sp 1P
  961. .LP
  962. 7.1.2
  963.     \fIAPDUs used\fR 
  964. .sp 9p
  965. .RT
  966. .PP
  967. The association\(hyestablishment procedures uses the RT\(hyOPEN\(hyREQUEST 
  968. (RTORQ) APDU, the RT\(hyOPEN\(hyACCEPT (RTCAC) APDU, and the RT\(hyOPEN\(hyREJECT 
  969. (RTORJ) APDU. 
  970. .PP
  971. \fINote\fR \ \(em\ These APDUs are also used in the association\(hyrecovery
  972. procedure.
  973. .RT
  974. .sp 1P
  975. .LP
  976. 7.1.2.1
  977.     \fIRTORQ APDU\fR 
  978. .sp 9p
  979. .RT
  980. .PP
  981. The RT\(hyOPEN REQUEST (RTORQ) APDU is used in the request to
  982. establish an application\(hyassociation. The fields of the RTORQ APDU are 
  983. listed in Table\ 2/X.228. 
  984. .RT
  985. .sp 1P
  986. .LP
  987. 7.1.2.2
  988.     \fIRTOAC APDU\fR 
  989. .sp 9p
  990. .RT
  991. .PP
  992. The RT\(hyOPEN\(hyACCEPT (RTOAC) APDU is used in the positive response 
  993. to the request to establish an application\(hyassociation. The fields of 
  994. the RTOAC 
  995. APDU are listed in Table\ 3/X.228.
  996. .bp
  997. .RT
  998. .ce
  999. \fBH.T. [T2.228]\fR 
  1000. .ce
  1001. TABLE\ 2/X.228
  1002. .ce
  1003. \fBRTORQ APDU Fields\fR 
  1004. .ps 9
  1005. .vs 11
  1006. .nr VS 11
  1007. .nr PS 9
  1008. .TS
  1009. center box;
  1010. cw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1011. Field name    Presence    Source    Sink
  1012. _
  1013. .T&
  1014. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1015. Checkpoint\(hysize    T    sp    sp
  1016. .T&
  1017. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1018. Window\(hysize    T    sp    sp
  1019. .T&
  1020. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1021. Dialogue\(hymode    U    req    ind
  1022. .T&
  1023. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1024. User\(hydata (Note\ 1)    U    req    ind
  1025. .T&
  1026. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1027. T{
  1028. Session\(hyconnection\(hyidentifier (Note\ 2)
  1029. T}    T    sp    sp
  1030. .T&
  1031. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1032. T{
  1033. Application\(hyprotocol (Note\ 3)
  1034. T}    U    req    T{
  1035. ind
  1036. \fINote\ 1\fR
  1037. \ \(em\ The User\(hydata field is used solely in the association\(hyestablishment procedure.
  1038. .parag
  1039. \fINote\ 2\fR
  1040. \ \(em\ The Session\(hyconnection\(hyidentifier field is used solely in the
  1041. association\(hyrecovery procedure.
  1042. .parag
  1043. \fINote\ 3\fR
  1044. \ \(em\ The Application\(hyprotocol field is used solely in the
  1045. X.410\(hy1984 mode.
  1046. .parag
  1047. T}
  1048. _
  1049. .TE
  1050. .nr PS 9
  1051. .RT
  1052. .ad r
  1053. \fBTableau 2/X.228 [T2.228], p.2\fR 
  1054. .sp 1P
  1055. .RT
  1056. .ad b
  1057. .RT
  1058. .LP
  1059. .sp 4
  1060. .ce
  1061. \fBH.T. [T3.228]\fR 
  1062. .ce
  1063. TABLE\ 3/X.228
  1064. .ce
  1065. \fBRTOAC APDU Fields\fR 
  1066. .ps 9
  1067. .vs 11
  1068. .nr VS 11
  1069. .nr PS 9
  1070. .TS
  1071. center box;
  1072. cw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1073. Field name    Presence    Source    Sink
  1074. _
  1075. .T&
  1076. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1077. Checkpoint\(hysize    T    sp    sp
  1078. .T&
  1079. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1080. Window\(hysize    T    sp    sp
  1081. .T&
  1082. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1083. User\(hydata (Note 1)    U    resp    conf
  1084. .T&
  1085. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1086. T{
  1087. Session\(hyconnection\(hyidentifier (Note 2)
  1088. T}    T    sp    T{
  1089. sp
  1090. \fINote\ 1\fR
  1091. \ \(em\ The User\(hydata field is used solely in the association\(hyestablishment procedure.
  1092. .parag
  1093. \fINote\ 2\fR
  1094. \ \(em\ The Session\(hyconnection\(hyidentifier field is used solely in the
  1095. association\(hyrecovery procedure.
  1096. .parag
  1097. T}
  1098. _
  1099. .TE
  1100. .nr PS 9
  1101. .RT
  1102. .ad r
  1103. \fBTableau 3/X.228 [T3.228], p.3\fR 
  1104. .sp 1P
  1105. .RT
  1106. .ad b
  1107. .RT
  1108. .sp 1P
  1109. .LP
  1110. .sp 2
  1111. 7.1.2.3
  1112.     \fIRTORJ APDU\fR 
  1113. .sp 9p
  1114. .RT
  1115. .PP
  1116. RT\(hyOPEN\(hyREJECT (RTORJ) APDU is used in the negative response to
  1117. the request to establish an application\(hyassociation. The fields of the RTORJ
  1118. APDU are listed in Table\ 4/X.228.
  1119. .bp
  1120. .RT
  1121. .ce
  1122. \fBH.T. [T4.228]\fR 
  1123. .ce
  1124. TABLE\ 4/X.228
  1125. .ce
  1126. \fBRTORJ APDU Fields\fR 
  1127. .ps 9
  1128. .vs 11
  1129. .nr VS 11
  1130. .nr PS 9
  1131. .TS
  1132. center box;
  1133. cw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1134. Field name    Presence    Source    Sink
  1135. _
  1136. .T&
  1137. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1138. Refuse\(hyreason (Note\ 1)    T    sp    sp
  1139. .T&
  1140. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1141. User\(hydata (Note\ 2)    U    resp    T{
  1142. conf
  1143. \fINote\ 1\fR
  1144. \ \(em\ The Refuse\(hyreason field is used solely in the\ X.410\(hy1984 mode.
  1145. .parag
  1146. \fINote\ 2\fR
  1147. \ \(em\ The User\(hydata field is used solely in the normal mode, and is not
  1148. used in the association\(hyrecovery procedure.
  1149. .parag
  1150. T}
  1151. _
  1152. .TE
  1153. .nr PS 9
  1154. .RT
  1155. .ad r
  1156. \fBTable 4/X.228 [T4.228], p.\fR 
  1157. .sp 1P
  1158. .RT
  1159. .ad b
  1160. .RT
  1161. .LP
  1162. .sp 2
  1163. .sp 1P
  1164. .LP
  1165. 7.1.3
  1166.     \fIAssociation\(hyestablishment procedure\fR 
  1167. .sp 9p
  1168. .RT
  1169. .PP
  1170. This procedure is driven by the following events:
  1171. .RT
  1172. .LP
  1173.     a)
  1174.     an RT\(hyOPEN request primitive from the requestor
  1175. (association\(hyinitiator);
  1176. .LP
  1177.     b)
  1178.     an RTORQ APDU as user\(hydata on an A\(hyASSOCIATE indication
  1179. primitive;
  1180. .LP
  1181.     c)
  1182.     an RT\(hyOPEN response primitive from the acceptor
  1183. (association\(hyresponder);
  1184. .LP
  1185.     d)
  1186.      an A\(hyASSOCIATE confirm primitive that may contain either an RTOAC 
  1187. APDU, or an RTORJ APDU, or no APDU. 
  1188. .sp 1P
  1189. .LP
  1190. 7.1.3.1
  1191.     \fIRT\(hyOPEN request primitive\fR 
  1192. .sp 9p
  1193. .RT
  1194. .PP
  1195. The requesting RTPM forms an RTORQ APDU from the parameter values of the 
  1196. RT\(hyOPEN request primitive and its internal data. The RT\(hyOPEN request 
  1197. primitive parameters, except user\(hydata, are stored by the requesting 
  1198. RTPM for association\(hyrecovery. The requesting RTPM issues an A\(hyASSOCIATE 
  1199. request 
  1200. primitive also using information from the RT\(hyOPEN request primitive. 
  1201. The RTORQ APDU is the user information parameter value of the A\(hyASSOCIATE 
  1202. request 
  1203. primitive.
  1204. .PP
  1205. The requesting RTPM waits for a primitive from the ACSE\(hyprovider and 
  1206. does not accept any other primitive from the requestor. 
  1207. .RT
  1208. .sp 1P
  1209. .LP
  1210. 7.1.3.2
  1211.     \fIRTORQ APDU\fR 
  1212. .sp 9p
  1213. .RT
  1214. .PP
  1215. If the application\(hyassociation is not accepted by the
  1216. ACSE\(hyprovider, no A\(hyASSOCIATE indication primitive is received by 
  1217. the accepting RTPM and no action takes place. 
  1218. .PP
  1219. If the application\(hyassociation is accepted by the ACSE\(hyprovider, 
  1220. the accepting RTPM receives the RTORQ APDU as the user information parameter 
  1221. on an A\(hyASSOCIATE indication primitive. 
  1222. .PP
  1223. If any of the A\(hyASSOCIATE indication parameters or any of the RTORQ
  1224. APDU fields is unacceptable to the accepting RTPM, or if the accepting 
  1225. RTPM is not able to accept the application\(hyassociation, it forms and 
  1226. sends an RTORJ 
  1227. APDU with appropriate parameters from internal data. The accepting RTPM 
  1228. issues an A\(hyASSOCIATE response primitive. The RTORJ APDU is sent as 
  1229. the user 
  1230. information parameter of the A\(hyASSOCIATE response primitive. The
  1231. application\(hyassociation is not established. The accepting RTPM does 
  1232. not issue an RT\(hyOPEN indication. 
  1233. .bp
  1234. .PP
  1235. If the A\(hyASSOCIATE indication primitive and the RTORQ APDU parameters 
  1236. are acceptable to the accepting RTPM, it issues an RT\(hyOPEN indication 
  1237. primitive to the acceptor. The RT\(hyOPEN indication parameter values are 
  1238. derived from the RTORQ APDU and the A\(hyASSOCIATE indication primitive 
  1239. parameter values. 
  1240. .PP
  1241. The accepting RTPM waits for an RT\(hyOPEN response primitive from the
  1242. acceptor, or a primitive from the ACSE\(hyprovider.
  1243. .RT
  1244. .sp 1P
  1245. .LP
  1246. 7.1.3.3
  1247.     \fIRT\(hyOPEN response primitive\fR 
  1248. .sp 9p
  1249. .RT
  1250. .PP
  1251. When the accepting RTPM receives an RT\(hyOPEN response primitive from 
  1252. the acceptor, the result parameter specifies whether the acceptor has accepted 
  1253. (value \*Qaccepted\*U) or rejected the application\(hyassociation. 
  1254. .PP
  1255. If the application\(hyassociation is accepted by the acceptor, the
  1256. accepting RTPM forms an RTOAC APDU using the RT\(hyOPEN response primitive
  1257. parameters and internal data. The RT\(hyOPEN response primitive parameters, 
  1258. except user data, are stored by the accepting RTPM for association\(hyrecovery. 
  1259. .PP
  1260. The accepting RTPM issues an A\(hyASSOCIATE response primitive also using 
  1261. information from the RT\(hyOPEN response primitive. The RTOAC APDU is sent 
  1262. as the user information parameter of the A\(hyASSOCIATE response primitive. 
  1263. .PP
  1264. If the application\(hyassociation is rejected by the acceptor, the
  1265. accepting RTPM forms a RTORJ APDU using the RT\(hyOPEN response primitive
  1266. parameters and internal data. The accepting RTPM issues an 
  1267. A\(hyASSOCIATE
  1268. response
  1269. primitive also using information from the RT\(hyOPEN request primitive. 
  1270. The RTORJ APDU is sent as the user information parameter of the A\(hyASSOCIATE 
  1271. response 
  1272. primitive. The application\(hyassociation is not established.
  1273. .RT
  1274. .sp 1P
  1275. .LP
  1276. 7.1.3.4
  1277.     \fIA\(hyASSOCIATE confirm primitive\fR 
  1278. .sp 9p
  1279. .RT
  1280. .PP
  1281. The requesting RTPM receives an A\(hyASSOCIATE confirm primitive. The following 
  1282. situations are possible: 
  1283. .RT
  1284. .LP
  1285.     a)
  1286.     the application\(hyassociation has been accepted by the
  1287. acceptor;
  1288. .LP
  1289.     b)
  1290.     the accepting RTPM or the acceptor has rejected the
  1291. application\(hyassociation; or
  1292. .LP
  1293.     c)
  1294.     the ACSE service provider has rejected the
  1295. application\(hyassociation.
  1296. .PP
  1297. If the application\(hyassociation was accepted by the acceptor, the A\(hyASSOCIATE 
  1298. confirm primitive result parameter has the value \*Qaccepted\*U and the 
  1299. RTOAC APDU is the value of the user information parameter of the A\(hyASSOCIATE 
  1300. confirm primitive. The requesting RTPM issues an RT\(hyOPEN confirm primitive 
  1301. to the requestor. The result parameter has the value \*Qaccepted\*U and 
  1302. the user\(hydata parameter contains the user\(hydata parameter value of 
  1303. the RTOAC APDU. The other parameters of the RT\(hyOPEN confirm primitive 
  1304. are derived from the A\(hyASSOCIATE 
  1305. confirm primitive.
  1306. .PP
  1307. If the application\(hyassociation was rejected by either the acceptor or 
  1308. the accepting RTPM, the 
  1309. A\(hyASSOCIATE confirm primitive result parameter has   one
  1310. of the values \*Qrejected\|.\|.\|.\*U, the A\(hyASSOCIATE confirm primitive 
  1311. result source parameter has the value \*QACSE service\(hyuser\*U and the 
  1312. RTORJ APDU is the value of the user information parameter of the A\(hyASSOCIATE 
  1313. confirm primitive. The 
  1314. requesting RTPM issues an RT\(hyOPEN confirm primitive to the requestor. The
  1315. result parameter has one of the values \*Qrejected\|.\|.\|.\*U and the 
  1316. other parameter values are derived from the A\(hyASSOCIATE confirm primitive 
  1317. parameters and the 
  1318. RTORJ APDU. The application\(hyassociation is not established.
  1319. .PP
  1320. If the application\(hyassociation was rejected by the ACSE
  1321. service\(hyprovider, the A\(hyASSOCIATE confirm primitive result parameter 
  1322. has one of the values \*Qrejected\|.\|.\|.\*U, the A\(hyASSOCIATE confirm 
  1323. primitive result source 
  1324. parameter has either the value \*QACSE service\(hyprovider\*U or \*Qpresentation 
  1325. service\(hyprovider\*U. The user\(hydata parameter of the RT\(hyOPEN confirm 
  1326. primitive is absent and the application\(hyassociation is not established. 
  1327. The other parameters of the RT\(hyOPEN confirm primitive are derived from 
  1328. the A\(hyASSOCIATE confirm 
  1329. primitive.
  1330. .bp
  1331. .RT
  1332. .sp 1P
  1333. .LP
  1334. 7.1.4
  1335.     \fIUse of the RTORQ APDU fields\fR 
  1336. .sp 9p
  1337. .RT
  1338. .PP
  1339. The RTORQ APDU fields are used as follows.
  1340. .RT
  1341. .sp 1P
  1342. .LP
  1343. 7.1.4.1
  1344.     \fICheckpoint\(hysize\fR 
  1345. .sp 9p
  1346. .RT
  1347. .PP
  1348. The checkpoint\(hysize field allows negotiation of the maximum amount of 
  1349. data (in units of 1024\ octets) that may be sent between two minor 
  1350. synchronization points. A value of zero from the requesting RTPM invites the
  1351. accepting RTPM to select checkpoint\(hysize. If this field is absent,
  1352. checkpoint\(hysize zero is assumed.
  1353. .RT
  1354. .sp 1P
  1355. .LP
  1356. 7.1.4.2
  1357.     \fIWindow\(hysize\fR 
  1358. .sp 9p
  1359. .RT
  1360. .PP
  1361. The window\(hysize field allows negotiation of the maximum number of outstanding 
  1362. minor synchronization points before data transfer shall be 
  1363. suspended. If this field is absent, window\(hysize\ 3 is assumed.
  1364. .RT
  1365. .sp 1P
  1366. .LP
  1367. 7.1.4.3
  1368.     \fIDialogue\(hymode\fR 
  1369. .sp 9p
  1370. .RT
  1371. .PP
  1372. This is the dialogue\(hymode parameter value from the RT\(hyOPEN request 
  1373. primitive. It appears as the dialogue\(hymode parameter value of the RT\(hyOPEN 
  1374. indication primitive.
  1375. .PP
  1376. The value of this field is either monologue, or two\(hyway\(hyalternate. 
  1377. If this field is absent, monologue is assumed. 
  1378. .RT
  1379. .sp 1P
  1380. .LP
  1381. 7.1.4.4
  1382.     \fIUser\(hydata\fR 
  1383. .sp 9p
  1384. .RT
  1385. .PP
  1386. This is the user\(hydata parameter value from the RT\(hyOPEN request
  1387. primitive. It appears as the user\(hydata paremeter value of the RT\(hyOPEN
  1388. indication primitive.
  1389. .PP
  1390. The value of this field is transparent to the RTPM.
  1391. .RT
  1392. .sp 1P
  1393. .LP
  1394. 7.1.4.5
  1395.     \fISession\(hyconnection\(hyidentifier\fR 
  1396. .sp 9p
  1397. .RT
  1398. .PP
  1399. This field is used only in the association\(hyrecovery procedure.
  1400. .RT
  1401. .sp 1P
  1402. .LP
  1403. 7.1.4.6
  1404.     \fIApplication\(hyprotocol\fR 
  1405. .sp 9p
  1406. .RT
  1407. .PP
  1408. This field is used solely in the X.410\(hy1984 mode. It is the
  1409. application\(hyprotocol parameter value from the RT\(hyOPEN request primitive. 
  1410. It 
  1411. appears as the application\(hyprotocol parameter value in the RT\(hyOPEN 
  1412. indication primitive. 
  1413. .RT
  1414. .sp 1P
  1415. .LP
  1416. 7.1.5
  1417.     \fIUse of the RTOAC APDU fields\fR 
  1418. .sp 9p
  1419. .RT
  1420. .PP
  1421. The RTOAC APDU fields are used as follows.
  1422. .RT
  1423. .sp 1P
  1424. .LP
  1425. 7.1.5.1
  1426.     \fICheckpoint\(hysize\fR 
  1427. .sp 9p
  1428. .RT
  1429. .PP
  1430. The checkpoint\(hysize field allows negotiation of the maximum amount of 
  1431. data (in units of 1024\ octets) that may be sent between two minor 
  1432. synchronization points. If the checkpoint\(hysize in the RTORQ APDU is greater
  1433. than zero, the accepting RTPM shall supply a value in the RTOAC APDU that is
  1434. less than or equal to the value in the RTORQ APDU, else the accepting RPTM 
  1435. may select checkpoint\(hysize. A value of zero from the accepting RTPM 
  1436. indicates that checkpointing will not be used. The value of this field 
  1437. becomes the agreed 
  1438. maximum value and governs both directions of transfer. If this field is 
  1439. absent, it is assumed that checkpointing will not be used. 
  1440. .RT
  1441. .sp 1P
  1442. .LP
  1443. 7.1.5.2
  1444.     \fIWindow\(hysize\fR 
  1445. .sp 9p
  1446. .RT
  1447. .PP
  1448. This field is only used if checkpoint\(hysize of the RTOAC APDU is
  1449. greater than zero. The window\(hysize field allows negotiation of the maximum
  1450. number of outstanding minor synchronization points before data transfer 
  1451. shall be suspended. The accepting RTPM shall supply a value that is less 
  1452. than or 
  1453. equal to the value in the RTORQ APDU. This becomes the agreed maximum size 
  1454. and governs both directions of transfer. If this field is absent, window\(hysize\ 
  1455. 3 is assumed. 
  1456. .bp
  1457. .RT
  1458. .sp 1P
  1459. .LP
  1460. 7.1.5.3
  1461.     \fIUser\(hydata\fR 
  1462. .sp 9p
  1463. .RT
  1464. .PP
  1465. This is the user\(hydata parameter value from the RT\(hyOPEN response
  1466. primitive. It appears as the user\(hydata parameter value of the RT\(hyOPEN 
  1467. confirm service primitive. 
  1468. .PP
  1469. The value of this field is transparent to the RTPM.
  1470. .RT
  1471. .sp 1P
  1472. .LP
  1473. 7.1.5.4
  1474.     \fISession\(hyconnection\(hyidentifier\fR 
  1475. .sp 9p
  1476. .RT
  1477. .PP
  1478. This field is used only in the association\(hyrecovery procedure.
  1479. .RT
  1480. .sp 1P
  1481. .LP
  1482. 7.1.6
  1483.     \fIUse of the RTORJ APDU fields\fR 
  1484. .sp 9p
  1485. .RT
  1486. .PP
  1487. The RTORJ APDU fields are used as follows.
  1488. .RT
  1489. .sp 1P
  1490. .LP
  1491. 7.1.6.1
  1492.     \fIRefuse\(hyreason\fR 
  1493. .sp 9p
  1494. .RT
  1495. .PP
  1496. The refuse\(hyreason field is only used in the X.410\(hy1984 mode.
  1497. .PP
  1498. This field may contain one of the following values:
  1499. .RT
  1500. .LP
  1501. .sp 1
  1502. \(em
  1503.     rts\(hybusy
  1504.     The accepting RTPM, or the acceptor, is so loaded that it cannot
  1505. support a new application\(hyassociation. The requesting RTPM should retry
  1506. after a period of time. This value is either provided by the accepting
  1507. RTPM, or is derived from the result parameter value \*Qrejected (transient)\*U
  1508. of the RT\(hyOPEN response primitive from the acceptor. It appears as the
  1509. result parameter value \*Qrejected (transient)\*U of the RT\(hyOPEN confirm
  1510. primitive to the requestor.
  1511. .LP
  1512. \(em
  1513.     cannot recover
  1514.     This value is used only by the accepting RTPM in the
  1515. association\(hyrecovery procedure if it is unable to accept an
  1516. association\(hyrecovery.
  1517. \(em
  1518.     validation failure 
  1519.     The acceptor does not recognize the requestor's credentials as being
  1520. valid for the proposed application\(hyassociation. This value is the
  1521. user\(hydata parameter value of the RT\(hyOPEN response primitive from the
  1522. acceptor. It appears as the user\(hydata parameter value of the RT\(hyOPEN
  1523. confirm primitive to the requestor.
  1524. .sp 1P
  1525. .LP
  1526. \(em
  1527.     unacceptable\(hydialogue\(hymode
  1528.     The acceptor does not accept the type of dialogue mode proposed for
  1529. the application\(hyassociation. This value is the user\(hydata parameter value
  1530. of the RT\(hyOPEN response primitive from the acceptor. It appears as the
  1531. user\(hydata parameter value of the RT\(hyOPEN confirm primitive to the
  1532. requestor.
  1533. 7.1.6.2
  1534.     \fIUser\(hydata\fR 
  1535. .sp 9p
  1536. .RT
  1537. .PP
  1538. This field is only used in the normal mode:
  1539. .PP
  1540. This is the user\(hydata parameter value of the RT\(hyOPEN response
  1541. primitive from the acceptor. It appears as the user\(hydata parameter value 
  1542. of the RT\(hyOPEN confirm primitive to the requestor. 
  1543. .PP
  1544. The value of this field is transparent to the RTPM.
  1545. .bp
  1546. .RT
  1547. .sp 2P
  1548. .LP
  1549. 7.2
  1550.     \fIAssociation\(hyrelease\fR 
  1551. .sp 1P
  1552. .RT
  1553. .sp 1P
  1554. .LP
  1555. 7.2.1
  1556.     \fIPurpose\fR 
  1557. .sp 9p
  1558. .RT
  1559. .PP
  1560. The association\(hyrelease procedure is used for the normal release of 
  1561. an application\(hyassociation by the association\(hyinitiator without loss 
  1562. of 
  1563. information in transit.
  1564. .RT
  1565. .sp 1P
  1566. .LP
  1567. 7.2.2
  1568.     \fIAPDUs used\fR 
  1569. .sp 9p
  1570. .RT
  1571. .PP
  1572. No APDUs are used in this procedure.
  1573. .RT
  1574. .sp 1P
  1575. .LP
  1576. 7.2.3
  1577.     \fIAssociation\(hyrelease procedure\fR 
  1578. .sp 9p
  1579. .RT
  1580. .PP
  1581. This procedure is driven by the following events:
  1582. .RT
  1583. .LP
  1584.     a)
  1585.     an RT\(hyCLOSE request primitive from the requestor
  1586. (association\(hyinitiator);
  1587. .LP
  1588.     b)
  1589.     an A\(hyRELEASE indication primitive;
  1590. .LP
  1591.     c)
  1592.     an RT\(hyCLOSE response primitive from the acceptor
  1593. (association\(hyresponder);
  1594. .LP
  1595.     d)
  1596.     an A\(hyRELEASE confirm primitive.
  1597. .sp 1P
  1598. .LP
  1599. 7.2.3.1
  1600.     \fIRT\(hyCLOSE request primitive\fR 
  1601. .sp 9p
  1602. .RT
  1603. .PP
  1604. The requestor may issue an RT\(hyCLOSE request primitive only if it
  1605. possesses the turn and if there is no outstanding RT\(hyTRANSFER confirm
  1606. primitive. When an RT\(hyCLOSE request primitive is received from the requestor, 
  1607. the requesting (association\(hyinitiating) RTPM issues an A\(hyRELEASE 
  1608. request 
  1609. primitive. The reason parameter of the A\(hyRELEASE request primitive is the
  1610. reason parameter of the RT\(hyCLOSE request primitive. The user information
  1611. parameter of the A\(hyRELEASE request primitive is the user\(hydata parameter 
  1612. of the RT\(hyCLOSE request primitive. 
  1613. .PP
  1614. \fINote\fR \ \(em\ No RT\(hyCLOSE request primitive parameters are present in
  1615. X.410\(hy1984 mode.
  1616. .PP
  1617. The requesting RTPM waits for a primitive from the ACSE
  1618. service\(hyprovider and does not accept any other primitive from the
  1619. requestor.
  1620. .RT
  1621. .sp 1P
  1622. .LP
  1623. 7.2.3.2
  1624.     \fIA\(hyRELEASE indication primitive\fR 
  1625. .sp 9p
  1626. .RT
  1627. .PP
  1628. The accepting RTPM receives the A\(hyRELEASE indication
  1629. primitive.
  1630. .PP
  1631. It issues an RT\(hyCLOSE indication primitive to the acceptor. The
  1632. RT\(hyCLOSE indication parameter values are derived from the A\(hyRELEASE 
  1633. indication primitive. 
  1634. .PP
  1635. \fINote\fR \ \(em\ No RT\(hyCLOSE indication primitive parameters are present 
  1636. in 
  1637. X.410\(hy1984 mode.
  1638. .PP
  1639. The RTPM waits for a primitive from the acceptor or the used service provider. 
  1640. .RT
  1641. .sp 1P
  1642. .LP
  1643. 7.2.3.3
  1644.     \fIRT\(hyCLOSE response primitive\fR 
  1645. .sp 9p
  1646. .RT
  1647. .PP
  1648. When the accepting RTPM receives an RT\(hyCLOSE response primitive,
  1649. the accepting RTPM issues an A\(hyRELEASE response primitive. The reason 
  1650. parameter of the A\(hyRELEASE response primitive is the reason parameter 
  1651. of the RT\(hyCLOSE 
  1652. response primitive. The user information parameter of the A\(hyRELEASE response
  1653. primitive is the user\(hydata parameter of the RT\(hyCLOSE response primitive. 
  1654. The 
  1655. result parameter value of the A\(hyRELEASE response primitive is \*Qaffirmative\*U. 
  1656. .PP
  1657. \fINote\fR \ \(em\ No RT\(hyCLOSE response primitive parameters are present in
  1658. X.410\(hy1984 mode.
  1659. .bp
  1660. .RT
  1661. .sp 1P
  1662. .LP
  1663. 7.2.3.4
  1664.     \fIA\(hyRELEASE confirm primitive\fR 
  1665. .sp 9p
  1666. .RT
  1667. .PP
  1668. The requesting RTPM receives an A\(hyRELEASE confirm primitive.
  1669. .PP
  1670. The requesting RTPM issues an RT\(hyOPEN confirm primitive to the
  1671. acceptor. The RT\(hyOPEN confirm primitive parameter values are derived 
  1672. from the A\(hyRELEASE confirm primitive. 
  1673. .PP
  1674. \fINote\fR \ \(em\ No RT\(hyCLOSE confirm primitive parameters are present in
  1675. X.410\(hy1984 mode.
  1676. .RT
  1677. .sp 2P
  1678. .LP
  1679. 7.3
  1680.     \fITransfer\fR 
  1681. .sp 1P
  1682. .RT
  1683. .sp 1P
  1684. .LP
  1685. 7.3.1
  1686.     \fIPurpose\fR 
  1687. .sp 9p
  1688. .RT
  1689. .PP
  1690. The transfer procedure is used to transfer an RTSE\(hyuser APDU from the 
  1691. requestor (sender) to the acceptor (receiver). 
  1692. .RT
  1693. .sp 1P
  1694. .LP
  1695. 7.3.2
  1696.     \fIAPDUs used\fR 
  1697. .sp 9p
  1698. .RT
  1699. .PP
  1700. Each RTSE\(hyuser APDU, conveyed in an RT\(hyTRANSFER request,
  1701. constitutes an activity. For each application\(hyassociation, at most one
  1702. activity, or one interrupted activity awaiting resumption, may exist at a
  1703. time.
  1704. .PP
  1705. The RTSE\(hyuser APDU value is transformed into the encoded\(hyAPDU\(hyvalue
  1706. and vice versa by means of the local syntax\(hymatching services. The transfer
  1707. procedure uses the RT\(hyTRANSFER (RTTR) APDU. The transfer procedure supports
  1708. segmenting and reassembling of the encoded\(hyAPDU\(hyvalue into/from one 
  1709. or more 
  1710. RTTR APDUs.
  1711. .PP
  1712. An encoded\(hyAPDU\(hyvalue is transferred as a single RTTR APDU if
  1713. checkpointing is not used. Otherwise, the encoded\(hyAPDU\(hyvalue is transferred 
  1714. as a series of RTTR APDUs, the maximum size (i.e.\ number of octets forming 
  1715. the 
  1716. RTTR APDU value) of each being the negotiated checkpoint\(hysize. The
  1717. concatenation of the RTTR APDU values is the encoded\(hyAPDU\(hyvalue.
  1718. .PP
  1719. The fields of the RTTR APDU are listed in Table 5/X.228.
  1720. .RT
  1721. .LP
  1722. .sp 1
  1723. .ce
  1724. \fBH.T. [T5.228]\fR 
  1725. .ce
  1726. TABLE\ 5/X.228
  1727. .ce
  1728. \fBRTTR APDU Fields\fR 
  1729. .ps 9
  1730. .vs 11
  1731. .nr VS 11
  1732. .nr PS 9
  1733. .TS
  1734. center box;
  1735. cw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1736. Field name    Presence    Source    Sink
  1737. _
  1738. .T&
  1739. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1740. User\(hydata\(hypart    M    req    ind/conf
  1741. _
  1742. .TE
  1743. .nr PS 9
  1744. .RT
  1745. .ad r
  1746. \fBTable 5/X.228 [T5.228], p.\fR 
  1747. .sp 1P
  1748. .RT
  1749. .ad b
  1750. .RT
  1751. .sp 1P
  1752. .LP
  1753. .sp 1
  1754. 7.3.3
  1755.     \fITransfer procedure\fR 
  1756. .sp 9p
  1757. .RT
  1758. .PP
  1759. This procedure is driven by the following events:
  1760. .RT
  1761. .LP
  1762.     a)
  1763.     an RT\(hyTRANSFER request primitive from the requestor
  1764. (sender);
  1765. .LP
  1766.     b)
  1767.      a P\(hyACTIVITY\(hySTART indication primitive, followed by one or more 
  1768. RTTR APDUs as user\(hydata of P\(hyDATA indication primitives each, except 
  1769. the last, followed by a P\(hyMINOR\(hySYNCHRONIZE indication primitive; 
  1770. .LP
  1771.     c)
  1772.     a P\(hyMINOR\(hySYNCHRONIZE confirm primitive;
  1773. .LP
  1774.     d)
  1775.     a P\(hyACTIVITY\(hyEND indication primitive;
  1776. .LP
  1777.     e)
  1778.     a P\(hyACTIVITY\(hyEND confirm primitive;
  1779. .LP
  1780.     f
  1781. )
  1782.     a transfer time\(hyout.
  1783. .bp
  1784. .sp 1P
  1785. .LP
  1786. 7.3.3.1
  1787.     \fIRT\(hyTRANSFER request primitive\fR 
  1788. .sp 9p
  1789. .RT
  1790. .PP
  1791. If the requesting RTPM possesses the turn and receives a
  1792. RT\(hyTRANSFER request from the requestor, the requesting RTPM transforms the
  1793. RTSE\(hyuser APDU value into the encoded\(hyAPDU\(hyvalue by means of the 
  1794. encoding 
  1795. service of the local syntax\(hymatching services.
  1796. .PP
  1797. The requesting RTPM issues a P\(hyACTIVITY\(hySTART request primitive and
  1798. may start transmitting the first RTTR APDU in a P\(hyDATA request primitive
  1799. immediately after the P\(hyACTIVITY\(hySTART request primitive is issued, 
  1800. since the latter service is not a confirmed service. 
  1801. .PP
  1802. The maximum RTTR APDU size will have been negotiated during the
  1803. association\(hyestablishment procedure. The requesting RTPM shall submit, in
  1804. P\(hyDATA request primitives, RTTR APDUs that conform to that agreement.
  1805. Checkpoints may only be inserted if a checkpoint\(hysize greater than zero was
  1806. negotiated during the association\(hyestablishment procedure.
  1807. .PP
  1808. If a transferred RTTR APDU is not the last in a series of RTTR APDUs used 
  1809. to transfer a single encoded\(hyAPDU\(hyvalue, the requesting RTPM inserts 
  1810. a 
  1811. checkpoint by issuing a P\(hyMINOR\(hySYNCHRONIZE request primitive. The 
  1812. requesting RTPM uses only the \*Qexplicit confirmation expected\*U type 
  1813. of minor 
  1814. synchronization. The requesting RTPM may issue further P\(hyDATA request
  1815. primitives and P\(hyMINOR\(hySYNCHRONIZE request primitives unless the agreed
  1816. window\(hysize has been reached.
  1817. .PP
  1818. If the RTTR APDU is the only one, or the last in a series of RTTR
  1819. APDUs used to transfer a single encoded\(hyAPDU\(hyvalue, the requesting 
  1820. RTPM issues a P\(hyACTIVITY\(hyEND request primitive. 
  1821. .PP
  1822. Consecutive P\(hyDATA request primitives shall not be issued, and all
  1823. data transfer shall take place within an activity.
  1824. .RT
  1825. .sp 1P
  1826. .LP
  1827. 7.3.3.2
  1828.     \fIP\(hyACTIVITY\(hySTART indication primitive, RTTR APDUs,\fR 
  1829. \fIand P\(hyMINOR\(hySYNCHRONIZE indication primitives\fR 
  1830. .sp 9p
  1831. .RT
  1832. .PP
  1833. The accepting RTPM receives a P\(hyACTIVITY\(hySTART indication
  1834. primitive, indicating the start of transfer of a RTSE\(hyuser APDU. The 
  1835. accepting RTPM receives an RTTR APDU as user\(hydata of a P\(hyDATA indication 
  1836. primitive. 
  1837. .PP
  1838. If the RTTR APDU is not the last in a series of RTTR APDUs used to
  1839. transfer a single encoded\(hyAPDU\(hyvalue, the accepting RTPM receives a
  1840. P\(hyMINOR\(hySYNCHRONIZE indication primitive. If the accepting RTPM has 
  1841. secured the RTTR APDU, it issues a P\(hyMINOR\(hySYNCHRONIZE response primitive. 
  1842. .RT
  1843. .sp 1P
  1844. .LP
  1845. 7.3.3.3
  1846.     \fIP\(hyMINOR\(hySYNCHRONIZE confirmed primitive\fR 
  1847. .sp 9p
  1848. .RT
  1849. .PP
  1850. When the requesting RTPM receives a P\(hyMINOR\(hySYNCHRONIZE confirm
  1851. primitive, it assumes that the accepting RTPM has secured the
  1852. encoded\(hyAPDU\(hyvalue APDU up to that point.
  1853. .PP
  1854. The requesting RTPM may issue further P\(hyDATA request primitives and
  1855. P\(hyMINOR\(hySYNCHRONIZE request primitives unless the agreed window\(hysize 
  1856. has been reached. The window is advanced when a P\(hyMINOR\(hySYNCHRONIZE 
  1857. confirm primitive is received by the requesting RTPM. 
  1858. .PP
  1859. When a complete encoded\(hyAPDU\(hyvalue has been transmitted, the
  1860. requesting RTPM issues a 
  1861. P\(hyACTIVITY\(hyEND request primitive.
  1862. .RT
  1863. .sp 1P
  1864. .LP
  1865. 7.3.3.4
  1866.     \fIP\(hyACTIVITY\(hyEND indication primitive\fR 
  1867. .sp 9p
  1868. .RT
  1869. .PP
  1870. A P\(hyACTIVITY\(hyEND indication primitive indicates to the accepting
  1871. RTPM that a complete encoded\(hyAPDU\(hyvalue has been transferred. The 
  1872. accepting 
  1873. RTPM transforms the encoded\(hyAPDU\(hyvalue into the RTSE\(hyuser APDU 
  1874. value by means of the decoding service of the local syntax\(hymatching\(hyservices. 
  1875. .PP
  1876. If the accepting RTPM has secured the complete RTSE\(hyuser APDU, it
  1877. issues an RT\(hyTRANSFER indication primitive to the acceptor, and issues a
  1878. P\(hyACTIVITY\(hyEND response primitive.
  1879. .PP
  1880. The accepting RTPM records the session\(hyconnection\(hyidentifier and 
  1881. the activity identifier of the last RTSE\(hyuser APDU which it completely 
  1882. secured for association\(hyrecovery purposes. 
  1883. .bp
  1884. .RT
  1885. .sp 1P
  1886. .LP
  1887. 7.3.3.5
  1888.     \fIP\(hyACTIVITY\(hyEND confirm primitive\fR 
  1889. .sp 9p
  1890. .RT
  1891. .PP
  1892. An activity end is an implicit major synchronization point and once successfully 
  1893. confirmed by means of an P\(hyACTIVITY\(hyEND confirm primitive, it 
  1894. indicates to the requesting RTPM that the RTSE\(hyuser APDU has been secured by
  1895. the accepting RTPM. The requesting RTPM may then delete the transferred
  1896. RTSE\(hyuser APDU.
  1897. .PP
  1898. When the requesting RTPM receives the P\(hyACTIVITY\(hyEND confirm
  1899. primitive, it issues an RT\(hyTRANSFER confirm primitive with a result 
  1900. parameter value of \*QAPDU\(hytransferred\*U to the requestor. 
  1901. .RT
  1902. .sp 1P
  1903. .LP
  1904. 7.3.3.6
  1905.     \fITransfer time\(hyout\fR 
  1906. .sp 9p
  1907. .RT
  1908. .PP
  1909. If an APDU has not been transferred within the time specified in
  1910. the transfer\(hytime parameter of the RT\(hyTRANSFER request primitive 
  1911. (that is, the requesting RTPM has not received the P\(hyACTIVITY\(hyEND 
  1912. confirm primitive), the 
  1913. requesting RTPM performs the transfer\(hydiscard procedure followed by the
  1914. transfer\(hyabort procedure.
  1915. .PP
  1916. If during the transfer\(hydiscard procedure, the requesting RTPM does not 
  1917. receive a P\(hyACTIVITY\(hyDISCARD confirm primitive within a (locally 
  1918. specified) 
  1919. reasonable time, the requesting RTPM performs the transfer\(hyabort procedure
  1920. followed by the provider\(hyabort procedure.
  1921. .RT
  1922. .sp 2P
  1923. .LP
  1924. 7.4
  1925.     \fITurn\(hyplease\fR 
  1926. .sp 1P
  1927. .RT
  1928. .sp 1P
  1929. .LP
  1930. 7.4.1
  1931.     \fIPurpose\fR 
  1932. .sp 9p
  1933. .RT
  1934. .PP
  1935. The turn\(hyplease procedure is used by a receiver (requestor) to
  1936. request the turn from the sender (acceptor).
  1937. .RT
  1938. .sp 1P
  1939. .LP
  1940. 7.4.2
  1941.     \fIAPDUs used\fR 
  1942. .sp 9p
  1943. .RT
  1944. .PP
  1945. The turn\(hyplease procedure uses the RT\(hyTURN\(hyPLEASE (RTTP) APDU.
  1946. .PP
  1947. The fields of the RTTP APDU are listed in Table 6/X.228.
  1948. .RT
  1949. .LP
  1950. .ce
  1951. \fBH.T. [T6.228]\fR 
  1952. .ce
  1953. TABLE\ 6/X.228
  1954. .ce
  1955. \fBRTTP APDU Fields\fR 
  1956. .ce
  1957. \fR 
  1958. .ps 9
  1959. .vs 11
  1960. .nr VS 11
  1961. .nr PS 9
  1962. .TS
  1963. center box;
  1964. cw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1965. Field name    Presence    Source    Sink
  1966. _
  1967. .T&
  1968. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  1969. Priority    U    req    ind
  1970. _
  1971. .TE
  1972. .nr PS 9
  1973. .RT
  1974. .ad r
  1975. \fBTable 6/X.228 [T6.228], p.\fR 
  1976. .sp 1P
  1977. .RT
  1978. .ad b
  1979. .RT
  1980. .sp 1P
  1981. .LP
  1982. 7.4.3
  1983.     \fITurn\(hyplease procedure\fR 
  1984. .sp 9p
  1985. .RT
  1986. .PP
  1987. This procedure is driven by the following events:
  1988. .RT
  1989. .LP
  1990.     a)
  1991.     am RT\(hyTURN\(hyPLEASE request primitive from the requestor;
  1992. .LP
  1993.     b)
  1994.     an RTTP APDU as user\(hydata of a P\(hyTOKEN\(hyPLEASE indication
  1995. primitive.
  1996. .sp 1P
  1997. .LP
  1998. 7.4.3.1
  1999.     \fIRT\(hyTURN\(hyPLEASE request primitive\fR 
  2000. .sp 9p
  2001. .RT
  2002. .PP
  2003. If the requesting RTPM does not possess the turn and receives an
  2004. RT\(hyTURN\(hyPLEASE request from the requestor, the requesting RTPM issues a
  2005. P\(hyTOKEN\(hyPLEASE request primitive. If the priority parameter is present 
  2006. in the RT\(hyTURN\(hyPLEASE request primitive, and RTTP APDU is formed 
  2007. from the parameter 
  2008. value and transferred as user\(hydata of the P\(hyTOKEN\(hyPLEASE request 
  2009. primitive. 
  2010. This procedure may be performed either inside or outside an activity.
  2011. .bp
  2012. .RT
  2013. .sp 1P
  2014. .LP
  2015. 7.4.3.2
  2016.     \fIRTTP APDU\fR 
  2017. .sp 9p
  2018. .RT
  2019. .PP
  2020. If the accepting RTPM receives a P\(hyTOKEN\(hyPLEASE indication
  2021. primitive, the accepting RTPM issues an RT\(hyTURN\(hyPLEASE indication 
  2022. primitive to the acceptor. If an RTTP APDU is transferred as user\(hydata 
  2023. of the P\(hyTOKEN\(hyPLEASE indication primitive, the RT\(hyTURN\(hyPLEASE 
  2024. indication primitive parameter is 
  2025. present and derived from the RTTP APDU.
  2026. .RT
  2027. .sp 1P
  2028. .LP
  2029. 7.4.4
  2030.     \fIUse of the RTTP fields\fR 
  2031. .sp 9p
  2032. .RT
  2033. .PP
  2034. The RTTP APDU fields are used as follows.
  2035. .RT
  2036. .sp 1P
  2037. .LP
  2038. 7.4.4.1
  2039.     \fIPriority\fR 
  2040. .sp 9p
  2041. .RT
  2042. .PP
  2043. This is the priority parameter value of the RT\(hyTURN\(hyPLEASE request 
  2044. primitive. It appears as the priority parameter value of the RT\(hyTURN\(hyPLEASE 
  2045. indication primitive.
  2046. .PP
  2047. The value of this field is transparent to the RTPM.
  2048. .RT
  2049. .sp 2P
  2050. .LP
  2051. 7.5
  2052.     \fITurn\(hygive\fR 
  2053. .sp 1P
  2054. .RT
  2055. .sp 1P
  2056. .LP
  2057. 7.5.1
  2058.     \fIPurpose\fR 
  2059. .sp 9p
  2060. .RT
  2061. .PP
  2062. The turn\(hygive procedure is used by a sender (requestor) to give the 
  2063. turn to the receiver (acceptor). The requestor becomes the receiver and 
  2064. the 
  2065. acceptor becomes the sender.
  2066. .RT
  2067. .sp 1P
  2068. .LP
  2069. 7.5.2
  2070.     \fIAPDUs used\fR 
  2071. .sp 9p
  2072. .RT
  2073. .PP
  2074. No APDUs are used in this procedure.
  2075. .RT
  2076. .sp 1P
  2077. .LP
  2078. 7.5.3
  2079.     \fITurn\(hygive procedure\fR 
  2080. .sp 9p
  2081. .RT
  2082. .PP
  2083. The turn\(hygive procedure is driven by the following
  2084. events:
  2085. .RT
  2086. .LP
  2087.     a)
  2088.     an RT\(hyTURN\(hyGIVE request primitive;
  2089. .LP
  2090.     b)
  2091.     a P\(hyCONTROL\(hyGIVE indication primitive.
  2092. .sp 1P
  2093. .LP
  2094. 7.5.3.1
  2095.     \fIRT\(hyTURN\(hyGIVE request primitive\fR 
  2096. .sp 9p
  2097. .RT
  2098. .PP
  2099. If the requesting RTPM possesses the turn and receives an
  2100. RT\(hyTURN\(hyGIVE request primitive from the requestor, it issues a P\(hyCONTROL\(hyGIVE 
  2101. request primitive and becomes the receiving RTPM. This may be done only 
  2102. outside an activity. 
  2103. .RT
  2104. .sp 1P
  2105. .LP
  2106. 7.5.3.2
  2107.     \fIP\(hyCONTROL\(hyGIVE indication primitive\fR 
  2108. .sp 9p
  2109. .RT
  2110. .PP
  2111. If the accepting RTPM receives a P\(hyCONTROL\(hyGIVE indication
  2112. primitive, the accepting RTPM issues an RT\(hyTURN\(hyGIVE indication primitive 
  2113. to 
  2114. the acceptor, and issues a P\(hyCONTROL\(hyGIVE response primitive. The 
  2115. accepting 
  2116. RTPM becomes the sending RTPM.
  2117. .RT
  2118. .LP
  2119. 7.6
  2120.     \fIError reporting\fR 
  2121. .sp 1P
  2122. .RT
  2123. .sp 2P
  2124. .LP
  2125. 7.6.1
  2126.     \fIUser\(hyexception\(hyreport\fR 
  2127. .sp 1P
  2128. .RT
  2129. .sp 1P
  2130. .LP
  2131. 7.6.1.1
  2132.     \fIPurpose\fR 
  2133. .sp 9p
  2134. .RT
  2135. .PP
  2136. The user\(hyexception\(hyreport procedure is used by the receiving RTPM 
  2137. to report an error situation to the sending RTPM. 
  2138. .RT
  2139. .sp 1P
  2140. .LP
  2141. 7.6.1.2
  2142.     \fIAPDUs used\fR 
  2143. .sp 9p
  2144. .RT
  2145. .PP
  2146. No APDUs are used in this procedure.
  2147. .bp
  2148. .RT
  2149. .sp 1P
  2150. .LP
  2151. 7.6.1.3
  2152.     \fIUser\(hyexception\(hyreport procedure\fR 
  2153. .sp 9p
  2154. .RT
  2155. .PP
  2156. This procedure is driven by the following events:
  2157. .RT
  2158. .LP
  2159.     a)
  2160.     a receiving RTPM problem;
  2161. .LP
  2162.     b)
  2163.     a P\(hyU\(hyEXCEPTION\(hyREPORT indication primitive.
  2164. .sp 1P
  2165. .LP
  2166. 7.6.1.3.1
  2167.     \fIReceiving RTPM problem\fR 
  2168. .sp 9p
  2169. .RT
  2170. .PP
  2171. If the receiving RTPM detects a problem, it issues a
  2172. P\(hyU\(hyEXCEPTION\(hyREPORT request primitive and starts a local recovery 
  2173. timer. 
  2174. Depending on the severity of the detected error, the value of the reason
  2175. parameter of the P\(hyU\(hyEXCEPTION\(hyREPORT request primitive is as
  2176. follows:
  2177. .RT
  2178. .LP
  2179.     a)
  2180.      In severe problem situations, the velue \*Qreceiving ability jeopardized\*U 
  2181. is used. 
  2182. .LP
  2183.     b)
  2184.      In exceptional circumstances, the receiving RTPM may have to delete a 
  2185. partially received RTSE\(hyuser APDU, even though some minor 
  2186. synchromization points have been confirmed. In this case, the value
  2187. \*Qunrecoverable procedure error\*U is used.
  2188. .LP
  2189.     c)
  2190.      If the receiving RTPM is not willing to complete a transfer procedure, 
  2191. the value \*Qnon\(hyspecific error\*U is used. 
  2192. .LP
  2193.     d)
  2194.     If the sending RTPM resumes a transfer procedure already
  2195. finished by the receiving RTPM (see clause\ 7.8.1.3.2), the value \*Qsequence
  2196. error\*U is used.
  2197. .LP
  2198.     e)
  2199.      For all other less severe error situations, the value \*Qlocal SS\(hyuser 
  2200. error\*U is used. 
  2201. .sp 1P
  2202. .LP
  2203. 7.6.1.3.2
  2204.     \fIP\(hyU\(hyEXCEPTION\(hyREPORT indication primitive\fR 
  2205. .sp 9p
  2206. .RT
  2207. .PP
  2208. If the sending RTPM receives a P\(hyU\(hyEXCEPTION\(hyREPORT indication
  2209. primitive, it performs one of the following procedures depending on the 
  2210. reason parameter value of the P\(hyU\(hyEXCEPTION\(hyREPORT indication 
  2211. primitive: 
  2212. .RT
  2213. .LP
  2214.     a)
  2215.     With a value \*Qreceiving ability jeopardized\*U, the
  2216. transfer\(hyabort procedure followed by the provider\(hyabort procedure are
  2217. performed.
  2218. .LP
  2219.     b)
  2220.     With a value \*Qunrecoverable procedure error\*U, the
  2221. transfer\(hydiscard procedure followed by transfer\(hyretry procedure are 
  2222. performed. 
  2223. .LP
  2224.     c)
  2225.     With a value \*Qnon\(hyspecific error\*U, the transfer\(hydiscard
  2226. procedure followed by the transfer\(hyabort procedure are performed.
  2227. .LP
  2228.     d)
  2229.     With a value \*Qsequence error\*U, the transfer\(hydiscard
  2230. procedure is performed and the requesting RTPM issues an RT\(hyTRANSFER confirm
  2231. primitive with a result parameter value of \*QAPDU\(hytransferred\*U to 
  2232. the requestor and the transfer procedure is finished. 
  2233. .LP
  2234.     e)
  2235.     With a value \*Qlocal SS\(hyuser error\*U and at least one
  2236. confirmed checkpoint in the transfer procedure, the transfer\(hyinterrupt
  2237. procedure followed by the transfer\(hyresumption procedure are performed. If no
  2238. checkpoint was confirmed in the transfer procedure, the transfer\(hydiscard
  2239. procedure followed by the transfer\(hyretry procedure are performed.
  2240. .sp 2P
  2241. .LP
  2242. 7.6.2
  2243.     \fIProvider\(hyexception\(hyreport\fR 
  2244. .sp 1P
  2245. .RT
  2246. .sp 1P
  2247. .LP
  2248. 7.6.2.1
  2249.     \fIPurpose\fR 
  2250. .sp 9p
  2251. .RT
  2252. .PP
  2253. If the presentation service\(hyprovider detects an unexpected
  2254. situation during an activity, not covered by other services, a
  2255. P\(hyP\(hyEXCEPTION\(hyREPORT indication primitive is issued to both RTPMs.
  2256. .RT
  2257. .sp 1P
  2258. .LP
  2259. 7.6.2.2
  2260.     \fIAPDUs used\fR 
  2261. .sp 9p
  2262. .RT
  2263. .PP
  2264. No APDUs are used in this procedure.
  2265. .bp
  2266. .RT
  2267. .sp 1P
  2268. .LP
  2269. 7.6.2.3
  2270.     \fIProvider\(hyexception\(hyreport procedure\fR 
  2271. .sp 9p
  2272. .RT
  2273. .PP
  2274. This procedure is driven by the following events:
  2275. .RT
  2276. .LP
  2277.     a)
  2278.     a P\(hyP\(hyEXCEPTION\(hyREPORT indication primitive.
  2279. .sp 1P
  2280. .LP
  2281. 7.6.2.3.1
  2282.     \fIP\(hyP\(hyEXCEPTION\(hyREPORT indication primitive\fR 
  2283. .sp 9p
  2284. .RT
  2285. .PP
  2286. The receiving RTPM receives a P\(hyP\(hyEXCEPTION\(hyREPORT indication
  2287. primitive.
  2288. .PP
  2289. If the sending RTPM receives a P\(hyP\(hyEXCEPTION\(hyREPORT indication
  2290. primitive, it may perform one of the following procedures:
  2291. .RT
  2292. .LP
  2293.     a)
  2294.     if at least one checkpoint was confirmed in the transfer
  2295. procedure, the transfer\(hyinterrupt procedure followed by the
  2296. transfer\(hyresumption procedure; or,
  2297. .LP
  2298.     b)
  2299.     if no checkpoint was confirmed in the transfer procedure,
  2300. the transfer\(hydiscard procedure followed by the transfer\(hyretry procedure; 
  2301. or, 
  2302. .LP
  2303.     c)
  2304.     the transfer\(hyabort procedure followed by the provider\(hyabort  procedure.
  2305. .LP
  2306. 7.7
  2307.     \fIError handling\fR 
  2308. .sp 1P
  2309. .RT
  2310. .sp 2P
  2311. .LP
  2312. 7.7.1
  2313.     \fITransfer\(hyinterrupt\fR 
  2314. .sp 1P
  2315. .RT
  2316. .sp 1P
  2317. .LP
  2318. 7.7.1.1
  2319.     \fIPurpose\fR 
  2320. .sp 9p
  2321. .RT
  2322. .PP
  2323. The transfer\(hyinterrupt procedure is used by the sending RTPM to
  2324. handle a less severe (than those handled by the other error handling
  2325. procedures) error situation during the transfer procedure, if at least one
  2326. checkpoint was confirmed during the transfer procedure.
  2327. .RT
  2328. .sp 1P
  2329. .LP
  2330. 7.7.1.2
  2331.     \fIAPDUs used\fR 
  2332. .sp 9p
  2333. .RT
  2334. .PP
  2335. No APDUs are used in this procedure.
  2336. .RT
  2337. .sp 1P
  2338. .LP
  2339. 7.7.1.3
  2340.     \fITransfer\(hyinterrupt procedure\fR 
  2341. .sp 9p
  2342. .RT
  2343. .PP
  2344. This procedure is driven by the following events:
  2345. .RT
  2346. .LP
  2347.     a)
  2348.     a sending RTPM problem;
  2349. .LP
  2350.     b)
  2351.     a P\(hyACTIVITY\(hyINTERRUPT indication primitive;
  2352. .LP
  2353.     c)
  2354.     a P\(hyACTIVITY\(hyINTERRUPT confirm primitive.
  2355. .sp 1P
  2356. .LP
  2357. 7.7.1.3.1
  2358.     \fISending RTPM problem\fR 
  2359. .sp 9p
  2360. .RT
  2361. .PP
  2362. If the sending RTPM detects a less severe problem and at least one checkpoint 
  2363. was confirmed during the transfer procedure, it issues a 
  2364. P\(hyACTIVITY\(hyINTERRUPT request primitive with one of the following reason
  2365. parameter values:
  2366. .RT
  2367. .LP
  2368.     a)
  2369.     \*Qnon\(hyspecific error\*U, if the problem was indicated by an
  2370. error reporting procedure;
  2371. .LP
  2372.     b)
  2373.     \*Qlocal SS\(hyuser error\*U, if the problem is a local sending
  2374. RTPM problem.
  2375. .sp 1P
  2376. .LP
  2377. 7.7.1.3.2
  2378.     \fIP\(hyACTIVITY\(hyINTERRUPT indication primitive\fR 
  2379. .sp 9p
  2380. .RT
  2381. .PP
  2382. If the receiving RTPM receives a P\(hyACTIVITY\(hyINTERRUPT indication
  2383. primitive, it issues a 
  2384. P\(hyACTIVITY\(hyINTERRUPT response primitive and starts a local recovery 
  2385. timer. 
  2386. .RT
  2387. .sp 1P
  2388. .LP
  2389. 7.7.1.3.3
  2390.     \fIP\(hyACTIVITY\(hyINTERRUPT confirm primitive\fR 
  2391. .sp 9p
  2392. .RT
  2393. .PP
  2394. If the sending RTPM receives a P\(hyACTIVITY\(hyINTERRUPT confirm
  2395. primitive, it starts the transfer\(hyresumption procedure.
  2396. .bp
  2397. .RT
  2398. .sp 2P
  2399. .LP
  2400. 7.7.2
  2401.     \fITransfer\(hydiscard\fR 
  2402. .sp 1P
  2403. .RT
  2404. .sp 1P
  2405. .LP
  2406. 7.7.2.1
  2407.     \fIPurpose\fR 
  2408. .sp 9p
  2409. .RT
  2410. .PP
  2411. The transfer\(hydiscard procedure is used by the sending RTPM to
  2412. escape from a more severe (than those handled by the transfer\(hyinterrupt
  2413. procedure) error situation, or a less severe error situation if no checkpoint 
  2414. was confirmed, during the transfer procedure. 
  2415. .RT
  2416. .sp 1P
  2417. .LP
  2418. 7.7.2.2
  2419.     \fIAPDUs used\fR 
  2420. .sp 9p
  2421. .RT
  2422. .PP
  2423. No APDUs are used in this procedure.
  2424. .RT
  2425. .sp 1P
  2426. .LP
  2427. 7.7.2.3
  2428.     \fITransfer\(hydiscard procedure\fR 
  2429. .sp 9p
  2430. .RT
  2431. .PP
  2432. This procedure is driven by the following events:
  2433. .RT
  2434. .LP
  2435.     a)
  2436.     a sending RTPM problem;
  2437. .LP
  2438.     b)
  2439.     a P\(hyACTIVITY\(hyDISCARD indication primitive;
  2440. .LP
  2441.     c)
  2442.     a P\(hyACTIVITY\(hyDISCARD confirm primitive.
  2443. .sp 1P
  2444. .LP
  2445. 7.7.2.3.1
  2446.     \fISending RTPM problem\fR 
  2447. .sp 9p
  2448. .RT
  2449. .PP
  2450. If the sending RTPM detects a more severe problem, or a less severe problem 
  2451. if no checkpoint was confirmed during the transfer procedure, it issues 
  2452. a P\(hyACTIVITY\(hyDISCARD request primitive with one of the following 
  2453. Reason 
  2454. parameter values:
  2455. .RT
  2456. .LP
  2457.     a)
  2458.     \*Qnon\(hyspecific error\*U, if the problem was indicated by an
  2459. error reporting procedure;
  2460. .LP
  2461.     b)
  2462.      \*Qlocal SS\(hyuser error\*U, or \*Qunrecoverable procedural error\*U, 
  2463. if the problem is a local sending RTPM problem. 
  2464. .sp 1P
  2465. .LP
  2466. 7.7.2.3.2
  2467.     \fIP\(hyACTIVITY\(hyDISCARD indication primitive\fR 
  2468. .sp 9p
  2469. .RT
  2470. .PP
  2471. If the receiving RTPM receives a P\(hyACTIVITY\(hyDISCARD indication
  2472. primitive, it issues a P\(hyACTIVITY\(hyDISCARD response primitive. The 
  2473. receiving 
  2474. RTPM deletes all knowledge and contents of the associated RTSE\(hyuser 
  2475. APDU so far received. 
  2476. .PP
  2477. If the receiving RTPM has already issued an RT\(hyTRANSFER indication
  2478. primitive, it performs the association\(hyabort procedure. The abort\(hyreason 
  2479. field value of the RTAB APDU is \*Qtransfer\(hycompleted\*U. In this case 
  2480. the sending RTPM ends the transfer procedure with a positive RT\(hyTRANSFER 
  2481. confirm primitive and the association\(hyrecovery procedure is performed. 
  2482. .RT
  2483. .sp 1P
  2484. .LP
  2485. 7.7.2.3.3
  2486.     \fIP\(hyACTIVITY\(hyDISCARD confirm primitive\fR 
  2487. .sp 9p
  2488. .RT
  2489. .PP
  2490. The receipt of a P\(hyACTIVITY\(hyDISCARD confirm primitive by the
  2491. sending RTPM signifies the completion of the transfer\(hydiscard procedure.
  2492. .RT
  2493. .sp 2P
  2494. .LP
  2495. 7.7.3
  2496.     \fIAssociation\(hyabort\fR 
  2497. .sp 1P
  2498. .RT
  2499. .sp 1P
  2500. .LP
  2501. 7.7.3.1
  2502.     \fIPurpose\fR 
  2503. .sp 9p
  2504. .RT
  2505. .PP
  2506. The association\(hyabort procedure is used by the RTPMs to handle the most 
  2507. severe error situations. This procedure can be performed between an 
  2508. RT\(hyTRANSFER request primitive and its corresponding RT\(hyTRANSFER confirm
  2509. primitive.
  2510. .RT
  2511. .sp 1P
  2512. .LP
  2513. 7.7.3.2
  2514.     \fIAPDUs used\fR 
  2515. .sp 9p
  2516. .RT
  2517. .PP
  2518. The association\(hyabort procedure uses the RT\(hyABORT (RTAB) APDU. The 
  2519. fields of the RTAB APDU are listed in Table\ 
  2520. 7B/FX.228.
  2521. .PP
  2522. \fINote\fR \ \(em\ The RTAB APDU is also used by the provider\(hyabort and the
  2523. user\(hyabort procedure.
  2524. .bp
  2525. .RT
  2526. .ce
  2527. \fBH.T. [T7.228]\fR 
  2528. .ce
  2529. TABLE\ 7/X.228
  2530. .ce
  2531. \fBRTAB APDU Fields\fR 
  2532. .ce
  2533. \fR 
  2534. .ps 9
  2535. .vs 11
  2536. .nr VS 11
  2537. .nr PS 9
  2538. .TS
  2539. center box;
  2540. cw(90p) | cw(30p) | cw(30p) | cw(30p) .
  2541. Field name    Presence    Source    Sink
  2542. _
  2543. .T&
  2544. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  2545. Abort\(hyreason    T    sp    sp
  2546. .T&
  2547. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  2548. Reflected\(hyparameter    T    sp    sp
  2549. .T&
  2550. lw(90p) | cw(30p) | cw(30p) | cw(30p) .
  2551. User\(hydata    U    req    ind
  2552. _
  2553. .TE
  2554. .nr PS 9
  2555. .RT
  2556. .ad r
  2557. \fBTable 7/X.228 [T7.228], p.\fR 
  2558. .sp 1P
  2559. .RT
  2560. .ad b
  2561. .RT
  2562. .sp 1P
  2563. .LP
  2564. 7.7.3.3
  2565.     \fIAssociation\(hyabort procedure\fR 
  2566. .sp 9p
  2567. .RT
  2568. .PP
  2569. This procedure is driven by the following events:
  2570. .RT
  2571. .LP
  2572.     a)
  2573.     an RTPM\(hyabort;
  2574. .LP
  2575.     b)
  2576.     an RTAB APDU.
  2577. .sp 1P
  2578. .LP
  2579. 7.7.3.3.1
  2580.     \fIRTPM\(hyabort\fR 
  2581. .sp 9p
  2582. .RT
  2583. .PP
  2584. Either the receiving or the sending RTPM transfers an RTAB APDU to its 
  2585. peer as user\(hydata of an A\(hyABORT request primitive. If the RTPM is 
  2586. the\fR 
  2587. association\(hyinitiating RTPM, it performs the association recovery procedure. 
  2588. If the RTPM is the association\(hyresponding RTPM, it awaits association\(hyrecovery. 
  2589. The receiving RTPM starts a local recovery timer.
  2590. .PP
  2591. After successful association recovery, the sending RTPM performs the transfer\(hyresumption 
  2592. procedure. 
  2593. .RT
  2594. .sp 1P
  2595. .LP
  2596. 7.7.3.3.2
  2597.     \fIRTAB APDU\fR 
  2598. .sp 9p
  2599. .RT
  2600. .PP
  2601. Either the sending RTPM or the receiving RTPM may receive an RTAB APDU 
  2602. as user\(hydata of an A\(hyABORT indication primitive. If the RTPM is the 
  2603. association\(hyinitiating RTPM, it performs the association\(hyrecovery 
  2604. procedure. If the RTPM is the association\(hyresponding RTPM, it awaits 
  2605. association recovery. 
  2606. The receiving RTPM starts a local recovery timer.
  2607. .PP
  2608. After successful association recovery, the sending RTPM performs the transfer\(hyresumption 
  2609. procedure. 
  2610. .RT
  2611. .sp 1P
  2612. .LP
  2613. 7.7.3.4
  2614.     \fIUse of the RTAB APDU fields\fR 
  2615. .sp 9p
  2616. .RT
  2617. .PP
  2618. The RTAB APDU fields are used as follows:
  2619. .RT
  2620. .sp 1P
  2621. .LP
  2622. 7.7.3.4.1
  2623.     \fIAbort\(hyreason\fR 
  2624. .sp 9p
  2625. .RT
  2626. .PP
  2627. This field may contain one of the following values:
  2628. .RT
  2629. .LP
  2630. .sp 1
  2631. \(em
  2632.     local\(hysystem\(hyproblem 
  2633.     \(em
  2634.     invalid\(hyparameter 
  2635.     The invalid parameters are specified in the reflected\(hyparameter
  2636. field.
  2637. \(em
  2638.     unrecognized\(hyactivity 
  2639.      The sending RTPM shall perform the transfer\(hyabort procedure optionally 
  2640. followed by the provider\(hyabort procedure. 
  2641. \(em
  2642.     temporary\(hyproblem 
  2643.      No attempt at association\(hyrecovery should be made for a period of 
  2644. time determined by a local rule. 
  2645. .LP
  2646. \(em
  2647.     protocol\(hyerror
  2648.     Of the RTPM.
  2649. \(em
  2650.     permanent\(hyerror 
  2651.     This value is used solely by the provider\(hyabort procedure in normal
  2652. mode.
  2653. \(em
  2654.     user\(hyabort 
  2655.     This value is used solely by the user\(hyabort procedure in normal
  2656. mode.
  2657. \(em
  2658.     transfer\(hycompleted 
  2659.     The receiving RTPM could not discard an already completed
  2660. transfer.
  2661. .bp
  2662. .sp 1P
  2663. .LP
  2664. 7.7.3.4.2
  2665.     \fIReflected\(hyparameter\fR 
  2666. .sp 9p
  2667. .RT
  2668. .PP
  2669. The reflected\(hyparameter field is a bit string that identifies which 
  2670. parameters are regarded as invalid parameters in the primitive received 
  2671. from 
  2672. the used service by the aborting RTMP before the association\(hyabort. 
  2673. The order of the bits in the bit string is the same as the order of the 
  2674. parameters in the tables of service parameters in Recommendations\ X.217 
  2675. and\ X.216 (i.e.\ bit\ 1 
  2676. represents the first parameter,\ etc.).
  2677. .RT
  2678. .sp 1P
  2679. .LP
  2680. 7.7.3.4.3
  2681.     \fIUser\(hydata\fR 
  2682. .sp 9p
  2683. .RT
  2684. .PP
  2685. This field is not used in the association\(hyabort procedure.
  2686. .bp
  2687. .RT
  2688. .sp 2P
  2689. .LP
  2690. 7.7.4
  2691.     \fIAssociation\(hyprovider\(hyabort\fR 
  2692. .sp 1P
  2693. .RT
  2694. .sp 1P
  2695. .LP
  2696. 7.7.4.1
  2697.     \fIPurpose\fR 
  2698. .sp 9p
  2699. .RT
  2700. .PP
  2701. The association\(hyprovider\(hyabort procedure is used to handle an
  2702. ACSE\(hyprovider, or a presentation service\(hyprovider abort.
  2703. .RT
  2704. .sp 1P
  2705. .LP
  2706. 7.7.4.2
  2707.     \fIAPDUs used\fR 
  2708. .sp 9p
  2709. .RT
  2710. .PP
  2711. No APDUs are used in this procedure.
  2712. .RT
  2713. .sp 1P
  2714. .LP
  2715. 7.7.4.3
  2716.     \fIAssociation\(hyprovider\(hyabort procedure\fR 
  2717. .sp 9p
  2718. .RT
  2719. .PP
  2720. This procedure is driven by the following event:
  2721. .RT
  2722. .LP
  2723.     a)
  2724.     an AP\(hyABORT indication primitive.
  2725. .sp 1P
  2726. .LP
  2727. 7.7.4.3.1
  2728.     \fIAP\(hyABORT indication primitive\fR 
  2729. .sp 9p
  2730. .RT
  2731. .PP
  2732. An association\(hyprovider\(hyabort is indicated to both RTPMs by an
  2733. AP\(hyABORT indication primitive, and may occur at any time.
  2734. .PP
  2735. After such an event, the association\(hyinitiating RTPM starts the
  2736. association\(hyrecovery procedure. Both RTPMs start a local recovery timer.
  2737. .PP
  2738. If the association\(hyprovider\(hyabort procedure was performed during 
  2739. the transfer procedure, the sending RTPM starts the transfer\(hyresumption 
  2740. procedure after the association\(hyrecovery procedure is successfully completed. 
  2741. If the 
  2742. association\(hyrecovery procedure was not successfully completed, the sending 
  2743. RTPM performs the transfer\(hyerror procedure, and the provider\(hyabort 
  2744. procedure. 
  2745. .RT
  2746. .LP
  2747. 7.8
  2748.     \fIError recovery\fR 
  2749. .sp 1P
  2750. .RT
  2751. .sp 2P
  2752. .LP
  2753. 7.8.1
  2754.     \fITransfer\(hyresumption\fR 
  2755. .sp 1P
  2756. .RT
  2757. .sp 1P
  2758. .LP
  2759. 7.8.1.1
  2760.     \fIPurpose\fR 
  2761. .sp 9p
  2762. .RT
  2763. .PP
  2764. The transfer\(hyresumption procedure is used by the sending RTPM to
  2765. recover from:
  2766. .RT
  2767. .LP
  2768.     a)
  2769.     an error situation handled by the transfer\(hyinterrupt
  2770. procedure; or,
  2771. .LP
  2772.     b)
  2773.     an error situation handled by the association\(hyabort
  2774. procedure during a transfer procedure. In this case the transfer\(hyresumption
  2775. procedure is performed after an association\(hyrecovery procedure is successfully 
  2776. performed. If no checkpoint was confirmed in the interrupted transfer 
  2777. procedure, the transfer\(hydiscard procedure followed by the transfer\(hyretry
  2778. procedure are performed after transfer\(hyresumption.
  2779. .sp 1P
  2780. .LP
  2781. 7.8.1.2
  2782.     \fIAPDUs used\fR 
  2783. .sp 9p
  2784. .RT
  2785. .PP
  2786. The transfer\(hyresumption procedure uses the RTTR APDU (see clause
  2787. 7.3.2).
  2788. .RT
  2789. .sp 1P
  2790. .LP
  2791. 7.8.1.3
  2792.     \fITransfer\(hyresumption procedure\fR 
  2793. .sp 9p
  2794. .RT
  2795. .PP
  2796. This procedure is driven by the following events:
  2797. .RT
  2798. .LP
  2799.     a)
  2800.     the resumption of an interrupted activity;
  2801. .LP
  2802.     b)
  2803.     a P\(hyACTIVITY\(hyRESUME indication primitive.
  2804. .PP
  2805. After these events, the transfer procedure is used to continue
  2806. (see clause\ 7.3.3).
  2807. .bp
  2808. .sp 1P
  2809. .LP
  2810. 7.8.1.3.1
  2811.     \fIResumption of an interrupted activity\fR 
  2812. .sp 9p
  2813. .RT
  2814. .PP
  2815. The sending RTPM issues a P\(hyACTIVITY\(hyRESUME request primitive with 
  2816. parameters that link the resumed Activity to the previously interrupted 
  2817. one. 
  2818. .PP
  2819. After the sending RTPM has issued the P\(hyACTIVITY\(hyRESUME request
  2820. primitive and at least one checkpoint was confirmed in the interrupted 
  2821. transfer procedure, it continues the transfer procedure by issuing a P\(hyDATA 
  2822. request 
  2823. primitive for the RTTR APDU following the last confirmed checkpoint.  If no
  2824. checkpoint was confirmed in the interrupted transfer procedure, the
  2825. transfer\(hydiscard procedure followed by the transfer\(hyretry procedure are
  2826. performed.
  2827. .RT
  2828. .sp 1P
  2829. .LP
  2830. 7.8.1.3.2
  2831.     \fIP\(hyACTIVITY\(hyRESUME indication primitive\fR 
  2832. .sp 9p
  2833. .RT
  2834. .PP
  2835. If the receiving RTPM receives a P\(hyACTIVITY\(hyRESUME indication
  2836. primitive, it checks the Old Activity Identifier and the Old Session Connection 
  2837. Identifier parameters of the P\(hyACTIVITY\(hyRESUME indication primitive 
  2838. with the 
  2839. corresponding information (session\(hyconnection\(hyidentifier, and Activity
  2840. Identifier) recorded for the last completely secured transfer (see
  2841. clause\ 7.3.3.4).
  2842. .PP
  2843. If the information coincides, the receiving RTPM either:
  2844. .RT
  2845. .LP
  2846.     a)
  2847.     responds correctly to the sending RTPM according to the
  2848. transfer procedure, but discards the data it receives, and does not issue an
  2849. RT\(hyTRANSFER indication primitive; or,
  2850. .LP
  2851.     b)
  2852.      performs the user\(hyexception\(hyreport procedure with a Reason parameter 
  2853. value of \*Qsequence error\*U. 
  2854. .PP
  2855. If the information does not coincide, and the old Activity
  2856. Identifier and the old Session Connection Identifier parameters match the
  2857. corresponding information of the previously interrupted activity, the
  2858. transfer\(hyresumption procedure continues as for the transfer procedure with a
  2859. P\(hyDATA indication primitive for the RTTR APDU following the last confirmed
  2860. checkpoint.
  2861. .PP
  2862. If the receiving RTPM cannot resume the activity, the receiving RTPM performs 
  2863. the user\(hyexception\(hyreport procedure or the association\(hyabort 
  2864. procedure.
  2865. .RT
  2866. .sp 2P
  2867. .LP
  2868. 7.8.2
  2869.     \fITransfer\(hyretry\fR 
  2870. .sp 1P
  2871. .RT
  2872. .sp 1P
  2873. .LP
  2874. 7.8.2.1
  2875.     \fIPurpose\fR 
  2876. .sp 9p
  2877. .RT
  2878. .PP
  2879. The transfer\(hyretry procedure is used by the sending RTPM to recover 
  2880. from an error situation handled by the transfer\(hydiscard procedure. 
  2881. .PP
  2882. The completion of this procedure is as for the transfer
  2883. procedure.
  2884. .RT
  2885. .sp 1P
  2886. .LP
  2887. 7.8.2.2
  2888.     \fIAPDUs used\fR 
  2889. .sp 9p
  2890. .RT
  2891. .PP
  2892. The transfer\(hyretry procedure uses the RTTR APDU (see
  2893. clause\ 7.3.2).
  2894. .RT
  2895. .sp 1P
  2896. .LP
  2897. 7.8.2.3
  2898.     \fITransfer\(hyretry procedure\fR 
  2899. .sp 9p
  2900. .RT
  2901. .PP
  2902. The sending RTPM performs the transfer procedure (see
  2903. clause\ 7.3.3). A new Activity Identifier parameter value is used in the
  2904. P\(hyACTIVITY\(hySTART request primitive.
  2905. .RT
  2906. .sp 2P
  2907. .LP
  2908. 7.8.3
  2909.     \fIAssociation\(hyrecovery\fR 
  2910. .sp 1P
  2911. .RT
  2912. .sp 1P
  2913. .LP
  2914. 7.8.3.1
  2915.     \fIPurpose\fR 
  2916. .sp 9p
  2917. .RT
  2918. .PP
  2919. The association\(hyrecovery procedure is used by the
  2920. association\(hyinitiating RTPM to recover from an error situation handled 
  2921. by the association\(hyabort procedure or the association\(hyprovider\(hyabort 
  2922. procedure. 
  2923. .RT
  2924. .sp 1P
  2925. .LP
  2926. 7.8.3.2
  2927.     \fIAPDUs used\fR 
  2928. .sp 9p
  2929. .RT
  2930. .PP
  2931. The association\(hyrecovery procedure uses the RT\(hyOPEN\(hyREQUEST (RTORQ) 
  2932. APDU, the RT\(hyOPEN\(hyACCEPT (RTOAC) APDU, and the RT\(hyOPEN\(hyREJECT 
  2933. (RTORJ) 
  2934. APDU.
  2935. .bp
  2936. .RT
  2937. .sp 1P
  2938. .LP
  2939. 7.8.3.2.1
  2940.     \fIRTORQ APDU\fR 
  2941. .sp 9p
  2942. .RT
  2943. .PP
  2944. The RT\(hyOPEN\(hyREQUEST (RTORQ) APDU is used in the request to recover 
  2945. an application\(hyassociation. The fields of the RTORQ APDU are listed 
  2946. in 
  2947. clause\ 7.1.2.1.
  2948. .PP
  2949. The following rules apply:
  2950. .RT
  2951. .LP
  2952.     a)
  2953.     the User\(hydata field is not used;
  2954. .LP
  2955.     b)
  2956.     the Session\(hyconnection\(hyidentifier field is mandatory.
  2957. .sp 1P
  2958. .LP
  2959. 7.8.3.2.2
  2960.     \fIRTOAC APDU\fR 
  2961. .sp 9p
  2962. .RT
  2963. .PP
  2964. The RT\(hyOPEN\(hyACCEPT (RTOAC) APDU is used in the positive response 
  2965. to the request to recover an application\(hyassociation. The fields of 
  2966. the RTOAC APDU are listed in clause\ 7.1.2.2. 
  2967. .PP
  2968. The following rules apply:
  2969. .RT
  2970. .LP
  2971.     a)
  2972.     the User\(hydata field is not used;
  2973. .LP
  2974.     b)
  2975.     the Session\(hyconnection\(hyidentifier field is mandatory.
  2976. .sp 1P
  2977. .LP
  2978. 7.8.3.2.3
  2979.     \fIRTORJ APDU\fR 
  2980. .sp 9p
  2981. .RT
  2982. .PP
  2983. The RT\(hyOPEN\(hyREJECT (RTORJ) APDU is used in the negative response 
  2984. to the request to recover an application\(hyassociation. The fields of 
  2985. the RTORJ APDU are listed in clause\ 7.1.2.3. 
  2986. .PP
  2987. The following rules apply:
  2988. .RT
  2989. .LP
  2990.     a)
  2991.     the Refuse\(hyreason field is used solely in the X.410\(hy1984
  2992. mode;
  2993. .LP
  2994.     b)
  2995.     the User\(hydata field is not used.
  2996. .sp 1P
  2997. .LP
  2998. 7.8.3.3
  2999.     \fIAssociation\(hyrecovery procedure\fR 
  3000. .sp 9p
  3001. .RT
  3002. .PP
  3003. This procedure is driven by the following events:
  3004. .RT
  3005. .LP
  3006.     a)
  3007.     an A\(hyASSOCIATE request primitive by the
  3008. association\(hyinitiating RTPM;
  3009. .LP
  3010.     b)
  3011.     an RTORQ APDU as user\(hydata on an A\(hyASSOCIATE indication
  3012. primitive;
  3013. .LP
  3014.     c)
  3015.      an A\(hyASSOCIATE confirm primitive that may contain either an RTOAC 
  3016. APDU, or an RTORJ, or no APDU. 
  3017. .sp 1P
  3018. .LP
  3019. 7.8.3.3.1
  3020.     \fIA\(hyASSOCIATE request primitive\fR 
  3021. .sp 9p
  3022. .RT
  3023. .PP
  3024. The association\(hyinitiating RTPM forms an RTORQ APDU from its
  3025. internal data. The association\(hyinitiating RTPM issues an A\(hyASSOCIATE 
  3026. request 
  3027. primitive using information stored during the association\(hyestablishment
  3028. procedure (see clause\ 7.1.3.1). The RTORQ APDU is the User Information
  3029. parameter value of the A\(hyASSOCIATE request primitive.
  3030. .PP
  3031. The association\(hyinitiating RTPM waits for a primitive from the ACSE
  3032. service\(hyprovider.
  3033. .RT
  3034. .sp 1P
  3035. .LP
  3036. 7.8.3.3.2
  3037.     \fIRTORQ APDU\fR 
  3038. .sp 9p
  3039. .RT
  3040. .PP
  3041. If the application\(hyassociation is not accepted by the ACSE
  3042. service\(hyprovider, no A\(hyASSOCIATE indication primitive is received by the
  3043. association\(hyresponding RTPM and no action takes place.
  3044. .PP
  3045. If the application\(hyassociation is accepted by the ACSE
  3046. service\(hyprovider, the association\(hyresponding RTPM receives the RTORQ 
  3047. APDU as 
  3048. the User Information parameter on an A\(hyASSOCIATE indication primitive.
  3049. .PP
  3050. If any of the A\(hyASSOCIATE indication primitive parameters, or any of 
  3051. the RTORQ APDU fields, is unacceptable to the association\(hyresponding 
  3052. RTPM, or if the association\(hyresponding RTPM is not able to accept the 
  3053. application\(hyassociation, it forms and sends an RTORJ APDU with appropriate
  3054. parameters from internal data. The association\(hyresponding RTPM issues an
  3055. A\(hyASSOCIATE response primitive. The RTORJ APDU is sent as the User Information 
  3056. parameter of the A\(hyASSOCIATE response primitive. The application\(hyassociation 
  3057. is not recovered. 
  3058. .bp
  3059. .PP
  3060. If the A\(hyASSOCIATE indication primitive parameters, and the RTORQ APDU 
  3061. fields are acceptable to the association\(hyresponding RTPM, the 
  3062. association\(hyresponding RTPM forms an RTOAC APDU using
  3063. internal data. The association\(hyresponding RTPM issues an A\(hyASSOCIATE 
  3064. response primitive. The RTOAC APDU is sent as the User Information parameter 
  3065. of the 
  3066. A\(hyASSOCIATE response primitive.
  3067. .RT
  3068. .sp 1P
  3069. .LP
  3070. 7.8.3.3.3
  3071.     \fIA\(hyASSOCIATE confirm primitive\fR 
  3072. .sp 9p
  3073. .RT
  3074. .PP
  3075. The association\(hyinitiating RTPM receives an A\(hyASSOCIATE confirm
  3076. primitive. The following situations are possible:
  3077. .RT
  3078. .LP
  3079.     a)
  3080.     the association\(hyrecovery has been accepted;
  3081. .LP
  3082.     b)
  3083.     the accepting RTPM has rejected the association\(hyrecovery;
  3084. or
  3085. .LP
  3086.     c)
  3087.     the ACSE service provider has rejected the
  3088. association\(hyrecovery.
  3089. .PP
  3090. If the association\(hyrecovery was accepted, the A\(hyASSOCIATE confirm 
  3091. primitive Result parameter has the value \*Qaccepted\*U and the RTOAC APDU 
  3092. is the value of the User Information Parameter of the A\(hyASSOCIATE confirm 
  3093. primitive. The application\(hyassociation is recovered successfully, and 
  3094. if the 
  3095. association\(hyabort occurred during the transfer procedure, the sending RTPM
  3096. continues with the transfer\(hyresumption procedure.
  3097. .PP
  3098. If the association\(hyrecovery was rejected by the responding RTPM, the 
  3099. A\(hyASSOCIATE confirm primitive Result parameter has one of the values 
  3100. \*Qrejected\|.\|.\|.\*U, the A\(hyASSOCIATE confirm primitive Result Source 
  3101. parameter has the value \*QACSE service\(hyuser\*U and the RTORJ APDU is 
  3102. the value of the User 
  3103. Information Parameter of the A\(hyASSOCIATE confirm primitive.  The
  3104. application\(hyassociation is not recovered.
  3105. .PP
  3106. If the association\(hyrecovery was rejected by the ACSE service\(hyprovider, 
  3107. the A\(hyASSOCIATE confirm primitive Result parameter has one of the values 
  3108. \*Qrejected\|.\|.\|.\*U and the A\(hyASSOCIATE confirm primitive Result 
  3109. Source parameter has either the value \*QACSE service\(hyprovider\*U or 
  3110. \*Qpresentation 
  3111. service\(hyprovider\*U.  The application\(hyassociation is not recovered.
  3112. .PP
  3113. If the application\(hyassociation was not recovered, the
  3114. association\(hyrecovery procedure is performed again by the association\(hyinitiating 
  3115. RTPM after a time determined by a local rule: 
  3116. .RT
  3117. .LP
  3118.     a)
  3119.      if the Result parameter of the A\(hyASSOCIATE confirm primitive has the 
  3120. following value \*Qrejected (transient)\*U; or 
  3121. .LP
  3122.     b)
  3123.      if, in X.410\(hy1984 mode, the Refuse\(hyreason field of the RTORJ APDU 
  3124. has the value \*Qrts\(hybusy\*U. 
  3125. .PP
  3126. In all other cases a provider\(hyabort is performed as follows.
  3127. .PP
  3128. If the association\(hyinitiating RTPM is the sending RTPM, and the
  3129. association\(hyabort occurred during the transfer procedure, the sending RTPM
  3130. performs the transfer\(hyabort procedure. The association\(hyinitiating 
  3131. RTPM performs the provider\(hyabort procedure. 
  3132. .PP
  3133. If the association\(hyresponding RTPM detects a recovery\(hytime\(hyout, the
  3134. following actions take place. If the association\(hyresponding RTPM is 
  3135. the sending RTPM, and the association\(hyabort occurred during the transfer 
  3136. procedure, the 
  3137. sending RTPM performs the transfer\(hyabort procedure. The association\(hyresponding 
  3138. RTPM performs the provider\(hyabort procedure. 
  3139. .RT
  3140. .sp 1P
  3141. .LP
  3142. 7.8.3.4
  3143.     \fIUse of the RTORQ APDU fields\fR 
  3144. .sp 9p
  3145. .RT
  3146. .PP
  3147. The RTORQ APDU fields are used as follows.
  3148. .RT
  3149. .sp 1P
  3150. .LP
  3151. 7.8.3.4.1
  3152.     \fICheckpoint\(hysize\fR 
  3153. .sp 9p
  3154. .RT
  3155. .PP
  3156. See clause 7.1.4.1.
  3157. .RT
  3158. .sp 1P
  3159. .LP
  3160. 7.8.3.4.2
  3161.     \fIWindow\(hysize\fR 
  3162. .sp 9p
  3163. .RT
  3164. .PP
  3165. See clause 7.1.4.2.
  3166. .RT
  3167. .sp 1P
  3168. .LP
  3169. 7.8.3.4.3
  3170.     \fIDialogue\(hymode\fR 
  3171. .sp 9p
  3172. .RT
  3173. .PP
  3174. See clause 7.1.4.3.
  3175. .bp
  3176. .RT
  3177. .sp 1P
  3178. .LP
  3179. 7.8.3.4.4
  3180.     \fIUser\(hydata\fR 
  3181. .sp 9p
  3182. .RT
  3183. .PP
  3184. This field is not used in the association\(hyrecovery procedure.
  3185. .RT
  3186. .sp 1P
  3187. .LP
  3188. 7.8.3.4.5
  3189.     \fISession\(hyconnection\(hyidentifier\fR 
  3190. .sp 9p
  3191. .RT
  3192. .PP
  3193. The Session\(hyconnection\(hyidentifier is used to specify the original 
  3194. session connection used in the association\(hyestablishment procedure. 
  3195. This is 
  3196. used in order to relate the new session\(hyconnection to the existing
  3197. application\(hyassociation.
  3198. .RT
  3199. .sp 1P
  3200. .LP
  3201. 7.8.3.5
  3202.     \fIUse of the RTOAC APDU fields\fR 
  3203. .sp 9p
  3204. .RT
  3205. .PP
  3206. The RTOAC APDU fields are used as follows.
  3207. .RT
  3208. .sp 1P
  3209. .LP
  3210. 7.8.3.5.1
  3211.     \fICheckpoint\(hysize\fR 
  3212. .sp 9p
  3213. .RT
  3214. .PP
  3215. See clause 7.1.5.1.
  3216. .RT
  3217. .sp 1P
  3218. .LP
  3219. 7.8.3.5.2
  3220.     \fIWindow\(hysize\fR 
  3221. .sp 9p
  3222. .RT
  3223. .PP
  3224. See clause 7.1.5.2.
  3225. .RT
  3226. .sp 1P
  3227. .LP
  3228. 7.8.3.5.3
  3229.     \fIUser\(hydata\fR 
  3230. .sp 9p
  3231. .RT
  3232. .PP
  3233. This field is used only in the association\(hyrecovery procedure.
  3234. .RT
  3235. .sp 1P
  3236. .LP
  3237. 7.8.3.5.4
  3238.     \fISession\(hyconnection\(hyidentifier\fR 
  3239. .sp 9p
  3240. .RT
  3241. .PP
  3242. The Session\(hyconnection\(hyidentifier is used to specify the original 
  3243. session connection used in the association\(hyestablishment procedure. 
  3244. This is 
  3245. used in order to relate the new session\(hyconnection to the existing
  3246. application\(hyassociation.
  3247. .RT
  3248. .sp 1P
  3249. .LP
  3250. 8.3.6
  3251.     \fIUse of the RTORJ APDU fields\fR 
  3252. .sp 9p
  3253. .RT
  3254. .PP
  3255. The RTORJ APDU fields are used as follows.
  3256. .RT
  3257. .sp 1P
  3258. .LP
  3259. 7.8.3.6.1
  3260.     \fIRefuse\(hyreason\fR 
  3261. .sp 9p
  3262. .RT
  3263. .PP
  3264. The Refuse\(hyreason field is used solely in the X.410\(hy1984 mode.
  3265. .PP
  3266. This field may contain one of the following values:
  3267. .RT
  3268. .LP
  3269. .sp 1
  3270. \(em
  3271.     rts\(hybusy
  3272.     The association\(hyresponding RTPM is so loaded that it cannot support
  3273. the application\(hyassociation. The association\(hyinitiating RTPM should
  3274. retry after a period of time. This value is provided by the
  3275. association\(hyresponding RTPM.
  3276. \(em
  3277.     cannot recover
  3278.     This value is used by the association\(hyresponding RTPM, if it is unable
  3279. to accept an association\(hyrecovery.
  3280. .sp 1P
  3281. .LP
  3282. 7.8.3.6.4
  3283.     \fIUser\(hydata\fR 
  3284. .sp 9p
  3285. .RT
  3286. .PP
  3287. This field is not used in the association\(hyrecovery procedure.
  3288. .RT
  3289. .sp 1P
  3290. .LP
  3291. 7.9
  3292.     \fIAbort\fR 
  3293. .sp 9p
  3294. .RT
  3295. .PP
  3296. These procedures are performed when a successful recovery from one of the 
  3297. error handling procedures is not possible. 
  3298. .bp
  3299. .RT
  3300. .sp 2P
  3301. .LP
  3302. 7.9.1
  3303.     \fITransfer\(hyabort\fR 
  3304. .sp 1P
  3305. .RT
  3306. .sp 1P
  3307. .LP
  3308. 7.9.1.1
  3309.     \fIPurpose\fR 
  3310. .sp 9p
  3311. .RT
  3312. .PP
  3313. The transfer\(hyabort procedure is used by the sending RTPM if the
  3314. transfer of an RTSE\(hyuser APDU is not possible.
  3315. .RT
  3316. .sp 1P
  3317. .LP
  3318. 7.9.1.2
  3319.     \fIAPDUs used\fR 
  3320. .sp 9p
  3321. .RT
  3322. .PP
  3323. No APDUs are used in this procedure.
  3324. .RT
  3325. .sp 1P
  3326. .LP
  3327. 7.9.1.3
  3328.     \fITransfer\(hyabort procedure\fR 
  3329. .sp 9p
  3330. .RT
  3331. .PP
  3332. The sending RTPM issues an RT\(hyTRANSFER confirm primitive with a
  3333. Result parameter value \*QAPDU\(hynot\(hytransferred\*U. The APDU parameter 
  3334. value is the RTSE\(hyuser APDU not transferred. 
  3335. .RT
  3336. .sp 2P
  3337. .LP
  3338. 7.9.2
  3339.     \fIProvider\(hyabort\fR 
  3340. .sp 1P
  3341. .RT
  3342. .sp 1P
  3343. .LP
  3344. 7.9.2.1
  3345.     \fIPurpose\fR 
  3346. .sp 9p
  3347. .RT
  3348. .PP
  3349. The provider\(hyabort procedure is used by the RTPMs, if recovery is not 
  3350. possible. 
  3351. .RT
  3352. .sp 1P
  3353. .LP
  3354. 7.9.2.2
  3355.     \fIAPDUs used\fR 
  3356. .sp 9p
  3357. .RT
  3358. .PP
  3359. If an application\(hyassociation exists, the provider\(hyabort procedure 
  3360. uses the RT\(hyABORT (RTAB) APDU. The RTAB APDU is specified in 
  3361. clause\ 7.7.3.2.
  3362. .RT
  3363. .sp 1P
  3364. .LP
  3365. 7.9.2.3
  3366.     \fIProvider\(hyabort procedure\fR 
  3367. .sp 9p
  3368. .RT
  3369. .PP
  3370. This procedure is driven by the following events:
  3371. .RT
  3372. .LP
  3373.     a)
  3374.     an RTPM\(hyabort;
  3375. .LP
  3376.     b)
  3377.     an RTAB APDU;
  3378. .LP
  3379.     c)
  3380.     local recovery time\(hyout.
  3381. .sp 1P
  3382. .LP
  3383. 7.9.2.3.1
  3384.     \fIRTPM\(hyabort\fR 
  3385. .sp 9p
  3386. .RT
  3387. .PP
  3388. If an application\(hyassociation exists, either the receiving or the sending 
  3389. RTPM transfers an RTAB APDU to its peer as the User\(hydata parameter of 
  3390. an A\(hyABORT request primitive. The RTPM issues a RT\(hyP\(hyABORT indication 
  3391. primitive to its RTSE\(hyuser. 
  3392. .RT
  3393. .sp 1P
  3394. .LP
  3395. 7.9.2.3.2
  3396.     \fIRTAB APDU\fR 
  3397. .sp 9p
  3398. .RT
  3399. .PP
  3400. If the sending or the receiving RTPM receives an RTAB APDU as the User\(hydata 
  3401. parameter of an A\(hyABORT indication primitive, it issues an RT\(hyP\(hyABORT 
  3402. indication primitive to its RTSE\(hyuser. 
  3403. .RT
  3404. .sp 1P
  3405. .LP
  3406. 7.9.2.3.3
  3407.     \fIRecovery time\(hyout\fR 
  3408. .sp 9p
  3409. .RT
  3410. .PP
  3411. If an application\(hyassociation does not exist and a local recovery time\(hyout 
  3412. occurs, the RTPM issues an RT\(hyP\(hyABORT indication primitive to its 
  3413. RTSE\(hyuser.
  3414. .RT
  3415. .sp 1P
  3416. .LP
  3417. 7.9.2.4
  3418.     \fIUse of the RTAB APDU fields\fR 
  3419. .sp 9p
  3420. .RT
  3421. .PP
  3422. The RTAB APDU fields are used as follows.
  3423. .RT
  3424. .sp 1P
  3425. .LP
  3426. 7.9.2.4.1
  3427.     \fIAbort\(hyreason\fR 
  3428. .sp 9p
  3429. .RT
  3430. .PP
  3431. The value of this field is \*Qpermanent\(hyerror\*U.
  3432. .bp
  3433. .RT
  3434. .sp 1P
  3435. .LP
  3436. 7.9.2.4.2
  3437.     \fIReflected\(hyparameter\fR 
  3438. .sp 9p
  3439. .RT
  3440. .PP
  3441. This field is not used.
  3442. .RT
  3443. .sp 1P
  3444. .LP
  3445. 7.9.2.4.3
  3446.     \fIUser\(hydata\fR 
  3447. .sp 9p
  3448. .RT
  3449. .PP
  3450. This field is not used.
  3451. .RT
  3452. .sp 2P
  3453. .LP
  3454. 7.9.3
  3455.     \fIUser\(hyabort\fR 
  3456. .sp 1P
  3457. .RT
  3458. .sp 1P
  3459. .LP
  3460. 7.9.3.1
  3461.     \fIPurpose\fR 
  3462. .sp 9p
  3463. .RT
  3464. .PP
  3465. The user\(hyabort procedure is used by the requestor to abort an
  3466. application\(hyassociation.
  3467. .RT
  3468. .sp 1P
  3469. .LP
  3470. 7.9.3.2
  3471.     \fIAPDUs used\fR 
  3472. .sp 9p
  3473. .RT
  3474. .PP
  3475. The user\(hyabort procedure uses the RT\(hyABORT (RTAB) APDU. The RTAB
  3476. APDU is specified in clause\ 7.7.3.2.
  3477. .RT
  3478. .sp 1P
  3479. .LP
  3480. 7.9.3.3
  3481.     \fIUser\(hyabort procedure\fR 
  3482. .sp 9p
  3483. .RT
  3484. .PP
  3485. This procedure is driven by the following events:
  3486. .RT
  3487. .LP
  3488.     a)
  3489.     an RT\(hyU\(hyABORT request primitive from the requestor;
  3490. .LP
  3491.     b)
  3492.     an RTAB APDU as User\(hydata of an A\(hyABORT indication
  3493. primitive.
  3494. .sp 1P
  3495. .LP
  3496. 7.9.3.3.1
  3497.     \fIRT\(hyU\(hyABORT request\fR 
  3498. .sp 9p
  3499. .RT
  3500. .PP
  3501. If the requesting RTPM receives an RT\(hyU\(hyABORT request primitive
  3502. from the requestor, an RTAB APDU is formed from the parameter value of the
  3503. RT\(hyU\(hyABORT request primitive and transferred as User\(hydata of an 
  3504. A\(hyABORT request primitive. 
  3505. .RT
  3506. .sp 1P
  3507. .LP
  3508. 7.9.3.3.2
  3509.     \fIRTAB APDU\fR 
  3510. .sp 9p
  3511. .RT
  3512. .PP
  3513. If the accepting RTPM receives the RTAB APDU as User\(hydata of an
  3514. A\(hyABORT indication primitive, the accepting RTPM issues an RT\(hyU\(hyABORT
  3515. indication primitive to the acceptor. The RT\(hyU\(hyABORT primitive parameter 
  3516. is 
  3517. derived from the RTAB APDU.
  3518. .RT
  3519. .sp 1P
  3520. .LP
  3521. 7.9.3.4
  3522.     \fIUse of the RTAB APDU fields\fR 
  3523. .sp 9p
  3524. .RT
  3525. .PP
  3526. The RTAB APDU fields are used as follows.
  3527. .RT
  3528. .sp 1P
  3529. .LP
  3530. 7.9.3.4.1
  3531.     \fIAbort\(hyreason\fR 
  3532. .sp 9p
  3533. .RT
  3534. .PP
  3535. The value of this field is \*Quser\(hyerror\*U.
  3536. .RT
  3537. .sp 1P
  3538. .LP
  3539. 7.9.3.4.2
  3540.     \fIReflected\(hyparameter\fR 
  3541. .sp 9p
  3542. .RT
  3543. .PP
  3544. This field is not used.
  3545. .RT
  3546. .sp 1P
  3547. .LP
  3548. 7.9.3.4.3
  3549.     \fIUser\(hydata\fR 
  3550. .sp 9p
  3551. .RT
  3552. .PP
  3553. This is the User\(hydata parameter value of the RT\(hyU\(hyABORT request
  3554. primitive. It appears as the User\(hydata parameter value of the RT\(hyU\(hyABORT 
  3555. indication primitive.
  3556. .RT
  3557. .sp 1P
  3558. .LP
  3559. 7.10
  3560.     \fIRules for extensibility\fR 
  3561. .sp 9p
  3562. .RT
  3563. .PP
  3564. In addition to the procedures stated above the following rule also applies 
  3565. when 
  3566. processing APDUs defined in this Recommendation:
  3567. .RT
  3568. .LP
  3569.     \(em
  3570.     Ignore parameters which are not defined in this
  3571. Recommendation for RTORQ, RTOAC, and RTORJ APDUs.
  3572. .LP
  3573. .bp
  3574.