home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / troff / 8_7_05.tro < prev    next >
Encoding:
Text File  |  1991-12-22  |  68.6 KB  |  3,457 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.403\fR 
  25. .RT
  26. .sp 2P
  27. .ce 1000
  28. \fBMESSAGE\ HANDLING\ SYSTEMS:\fR 
  29. .EF '%    Fascicle\ VIII.7\ \(em\ Rec.\ X.403''
  30. .OF '''Fascicle\ VIII.7\ \(em\ Rec.\ X.403    %'
  31. .ce 0
  32. .sp 1P
  33. .ce 1000
  34. \fBCONFORMANCE\ TESTING\fR 
  35. .ce 0
  36. .sp 1P
  37. .ce 1000
  38. \fI(Melbourne, 1988)\fR 
  39. .sp 9p
  40. .RT
  41. .ce 0
  42. .sp 1P
  43. .sp 2P
  44. .LP
  45.     The\ CCITT,
  46. .sp 1P
  47. .RT
  48. .sp 1P
  49. .LP
  50. \fIconsidering\fR 
  51. .sp 9p
  52. .RT
  53. .PP
  54. (a)
  55. the need for Message Handling Systems;
  56. .PP
  57. (b)
  58. the need to ensure the interoperability of Message
  59. Handling Systems;
  60. .PP
  61. (c)
  62. the need for conformance testing specifications for
  63. Message Handling Systems;
  64. .PP
  65. (d)
  66. that the X.400\(hySeries Recommendations specify
  67. Message Handling Systems;
  68. .PP
  69. (e)
  70. the state\(hyof\(hythe\(hyart of OSI testing methodology and
  71. notation within CCITT\(hyISO,
  72. .sp 1P
  73. .LP
  74. \fIunanimously declares\fR 
  75. .sp 9p
  76. .RT
  77. .PP
  78. (1)
  79. that this Recommendation describes the testing
  80. methodology for Message Handling Systems;
  81. .PP
  82. (2)
  83. that this Recommendation describes a notation used to define test specifications 
  84. for Message Handling Systems; 
  85. .PP
  86. (3)
  87. that this Recommendation describes the scope and
  88. content of CCITT Conformance Testing Specification Manuals for Message 
  89. Handling Systems. 
  90. .sp 1P
  91. .ce 1000
  92. CONTENTS
  93. .ce 0
  94. .sp 1P
  95. .sp 2P
  96. .LP
  97. 0
  98.     \fIIntroduction\fR 
  99. .sp 1P
  100. .RT
  101. .sp 1P
  102. .LP
  103. 1
  104.     \fIScope and field of application\fR 
  105. .sp 9p
  106. .RT
  107. .sp 1P
  108. .LP
  109. 2
  110.     \fIReferences\fR 
  111. .sp 9p
  112. .RT
  113. .sp 1P
  114. .LP
  115. 3
  116.     \fIDefinitions\fR 
  117. .sp 9p
  118. .RT
  119. .sp 1P
  120. .LP
  121. 4
  122.     \fIAbbreviations\fR 
  123. .sp 9p
  124. .RT
  125. .sp 1P
  126. .LP
  127. 5
  128.     \fIConventions\fR 
  129. .sp 9p
  130. .RT
  131. .sp 1P
  132. .LP
  133. 6
  134.     \fIOverview\fR 
  135. .sp 9p
  136. .RT
  137. .sp 1P
  138. .LP
  139. 7
  140.     \fIConformance requirements\fR 
  141. .sp 9p
  142. .RT
  143. .sp 1P
  144. .LP
  145. 8
  146.     \fITesting methodology\fR 
  147. .sp 9p
  148. .RT
  149. .sp 1P
  150. .LP
  151. 9
  152.     \fIStructure of test suites\fR 
  153. .sp 9p
  154. .RT
  155. .sp 1P
  156. .LP
  157. 10
  158.     \fIInformation to be supplied by implementors\fR 
  159. .sp 9p
  160. .RT
  161. .sp 1P
  162. .LP
  163. 11
  164.     \fITest notation\fR 
  165. .sp 9p
  166. .RT
  167. .sp 1P
  168. .LP
  169. 12
  170.     \fIConformance assessment procedures\fR 
  171. .sp 9p
  172. .RT
  173. .sp 1P
  174. .LP
  175. \fIAnnex\ A\fR     \(em
  176.     Test notation
  177. .sp 9p
  178. .RT
  179. .sp 1P
  180. .LP
  181. \fIAnnex\ B\fR     \(em
  182.     IPMS\ (P2) PICS proformas
  183. .sp 9p
  184. .RT
  185. .sp 1P
  186. .LP
  187. \fIAnnex\ C\fR     \(em
  188.     MTS\ (P1) PICS proformas
  189. .sp 9p
  190. .RT
  191. .sp 1P
  192. .LP
  193. \fIAnnex\ D\fR     \(em
  194.     RTS PICS proformas
  195. .bp
  196. .sp 9p
  197. .RT
  198. .sp 2P
  199. .LP
  200. \fB0\fR     \fBIntroduction\fR 
  201. .sp 1P
  202. .RT
  203. .PP
  204. This Recommendation describes the test methods, test criteria and test 
  205. notation to be used for the conformance testing of message handling 
  206. systems based on the 1984 X.400\(hyseries of Recommendations as supplemented by
  207. the X.400\(hyseries Implementor's Guide (version\ 5).
  208. .RT
  209. .sp 2P
  210. .LP
  211. \fB1\fR     \fBScope and field of application\fR 
  212. .sp 1P
  213. .RT
  214. .PP
  215. The message handling protocols in the scope of this Recommendation are 
  216. contained in the 1984\ X.400\(hyseries of Recommendations together with 
  217. the 
  218. X.400\(hyseries Implementor's Guide (version\ 5).
  219. .PP
  220. Abstract test specifications for these are contained in the CCITT
  221. Conformance Testing Specification Manuals associated with this
  222. Recommendation:
  223. .RT
  224. .LP
  225.     \(em
  226.     Conformance Testing Specification Manual for IPMS\ (P2)
  227. .LP
  228.     \(em
  229.     Conformance Testing Specification Manual for MTS\ (P1)
  230. .LP
  231.     \(em
  232.     Conformance Testing Specification Manual for RTS.
  233. .PP
  234. Even though these Manuals are referred to by this Recommendation they are 
  235. not part of it. 
  236. .PP
  237. While the complete and correct operation of session, transport and
  238. other lower\(hylayer protocols is required for interworking the testing 
  239. of these layers is not in the scope of this Recommendation. On the other 
  240. hand, 
  241. X.400\ conformance tests should verify that the Reliable Transfer Server 
  242. (RTS) correctly uses the layers beneath it. 
  243. .PP
  244. The tests defined in this document apply to inter\(hydomain working (ADMD 
  245. to ADMD and ADMD to PRMD). They relate to any MTA or UA in a domain that 
  246. supports communications with other domains.
  247. .PP
  248. Conformance testing of the semantics and syntax of the actual body
  249. part information carried in a BODY PART is beyond the scope of this
  250. document.
  251. .PP
  252. The purpose of this Recommendation is to minimize the time and expense 
  253. that manufacturers of X.400\ implementations and providers of X.400\ services 
  254. must incur to ensure a high degree of interoperability of their equipment. 
  255. This purpose is achieved by having a set of X.400\ conformance test specifications. 
  256. The successful joint execution of the test specifications by two 
  257. implementations can be accepted as compelling evidence of the complete and
  258. correct operation of these implementations.
  259. .PP
  260. The scope and intention of this Recommendation is different from other 
  261. CCITT Recommendations which define communication services and protocols 
  262. such as the 1984 X.400\(hyseries of Recommendations. The purpose of the 
  263. latter 
  264. Recommendations is to unambiguously define a system. However a Recommendation 
  265. for conformance testing provides a well chosen subset of tests of the virtually 
  266. infinite number of tests needed to guarantee full compliance to a protocol 
  267. standard. The subset is chosen in such a way that it gives a high level of
  268. confidence that tested implementations will interwork while taking into 
  269. account pragmatic considerations such as time taken to perform the tests. 
  270. .PP
  271. Testing for conformance to functional standards is beyond the scope of 
  272. this Recommendation. However it is recognized that conformance tests for 
  273. functional standards can be derived from this Recommendation and the associated 
  274. Test Specification Manuals. 
  275. .PP
  276. It should be recognized that the conformance testing of message
  277. handling systems may fall within the framework of national regulations 
  278. and may be subject to the testing policies of Administrations which are 
  279. beyond the 
  280. scope of this document.
  281. .RT
  282. .sp 2P
  283. .LP
  284. \fB2\fR     \fBReferences (1984 version)\fR 
  285. .sp 1P
  286. .RT
  287. .LP
  288. Recommendation X.210
  289.     Open Systems Interconnection (OSI) Layer Service
  290. Definitions Convention.
  291. .LP
  292. Recommendation X.400
  293.     Message Handling Systems: System Model\(hyService
  294. Elements.
  295. .LP
  296. Recommendation X.401
  297.     Message Handling Systems: Basic service
  298. elements and optional user facilities.
  299. .LP
  300. Recommendation X.408
  301.     Message Handling Systems: Encoded information type
  302. conversion rules.
  303. .bp
  304. .LP
  305. Recommendation X.409
  306.     Message Handling Systems: Presentation transfer
  307. syntax and notation.
  308. .LP
  309. Recommendation X.410
  310.     Message Handling Systems: Remote operations
  311. and reliable transfer server.
  312. .LP
  313. Recommendation X.411
  314.     Message Handling Systems: Message transfer layer.
  315. .LP
  316. Recommendation X.420
  317.     Message Handling Systems: Interpersonal
  318. messaging user agent layer.
  319. .LP
  320. X.400 Series
  321.     Implementor's Guide version 5.
  322. .sp 2P
  323. .LP
  324. \fB3\fR     \fBDefinitions\fR 
  325. .sp 1P
  326. .RT
  327. .sp 1P
  328. .LP
  329. 3.1
  330.     \fIService convention definitions\fR 
  331. .sp 9p
  332. .RT
  333. .PP
  334. This Recommendation makes use of the following terms defined in \fR Recommendation\ 
  335. X.210, (version\ 1984): 
  336. .RT
  337. .LP
  338.     a)
  339.     primitive;
  340. .LP
  341. \fR 
  342.     b)
  343.     request (primitive);
  344. .LP
  345.     c)
  346.     indication (primitive);
  347. .LP
  348.     d)
  349.     response (primitive);
  350. .LP
  351.     e)
  352.     confirm (primitive).
  353. .sp 1P
  354. .LP
  355. 3.2
  356.     \fIMessage handling definitions\fR 
  357. .sp 9p
  358. .RT
  359. .PP
  360. This Recommendation makes use of the following terms defined in
  361. Recommendation\ X.400, (version\ 1984):
  362. .RT
  363. .LP
  364.     a)
  365.     administration management domain;
  366. .LP
  367.     b)
  368.     interpersonal message (Recommendation X.420);
  369. .LP
  370.     c)
  371.     message;
  372. .LP
  373.     d)
  374.     message transfer (Recommendation X.411);
  375. .LP
  376.     e)
  377.     originator;
  378. .LP
  379.     f
  380. )
  381.     private management domain;
  382. .LP
  383.     g)
  384.     recipient;
  385. .LP
  386.     h)
  387.     user.
  388. .sp 2P
  389. .LP
  390. \fB4\fR     \fBAbbreviations\fR 
  391. .sp 1P
  392. .RT
  393. .PP
  394. The following abbreviations are used in this
  395. Recommendation:
  396. .RT
  397. .LP
  398.     ADMD
  399.     Administration Management Domain
  400. .LP
  401.     ASP
  402.     Abstract Service Primitive
  403. .LP
  404.     DSE
  405.     Distributed Single layer Embedded testmethod
  406. .LP
  407.     MHS
  408.     Message Handling System
  409. .LP
  410.     IPMS
  411.     Interpersonal Messaging System
  412. .LP
  413.     IUT
  414.     Implementation Under Test
  415. .LP
  416.     MPDU
  417.     Message Protocol Data Unit
  418. .LP
  419.     MT
  420.     Message Transfer
  421. .LP
  422.     MTA
  423.     Message Transfer Agent
  424. .LP
  425.     MTS
  426.     Message Transfer System
  427. .LP
  428.     P1
  429.     The Message Transfer Protocol [X.411]
  430. .LP
  431.     P2
  432.     The Interpersonal Messaging Protocol [X.420]
  433. .LP
  434.     PCO
  435.     Point of Control and Observation
  436. .LP
  437.     PICS
  438.     Protocol Implementation Conformance Statement
  439. .bp
  440. .LP
  441.     PIXIT
  442.     Protocol Implementation Extra Information for Testing
  443. .LP
  444.     PDU
  445.     Protocol data unit
  446. .LP
  447.     PRMD
  448.     Private management domain
  449. .LP
  450.     RTS
  451.     Reliable Transfer Server
  452. .LP
  453.     SAP
  454.     Service Access Point
  455. .LP
  456.     TSP
  457.     Test Suite Parameter
  458. .LP
  459.     TTCN
  460.     Tree and Tabular Combined Notation
  461. .LP
  462.     UA
  463.     User Agent.
  464. .sp 2P
  465. .LP
  466. \fB5\fR     \fBConventions\fR 
  467. .sp 1P
  468. .RT
  469. .PP
  470. No conventions are defined for this Recommendation.
  471. .RT
  472. .sp 2P
  473. .LP
  474. \fB6\fR     \fBOverview\fR 
  475. .sp 1P
  476. .RT
  477. .PP
  478. There are two kinds of CCITT documents concerned
  479. with X.400 Conformance testing:
  480. .RT
  481. .LP
  482.     (a)
  483.      This CCITT Recommendation entitled \*QX.403 Message Handling Systems\ 
  484. \(em\ Conformance testing\*U; 
  485. .LP
  486.     (b)
  487.     Three associated CCITT Conformance Testing Specification
  488. Manuals entitled:
  489. .LP
  490.     \(em
  491.     Conformance Testing Specification Manual for IPMS\ (P2)
  492. .LP
  493.     \(em
  494.     Conformance Testing Specification Manual for MTS\ (P1)
  495. .LP
  496.     \(em
  497.     Conformance Testing Specification Manual for RTS
  498. .PP
  499. The CCITT Recommendation is intended for a wide readership. The
  500. Manuals are intended for test implementors and contain detailed test
  501. specifications.
  502. .sp 1P
  503. .LP
  504. 6.1
  505.     \fIThe X.400 conformance testing Recommendation\fR 
  506. .sp 9p
  507. .RT
  508. .PP
  509. This Recommendation gives the following information:
  510. .RT
  511. .LP
  512.     a)
  513.     Conformance requirements of X.400 implementations.
  514. .LP
  515.     b)
  516.     The testing methodology.
  517. .LP
  518.     c)
  519.     The structure of the test specifications.
  520. .LP
  521.     d)
  522.     Information to be supplied by implementors as a
  523. prerequisite to conformance testing.
  524. .LP
  525.     e)
  526.     The test notation.
  527. .LP
  528.     f
  529. )
  530.     Conformance assessment procedures.
  531. .sp 1P
  532. .LP
  533. 6.2
  534.     \fIThe X.400 conformance testing specification manuals\fR 
  535. .sp 9p
  536. .RT
  537. .PP
  538. Three CCITT conformance testing specification manuals contain test specifications 
  539. for the IPMS\ (P2), MTS\ (P1), RTS. The test specifications are 
  540. written in a notation described in general terms in \(sc\ 11. The conformance
  541. testing specification manuals are referred to by this Recommendation but 
  542. they are not part of it. 
  543. .PP
  544. Since the manuals contain detailed and unambiguous test
  545. specifications, users of these manuals should be familiar with the X.400\(hyseries 
  546. of Recommendations and with the testing methodology used. 
  547. .RT
  548. .sp 2P
  549. .LP
  550. \fB7\fR     \fBConformance requirements\fR 
  551. .sp 1P
  552. .RT
  553. .PP
  554. The purpose of the test specifications referenced by this
  555. Recommendation is to define tests that will establish to a high degree
  556. of confidence that the various protocol layers of an implementation
  557. under test conform to the requirements of the X.400\(hyseries of
  558. Recommendations\ (1984).
  559. .bp
  560. .RT
  561. .PP
  562. 7.1
  563. A system claiming to conform to the X.400 IPM\(hyService has to
  564. support correctly:
  565. .sp 9p
  566. .RT
  567. .LP
  568.     \(em
  569.     the basic IPM service elements as defined in Table\ 2/X.400;
  570. .LP
  571.     \(em
  572.     the IPM Optional User facilities defined as Essential in
  573. Tables\ 1/X.401 and\ 2/X.401 (where the
  574. categorization for origination and
  575. reception should be considered);
  576. .LP
  577.     \(em
  578.     the IPM Optional User facilities defined as Additional in
  579. Tables\ 1/X.401 and 2/X.401, which
  580. are claimed to be supported;
  581. .LP
  582.     \(em
  583.     the requirements related to the IPM service as defined in
  584. version\ 5 of the X.400\(hyseries Implementor's Guide.
  585. .PP
  586. 7.2
  587. A system claiming to conform to the X.400 MT\(hyservice has to
  588. support correctly:
  589. .LP
  590.     \(em
  591.     the basic MT service elements as defined in Table\ 1/X.400
  592. related to the MTS\ (P1) protocol;
  593. .LP
  594.     \(em
  595.     the MT Optional User facilities defined as Essential in
  596. Tables\ 3/X.401 and 4/X.401 and related to the MTS\ (P1) protocol;
  597. .LP
  598.     \(em
  599.     the MT Optional User facilities defined as Additional in
  600. Tables\ 3/X.401 and 4/X.401 and related to the MTS\ (P1) protocol, which are
  601. claimed to be supported;
  602. .LP
  603.     \(em
  604.      the requirements related to the P1 MT\(hyservice as defined in version 
  605. 5 of the CCITT X.400\(hyseries Implementor's Guide. 
  606. .PP
  607. 7.3
  608. system claiming to conform to the X.400 RTS\(hyservice has to support correctly: 
  609. .LP
  610.     \(em
  611.     the RTS\(hyservices as defined in X.410;
  612. .LP
  613.     \(em
  614.     the requirements related to the RTS\(hyservice as defined in
  615. version 5 of the CCITT X.400\(hyseries Implementor's Guide.
  616. .PP
  617. 7.4
  618. Claims of conformance of an implementation to the X.400\(hyseries of Recommendations 
  619. can be tested using the conformance testing specification 
  620. manuals associated with this Recommendation to ensure that:
  621. .LP
  622.     (a)
  623.      The implementation does not act or react in a way different to the one 
  624. described in the Recommendations. 
  625. .LP
  626.     (b)
  627.     The implementation is capable of handling protocol
  628. errors.
  629. .LP
  630.     The reaction of an implementation on receipt of protocol
  631. errors is not defined in the X.400\(hyseries of Recommendations. For the 
  632. purpose of conformance testing the minimum additional requirement is made 
  633. that the 
  634. implementation subsequently continues to operate normally in such cases.
  635. .LP
  636.      The absence of a mandatory protocol element in P2 or P1 is regarded as 
  637. a protocol error. It should be noted that in an implementated MHS a recipient 
  638. domain may choose to deliver an incorrect MPDU. This should be 
  639. considered as proprietary design by the equipment vendor, and the specific
  640. actions taken in these situations are defined by the vendor and not subject 
  641. to conformance. 
  642. .LP
  643.     (c)
  644.     The implementation correctly handles the requirements
  645. defined in X.400 Implementor's Guide Version\ 5.
  646. .LP
  647.     Maximum lengths and maximum number of occurrences are
  648. interpreted in the following way:
  649. .LP
  650.     \(em
  651.     on origination: the implementation may support
  652. maximum lengthsB/Foccurrences up to but not exceeding the
  653. constraint value.
  654. .LP
  655.     \(em
  656.     on reception: the implementation must support the
  657. maximum lengthsB/Foccurrences of the constraints. Values above the constraints
  658. may be supported but the conformance requirements on the implementation upon
  659. reception of a lengthB/Foccurrence exceeding the constraint are
  660. the same as for protocol errors.
  661. .PP
  662. Claims of conformance to the X.400 series of
  663. Recommendations can not be tested for those implementations for which it 
  664. is not possible to perform all the required tests for features labeled 
  665. mandatory, 
  666. basic or essential optional.
  667. .bp
  668. .sp 2P
  669. .LP
  670. \fB8\fR     \fBTesting methodology\fR 
  671. .sp 1P
  672. .RT
  673. .sp 1P
  674. .LP
  675. 8.1
  676.     \fITest configurations\fR 
  677. .sp 9p
  678. .RT
  679. .PP
  680. Two test configurations are used. The first configuration is shown in Figure\ 
  681. 1/X.403 and is used to test IPMS\ (P2), MTS\ (P1) and RTS. 
  682. .RT
  683. .LP
  684. .rs
  685. .sp 7P
  686. .ad r
  687. \fBFigure 1/X.403, (N), p.\fR 
  688. .sp 1P
  689. .RT
  690. .ad b
  691. .RT
  692. .PP
  693. The second configuration is shown in Figure 2/X.403 and is used to test 
  694. the relay aspects of the MTS\ (P1) protocol. 
  695. .LP
  696. .rs
  697. .sp 8P
  698. .ad r
  699. \fBFigure 2/X.403, (N), p.\fR 
  700. .sp 1P
  701. .RT
  702. .ad b
  703. .RT
  704. .sp 1P
  705. .LP
  706. 8.2
  707.     \fIPoints of control and observation\fR 
  708. .sp 9p
  709. .RT
  710. .PP
  711. Test cases are described abstractly in terms of events at Points of Control 
  712. and Observation (PCO) in both the tester and the Implementation Under Test 
  713. (IUT). These PCOs are generally Service Access Points (SAPs) and the 
  714. events are generally Abstract Service Primitives (ASPs). This does not imply
  715. that manufacturers are required to have accessible SAPs or to implement ASPs
  716. within their systems. During test execution the PCOs of an IUT may be accessed 
  717. indirectly through a user interface. Where testing is performed through 
  718. a user interface, the mapping of events between the SAP and the user interface 
  719. is 
  720. provided by the supplier of the IUT as described in \(sc\ 10.2.
  721. .RT
  722. .sp 1P
  723. .LP
  724. 8.2.1
  725.     \fIPCOs for IPMS(P2)\fR 
  726. .sp 9p
  727. .RT
  728. .PP
  729. The IPMS\ (P2) test cases are described using the Points of Control and 
  730. Observation (PCOs) shown in Figure 3/X.403. 
  731. .RT
  732. .LP
  733. .rs
  734. .sp 12P
  735. .ad r
  736. \fBFigure 3/X.403, (N), p.\fR 
  737. .sp 1P
  738. .RT
  739. .ad b
  740. .RT
  741. .LP
  742. .bp
  743. .PP
  744. For the tester, the Point of Control and Observation is the
  745. Service Access Point (SAP) defined at the boundary between the User Agent 
  746. Layer and the Message Transfer Layer. This PCO makes use of the Message 
  747. Transfer 
  748. Layer Service Primitives defined in Recommendation\ X.411.
  749. .PP
  750. For the IUT, the PCO is the SAP defined at the upper boundary of the User 
  751. Agent Layer. However Recommendation\ X.420 does not include definition 
  752. of Service Primitives and it has therefore been necessary to construct 
  753. hypothetical ones for sending and receiving IP\(hymessages, in order that 
  754. the test cases can be described in a formal way. 
  755. .RT
  756. .sp 1P
  757. .LP
  758. 8.2.2
  759.     \fIPCOs for MTS(P1)\fR 
  760. .sp 9p
  761. .RT
  762. .PP
  763. The MTS\ (P1) test cases are described using the PCOs shown in
  764. Figure\ 4/X.403.
  765. .RT
  766. .LP
  767. .rs
  768. .sp 20P
  769. .ad r
  770. \fBFigure 4/X.403, (N), p.\fR 
  771. .sp 1P
  772. .RT
  773. .ad b
  774. .RT
  775. .PP
  776. For the tester, the PCO is the SAP defined at the boundary between the 
  777. MT Layer and the RTS. This PCO makes use of the RTS primitives defined 
  778. in Recommendation\ X.410. 
  779. .PP
  780. For the IUT, the PCO is the SAP defined at the boundary between the UA 
  781. Layer and the MT Layer. This PCO makes use of the MT Service Primitives 
  782. defined in Recommendation\ X.411. 
  783. .PP
  784. The testing of relay functions requires more than one tester SAP.
  785. Similarly the testing of multiple destination delivery requires more than 
  786. one UA on the IUT. 
  787. .RT
  788. .sp 1P
  789. .LP
  790. 8.2.3
  791.     \fIPCOs for RTS\fR 
  792. .sp 9p
  793. .RT
  794. .PP
  795. The RTS test cases are described using the PCOs shown in
  796. Figure\ 5/X.403.
  797. .RT
  798. .PP
  799. For the tester, the PCO is the SAP defined at the boundary between the 
  800. RTS and the Session Layer. This PCO makes use of the Session Service 
  801. Primitives defined in Recommendation\ X.215.
  802. .PP
  803. For the IUT, the PCO is the SAP defined at the upper boundary of the User 
  804. Agent Layer. This PCO makes use of the same hypothetical Service 
  805. Primitives defined for IPMS\ (P2) (\(sc\ 8.2.1).
  806. .PP
  807. The description of the RTS test cases includes events at a third SAP at 
  808. the IUT (SAP\(hyI) between the MT Layer and RTS. The events of this SAP 
  809. are 
  810. used only for clarification and it is not used as a PCO.
  811. .bp
  812. .RT
  813. .LP
  814. .rs
  815. .sp 18P
  816. .ad r
  817. \fBFigure 5/X.403, (N), p.\fR 
  818. .sp 1P
  819. .RT
  820. .ad b
  821. .RT
  822. .sp 1P
  823. .LP
  824. 8.3
  825.     \fITest design strategy\fR 
  826. .sp 9p
  827. .RT
  828. .PP
  829. The MHS test specifications are designed using
  830. the following concepts:
  831. .RT
  832. .LP
  833.     a)
  834.     A test specification is defined as a test
  835. suite composed of a
  836. number of test cases as defined in \(sc\ 11.1.
  837. .LP
  838.     b)
  839.     Test cases are defined in terms of:
  840. .LP
  841.     \(em
  842.     lower layer ASP events at the tester;
  843. .LP
  844.     \(em
  845.     upper layer ASP events at the IUT.
  846. .LP
  847.     c)
  848.     The test cases define the sequencing of these ASP events
  849. and the associated parameters, in particular the PDUs.
  850. .LP
  851.     d)
  852.     Test cases for valid behaviour specify ASP
  853. event sequences and PDUs that are in accordance with the
  854. X.400\(hyseries of Recommendations.
  855. .LP
  856.     e)
  857.     Test cases for invalid behaviour are characterized by:
  858. .LP
  859.     \(em
  860.     a correct PDU or event initiated by the tester in a
  861. protocol state where it is not permitted
  862. (an inopportune event); or
  863. .LP
  864.     \(em
  865.     a correct PDU incorporating an element which is
  866. syntactically correct and in range, but conflicts with
  867. the negotiated value; or
  868. .LP
  869.     \(em
  870.     a PDU sent by the tester which is syntactically
  871. incorrect (examples are a missing mandatory protocol element, an out\(hyof\(hyrange 
  872. value or an incorrectly encoded length indicator); or 
  873. .LP
  874.     \(em
  875.      for RTS a lower layer ASP event issued by the tester used with parameters 
  876. that are not allowed or not appropriate (example SPSN in SConnect) by X.400 
  877. restrictions. 
  878. .LP
  879.     f
  880. )
  881.     The depth of testing is restricted to a reasonable
  882. number of test cases using the following principles:
  883. .LP
  884.     1)
  885.     For valid behaviour:
  886. .LP
  887.     \(em
  888.     if there is a small number of valid
  889. protocol element values, test all of them;
  890. .LP
  891.     \(em
  892.     if there is a range of values, test the
  893. bounds and a few common values;
  894. .LP
  895.     \(em
  896.     if there are no bounds, test an extreme value
  897. besides the common ones.
  898. .LP
  899.     2)
  900.     For invalid behaviour:
  901. .LP
  902.     \(em
  903.      The number of test cases for a particular type of error is reduced to 
  904. one or just a few common ones. 
  905. .bp
  906. .sp 1P
  907. .LP
  908. 8.3.1
  909.     \fIStrategy for X.409 testing\fR 
  910. .sp 9p
  911. .RT
  912. .PP
  913. The X.409 test cases defined in the CCITT conformance testing
  914. specification manuals associated with this Recommendation are applicable 
  915. only to X.400 message handling systems. The testing of X.409 is done as 
  916. part of the MTS\ (P1), IPMS\ (P2) and RTS testing. The features tested 
  917. are the data types 
  918. defined in X.409, the various forms of length encoding and the use of primitive 
  919. and constructor data elements. To increase the likelihood that the tests 
  920. can be performed, the test cases wherever possible have been defined using 
  921. the 
  922. protocol elements associated with mandatory service elements.
  923. .PP
  924. Two categories of X.409 tests are identified:
  925. .RT
  926. .LP
  927.     \(em
  928.     \fIDecoding tests\fR 
  929. .LP
  930.      These tests are constructed by identifying X.409 features to be exercised 
  931. and devising sets of correctly and incorrectly encoded test PDUs containing 
  932. these features. The tests are performed by transmitting the test 
  933. PDUs to the IUT and observing the local reaction of the implementation 
  934. and/or any PDUs returned to the tester. 
  935. .LP
  936.     \(em
  937.     \fIEncoding tests\fR 
  938. .LP
  939.     These tests are constructed by identifying a set of user
  940. several requests that will generate PDUs whose encoding will exercise major
  941. X.409 features. The tester must check the validity of the coding of the
  942. resulting PDUs generated by the IUT.
  943. .LP
  944.     The decoding tests allow the X.409 decoding features of an
  945. implementation to be fully exercised using valid and invalid test PDUs.
  946. Encoding tests only allow the valid behaviour of X.409 encoding to be
  947. checked.
  948. .sp 1P
  949. .LP
  950. 8.3.2
  951.     \fIStrategy for IPMS(P2) testing\fR 
  952. .sp 9p
  953. .RT
  954. .PP
  955. Two categories of test are identified:
  956. .RT
  957. .LP
  958.     \(em
  959.     IUT as originator;
  960. .LP
  961.     \(em
  962.     IUT as recipient.
  963. .PP
  964. With the IUT as originator, for each service element supported by the implementation, 
  965. tests are performed by: 
  966. .LP
  967.     \(em
  968.     invoking the service;
  969. .LP
  970.     \(em
  971.     the tester checking the validity of the resulting PDUs;
  972. .LP
  973.     \(em
  974.     where appropriate the tester returning valid and invalid
  975. response PDUs to the originator.
  976. .PP
  977. With the IUT as recipient, for each service element,
  978. tests are performed by:
  979. .LP
  980.     \(em
  981.     the tester sending valid and invalid PDUs for that
  982. service;
  983. .LP
  984.     \(em
  985.     observing the local reaction of the UA;
  986. .LP
  987.     \(em
  988.     checking the validity of any further PDUs generated
  989. by the UA.
  990. .PP
  991. In order to avoid unnecessary duplication of test cases, IPM
  992. service elements which are also MT service elements (for instance Delivery
  993. Notification) are listed in the MTS\ (P1) test suite in conjunction with the
  994. corresponding MT service elements, and not in the IPMS\ (P2) test suite.
  995. .PP
  996. It is assumed that the testing of the MT layer is done through a User  Agent.
  997. .RT
  998. .sp 1P
  999. .LP
  1000. 8.3.3
  1001.     \fIStrategy for MTS(P1) testing\fR 
  1002. .sp 9p
  1003. .RT
  1004. .PP
  1005. When testing the operation of a MTS\ (P1) implementation five
  1006. categories of tests are identified.
  1007. .RT
  1008. .LP
  1009.     \(em
  1010.     IUT as originator;
  1011. .LP
  1012.     \(em
  1013.     IUT as recipient;
  1014. .LP
  1015.     \(em
  1016.     IUT as relay;
  1017. .LP
  1018.     \(em
  1019.     IUT as relay recipient;
  1020. .LP
  1021.     \(em
  1022.     IUT as recipient/originator.
  1023. .PP
  1024. With the IUT as originator, for each service element supported by the implementation, 
  1025. tests are performed by: 
  1026. .LP
  1027.     \(em
  1028.     invoking the service;
  1029. .LP
  1030.     \(em
  1031.     checking the validity of the resulting PDUs.
  1032. .bp
  1033. .PP
  1034. With the IUT as recipient, for each service element supported by the implementation, 
  1035. tests are performed by: 
  1036. .LP
  1037.     \(em
  1038.     the tester sending valid and invalid PDUs for that
  1039. service;
  1040. .LP
  1041.     \(em
  1042.     observing the local reaction of the UA;
  1043. .LP
  1044.     \(em
  1045.     checking the validity of any further PDUs generated by
  1046. the UA.
  1047. .PP
  1048. With the IUT as relay, for each service element tests are
  1049. performed by:
  1050. .LP
  1051.     \(em
  1052.     the tester sending valid and invalid PDUs for relaying;
  1053. .LP
  1054.     \(em
  1055.     checking the validity of the reaction of the IUT.
  1056. .PP
  1057. With the IUT as a relay recipient, for each service element tests are performed 
  1058. by: 
  1059. .LP
  1060.     \(em
  1061.     sending a set of valid and invalid PDUs destined for more
  1062. than one recipient. At least one of these recipients is attached to the 
  1063. IUT and a further recipient is attached to a remote MTA such that the IUT 
  1064. has to relay the message; 
  1065. .LP
  1066.     \(em
  1067.     checking the validity of the reaction of the IUT as
  1068. recipient;
  1069. .LP
  1070.     \(em
  1071.      checking that the PDUs that are relayed are not corrupted and are modified 
  1072. appropriately. 
  1073. .PP
  1074. With the IUT as a recipientB/Foriginator, for each service element supported 
  1075. by the implementation, tests are performed by: 
  1076. .LP
  1077.     \(em
  1078.     invoking the IUT to send a message to multiple recipients.
  1079. At least one recipient will be attached to the IUT itself and a further
  1080. recipient will be attached to a remote MTA;
  1081. .LP
  1082.     \(em
  1083.     checking the validity of the reaction of the IUT as
  1084. recipient;
  1085. .LP
  1086.     \(em
  1087.     checking the validity of the PDUs transmitted by the
  1088. IUT.
  1089. .sp 1P
  1090. .LP
  1091. 8.3.4
  1092.     \fIStrategy for RTS testing\fR 
  1093. .sp 9p
  1094. .RT
  1095. .PP
  1096. The following testing phases are used:
  1097. .RT
  1098. .LP
  1099.     a)
  1100.     \fIThe connection/association establishment and\fR 
  1101. \fInegotiation phase\fR 
  1102. .LP
  1103.     The X.410 Recommendation allows different negotiable
  1104. options and the negotiation phase is tested exhaustively using valid and
  1105. invalid elements.
  1106. .LP
  1107.     b)
  1108.     \fIThe orderly release of the connection/association\fR 
  1109. .LP
  1110.     Only a few tests are required to check the correct
  1111. implementation of the RTS release features.
  1112. .LP
  1113.     c)
  1114.     \fIThe data transfer phase with token exchange\fR 
  1115. .LP
  1116.     The data transfer tests check:
  1117. .LP
  1118.     \(em
  1119.     the correct operation of data transfer using the
  1120. negotiated values;
  1121. .LP
  1122.     \(em
  1123.     the correct operation of token exchange;
  1124. .LP
  1125.     \(em
  1126.     the correct confirmation of confirmed services;
  1127. .LP
  1128.     \(em
  1129.     the correct reaction to invalid (e.g. non\(hynegotiated)  elements.
  1130. .LP
  1131.     d)
  1132.     \fIRecovery\fR 
  1133. .LP
  1134.     Tests are performed to check that an IUT can perform
  1135. correct recovery after:
  1136. .LP
  1137.     \(em
  1138.     user aborts;
  1139. .LP
  1140.     \(em
  1141.     provider aborts;
  1142. .LP
  1143.     \(em
  1144.     exception reports;
  1145. .LP
  1146.     \(em
  1147.     not acknowledged checkpoints.
  1148. .sp 2P
  1149. .LP
  1150. \fB9\fR     \fBStructure of test suites\fR 
  1151. .sp 1P
  1152. .RT
  1153. .PP
  1154. The IPMS\ (P2) and MTS\ (P1) test suites have a common structure
  1155. which differs from that of the RTS test suites.
  1156. .RT
  1157. .sp 1P
  1158. .LP
  1159. 9.1
  1160.     \fIStructure of IPMS(P2) and MTS(P1) test suites\fR 
  1161. .sp 9p
  1162. .RT
  1163. .PP
  1164. The IPMS\ (P2) and MTS\ (P1) test suites consist of five groups of
  1165. test cases:
  1166. .RT
  1167. .LP
  1168.     a)
  1169.     \fIInitial tests\fR 
  1170. .LP
  1171.      The initial tests check mandatory features in a small number of test 
  1172. cases. They have been defined in order to check that the implementation 
  1173. correctly supports the main mandatory features and that it is sensible 
  1174. to 
  1175. continue with full conformance testing.
  1176. .bp
  1177. .LP
  1178.     b)
  1179.     \fIX.409 tests\fR 
  1180. .LP
  1181.     The X.409 tests check the IUT's encoding and decoding of
  1182. protocol elements. Decoding tests are performed by transmitting test PDUs to
  1183. the IUT. Encoding tests are performed by checking PDUs received
  1184. from the IUT.
  1185. .LP
  1186.     c)
  1187.     \fIProtocol element tests\fR 
  1188. .LP
  1189.     Protocol element tests identify test purposes for every
  1190. protocol element in the IPMS\ (P2)/MTS\ (P1) protocols. This is important in
  1191. ensuring a full test coverage for the IPMS\ (P2)/MTS\ (P1) protocols. Many of
  1192. these tests are necessarily performed as part of the service element tests.
  1193. .LP
  1194.     d)
  1195.     \fIService element tests\fR 
  1196. .LP
  1197.     Service element tests check the capability of the IUT to
  1198. support the service elements in X.400. Some of these tests are carried 
  1199. out in the initial tests and the X.409 tests. Service element tests include 
  1200. both tests for specific service elements and tests for combinations of 
  1201. interdependent 
  1202. service elements.
  1203. .LP
  1204.     e)
  1205.     \fIAdditional test\fR 
  1206. .LP
  1207.      The additional test group checks features not covered in the other test 
  1208. groups. 
  1209. .LP
  1210.     As indicated in a) to e) above the number of test cases
  1211. has been minimized by taking advantage of the fact that the performance of a
  1212. given test case may cover more than one test purpose. Figure\ 6/X.403 shows 
  1213. how some of the test purposes identified in a particular test group may 
  1214. actually be achieved by test cases in another group. 
  1215. .LP
  1216. .rs
  1217. .sp 14P
  1218. .ad r
  1219. \fBFigure 6/X.403, (N), p.\fR 
  1220. .sp 1P
  1221. .RT
  1222. .ad b
  1223. .RT
  1224. .sp 1P
  1225. .LP
  1226. 9.2
  1227.     \fIStructure of RTS test suites\fR 
  1228. .sp 9p
  1229. .RT
  1230. .PP
  1231. The RTS test suite is made up of five groups of test
  1232. cases:
  1233. .RT
  1234. .LP
  1235.     \(em
  1236.     association establishment tests;
  1237. .LP
  1238.     \(em
  1239.     asociation release tests;
  1240. .LP
  1241.     \(em
  1242.     data transfer tests;
  1243. .LP
  1244.     \(em
  1245.     association recovery tests;
  1246. .LP
  1247.     \(em
  1248.     X.409 tests.
  1249. .PP
  1250. The association establishment tests check the negotiation of the connection 
  1251. elements. 
  1252. .PP
  1253. The association release tests check the orderly release of
  1254. associations.
  1255. .PP
  1256. The data transfer tests check that data is transferred correctly in
  1257. accordance with the values of the connection elements negotiated during
  1258. association establishment.
  1259. .PP
  1260. The association recovery tests check that the IUT can recover from
  1261. breaks in connection both inside and outside activities.
  1262. .PP
  1263. The X.409 tests check the IUT's encoding and decoding of session
  1264. service user data.
  1265. .bp
  1266. .RT
  1267. .sp 2P
  1268. .LP
  1269. \fB10\fR     \fBInformation to be supplied by implementors\fR 
  1270. .sp 1P
  1271. .RT
  1272. .sp 1P
  1273. .LP
  1274. 10.1
  1275.     \fIProtocol implementation conformance statement\fR 
  1276. \fI(PICS)\fR 
  1277. .sp 9p
  1278. .RT
  1279. .PP
  1280. The Protocol Implementation Conformance Statement (PICS) is
  1281. information supplied by an implementor that specifies the protocol features
  1282. implemented in a Message Handling System.
  1283. .PP
  1284. This information is used during conformance testing:
  1285. .RT
  1286. .LP
  1287.     \(em
  1288.     to check that the protocol features that have been
  1289. implemented are consistent with the conformance requirements, in terms of\fR 
  1290. optional and mandatory features, of the X.400\(hyseries of
  1291. Recommendations;
  1292. .LP
  1293.     \(em
  1294.      to select the originator tests to be executed. Recipient and relay tests 
  1295. will be performed to check the behaviour of the system even when it is 
  1296. requested to handle features that it does not implement. 
  1297. .PP
  1298. PICS \fIproformas\fR \| for IPMS\ (P2), MTS\ (P1) and RTS are shown in
  1299. Annexes\ B, C and D. These \fIproformas\fR specify the information to be 
  1300. supplied by an implementor concerning: 
  1301. .LP
  1302.     \(em
  1303.     the services that are supported for origination,
  1304. reception and relay functions;
  1305. .LP
  1306.     \(em
  1307.     the protocol features that have been implemented in
  1308. order to support the services.
  1309. .PP
  1310. The IPMS (P2) PICS explicitly includes the MTS (P1) service
  1311. elements made available by the IPMS (P2). In order to avoid duplication with
  1312. the MTS (P1) test suite, tests for such MTS (P1) service elements are not
  1313. contained in the IPMS (P2) test suite. Where the testing of MTS (P1) is not
  1314. performed using a UA, MTS (P1) tests may need to be repeated using a UA in
  1315. order to ensure conformance to the IPMS (P2).
  1316. .sp 1P
  1317. .LP
  1318. 10.2
  1319.     \fIProtocol implementation extra information for testing (PIXIT)\fR 
  1320. .sp 9p
  1321. .RT
  1322. .PP
  1323. The Protocol Implementation extra Information for Testing (PIXIT) is supplied 
  1324. by an implementor specifying information needed by a 
  1325. tester to execute a test suite.
  1326. .PP
  1327. The IPMS\ (P2), MTS\ (P1) and RTS test suites define the behaviour of
  1328. the implementation in terms of abstract service primitives. In order to 
  1329. invoke and observe this behaviour during test execution the test operator 
  1330. must know 
  1331. how (if at all) these abstract service primitives can be invoked or observed 
  1332. at the real accessible user interface. 
  1333. .PP
  1334. The IPMS\ (P2), MTS\ (P1) and RTS PIXIT \fIproformas\fR will list all the
  1335. IUT upper layer abstract service primitives used in the test definitions and
  1336. will ask the implementor to specify how these primitives can be invoked or
  1337. observed (if at all).
  1338. .RT
  1339. .sp 2P
  1340. .LP
  1341. \fB11\fR     \fBTest notation\fR 
  1342. .sp 1P
  1343. .RT
  1344. .sp 1P
  1345. .LP
  1346. 11.1
  1347.     \fIDefinitions\fR 
  1348. .sp 9p
  1349. .RT
  1350. .PP
  1351. The notation used to define the MHS test specifications makes use of the 
  1352. following definitions: 
  1353. .RT
  1354. .LP
  1355.     a)
  1356.     \fBtest suite\fR 
  1357. .LP
  1358.     A set of test cases, possibly combined into nested test
  1359. groups, necessary to perform conformance testing of an implementation.
  1360. .LP
  1361.     The test suites do not imply an order of execution.
  1362. .LP
  1363.     b)
  1364.     \fBtest group\fR 
  1365. .LP
  1366.      A set of related test cases. Test groups may be nested to provide a logical 
  1367. structuring of test cases. 
  1368. .LP
  1369.     c)
  1370.     \fBtest case\fR 
  1371. .LP
  1372.      Specifies the sequences of test events required to achieve the purpose 
  1373. of the test and to assign a verdict \*Qpass\*U, \*Qfail\*U or 
  1374. \*Qinconclusive\*U.
  1375. .LP
  1376.     d)
  1377.     \fBtest event\fR 
  1378. .LP
  1379.      An indivisible unit of test specification at the level of abstraction 
  1380. of the specification (e.g.\ sending or receiving a single PDU). 
  1381. .LP
  1382.     e)
  1383.     \fBuser\fR 
  1384. .LP
  1385.     A user\(hyinterface process or a computer application which
  1386. makes use of an MHS.
  1387. .bp
  1388. .sp 1P
  1389. .LP
  1390. 11.2
  1391.     \fINotation\fR 
  1392. .sp 9p
  1393. .RT
  1394. .PP
  1395. The Conformance Test Suites for Message Handling Systems use the
  1396. Tree and Tabular Combined Notation as described in Annexe\ A of this
  1397. Recommendation.
  1398. .PP
  1399. Each test suite specification is defined in six sections:
  1400. .RT
  1401. .LP
  1402.     1)
  1403.     \fIIntroduction\fR 
  1404. .LP
  1405.      This contains an overview describing the scope of the tests and the structure 
  1406. of the test suite. 
  1407. .LP
  1408.     2)
  1409.     \fISummary of test cases\fR 
  1410. .LP
  1411.      This is a list of all tests giving the test identifier, the test reference 
  1412. and a short title for each test case in the test suite. 
  1413. .LP
  1414.     3)
  1415.     \fIDeclarations part\fR 
  1416. .LP
  1417.     Declares the names and types of all items to be used in
  1418. defining the test cases.
  1419. .LP
  1420.     4)
  1421.     \fIDynamic part\fR 
  1422. .LP
  1423.     This is the main body of the test suite and defines test
  1424. cases in terms of trees of behaviour.
  1425. .LP
  1426.     5)
  1427.     \fIConstraints part\fR 
  1428. .LP
  1429.     Specifies the values of the ASPs and PDUs used in the
  1430. dynamic part.
  1431. .LP
  1432.     6)
  1433.     \fICross references\fR 
  1434. .LP
  1435.     Provides an index to all values used in the main body of the test suite.
  1436. .sp 2P
  1437. .LP
  1438. \fB12\fR     \fBConformance assessment procedures\fR \| (see Figure 7/X.403)
  1439. .sp 1P
  1440. .RT
  1441. .PP
  1442. This Recommendation deals only with abstract test specifications
  1443. for Message Handling Systems. It does not deal with the realization of these
  1444. test specifications nor with their execution.  This clause\fR in the
  1445. Recommendation is purely for information purposes to\fR describe in general 
  1446. terms how real testing may be done. 
  1447. .RT
  1448. .sp 1P
  1449. .LP
  1450. 12.1
  1451.     \fIOverview of the procedure\fR 
  1452. .sp 9p
  1453. .RT
  1454. .PP
  1455. The procedures needed to assess the conformance of an
  1456. implementation include:
  1457. .RT
  1458. .LP
  1459.     \(em
  1460.     the completion of the PICS and PIXIT proformas by the
  1461. supplier of the implementation;
  1462. .LP
  1463.     \(em
  1464.     the assessment of these documents;
  1465. .LP
  1466.     \(em
  1467.     the selection and execution of test cases;
  1468. .LP
  1469.     \(em
  1470.     the analysis of the results and the production of test
  1471. reports.
  1472. .sp 1P
  1473. .LP
  1474. 12.2
  1475.     \fIAnalysis of PICS\fR 
  1476. .sp 9p
  1477. .RT
  1478. .PP
  1479. The first phase in conformance assessment is to ensure that the
  1480. features claimed to be supported by an IUT comply with appropriate conformance 
  1481. requirements. The conformance requirements for IPMS\ (P2), MTS\ (P1) and 
  1482. RTS 
  1483. implementations are defined in \(sc\ 7 of this document. This check is 
  1484. performed by analysing the information in the PICS documents. 
  1485. .RT
  1486. .sp 1P
  1487. .LP
  1488. 12.3
  1489.     \fITest case selection\fR 
  1490. .sp 9p
  1491. .RT
  1492. .PP
  1493. The tests to be performed are selected primarily on the basis of
  1494. information in the PICS. For every supported feature claimed in the PICS the
  1495. corresponding test cases in the test suites are selected and executed to 
  1496. check the correct implementation of these features under an extensive range 
  1497. of valid and invalid conditions. 
  1498. .PP
  1499. For non\(hysupported features, some recipient test cases shall be
  1500. executed to explore the response of the IUT. Since in general the X.400 
  1501. (1984) Series of Recommendations do not define the expected behaviour in 
  1502. these 
  1503. situations, these tests can be \*Qpassed\*U with almost any behaviour apart 
  1504. from 
  1505. catastrophic failure by the IUT.
  1506. .PP
  1507. Information in the PIXIT may also provide some constraints on the test 
  1508. cases that can be executed. 
  1509. .bp
  1510. .RT
  1511. .sp 1P
  1512. .LP
  1513. 12.4
  1514.     \fIExecution of tests\fR 
  1515. .sp 9p
  1516. .RT
  1517. .PP
  1518. It is recommended that the testing of Message Handling Systems
  1519. should be done in the order of RTS, then MTS\ (P1) and then IPMS\ (P2)
  1520. testing.
  1521. .PP
  1522. However the order of test cases in the test suites does not imply an order 
  1523. of execution. Apart from the general recommendation that for 
  1524. IPMS\ (P2)/MTS\ (P1) the Initial Test Group should be executed first, the 
  1525. order of execution of tests can be determined by the test operators taking 
  1526. into 
  1527. account their test environment and test tools.
  1528. .RT
  1529. .LP
  1530. .rs
  1531. .sp 22P
  1532. .ad r
  1533. \fBFigure 7/X.403, (N), p.\fR 
  1534. .sp 1P
  1535. .RT
  1536. .ad b
  1537. .RT
  1538. .ce 1000
  1539. ANNEX\ A
  1540. .ce 0
  1541. .ce 1000
  1542. (to Recommendation X. 403)
  1543. .sp 9p
  1544. .RT
  1545. .ce 0
  1546. .ce 1000
  1547. \fBTest notation\fR 
  1548. .sp 1P
  1549. .RT
  1550. .ce 0
  1551. .LP
  1552. A.1
  1553.     \fIIntroduction\fR 
  1554. .sp 1P
  1555. .RT
  1556. .PP
  1557. This annex is an integral part of this Recommendation and describes the 
  1558. notation used in the test suite manuals. 
  1559. .PP
  1560. The test notation described here is based on the test notation called Tree 
  1561. and Tabular Combined Notation (TTCN) that has been developed jointly by 
  1562. ISO and CCITT.
  1563. .PP
  1564. The notation described in this Recommendation is derived from an early 
  1565. form of TTCN and has been developed specifically for use in the MHS conformance 
  1566. testing specifications. 
  1567. .PP
  1568. Each of the MHS test suites is specified in five parts:
  1569. .RT
  1570. .LP
  1571.     \(em
  1572.     Declaration part;
  1573. .LP
  1574.     \(em
  1575.     Dynamic part;
  1576. .LP
  1577.     \(em
  1578.     Constraints part;
  1579. .LP
  1580.     \(em
  1581.     Test case identification;
  1582. .LP
  1583.     \(em
  1584.     Cross\(hyreferences.
  1585. .bp
  1586. .sp 1P
  1587. .LP
  1588. A.2
  1589.     \fIDeclaration part\fR 
  1590. .sp 9p
  1591. .RT
  1592. .PP
  1593. The Declaration Part declares the environment and objects used in the test 
  1594. suites and is composed of 7\ sections: 
  1595. .RT
  1596. .LP
  1597.     \(em
  1598.     Test configurations;
  1599. .LP
  1600.     \(em
  1601.     Test suite parameters (TSPs);
  1602. .LP
  1603.     \(em
  1604.     Service access points (SAPs);
  1605. .LP
  1606.     \(em
  1607.     Abstract service primitives (ASPs);
  1608. .LP
  1609.     \(em
  1610.     Protocol data units (PDUs);
  1611. .LP
  1612.     \(em
  1613.     Timers;
  1614. .LP
  1615.     \(em
  1616.     Abbreviations.
  1617. .sp 1P
  1618. .LP
  1619. A.2.1
  1620.     \fITest configurations\fR 
  1621. .sp 9p
  1622. .RT
  1623. .PP
  1624. The points of control and observation are declared in this
  1625. section.
  1626. .RT
  1627. .sp 1P
  1628. .LP
  1629. A.2.2
  1630.     \fITest suite parameters\fR 
  1631. .sp 9p
  1632. .RT
  1633. .PP
  1634. Every MHS Test Suite has a set of parameters whose values are fixed prior 
  1635. to testing and which are used to define a specific testing environment. 
  1636. .PP
  1637. TSPs are declared in tabular form as shown in Figure A\(hy1/X.403.
  1638. .RT
  1639. .LP
  1640. .rs
  1641. .sp 9P
  1642. .ad r
  1643. \fBFigure A\(hy1/X.403 (trait\*'e comme tableau) [T1.403], p.\fR 
  1644. .sp 1P
  1645. .RT
  1646. .ad b
  1647. .RT
  1648. .PP
  1649. By convention the name of each Test Suite Parameter in the MHS
  1650. test suites is of the form:
  1651. \v'6p'
  1652. .sp 1P
  1653. .ce 1000
  1654. TSP
  1655. \(ul<name>
  1656. .ce 0
  1657. .sp 1P
  1658. .LP
  1659. .sp 1
  1660. A.2.3
  1661.     \fIService access points\fR (SAPs)
  1662. .sp 9p
  1663. .RT
  1664. .PP
  1665. Service Access Points are used as points of control and observation in 
  1666. the MHS Test Suites and are declared in tabular form as shown in 
  1667. Figure\ A\(hy2/X.403.
  1668. .RT
  1669. .LP
  1670. .rs
  1671. .sp 9P
  1672. .ad r
  1673. \fBFigure A\(hy2/X.403 (trait\*'e comme tableau) [T2.403], p.\fR 
  1674. .sp 1P
  1675. .RT
  1676. .ad b
  1677. .RT
  1678. .LP
  1679. .bp
  1680. .PP
  1681. By convention the name of a SAP in the MHS Test Suites is
  1682. generally one capital letter, such as T, U, V (for tester SAPs) or I, J, 
  1683. K (for IUT SAPs). 
  1684. .sp 1P
  1685. .LP
  1686. A.2.4
  1687.     \fIAbstract service primitives\fR 
  1688. .sp 9p
  1689. .RT
  1690. .PP
  1691. Each ASP type and its associated parameters used in a test suite is declared 
  1692. in tabular form as shown in Figure\ A\(hy3/X.403. 
  1693. .RT
  1694. .LP
  1695. .rs
  1696. .sp 12P
  1697. .ad r
  1698. \fBFigure A\(hy3/X.403 (trait\*'e comme tableau) [T3.403], p.\fR 
  1699. .sp 1P
  1700. .RT
  1701. .ad b
  1702. .RT
  1703. .PP
  1704. The name of the ASP is specified in the \*QASP\*U field and is derived 
  1705. from the corresponding name in the X.400\(hyseries of Recommendations. 
  1706. The SAP at which the ASP occurs is specified in the \*QSAP\*U field. The 
  1707. parameters of the 
  1708. ASP are declared in the \*QNAME\*U column together with information in 
  1709. \*QRANGE OF 
  1710. VALUES OR TYPE\*U, \*QCOMMENTS\*U and \*QConditional/Mandatory\*U columns.
  1711. .PP
  1712. Since there are no IPMS\ (P2) ASPs defined in the Recommendations, in order 
  1713. to describe conformance tests it has been necessary to construct 
  1714. hypothetical ASPs at the upper boundary of the User Agent Layer. This does 
  1715. not imply, however that manufacturers are required to implement these ASPs 
  1716. within their systems. It serves only to formalize the requirements for 
  1717. observation 
  1718. and invocation of IPMS service elements by the use of these new ASPs. The
  1719. relation between IPMS service elements and the actual behaviour of the 
  1720. IUT has to be specified in the implementation\(hydependent PIXIT. 
  1721. .RT
  1722. .sp 1P
  1723. .LP
  1724. A.2.5
  1725.     \fIProtocol data units\fR 
  1726. .sp 9p
  1727. .RT
  1728. .PP
  1729. The PDU types used in test suites are declared in the form of
  1730. tables as shown in Figure\ A\(hy4/X.403. These PDUs are not defined explicitly 
  1731. in the test suite, but are given a precise reference to the full definition 
  1732. in the X.400 Recommendations, in the type name section of the table. 
  1733. .RT
  1734. .LP
  1735. .rs
  1736. .sp 9P
  1737. .ad r
  1738. \fBFigure A\(hy4/X.403 (trait\*'e comme tableau) [T4.403], p.\fR 
  1739. .sp 1P
  1740. .RT
  1741. .ad b
  1742. .RT
  1743. .LP
  1744. .bp
  1745. .sp 1P
  1746. .LP
  1747. A.2.6
  1748.     \fITimers\fR 
  1749. .sp 9p
  1750. .RT
  1751. .PP
  1752. This section declares the timers to be used. Timer values are
  1753. expressions in terms of Test Suite Parameters, and are fixed for the whole 
  1754. test suite. Timer values are declared in tabular form as shown in 
  1755. Figure\ A\(hy5/X.403.
  1756. .RT
  1757. .LP
  1758. .rs
  1759. .sp 9P
  1760. .ad r
  1761. \fBFigure A\(hy5/X.403 (trait\*'e comme tableau) [T5.403], p.\fR 
  1762. .sp 1P
  1763. .RT
  1764. .ad b
  1765. .RT
  1766. .LP
  1767. .sp 3
  1768. .sp 1P
  1769. .LP
  1770. A.2.7
  1771.     \fIAbbreviations\fR 
  1772. .sp 9p
  1773. .RT
  1774. .PP
  1775. Abbreviations used in the Test Suite are defined in the form of a table 
  1776. as shown in Figure\ A\(hy6/X.403. 
  1777. .RT
  1778. .LP
  1779. .rs
  1780. .sp 9P
  1781. .ad r
  1782. \fBFigure A\(hy6/X.403 (trait\*'e comme tableau) [T6.403], p.\fR 
  1783. .sp 1P
  1784. .RT
  1785. .ad b
  1786. .RT
  1787. .LP
  1788. .sp 3
  1789. .sp 1P
  1790. .LP
  1791. A.3
  1792.     \fIDynamic part\fR 
  1793. .sp 9p
  1794. .RT
  1795. .PP
  1796. The Dynamic Part defines the test cases of a test suite in terms of trees 
  1797. of behaviour. 
  1798. .PP
  1799. Sections A.3.1 and A.3.2 describe generally how trees of behaviour are defined.
  1800. .PP
  1801. Section A.3.3 describes the content and use of Defaults Library.
  1802. .PP
  1803. Section A.3.4 describes the content and use of Test Step Library.
  1804. .PP
  1805. Section A.3.5 describes how each test case in the main body of a test suite 
  1806. is specified. 
  1807. .bp
  1808. .RT
  1809. .sp 1P
  1810. .LP
  1811. A.3.1
  1812.     \fIProforma table for test behaviours\fR (see Figure A\(hy7/X.403)
  1813. .sp 9p
  1814. .RT
  1815. .LP
  1816. .rs
  1817. .sp 18P
  1818. .ad r
  1819. \fBFigure A\(hy7/X.403 (trait\*'e comme tableau) [T7.403], p.\fR 
  1820. .sp 1P
  1821. .RT
  1822. .ad b
  1823. .RT
  1824. .sp 1P
  1825. .LP
  1826.     <title> BEHAVIOUR
  1827. .sp 9p
  1828. .RT
  1829. .PP
  1830. Title of the behaviour: DEFAULT for the Default Library; DYNAMIC
  1831. for the Test Step Library and test cases.
  1832. .RT
  1833. .sp 1P
  1834. .LP
  1835.     IDENTIFIER
  1836. .sp 9p
  1837. .RT
  1838. .PP
  1839. This provides a unique identifier for the behaviour
  1840. description.
  1841. .RT
  1842. .sp 1P
  1843. .LP
  1844.     DEFAULTS
  1845. .sp 9p
  1846. .RT
  1847. .PP
  1848. This lists the identifiers of default behaviour descriptions which are 
  1849. to be used in conjunction with the Dynamic behaviour shown in the 
  1850. \*QBEHAVIOUR DESCRIPTION\*U part.
  1851. .RT
  1852. .sp 1P
  1853. .LP
  1854.     BEHAVIOUR DESCRIPTION
  1855. .sp 9p
  1856. .RT
  1857. .PP
  1858. Test behaviour is defined using a tree notation as described in
  1859. A.3.2.
  1860. .RT
  1861. .sp 1P
  1862. .LP
  1863.     LABEL
  1864. .sp 9p
  1865. .RT
  1866. .PP
  1867. The LABELS column may be used to identify events. Branches between events 
  1868. (i.e.\ \*QGO TO\*U) are specified by \*Q\(raLabel\*U in the behaviour tree. 
  1869. .RT
  1870. .sp 1P
  1871. .LP
  1872.     CONSTRAINTS REFERENCE
  1873. .sp 9p
  1874. .RT
  1875. .PP
  1876. For each ASP event of a behaviour tree line, this column gives the reference 
  1877. to the specific ASP value defined in the Constraints Part. 
  1878. .bp
  1879. .RT
  1880. .sp 1P
  1881. .LP
  1882.     COMMENTS
  1883. .sp 9p
  1884. .RT
  1885. .PP
  1886. This column provides comments which ease understanding of the
  1887. events. Additional comments may be given in the \*QExtended Comments\*U 
  1888. area. This column can also be used to identify test PDUs associated with 
  1889. test events. 
  1890. .RT
  1891. .sp 1P
  1892. .LP
  1893.     RESULT
  1894. .sp 9p
  1895. .RT
  1896. .PP
  1897. This column indicates which test events generate test verdicts.
  1898. Values of test verdicts are:
  1899. .RT
  1900. .LP
  1901.     \(em
  1902.     pass:\ no misbehaviour of the IUT is detected;
  1903. .LP
  1904.     \(em
  1905.     fail:\ misbehaviour of the IUT is detected;
  1906. .LP
  1907.     \(em
  1908.     inconclusive:\ the observed behaviour does not allow the
  1909. assignment of a pass or fail verdict.
  1910. .sp 1P
  1911. .LP
  1912. A.3.2
  1913.     \fITree notation for test behaviours\fR 
  1914. .sp 9p
  1915. .RT
  1916. .PP
  1917. Trees of behaviour are defined in terms of events which are
  1918. generally of the form:
  1919. .RT
  1920. .LP
  1921.     <SAP>!<event>
  1922. .LP
  1923. or of the form
  1924. .LP
  1925.     <SAP>?<event>
  1926. .PP
  1927. The <SAP> is the point of control and observation at which the
  1928. <event> occurs. The SAPs used are those declared in the Declaration Part.
  1929. .PP
  1930. The \*Q!\*U symbol indicates that the event is sent from the SAP and \*Q?\*U 
  1931. indicates that the event is received at the SAP. 
  1932. .PP
  1933. The <event> can be:
  1934. .RT
  1935. .LP
  1936.     \(em
  1937.     an ASP event;
  1938. .LP
  1939.     \(em
  1940.     a timer event;
  1941. .LP
  1942.     \(em
  1943.     an OTHERWISE pseudo\(hyevent.
  1944. .sp 1P
  1945. .LP
  1946. A.3.2.1
  1947.     \fISingle ASP events\fR 
  1948. .sp 9p
  1949. .RT
  1950. .PP
  1951. If the <event> is an ASP event then the names for the ASPs are
  1952. those specified in the Declaration Part (the value is specified as a reference 
  1953. in the CONSTRAINTS REFERENCE column). 
  1954. .PP
  1955. \fIExample line for an ASP event\fR :
  1956. .PP
  1957. I?DELind
  1958. .PP
  1959. This means that a Deliver Indication is received
  1960. at the IUT's SAP\ I.
  1961. .RT
  1962. .sp 1P
  1963. .LP
  1964. A.3.2.2
  1965.     \fISingle timer events\fR 
  1966. .sp 9p
  1967. .RT
  1968. .PP
  1969. If <event> is a timer event then it is of the form:
  1970. \v'6p'
  1971. .RT
  1972. .sp 1P
  1973. .ce 1000
  1974. <operation> <parameters>
  1975. .ce 0
  1976. .sp 1P
  1977. .LP
  1978. .sp 1
  1979. .PP
  1980. The \*Qstart\*U operation can take one of two forms:
  1981. .LP
  1982.     Start <timer type>
  1983. .LP
  1984.     Start (<timer type>, <timer id>)
  1985. .LP
  1986. Where <timer type> is defined in the Declaration Part and has a fixed value
  1987. associated with it defined in terms of TSPs. The <timer id> allows a name 
  1988. to be attached to an instance of a timer type. 
  1989. .bp
  1990. .PP
  1991. The other operations are:
  1992. .LP
  1993.     \(em
  1994.     Cancel:\ cancels a running or suspended timer;
  1995. .LP
  1996.     \(em
  1997.     Suspend:\ suspends a running timer;
  1998. .LP
  1999.     \(em
  2000.     Resume:\ resumes a suspended timer;
  2001. .LP
  2002.     \(em
  2003.     Timeout:\ expiration of a running timer;
  2004. .PP
  2005. These operations take one of two forms:
  2006. .LP
  2007.     <operation> <timer type>
  2008. .LP
  2009.     <operation> <timer id>
  2010. .LP
  2011. where <operation> denotes the operation. When the timer was started using 
  2012. the form \*QStart <timer type>\*U, the form \*Q<operation> <timer type> 
  2013. must be used; 
  2014. when the timer was started using the form \*QStart <timer id>\*U, the form
  2015. \*Q<operation> <timer id>\*U must be used.
  2016. .LP
  2017.     \fIExample\fR :
  2018. .LP
  2019.     I!Start T/I\(hytimer
  2020. \(ul1
  2021. .LP
  2022.     means that at the IUT's SAP I the T/I\(hytimer
  2023. \(ul1 (e.g. for a
  2024. transmission time for a UAPDU to be transferred from the tester to the IUT's
  2025. user) is started.
  2026. .LP
  2027.     I?Timeout T/I\(hytimer
  2028. \(ul1
  2029. .LP
  2030.     means that at the IUT's SAP I the timeout of the above timer is
  2031. received.
  2032. .sp 1P
  2033. .LP
  2034. A.3.2.3
  2035.     \fISingle OTHERWISE events\fR 
  2036. .sp 9p
  2037. .RT
  2038. .PP
  2039. If <event> is the OTHERWISE pseudo\(hyevent, this indicates an
  2040. unspecified event.
  2041. .PP
  2042. Example:
  2043. .RT
  2044. .LP
  2045.     T?OTHERWISE
  2046. .LP
  2047.     Means that at the tester's SAP T an unspecified event is
  2048. received.
  2049. .sp 1P
  2050. .LP
  2051. A.3.2.4
  2052.     \fITrees of behaviour\fR 
  2053. .sp 9p
  2054. .RT
  2055. .PP
  2056. Trees of behaviour combine events in two ways:
  2057. .RT
  2058. .LP
  2059.     \(em
  2060.     as sequences of events
  2061. .LP
  2062.     \(em
  2063.     as alternative events
  2064. .PP
  2065. The two combination kinds are distinguished by indented and
  2066. vertical alignment respectively.
  2067. .PP
  2068. \fIExample of a sequence of events:\fR 
  2069. .RT
  2070. .LP
  2071.     I!SUBreq
  2072. .LP
  2073. I
  2074. I?SUBcon
  2075. .LP
  2076. I!
  2077. T?TRNind
  2078. .LP
  2079.      This means that first at the SAP I a Submission Request is sent, then 
  2080. at the same SAP a Submission Confirmation is received, after which a 
  2081. Transfer Indication is received at the tester's SAP\ T.
  2082. .LP
  2083.     \fIExample of alternative events:\fR 
  2084. .LP
  2085.     T?DELind
  2086. .LP
  2087. T?Timeout I/T\(hytimer
  2088. .LP
  2089.     This means that at SAP T either a Deliver Indication
  2090. is received or alternatively the timeout is received there.
  2091. .PP
  2092. To build up a complex behaviour tree, the two kinds of combination can 
  2093. be mixed. 
  2094. .PP
  2095. \fIExample:\fR 
  2096. .RT
  2097. .LP
  2098.     I!SUBreq
  2099. .LP
  2100.     I
  2101. I?SUBcon 
  2102.     ?04
  2103. .LP
  2104.     
  2105.     ?05\ alternative events
  2106. .LP
  2107.     I!
  2108. T?TRNind
  2109.     \(rb
  2110. .LP
  2111.     T?DISind
  2112. .LP
  2113.      This means that after sending a Submission Request at I, either a Submission 
  2114. Confirmation is received at I, followed by the receipt of a Transfer Indication 
  2115. at T, or a Disconnect Indication is received at T. 
  2116. .bp
  2117. .sp 1P
  2118. .LP
  2119. A.3.3
  2120.     \fIDefaults library\fR 
  2121. .sp 9p
  2122. .RT
  2123. .PP
  2124. General default behaviours which are used by several test cases are defined 
  2125. in the Defaults Library using the format shown in Figure\ A\(hy8/X.403. 
  2126. The name of the default is of the form:
  2127. .RT
  2128. .LP
  2129.     LIB
  2130. \(ul<name>
  2131. .LP
  2132. or
  2133. .LP
  2134.     LIB
  2135. \(ul<name> [X]
  2136. .LP
  2137. where X is a place holder which is replaced by an actual SAP when applying 
  2138. the default element in a particular Test Case. 
  2139. .PP
  2140. \fINote\fR \ \(em\ Where particular default behaviour applies to a single
  2141. test case only the behaviour table is associated with that test case and the
  2142. identifier is not prefixed with \*QLIB
  2143. \(ul\*U.
  2144. .LP
  2145. .rs
  2146. .sp 18P
  2147. .ad r
  2148. \fBFigure A\(hy8/X.403 (trait\*'e comme tableau) [T8.403], p.\fR 
  2149. .sp 1P
  2150. .RT
  2151. .ad b
  2152. .RT
  2153. .sp 1P
  2154. .LP
  2155. A.3.4
  2156.     \fITest step library\fR \| (see Figure
  2157. A\(hy9/X.403)
  2158. .sp 9p
  2159. .RT
  2160. .PP
  2161. Where a sequence of test steps is of use in several test cases they can 
  2162. be included in the Test Step Library and given a name of the form: 
  2163. .RT
  2164. .LP
  2165.     LIB
  2166. \(ul<name>
  2167. .PP
  2168. \fINote\fR \ \(em\ Where a test step applies to a single test case the
  2169. behaviour table is associated with that test case and the identifier is not
  2170. prefixed with \*QLIB
  2171. \(ul\*U.
  2172. .sp 1P
  2173. .LP
  2174. A.3.5
  2175.     \fITest case\fR \|\fR (see Figure A\(hy10/X.403)
  2176. .sp 9p
  2177. .RT
  2178. .PP
  2179. Each test case in the main body of the test suite is described in terms 
  2180. of three headings\ a)\(hyc), and a behaviour tree d): 
  2181. .RT
  2182. .LP
  2183.     a)
  2184.     \fITest reference and test identifier\fR 
  2185. .LP
  2186.     These elements give a unique reference and identifier for
  2187. each test case and are described fully in \(sc\ A.5.
  2188. .LP
  2189.     b)
  2190.     \fISummary\fR 
  2191. .LP
  2192.     A brief overview of the purpose of the test is provided.
  2193. .LP
  2194.     c)
  2195.     \fITest description\fR \| (optional)
  2196. .LP
  2197.     This provides an informal description of the actions and
  2198. events that should take place during the test and an informal verdict
  2199. criteria.
  2200. .LP
  2201.     d)
  2202.     \fIBehaviour tree\fR 
  2203. .LP
  2204.     Dynamic behaviour is described using the tree notation
  2205. defined in \(sc\ A.3.2.
  2206. .bp
  2207. .LP
  2208. .rs
  2209. .sp 18P
  2210. .ad r
  2211. \fBFigure A\(hy9/X.403 (trait\*'e comme tableau) [T9.403], p.\fR 
  2212. .sp 1P
  2213. .RT
  2214. .ad b
  2215. .RT
  2216. .LP
  2217. .sp 2
  2218. .rs
  2219. .sp 25P
  2220. .ad r
  2221. \fBFigure A\(hy10/X.403 (trait\*'e comme tableau) [T10.403], p.\fR 
  2222. .sp 1P
  2223. .RT
  2224. .ad b
  2225. .RT
  2226. .LP
  2227. .bp
  2228. .sp 1P
  2229. .LP
  2230. A.4
  2231.     \fIConstraints part\fR \|(see Figure A\(hy11/X.403)
  2232. .sp 9p
  2233. .RT
  2234. .PP
  2235. The Constraints Part of a Test Suite specifies the values and their encoding 
  2236. of all instances of ASPs, Test PDUs, Base PDUs and Library Components. 
  2237. The Constraints Parts is divided into the following sections: 
  2238. .RT
  2239. .LP
  2240.     \(em
  2241.     Introduction to Constraints Part;
  2242. .LP
  2243.     \(em
  2244.     ASP Constraints;
  2245. .LP
  2246.     \(em
  2247.     Test PDU Constraints;
  2248. .LP
  2249.     \(em
  2250.     Base PDU Constraints;
  2251. .LP
  2252.     \(em
  2253.     Components Library.
  2254. .LP
  2255. .rs
  2256. .sp 21P
  2257. .ad r
  2258. \fBFigure A\(hy11/X.403, (N), p.\fR 
  2259. .sp 1P
  2260. .RT
  2261. .ad b
  2262. .RT
  2263. .sp 1P
  2264. .LP
  2265. A.4.1
  2266.     \fIASP constraints\fR 
  2267. .sp 9p
  2268. .RT
  2269. .PP
  2270. Values of ASPs are defined as specific instances of a generic
  2271. ASP.
  2272. .RT
  2273. .sp 1P
  2274. .LP
  2275. A.4.1.1
  2276.     \fISpecification of a \fR \fI\*QGeneric\*U ASP\fR 
  2277. .sp 9p
  2278. .RT
  2279. .PP
  2280. A generic ASP is defined using the format shown in
  2281. Figure A\(hy12/X.403.
  2282. .RT
  2283. .PP
  2284. The \*QFIELDS\*U column is used to list all the parameters of the
  2285. ASP.
  2286. .PP
  2287. The \*QVALUE or REFERENCE\*U column is used to specify
  2288. a value for each
  2289. parameter and this can be done in four ways:
  2290. .RT
  2291. .LP
  2292.     a)
  2293.     as a reference which can be a TSP name or a library
  2294. component name;
  2295. .LP
  2296.     b)
  2297.     as an explicit value;
  2298. .LP
  2299.     c)
  2300.     as \*Q\(hy\*U to indicate that this parameter may be omitted in
  2301. specific instances of this ASP;
  2302. .LP
  2303.     d)
  2304.      as \*Q?\*U to indicate that for \*Qrequest\*U ASP's this parameter must 
  2305. have a value defined in a specific instance if it is a component of 
  2306. interest.
  2307. .bp
  2308. .LP
  2309. .rs
  2310. .sp 13P
  2311. .ad r
  2312. \fBFigure A\(hy12/X.403 (trait\*'e comme tableau) [T11.403], p.\fR 
  2313. .sp 1P
  2314. .RT
  2315. .ad b
  2316. .RT
  2317. .sp 1P
  2318. .LP
  2319. A.4.1.2
  2320.     \fISpecification of \fR \fIASP instances\fR 
  2321. .sp 9p
  2322. .RT
  2323. .PP
  2324. Specific values of ASPs are defined using the tabular format shown in Figure\ 
  2325. A\(hy13/X.403. 
  2326. .RT
  2327. .LP
  2328. .rs
  2329. .sp 15P
  2330. .ad r
  2331. \fBFigure A\(hy13/X.403 (trait\*'e comme tableau) [T12.403], p.\fR 
  2332. .sp 1P
  2333. .RT
  2334. .ad b
  2335. .RT
  2336. .PP
  2337. The \*QINSTANCE NAME\*U column is used to identify specific instances of 
  2338. the ASP used in the test suite. 
  2339. .PP
  2340. The \*QMODIFIED PARAMETER\*U column identifies, for \*Qrequest\*U ASP's 
  2341. those parameters whose values are to be modified from the generic ASP specification, 
  2342. and for \*Qnotification\*U ASP's those parameters whose values are to be 
  2343. checked. 
  2344. .PP
  2345. The \*QVALUE or REFERENCE\*U column can contain either specific values 
  2346. or references to library components ASPs or test PDUs. 
  2347. .RT
  2348. .sp 1P
  2349. .LP
  2350. A.4.2
  2351.     \fISpecifying PDU values\fR 
  2352. .sp 9p
  2353. .RT
  2354. .PP
  2355. The MHS test suite contains a large number of test PDU values. Each PDU 
  2356. is defined in terms of modifications to one of the small number of \*Qbase\*U 
  2357. PDUs. 
  2358. .PP
  2359. For convenience commonly used PDU components are defined in a library and 
  2360. are referenced by test PDUs and base PDUs. 
  2361. .bp
  2362. .RT
  2363. .sp 2P
  2364. .LP
  2365. A.4.3
  2366.     \fIBase PDUs\fR 
  2367. .sp 1P
  2368. .RT
  2369. .sp 1P
  2370. .LP
  2371. A.4.3.1
  2372.     \fIBase PDU specification\fR 
  2373. .sp 9p
  2374. .RT
  2375. .PP
  2376. Base PDUs are not themselves used as test PDUs but they serve as a basis 
  2377. from which to derive the test PDUs. Usually only a few Base PDUs need to 
  2378. be specified. 
  2379. .PP
  2380. The name of a Base PDU is of the form:
  2381. .PP
  2382. BASE
  2383. \(ul<PDUtypename>
  2384. \(ul<number>
  2385. .PP
  2386. \fIExample of a Base PDU\fR :
  2387. .RT
  2388. .ce
  2389. \fBH.T. [T13.403]\fR 
  2390. .ps 9
  2391. .vs 11
  2392. .nr VS 11
  2393. .nr PS 9
  2394. .TS
  2395. center box;
  2396. lw(84p) | lw(84p) | lw(60p) .
  2397. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  2398. _
  2399. .T&
  2400. lw(48p) .
  2401. BASE \(ulIM\(hyUAPDU \(ul1 
  2402. _
  2403. .T&
  2404. lw(84p) | lw(84p) | lw(60p) .
  2405. SEQUENCE {        
  2406. .T&
  2407. lw(84p) | lw(84p) | lw(60p) .
  2408. Heading    T{
  2409. [BASE
  2410. \(ulIM
  2411. \(ulUAPDU
  2412. \(ul1
  2413. \(ulHeading]
  2414. T}    
  2415. .T&
  2416. lw(84p) | lw(84p) | lw(60p) .
  2417. Body    T{
  2418. [BASE
  2419. \(ulIM\(hyUAPDU
  2420. \(ul1
  2421. \(ulBody]
  2422. T}    
  2423. .T&
  2424. lw(84p) | lw(84p) | lw(60p) .
  2425. }         
  2426. .T&
  2427. lw(84p) | lw(84p) | lw(60p) .
  2428. T{
  2429. BASE
  2430. \(ulIM\(hyUAPDU
  2431. \(ul1
  2432. \(ulHeading 
  2433. T}        
  2434. .T&
  2435. lw(84p) | lw(84p) | lw(60p) .
  2436. SET {         
  2437. .T&
  2438. lw(84p) | lw(84p) | lw(60p) .
  2439. IPMessageID    [L \(ulIPMessageID \(ul20]     
  2440. .T&
  2441. lw(84p) | lw(84p) | lw(60p) .
  2442. }         
  2443. .T&
  2444. lw(84p) | lw(84p) | lw(60p) .
  2445. T{
  2446. BASE
  2447. \(ulIM\(hyUAPDU
  2448. \(ul1
  2449. \(ulBody
  2450. T}        
  2451. .T&
  2452. lw(84p) | lw(84p) | lw(60p) .
  2453. SEQUENCE OF {        
  2454. .T&
  2455. lw(84p) | lw(84p) | lw(60p) .
  2456. BodyPart    [L \(ulBodyPart \(ul20]    
  2457. .T&
  2458. lw(84p) | lw(84p) | lw(60p) .
  2459. }         
  2460. _
  2461. .TE
  2462. .nr PS 9
  2463. .RT
  2464. .ad r
  2465. \fBTableau [T13.403], p.\fR 
  2466. .sp 1P
  2467. .RT
  2468. .ad b
  2469. .RT
  2470. .PP
  2471. The value or value reference of each element of the structure is specified 
  2472. within square brackets (\*U[\*U and \*Q]\*U) under the VALUE or REFERENCE 
  2473. heading.
  2474. .PP
  2475. When specifying the encoding of a PDU for encoding/decoding tests,two additional 
  2476. columns are used to specify the ID Code\ [ID] and Length 
  2477. Indicator\ [LI] of each element of the PDU. The format for doing this is 
  2478. shown in the example below. 
  2479. .RT
  2480. .ce
  2481. \fBH.T. [T14.403]\fR 
  2482. .ps 9
  2483. .vs 11
  2484. .nr VS 11
  2485. .nr PS 9
  2486. .TS
  2487. center box;
  2488. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2489. DESCRIPTION    ID    LI    VALUE or REF    COMMENT
  2490. _
  2491. .T&
  2492. lw(36p) .
  2493. L \(ulPhantasy \(ul2 
  2494. _
  2495. .T&
  2496. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2497. SEQUENCE {    [`AO`H]    [LI]        IA5Text
  2498. .T&
  2499. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2500. SET {    [`31`H]    [LI]         
  2501. .T&
  2502. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2503. repertoire INTEGER    [`80`H]    [LI]    [5]    ia5 
  2504. .T&
  2505. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2506. }                 
  2507. .T&
  2508. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2509. IA5String    [`36`H]    [`8106`H]        constructor 
  2510. .T&
  2511. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2512.     [`04`H]    [`01`H]    [\*Q1\*U]     
  2513. .T&
  2514. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2515.     [`04`H]    [`02`H]    [\*Q23\*U]    
  2516. .T&
  2517. lw(96p) | lw(30p) | lw(30p) | lw(30p) | lw(42p) .
  2518. }                 
  2519. _
  2520. .TE
  2521. .nr PS 9
  2522. .RT
  2523. .ad r
  2524. \fBTableau [T14.403], p.\fR 
  2525. .sp 1P
  2526. .RT
  2527. .ad b
  2528. .RT
  2529. .LP
  2530. .bp
  2531. .PP
  2532. The values of ID and LI can be specified explicitly to allow
  2533. invalid and various forms of valid codings to be defined. The mnemonic 
  2534. \*QLI\*U is used to indicate that any valid encoding of length is allowed. 
  2535. .sp 1P
  2536. .LP
  2537. A.4.3.2
  2538.     \fIIdentifying the components to be modified\fR 
  2539. .sp 9p
  2540. .RT
  2541. .PP
  2542. A component which is to be replaced in a PDU is identified by a
  2543. path through the declaration of the PDU. The path is written as a list of
  2544. elements, each separated from the next by a \*Q.\*U. The elements in the 
  2545. list can be labels which appear in a BASE PDU, components which appear 
  2546. in the left\(hyhand side of a labeled declaration, or components which 
  2547. appear in the left\(hyhand side of the expansion of a library reference 
  2548. in the right\(hyhand side of a 
  2549. declaration.
  2550. .PP
  2551. For example, consider the following definitions:
  2552. .RT
  2553. .LP
  2554.     Instance
  2555. \(ul
  2556. .LP
  2557. \ \ \ SET{
  2558. .LP
  2559. \ \ \ \ \ \ a
  2560.     [value]
  2561. .LP
  2562.     \ \ \ \ \ \ b
  2563.     [L
  2564. \(ulComponent
  2565. \(ul1]
  2566. .LP
  2567.     \ \ \ }
  2568. .LP
  2569.     L
  2570. \(ulComponent
  2571. \(ul1
  2572. .LP
  2573. \ \ \ SET{
  2574. .LP
  2575. \ \ \ \ \ \ c
  2576.     [value]
  2577. .LP
  2578.     \ \ \ \ \ \ d
  2579.     [L
  2580. \(ulComponent
  2581. \(ul2]
  2582. .LP
  2583.     \ \ \ }
  2584. .LP
  2585.     L
  2586. \(ulComponent
  2587. \(ul2
  2588. .LP
  2589. \ \ \ SEQUENCE
  2590. .LP
  2591. \ \ \ \ \ \ e
  2592.     [value]
  2593. .LP
  2594.     \ \ \ }
  2595. .PP
  2596. \fINote\fR \ \(em\ L
  2597. \(ulComponent
  2598. \(ul1 is in the Component Library.
  2599. .LP
  2600. In order to reference \*Qa\*U, the path would be instance
  2601. \(ul1.a.
  2602. .LP
  2603. In order to reference \*Qe\*U, the path would be instance
  2604. \(ul1.b.d.e.
  2605. .sp 1P
  2606. .LP
  2607. A.4.4
  2608.     \fITest PDUs\fR 
  2609. .sp 9p
  2610. .RT
  2611. .PP
  2612. Test PDUs are defined in terms of operations on Base PDU's. These operations 
  2613. refer to Library Components, TSPs or specific values. 
  2614. .PP
  2615. There are two kinds of test PDU:
  2616. .RT
  2617. .LP
  2618.     \(em
  2619.     PDUs sent by the tester (IUT as recipient)
  2620. .LP
  2621.     By convention the names of these PDUs are of the form
  2622. .sp 1P
  2623. .ce 1000
  2624. <PDU name>
  2625. \(ulx
  2626. \(ul<number>
  2627. .ce 0
  2628. .sp 1P
  2629. .LP
  2630.     where x is the number of the base PDU from which the test PDU is derived.
  2631. .LP
  2632.     \(em
  2633.     PDUs received by the tester (IUT as originator)
  2634. .LP
  2635.     By convention the names of these PDUs are of the form
  2636. .sp 1P
  2637. .ce 1000
  2638. <PDU name>
  2639. \(ul0<number>
  2640. .ce 0
  2641. .sp 1P
  2642. .LP
  2643.     where \*Q0\*U indicates that these test PDUs are not derived from a base PDU.
  2644. .sp 1P
  2645. .LP
  2646. A.4.4.1
  2647.     \fITest PDUs sent by the tester\fR 
  2648. .sp 9p
  2649. .RT
  2650. .PP
  2651. A test PDU sent by the tester to the IUT is normally constructed
  2652. from a Base PDU by means of the REPLACE operation.
  2653. .bp
  2654. .PP
  2655. The specification has the form:
  2656. .RT
  2657. .ce
  2658. \fBH.T. [T15.403]\fR 
  2659. .ce
  2660.  
  2661. .ps 9
  2662. .vs 11
  2663. .nr VS 11
  2664. .nr PS 9
  2665. .TS
  2666. center box;
  2667. lw(84p) | lw(72p) | lw(72p) .
  2668. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  2669. _
  2670. .T&
  2671. lw(60p) .
  2672. <test PDU to be specified> 
  2673. _
  2674. .T&
  2675. lw(84p) | lw(72p) | lw(72p) .
  2676. <base PDU to be used>        
  2677. .T&
  2678. lw(84p) | lw(72p) | lw(72p) .
  2679. REPLACE         
  2680. .T&
  2681. lw(84p) | lw(72p) | lw(72p) .
  2682. <base PDU part>        
  2683. .T&
  2684. lw(84p) | lw(72p) | lw(72p) .
  2685. BY        
  2686. .T&
  2687. lw(84p) | lw(72p) | lw(72p) .
  2688. <partial ASN.1 tree>    [<value>]     
  2689. _
  2690. .TE
  2691. .nr PS 9
  2692. .RT
  2693. .ad r
  2694. \fBTableau [T15.403], p.\fR 
  2695. .sp 1P
  2696. .RT
  2697. .ad b
  2698. .RT
  2699. .PP
  2700. For the conventions of value assignments see \(sc A.4.6.
  2701. .LP
  2702.     \fIExample\fR :
  2703. .ce
  2704. \fBH.T. [T16.403]\fR 
  2705. .ce
  2706.  
  2707. .ps 9
  2708. .vs 11
  2709. .nr VS 11
  2710. .nr PS 9
  2711. .TS
  2712. center box;
  2713. lw(84p) | lw(72p) | lw(72p) .
  2714. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  2715. _
  2716. .T&
  2717. lw(36p) .
  2718. IM\(hyUAPDU\(hy1\(hy18
  2719. _
  2720. .T&
  2721. lw(84p) | lw(72p) | lw(72p) .
  2722. BASE \(ulIM\(hyUAPDU \(ul1        
  2723. .T&
  2724. lw(84p) | lw(72p) | lw(72p) .
  2725. REPLACE        
  2726. .T&
  2727. lw(84p) | lw(72p) | lw(72p) .
  2728. BASE \(ulIM\(hyUAPDU. Heading        
  2729. .T&
  2730. lw(84p) | lw(72p) | lw(72p) .
  2731. BY        
  2732. .T&
  2733. lw(84p) | lw(72p) | lw(72p) .
  2734. SET {         
  2735. .T&
  2736. lw(84p) | lw(72p) | lw(72p) .
  2737. IPMessageID    [L \(ulIPMessageID \(ul7]    Library Components
  2738. .T&
  2739. lw(84p) | lw(72p) | lw(72p) .
  2740. originator ORDescriptor    [L \(ulORDescriptor \(ul11]    
  2741. .T&
  2742. lw(84p) | lw(72p) | lw(72p) .
  2743. }        
  2744. _
  2745. .TE
  2746. .nr PS 9
  2747. .RT
  2748. .ad r
  2749. \fBTableau [T16.403], p.\fR 
  2750. .sp 1P
  2751. .RT
  2752. .ad b
  2753. .RT
  2754. .PP
  2755. To construct invalid components in test PDUs to be sent by the
  2756. tester, the abstract REDEFINE operation is sometimes used. It is used together 
  2757. with the REPLACE operation in the following form: 
  2758. .ce
  2759. \fBH.T. [T17.403]\fR 
  2760. .ce
  2761.  
  2762. .ps 9
  2763. .vs 11
  2764. .nr VS 11
  2765. .nr PS 9
  2766. .TS
  2767. center box;
  2768. lw(84p) | lw(72p) | lw(72p) .
  2769. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  2770. _
  2771. .T&
  2772. lw(60p) .
  2773. <test PDU to be specified>
  2774. _
  2775. .T&
  2776. lw(84p) | lw(72p) | lw(72p) .
  2777. REDEFINE        
  2778. .T&
  2779. rw(84p) | lw(72p) | lw(72p) .
  2780. <Type to be redefined>    :: = <new definition>    
  2781. .T&
  2782. lw(84p) | lw(72p) | lw(72p) .
  2783. <base PDU to be used>        
  2784. .T&
  2785. lw(84p) | lw(72p) | lw(72p) .
  2786. REPLACE        
  2787. .T&
  2788. lw(84p) | lw(72p) | lw(72p) .
  2789. <base PDU part>        
  2790. .T&
  2791. lw(84p) | lw(72p) | lw(72p) .
  2792. BY        
  2793. .T&
  2794. lw(84p) | lw(72p) | lw(72p) .
  2795. <partial ASN.1 tree>    [<value>]     
  2796. _
  2797. .TE
  2798. .nr PS 9
  2799. .RT
  2800. .ad r
  2801. \fBTableau [T17.403], p.\fR 
  2802. .sp 1P
  2803. .RT
  2804. .ad b
  2805. .RT
  2806. .LP
  2807. .bp
  2808. .PP
  2809. The scope of the newly defined type is restricted to the PD
  2810. definition containing the REDEFINE operation.
  2811. .PP
  2812. \fINote\fR \ \(em\ That if the <value> is a reference to an element defined
  2813. elsewhere (i.e.\ a TSP or a Library Component), then the new type definition
  2814. does not affect the referenced element itself but only its usage in the 
  2815. actual PDU. 
  2816. .RT
  2817. .LP
  2818.     \fIExample\fR :
  2819. .ce
  2820. \fBH.T. [T18.403]\fR 
  2821. .ps 9
  2822. .vs 11
  2823. .nr VS 11
  2824. .nr PS 9
  2825. .TS
  2826. center box;
  2827. lw(42p) | lw(138p) .
  2828. IM \(ulUAPDU \(ul1 \(ul3     
  2829. .T&
  2830. lw(180p) .
  2831. REDEFINE 
  2832. .T&
  2833. lw(180p) .
  2834. T{
  2835. ORName :: = [APPLICATION 1] IMPLICIT SEQUENCE { 
  2836. T}
  2837. .T&
  2838. lw(180p) .
  2839. T{
  2840. P1.StandardAttributeList
  2841. P2.DomainDefinedAttributeList\ \ \ OPTIONAL
  2842. T}
  2843. .T&
  2844. lw(180p) .
  2845. BASE \(ulIM \(ulUAPDU \(ul1 
  2846. .T&
  2847. lw(180p) .
  2848. REPLACE 
  2849. .T&
  2850. lw(180p) .
  2851. T{
  2852. BASE
  2853. \(ulIM
  2854. \(ulUAPDU
  2855. \(ul1
  2856. \(ulHeading 
  2857. T}
  2858. .T&
  2859. lw(180p) .
  2860. BY 
  2861. .T&
  2862. lw(180p) .
  2863. SET {
  2864. .T&
  2865. lw(126p) | lw(54p) .
  2866. IPMessageID    [L \(ulIPMessageID \(ul1]
  2867. .T&
  2868. lw(126p) | lw(54p) .
  2869. originator ORDescriptor    [L \(ulORDescriptor \(ul1] 
  2870. .T&
  2871. lw(126p) | lw(54p) .
  2872. }     
  2873. _
  2874. .TE
  2875. .nr PS 9
  2876. .RT
  2877. .ad r
  2878. \fBTableau [T18.403], p.\fR 
  2879. .sp 1P
  2880. .RT
  2881. .ad b
  2882. .RT
  2883. .PP
  2884. The error to be constructed here is the wrong tag of the ORName
  2885. type (the correct tag would be [APPLICATION 0]).  The scope of the erroneous
  2886. type\(hydefinition constructed by \*QREDEFINE\*U is restricted to all occurrences 
  2887. of ORName in the definition of IM 
  2888. \(ulUAPDU
  2889. \(ul1
  2890. \(ul3.  This means that
  2891. L
  2892. \(ulORDescriptor
  2893. \(ul1 is used here with the modified ORName type, whereas the
  2894. usage of this library component in other PDUs or components remains unaltered.
  2895. .sp 1P
  2896. .LP
  2897. A.4.4.2
  2898.     \fITest PDUs received by the tester\fR 
  2899. .sp 9p
  2900. .RT
  2901. .PP
  2902. For received PDUs normally only a portion of the PDU relates to the purpose 
  2903. of the test. 
  2904. .PP
  2905. A component of interest is identified and its value assigned using the 
  2906. techniques described in \(sc\ A.4.3. 
  2907. .PP
  2908. The specification scheme has the following form:
  2909. .RT
  2910. .ce
  2911. \fBH.T. [T19.403]\fR 
  2912. .ps 9
  2913. .vs 11
  2914. .nr VS 11
  2915. .nr PS 9
  2916. .TS
  2917. center box;
  2918. lw(96p) | lw(66p) | lw(66p) .
  2919. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  2920. _
  2921. .T&
  2922. lw(60p) .
  2923. <Test PDU to be specified> 
  2924. _
  2925. .T&
  2926. lw(96p) | lw(66p) | lw(66p) .
  2927. T{
  2928. Partial definition \(em Components of interest 
  2929. T}        
  2930. .T&
  2931. lw(96p) | lw(66p) | lw(66p) .
  2932. <Test PDU part>    [<value>]     
  2933. _
  2934. .TE
  2935. .nr PS 9
  2936. .RT
  2937. .ad r
  2938. \fBTableau [T19.403], p.\fR 
  2939. .sp 1P
  2940. .RT
  2941. .ad b
  2942. .RT
  2943. .LP
  2944. .bp
  2945. .LP
  2946.     \fIExample\fR :
  2947. .ce
  2948. \fBH.T. [T20.403]\fR 
  2949. .ps 9
  2950. .vs 11
  2951. .nr VS 11
  2952. .nr PS 9
  2953. .TS
  2954. center box;
  2955. lw(96p) | lw(66p) | lw(66p) .
  2956. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  2957. _
  2958. .T&
  2959. lw(39p) .
  2960. SR\(hyUAPDU\(hyO\(hy95 
  2961. _
  2962. .T&
  2963. lw(96p) | lw(66p) | lw(66p) .
  2964. T{
  2965. Partial definition \(em Components of interest
  2966. T}        
  2967. .T&
  2968. lw(96p) | lw(66p) | lw(66p) .
  2969. T{
  2970. SR\(hyUAPDU.CHOICE.non\(hyReceipt 
  2971. T}        
  2972. .T&
  2973. lw(96p) | lw(66p) | lw(66p) .
  2974. reason INTEGER    [1]    autoforward 
  2975. .T&
  2976. lw(96p) | lw(66p) | lw(66p) .
  2977. comments PrintableString    [\*Qon holiday\*U]    
  2978. .T&
  2979. lw(96p) | lw(66p) | lw(66p) .
  2980. returned IM\(hyUAPDU    L \(ulIMUAPDU \(ul2]     
  2981. .T&
  2982. lw(96p) | lw(66p) | lw(66p) .
  2983. SR\(hyUAPDU.report         
  2984. .T&
  2985. lw(96p) | lw(66p) | lw(66p) .
  2986. IPMessageID    [L \(ulIPMessageID \(ul15]     
  2987. _
  2988. .TE
  2989. .nr PS 9
  2990. .RT
  2991. .ad r
  2992. \fBTableau [T20.403], p.\fR 
  2993. .sp 1P
  2994. .RT
  2995. .ad b
  2996. .RT
  2997. .LP
  2998. .sp 2
  2999. .sp 1P
  3000. .LP
  3001. A.4.5
  3002.     \fIComponent library\fR 
  3003. .sp 9p
  3004. .RT
  3005. .PP
  3006. Components of PDUs are defined in the library and are referenced in Base 
  3007. PDU specifications, Test PDU specifications and by other library 
  3008. components.
  3009. .PP
  3010. The name of a Library Component is of the form:
  3011. .RT
  3012. .sp 1P
  3013. .ce 1000
  3014. L
  3015. \(ul<ASN.1 type name>
  3016. \(ul<number>
  3017. .ce 0
  3018. .sp 1P
  3019. .LP
  3020. and is specified using the techniques described in \(sc\ A.4.3
  3021. .LP
  3022.     \fIExample\fR :
  3023. .ce
  3024. \fBH.T. [T21.403]\fR 
  3025. .ps 9
  3026. .vs 11
  3027. .nr VS 11
  3028. .nr PS 9
  3029. .TS
  3030. center box;
  3031. lw(84p) | lw(72p) | lw(72p) .
  3032. DESCRIPTION    VALUE or REFERENCE    COMMENT 
  3033. _
  3034. .T&
  3035. lw(42p) .
  3036. L \(ulPhantasy \(ul1 
  3037. _
  3038. .T&
  3039. lw(84p) | lw(72p) | lw(72p) .
  3040. SEQUENCE {        
  3041. .T&
  3042. lw(84p) | lw(72p) | lw(72p) .
  3043. SET {        
  3044. .T&
  3045. lw(84p) | lw(72p) | lw(72p) .
  3046. SET {        
  3047. .T&
  3048. lw(84p) | lw(72p) | lw(72p) .
  3049. ContentType  originator    [2]    p2
  3050. .T&
  3051. lw(84p) | lw(72p) | lw(72p) .
  3052. Pl.ORName    [TSP \(ulOrName \(ul1]    Test Suite Parameter 
  3053. .T&
  3054. lw(84p) | lw(72p) | lw(72p) .
  3055. original         
  3056. .T&
  3057. lw(84p) | lw(72p) | lw(72p) .
  3058. SET {BIT STRING}    [{`20H`}]    IA5 Text
  3059. .T&
  3060. lw(84p) | lw(72p) | lw(72p) .
  3061. DeliveryFlags    [`40H`]    Conversion Prohibited 
  3062. .T&
  3063. lw(84p) | lw(72p) | lw(72p) .
  3064. ThisRecipient         
  3065. .T&
  3066. lw(84p) | lw(72p) | lw(72p) .
  3067. Pl.ORName    [TSP \(ulORName \(ul1]     
  3068. .T&
  3069. lw(84p) | lw(72p) | lw(72p) .
  3070. submission TIME    [TPS \(ulUTCTime \(ul1]     
  3071. .T&
  3072. lw(84p) | lw(72p) | lw(72p) .
  3073. }         
  3074. .T&
  3075. lw(84p) | lw(72p) | lw(72p) .
  3076. }         
  3077. .T&
  3078. lw(84p) | lw(72p) | lw(72p) .
  3079. IM\(hyUAPDU    [L \(ulIM\(hyUAPDU \(ul1]    Library Cpt 
  3080. .T&
  3081. lw(84p) | lw(72p) | lw(72p) .
  3082. }         
  3083. _
  3084. .TE
  3085. .nr PS 9
  3086. .RT
  3087. .ad r
  3088. \fBTableau [T21.403], p.\fR 
  3089. .sp 1P
  3090. .RT
  3091. .ad b
  3092. .RT
  3093. .LP
  3094. .bp
  3095. .sp 1P
  3096. .LP
  3097. A.4.6
  3098.     \fIValue conventions\fR 
  3099. .sp 9p
  3100. .RT
  3101. .PP
  3102. The following conventions are used when defining values or value
  3103. references for PDU components.
  3104. .PP
  3105. Value references identify components defined either within the
  3106. Component Library or within the Test Suite Parameters section. CharacterString 
  3107. Values can specified within double\(hyquotes (e.g.\ \*Qabc\*U); Bit String 
  3108. Values are specified within single\(hyquotes (e.g.\ '0A'H or '0001'B; hexadecimal 
  3109. or binary 
  3110. notation); Integer Values are specified as numeric characters (e.g.\ 2); sets
  3111. and sequences of values are specified within curly brackets separated by 
  3112. comma (e.g.\ {\*Qabc\*U, `OA'H}). 
  3113. .PP
  3114. For PDU's sent by the tester:
  3115. .RT
  3116. .LP
  3117.     [?]
  3118.      indicates that the value has no influence on the test and may be anything 
  3119. that is legal according to the relevant service or protocol 
  3120. standard;
  3121. .LP
  3122.     [\(hy]
  3123.     indicates that the parameter shall be absent;
  3124. .LP
  3125.     [*]
  3126.     indicates that the value is to be inserted by the tester
  3127. before test execution.
  3128. .LP
  3129.     For PDU's received by the tester:
  3130. .LP
  3131.     [?]
  3132.     indicates that the tester need make no verification of
  3133. the value of the parameter;
  3134. .LP
  3135.     [\(hy]
  3136.     indicates that the tester shall check that the parameter
  3137. is absent.
  3138. .PP
  3139. \fINote\fR \ \(em\ That the \*Q?\*U and \*Q\(hy\*U symbols in value assignments 
  3140. of 
  3141. PDU components have got other meanings than \*Q?\*U and \*Q\(hy\*U in generic 
  3142. ASP 
  3143. schedules.
  3144. .sp 1P
  3145. .LP
  3146. A.5
  3147.     \fITest case identification\fR 
  3148. .sp 9p
  3149. .RT
  3150. .PP
  3151. Test cases are completely identified using four
  3152. components:
  3153. .RT
  3154. .LP
  3155.     \(em
  3156.     a test group identifier;
  3157. .LP
  3158.     \(em
  3159.     a subgroup identifier;
  3160. .LP
  3161.     \(em
  3162.     a validity identifier;
  3163. .LP
  3164.     \(em
  3165.     a test number.
  3166. .PP
  3167. These four components are specified in two equivalent ways:
  3168. .LP
  3169.     \(em
  3170.     as a Test Reference where the four components
  3171. are textual and descriptive;
  3172. .LP
  3173.     \fIExample:\fR OriginalEncodedInfoTypeIndication/Recipient/Valid/2
  3174. .LP
  3175.     \(em
  3176.     as a Test Identifier where the four components are numeric
  3177. and concise.
  3178. .LP
  3179.     \fIExample:\fR 307.2.1.2.
  3180. .sp 2P
  3181. .LP
  3182. A.5.1
  3183.     \fIIPMS(P2) and MTS(P1) identification\fR 
  3184. .sp 1P
  3185. .RT
  3186. .sp 1P
  3187. .LP
  3188. A.5.1.1
  3189.     \fITest Groups\fR 
  3190. .sp 9p
  3191. .RT
  3192. .PP
  3193. Number ranges have been allocated for the test groups as shown
  3194. below:
  3195. .RT
  3196. .LP
  3197.     Initial Tests
  3198.     001\|\(hy\|099
  3199. .LP
  3200.     X.409 Tests
  3201.     100\|\(hy\|199
  3202. .LP
  3203.     Protocol Elements Tests
  3204.     200\|\(hy\|299
  3205. .LP
  3206.     (for frequently occurring Elements)
  3207. .LP
  3208.     X.400
  3209. .LP
  3210. Service Elements Tests
  3211.     300\|\(hy\|399
  3212. .LP
  3213.     Additional Tests
  3214.     400\|\(hy\|499
  3215. .sp 1P
  3216. .LP
  3217. A.5.1.2
  3218.     \fISubgroups\fR 
  3219. .sp 9p
  3220. .RT
  3221. .PP
  3222. Numeric identifiers have been allocated to the
  3223. test subgroups as shown below:
  3224. .RT
  3225. .LP
  3226.     Originator
  3227.     1
  3228. .LP
  3229.     Recipient
  3230.     2
  3231. .LP
  3232.     Encode
  3233.     1
  3234. .LP
  3235.     Decode
  3236.     2
  3237. .LP
  3238.     Relay
  3239.     3
  3240. .LP
  3241.     Relaying\(hyRecipient
  3242.     4
  3243. .LP
  3244.     Relaying\(hyOriginator
  3245.     5
  3246. .bp
  3247. .sp 1P
  3248. .LP
  3249. A.5.1.3
  3250.     \fIValidity identifiers\fR 
  3251. .sp 9p
  3252. .RT
  3253. .PP
  3254. Test cases which exercise valid behaviour are distinguished from
  3255. those which exercise the IUT's reaction to invalid behaviour using the 
  3256. numeric identifiers shown below: 
  3257. .RT
  3258. .LP
  3259.     Valid
  3260.     1
  3261. .LP
  3262.     Invalid
  3263.     2
  3264. .sp 1P
  3265. .LP
  3266. A.5.1.4
  3267.     \fITest case numbers\fR 
  3268. .sp 9p
  3269. .RT
  3270. .PP
  3271. Test cases for a particular group/subgroup/validity are numbered
  3272. sequentially.
  3273. .RT
  3274. .sp 2P
  3275. .LP
  3276. A.5.2
  3277.     \fIRTS identification\fR 
  3278. .sp 1P
  3279. .RT
  3280. .sp 1P
  3281. .LP
  3282. A.5.2.1
  3283.     \fITest groups\fR 
  3284. .sp 9p
  3285. .RT
  3286. .PP
  3287. Number ranges have been allocated for the test groups as shown
  3288. below:
  3289. .RT
  3290. .LP
  3291.     Association Establishment
  3292.     1
  3293. .LP
  3294.     Association Release
  3295.     2
  3296. .LP
  3297.     Data Transfer
  3298.     3
  3299. .LP
  3300.     Association Recovery
  3301.     4
  3302. .LP
  3303.     X.409 Tests
  3304.     5
  3305. .sp 1P
  3306. .LP
  3307. A.5.2.2
  3308.     \fISubgroups\fR 
  3309. .sp 9p
  3310. .RT
  3311. .PP
  3312. Numeric identifiers have been allocated to the RTS subgroups as
  3313. shown below:
  3314. .RT
  3315. .LP
  3316.     Initiator
  3317.     1
  3318. .LP
  3319.     Responder
  3320.     2
  3321. .LP
  3322.     Sender
  3323.     1
  3324. .LP
  3325.     Receiver
  3326.     2
  3327. .sp 1P
  3328. .LP
  3329. A.5.2.3
  3330.     \fIValidity identifiers\fR 
  3331. .sp 9p
  3332. .RT
  3333. .PP
  3334. Test cases which exercise valid behaviour are distinguished from
  3335. those which exercise the IUT's reaction to invalid and inopportune behaviour
  3336. using the numeric identifiers shown below:
  3337. .RT
  3338. .LP
  3339.     Valid
  3340.     1
  3341. .LP
  3342.     Invalid
  3343.     2
  3344. .LP
  3345.     Inopportune
  3346.     3
  3347. .sp 2P
  3348. .LP
  3349. A.6
  3350.     \fICross referencing\fR 
  3351. .sp 1P
  3352. .RT
  3353. .sp 1P
  3354. .LP
  3355. A.6.1
  3356.     \fICross reference numbering\fR 
  3357. .sp 9p
  3358. .RT
  3359. .PP
  3360. The MTS\ (P1) and IPMS\ (P2) test suites contain a cross referencing system 
  3361. for the ASPs, test PDUs and library components. The cross referencing appears 
  3362. in the left and right margins of the test suite as shown in 
  3363. Figure\ A\(hy14/X.403.
  3364. .RT
  3365. .PP
  3366. Numbers in the left hand margin of the test suite are in
  3367. sequential order and are \*Qplace identifiers\*U. They occur whenever an 
  3368. ASP, test PDU or library component occurs in the test suite. 
  3369. .PP
  3370. Whenever an ASP, test PDU or library component occurs, numbers are
  3371. also placed in the right hand margin. These numbers are forward and backward
  3372. references to the place identifiers of the other occurrences of the ASP, 
  3373. test PDU or library component. 
  3374. .PP
  3375. Where a forward or backward reference can not be found then a dot
  3376. (\*U.\*U) is printed in the right hand margin. This should not occur in fully
  3377. defined test suites.
  3378. .PP
  3379. Where a line in the test suite contains more than one ASP, test PDU or 
  3380. library component, the cross references for each item in the line are separated 
  3381. by vertical bars (\*U|\*Q) in the right hand margin as shown in 
  3382. Figure\ A\(hy15/X.403.
  3383. .bp
  3384. .RT
  3385. .LP
  3386. .rs
  3387. .sp 13P
  3388. .ad r
  3389. \fBFigure A\(hy14/X.403 (trait\*'e comme tableau) [T22.403], p.\fR 
  3390. .sp 1P
  3391. .RT
  3392. .ad b
  3393. .RT
  3394. .LP
  3395. .sp 5
  3396. .rs
  3397. .sp 6P
  3398. .ad r
  3399. \fBFigure A\(hy15/X.403 (trait\*'e comme tableau) [T23.403], p.\fR 
  3400. .sp 1P
  3401. .RT
  3402. .ad b
  3403. .RT
  3404. .LP
  3405. .sp 5
  3406. .sp 1P
  3407. .LP
  3408. A.6.2
  3409.     \fICross reference listing\fR 
  3410. .sp 9p
  3411. .RT
  3412. .PP
  3413. At the end of MTS\ (P1) and IPMS\ (P2) test suites there is a
  3414. separate cross reference listing of all the ASPs, test PDUs and library
  3415. components together with the place identifiers of all their occurrences 
  3416. in the test suite. 
  3417. .PP
  3418. \fIExample:\fR 
  3419. .RT
  3420. .ce 1000
  3421. :\ \ \ \ \ \ \ \ \ \ \ \ 
  3422. .ce 0
  3423. .ce 1000
  3424. :\ \ \ \ \ \ \ \ \ \ \ \ 
  3425. .ce 0
  3426. .ce 1000
  3427. :\ \ \ \ \ \ \ \ \ \ \ \ 
  3428. .ce 0
  3429. .ce 1000
  3430. IM
  3431. \(ulUAPDU
  3432. \(ul1
  3433. \(ul14\ \ \ \ 586\ 1467
  3434. .ce 0
  3435. .ce 1000
  3436. IM
  3437. \(ulUAPDU
  3438. \(ul1
  3439. \(ul15\ \ \ \ 587\ 1470
  3440. .ce 0
  3441. .ce 1000
  3442. :\ \ \ \ \ \ \ \ \ \ \ \ 
  3443. .ce 0
  3444. .ce 1000
  3445. :\ \ \ \ \ \ \ \ \ \ \ \ 
  3446. .ce 0
  3447. .sp 1P
  3448. .ce 1000
  3449. :\ \ \ \ \ \ \ \ \ \ \ \ 
  3450. .ce 0
  3451. .sp 1P
  3452. .PP
  3453. The numbers on the right side indicate the places where the item occurs 
  3454. in the test suite. 
  3455. .LP
  3456. .bp
  3457.