Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers Output from the June 1994 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: James Quigley, Hewlett-Packard SIG Editors: Debra Britt, NCTS Laura Emmons, Telenex Part 5 - Upper Layers June 1994 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Upper Layers Special Interest Group (ULSIG) of the Open Systems Environment Implementors' Workshop (OIW). The charter for the OIW is located in Part 1 - Workshop Policies and Procedures of the "Draft Working Implementation Agreements Document." The text in this part has been approved by the Plenary of the OIW. This part replaces the previously existing part on the Upper Layers. Annex B is for information purposes only. Annex A forms an integral part of these Implementor Agreements. Future changes and additions to these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as struck. New and replacement text will be shown as shaded. ii Part 5 - Upper Layers June 1994 (Stable) Table of Contents Part 5 - Upper Layers . . . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 1 2.1 Session Layer . . . . . . . . . . . . . . . . . . . 1 2.2 Presentation Layer . . . . . . . . . . . . . . . . . 2 2.3 Application Layer . . . . . . . . . . . . . . . . . 3 2.4 Application Layer - ASE/ACSE . . . . . . . . . . . . 3 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Technical Corriagenda and Defect Reports . . . . . . 4 4.2 Defect Registers . . . . . . . . . . . . . . . . . . 5 4.3 Exception Handling . . . . . . . . . . . . . . . . . 8 5 Association Control Service Element . . . . . . . . . . . 9 5.1 Introduction . . . . . . . . . . . . . . . . . . . . 9 5.2 Services . . . . . . . . . . . . . . . . . . . . . . 9 5.3 Protocol Agreements . . . . . . . . . . . . . . . . 9 5.3.1 Application Context . . . . . . . . . . . . 9 5.3.2 AE Title . . . . . . . . . . . . . . . . . 9 5.3.3 Peer Entity Authentication . . . . . . . . 10 5.4 ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 10 5.5 Connectionless . . . . . . . . . . . . . . . . . . . 10 6 ROSE . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7 RTSE . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8 Presentation . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Introduction . . . . . . . . . . . . . . . . . . . . 11 8.2 Service . . . . . . . . . . . . . . . . . . . . . . 11 8.3 Protocol Agreements . . . . . . . . . . . . . . . . 12 8.3.1 Transfer Syntaxes . . . . . . . . . . . . . 12 8.3.2 Presentation Context Identifier . . . . . . 12 8.3.3 Default Context . . . . . . . . . . . . . . 12 8.3.4 P-Selectors . . . . . . . . . . . . . . . . 12 8.3.5 Provider Abort Parameters . . . . . . . . . 13 8.3.6 Provider Aborts and Session Version . . . . 13 8.3.7 CPC-Type . . . . . . . . . . . . . . . . . 14 8.3.8 Presentation-context-definition-result-list 14 8.3.9 RS-PPDU . . . . . . . . . . . . . . . . . . 14 iii Part 5 - Upper Layers June 1994 (Stable) 8.4 Presentation ASN.1 Encoding Rules . . . . . . . . . 15 8.5 Presentation Data Value (PDV) . . . . . . . . . . . 15 8.6 Connection Oriented . . . . . . . . . . . . . . . . 15 8.7 Connectionless . . . . . . . . . . . . . . . . . . . 16 9 Session . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1 Introduction . . . . . . . . . . . . . . . . . . . . 16 9.2 Services . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Protocol Agreements . . . . . . . . . . . . . . . . 17 9.3.1 Concatenation . . . . . . . . . . . . . . . 17 9.3.2 Segmenting . . . . . . . . . . . . . . . . 17 9.3.3 Reuse of Transport Connection . . . . . . . 17 9.3.4 Use of Transport Expedited Data . . . . . . 17 9.3.5 Use of Session Version Number . . . . . . . 17 9.3.5.1 Selection of session version . . . . . . . 17 9.3.5.2 User data in session version 2 . . . . . . 18 9.3.6 Receipt of Invalid SPDUs . . . . . . . . . 19 9.3.7 Invalid SPM Intersections . . . . . . . . . 19 9.3.8 S-Selectors . . . . . . . . . . . . . . . . 19 9.4 Connectionless . . . . . . . . . . . . . . . . . . . 22 10 UNIVERSAL ASN.1 ENCODING RULES . . . . . . . . . . . . . 22 10.1 TAGS . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2 Definite Length . . . . . . . . . . . . . . . . . . 22 10.3 External . . . . . . . . . . . . . . . . . . . . . . 22 10.4 Integer . . . . . . . . . . . . . . . . . . . . . . 23 10.5 String Types . . . . . . . . . . . . . . . . . . . . 23 10.6 Extensibility . . . . . . . . . . . . . . . . . . . 23 11 Additions to ISP on Common Upper Layer Requirements . . . 24 11.1 Service . . . . . . . . . . . . . . . . . . . . . . 24 11.2 Provider Abort Parameters . . . . . . . . . . . . . 24 11.3 Concatenation . . . . . . . . . . . . . . . . . . . 24 11.4 Segmenting . . . . . . . . . . . . . . . . . . . . . 24 11.5 Reuse of Transport Connection . . . . . . . . . . . 24 11.6 Use of Transport Expedited Data . . . . . . . . . . 25 12 Character Sets . . . . . . . . . . . . . . . . . . . . . 25 13 Conformance . . . . . . . . . . . . . . . . . . . . . . . 25 14 Specific ASE Requirements . . . . . . . . . . . . . . . . 25 14.1 FTAM Phase 2 . . . . . . . . . . . . . . . . . . . . 25 14.1.1 ACSE Requirements . . . . . . . . . . . . . 25 14.1.2 Presentation Requirements . . . . . . . . . 26 14.1.3 Session Requirements . . . . . . . . . . . 27 14.1.4 Session Options . . . . . . . . . . . . . . 27 14.1.5 ASN.1 Encoding Requirements . . . . . . . . 28 14.2 MHS . . . . . . . . . . . . . . . . . . . . . . . . 28 14.2.1 Phase 1 (1984 X.400) Session Requirements . 28 iv Part 5 - Upper Layers June 1994 (Stable) 14.2.2 Phase 2, Protocol P1 (1988 X.400) . . . . . 28 14.2.2.1 ROSE Requirements . . . . . . . . . . . . . 28 14.2.2.2 RTSE Requirements . . . . . . . . . . . . . 29 14.2.2.3 ACSE Requirements . . . . . . . . . . . . . 29 14.2.2.4 Presentation Requirements . . . . . . . . . 30 14.2.2.5 Session Requirements . . . . . . . . . . . 30 14.2.3 Phase 2, Protocol P7 (1988 X.400) . . . . . 30 14.2.3.1 ROSE Requirements . . . . . . . . . . . . . 30 14.2.3.2 RTSE Requirements . . . . . . . . . . . . . 30 14.2.3.3 ACSE Requirements . . . . . . . . . . . . . 31 14.2.3.4 Presentation Requirements . . . . . . . . . 31 14.2.3.5 Session Requirements . . . . . . . . . . . 32 14.2.4 Phase 2, Protocol P3 (1988 X.400) . . . . . 33 14.2.4.1 ROSE Requirements . . . . . . . . . . . . . 33 14.2.4.2 RTSE Requirements . . . . . . . . . . . . . 33 14.2.4.3 ACSE Requirements . . . . . . . . . . . . . 33 14.2.4.4 Presentation Requirements . . . . . . . . . 33 14.2.4.5 Session Requirements . . . . . . . . . . . 33 14.3 DS Phase 1 . . . . . . . . . . . . . . . . . . . . . 33 14.3.1 ACSE Requirements . . . . . . . . . . . . . 33 14.3.2 Presentation Requirements . . . . . . . . . 34 14.3.3 Session Requirements . . . . . . . . . . . 34 14.4 Virtual Terminal . . . . . . . . . . . . . . . . . . 34 14.4.1 Phase 1a . . . . . . . . . . . . . . . . . 34 14.4.1.1 ACSE Requirements . . . . . . . . . . . . . 34 14.4.1.2 Presentation Requirements . . . . . . . . . 35 14.4.1.3 Session Requirements . . . . . . . . . . . 35 14.4.2 Phase 1b . . . . . . . . . . . . . . . . . 36 14.4.2.1 ACSE Requirements . . . . . . . . . . . . . 36 14.4.2.2 Presentation Requirements . . . . . . . . . 36 v Part 5 - Upper Layers June 1994 (Stable) 14.4.2.3 Session Requirements . . . . . . . . . . . 36 14.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . 37 14.5.1 ACSE Requirements . . . . . . . . . . . . . 37 14.5.2 Constructed Encodings . . . . . . . . . . . 37 14.5.3 Presentation Requirements . . . . . . . . . 37 14.5.4 Session Requirements . . . . . . . . . . . 38 14.6 Transaction Processing . . . . . . . . . . . . . . . 38 14.6.1 ACSE Requirements . . . . . . . . . . . . . 38 14.6.2 Presentation Requirements . . . . . . . . . 38 14.6.3 Session Requirements . . . . . . . . . . . 39 14.7 Network Management . . . . . . . . . . . . . . . . . 39 14.7.1 ROSE Requirements . . . . . . . . . . . . . 39 14.7.2 ACSE Requirements . . . . . . . . . . . . . 39 14.7.3 Presentation Requirements . . . . . . . . . 39 14.7.4 Session Requirements . . . . . . . . . . . 40 14.8 Remote Database Access . . . . . . . . . . . . . . . 40 14.8.1 ACSE Requirements . . . . . . . . . . . . . 40 14.8.2 Presentation Requirements . . . . . . . . . 40 14.8.2.1 Presentation Contexts for the RDA Basic Application Context . . . . . . . . . . . . 41 14.8.2.2 Presentation Contexts for the RDA TP Application Context . . . . . . . . . . . . 41 14.8.3 Session Requirements . . . . . . . . . . . 41 Annex A (normative) Object Identifier Register . . . . . . . . . . . . . . . . . 43 A.1 Register Index . . . . . . . . . . . . . . . . . . . 43 A.2 Object Identifier Descriptions . . . . . . . . . . . 43 Annex B (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 45 Annex C (normative) Draft of new ISP on Minimal OSI facilities . . . . . . . . . 49 vi Part 5 - Upper Layers June 1994 (Stable) List of Tables Table ISO Defect Reports . . . . . . . . . . . . . . . . . . 6 Table 1 - Called and Responding P-Selectors . . . . . . . . . 13 Table 2 - Called and Responding S-Selectors . . . . . . . . . 21 Table 3 - Calling S-Selectors . . . . . . . . . . . . . . . . 21 Table A.1 - Session States . . . . . . . . . . . . . . . . . 46 Table A.2 - Incoming Events . . . . . . . . . . . . . . . . . 47 vii Part 5 - Upper Layers 0 Introduction In this portion of the Implementors' Agreements, the Upper Layers SIG is primarily concerned with providing implementation agreements for ACSE, ROSE, RTSE, and the Presentation and Session layers, so that systems implemented according to these agreements can successfully interoperate. 1 Scope The agreements in this part apply to all ASE agreements in this document. A referencing specification may use the requirements in this part in one of the following ways: a) The referencing specification does not duplicate any of the requirements of this part of the document within its own specifications and instead requires an implementation to conform to the requirements of this part. This is the preferred method. b) The referencing specification duplicates all of the requirements of this part of the document as part of its requirements and related conformance statements. Each ASE SIG supplements the common requirements in this part of the document by a statement in the "Specific ASE Requirements" clause of this part which outlines the ASE's specific requirements for the use of the ACSE, presentation and session protocol standards. 2 Normative References 2.1 Session Layer [1] ISO 8326: 1987 (E), Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Service Definition. [2] ISO 8327: 1987 (E), Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Protocol Specification. [3] ISO/IEC JTC1/SC21 N2494, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Service Definition-AD 2 to ISO 8326 to Incorporate Unlimited User Data. 1 Part 5 - Upper Layers June 1994 (Stable) [4] ISO/IEC JTC1/SC21 N2495, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Protocol Specification - AD 2 to ISO 8327 to Incorporate Unlimited User Data. [5] ISO/AD3 8326, Information Processing Systems - Open Systems Interconnection-Session Service Definition: Addendum 3 Covering Connectionless-Mode Session Service. [6] ISO/IS 9548, Information Processing Systems - Open Systems Interconnection-Connectionless Session Protocol to Provide the Connectionless-Mode Session Service. 2.2 Presentation Layer [7] ISO 8822: 1988 (ISO/IEC JTC1/SC21 N2335), Information Processing Systems - Open Systems Interconnection - Connection-Oriented Presentation Service Definition. [8] ISO 8823: 1988 (ISO/IEC JTC1/SC21 N2336), Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Specification. [9] ISO 8824: 1990 (E), Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). [10] ISO 8825: 1990 (E), Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). [11] ISO/DAD1 8822: 1989-02-15(e) (ISO/IEC JTC1/SC21 N 3171), Information Processing Systems - Open Systems Interconnection - Presentation Service Definition: Draft Addendum 1 Covering Connectionless-Mode Presentation Service. [12] ISO/IS 9576: 1989-02-25 5(E) (ISO/IEC JTC1/SC21 N 3172), Information Processing Systems - Open Systems Interconnection - Connectionless Presentation Protocol to Provide the Connectionless-Mode Presentation Service. 2 Part 5 - Upper Layers June 1994 (Stable) 2.3 Application Layer [13] ISO/DP 9545, ISO/TC97/SC21/N1743, July 24, 1987, revised November 1987, Information Processing Systems - Open Systems Interconnection - Application Layer Structure. 2.4 Application Layer - ASE/ACSE [14] ISO 8649: 1987 (E) (ISO/IEC JTC1/SC21 N2326), Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element. [15] ISO 8650: 1987 (E) (ISO/IEC JTC1/SC21 N2327), Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element. [16] ISO 8649/DAD2, Information Processing System - Open Systems Interconnection - ACSE Service Definition: Draft Addendum 2 Covering Connectionless-Mode ACSE Service. [17] ISO 8649/DAD1 (ISO/IEC JTC1/SC21 N3771), Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element - Addendum 1: Peer-Entity Authentication During Association Establishment [18] ISO 8650/DAD1 (ISO/IEC JTC1/SC21 N3772), Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element - Addendum 1: Peer-Entity Authentication During Association Establishment [19] ISO 8649/Cor.1: 1991 (E) (ISO/IEC JTC1/SC21 N5630), Information Processing Systems - Open Systems Interconnection - Technical Corrigendum 1 to ACSE Service (ISO 8649: 1988) Covering Defects 8649/001, 8649/002 and 8649/003. [20] ISO 8650/Cor.1: 1991 (E) (ISO/IEC JTC1/SC21 N5631), Information Processing Systems - Open Systems Interconnection - Technical Corrigendum 1 to ACSE Protocol (ISO 8650: 1988) Covering Defects 8650/001, 8649/004. [21] ISO IS 10035: 1989-02-25 (ISO/IEC JTC1/SC21 N 3456), Information Processing Systems - Open Systems Interconnection - Connectionless ACSE Protocol to Provide the Connectionless-Mode ACSE Service. 3 Part 5 - Upper Layers June 1994 (Stable) 3 Status This text is stable. NOTE - Changes due to errata are summarized in clause 4 4 Errata In accordance with FIPS 146-1, with specific exceptions as noted below, this edition of the Part 5 - Stable Implementation Agreements remains backwardly compatible with Part 5 - Stable Implementation Agreements, Version 3, Edition 1. The method for assuring continued interoperability when these specific exceptions occur is detailed below and has been approved by the plenary of the OIW. Therefore, this edition of Part 5 - Stable Implementation Agreements supersedes all previous versions and editions of the Part 5 - Stable Implementation Agreements. 4.1 Technical Corriagenda and Defect Reports An existing ISO base standard (e.g., ISO 8649 -- ACSE service) may be modified by an approved/registered Technical Corriagenda (TC) that fixes problems as reported in one or more Defect Reports (DR). An error or request for clarification concerning a base standard is brought to the attention of ISO by a Defect Report. Defect Reports may be submitted to ISO by the OIW or by national bodies such as ANSI X3T5 task group in the USA. A Defect Report is processed by the Defect Editing Group of the base standard as part of the ISO "Rapid Amendment Process." If the Defect Editing Group agrees that the Defect Report concerns an error in the base standard, the Defect Editing Group prepares a fix to the error in the form of a Draft Technical Corrigenda (DTC). A DTC is not used to add new or revised facility to the base standard. The purpose of the DTC is to rectify inconsistencies and or mechanisms that do not provide the defined facility. NOTE - The amendment procedure is not used to add facility to a base standard. A DTC undergoes a 3-month draft ballot by national bodies. An editing meeting may be necessary to resolve national body comments. An accepted/registered DTC becomes a TC. A TC immediately 4 Part 5 - Upper Layers June 1994 (Stable) becomes a part of the base standard that it references. For a referencing standard or profile, the modification by a TC or an errata immediately takes effect unless it applies to an option that is "out-of-scope" or prohibited by the referencing standard or profile. A TC may impact the interoperability of a base standard. In some cases, recertification may be necessary. 4.2 Defect Registers 5 Part 5 - Upper Layers June 1994 (Stable) Table ISO Defect Reports +--------+------+-------+---------+--------+--------------------- ---+--------+------+-----+----------------+ |Defect |Source|Circ. |Distr. as|Resp to |Returned to Editor for -|Ballot |Voting|Final|Remarks | | | | | | +----+----+------+-------+ | | | | | | |by Sec.| WG doc. |Sec. by |info|actn|DTC/49|DTC/50 |ends |Sum'ry|text | | +--------+------+-------+---------+--------+----+----+------+---- ---+--------+------+-----+----------------+ |8649/001|Editor|88-12 |-- |89-11 |-- |-- |N4447 |-- |90-05-15|N4687 |N5630|Closed: Part of | | | | | | | | | | | | | |8649/TC1 | |8649/002|Editor|89-11 |-- |89-11 |-- |-- |N4448 |-- |90-05-15|N4688 |N5630|Closed: Part of | | | | | | | | | | | | | |8649/TC1 | | | | | | | | | | | | | | | |8649/003|Editor|89-11 |-- |89-11 |-- |-- |N4449 |-- |90-05-15|N4689 |N5630|Closed: Part of | | | | | | | | | | | | | |8649/TC1 | | | | | | | | | | | | | | | |8649/004|Editor|90-02 |N765 |90-05-30|-- |yes |tbd |tbd |tbd |tbd |tbd |Open: ULA advice| | | | | | | | | | | | | |- wait for XALS | | | | | | | | | | | | | |developments | | | | | | | | | | | | | | | |8649/005|-- | | | | | | | | | | |Number not used | | | | | | | | | | | | | | | |8649/006|Japan |90-03 |N782 |90-06 |-- |-- |N5320 |-- |91-01 |N5690 |-- |Referred back to| | | | | | | | | | | | | |WG6 ULA group; | | | | | | | | | | | | | |response Nxxxx | | | | | | | | |N6336 |N6336 |91-12-10|N6627 |-- |AFNOR: no vote | | | | | | | | |tbd |tbd |tbd |tbd |tbd |Revised DTC due | | | | | | | | | | 6 Part 5 - Upper Layers June 1994 (Stable) | | | |from Editor | | | | | | | | | | | | | | | |8649/007|CCITT |90-12 |N962 |91-03-25|-- |-- | | | |N6628 |Ed 2 |Closed: DTC text| | | | | | | | | | | | | |unchanged; add | | | | | | | | | | | | | |to Edition 2 | | | | | | | | | | | | | | | |8650/001|Editor|88-08 |N533 |89-11 |-- |-- |-- |N3473 |89-08 |N3862 |N4286|Closed: Part of | | | | | | | | | | | | | |8650/TC1 | | | | | | | | | | | | | | | |8650/002|Editor|88-08 |N534 |89-11 |N653|-- |-- |-- |-- |-- |-- |Closed: Not | | | | | | | | | | | | | |recommended for | | | | | | | | | | | | | |progression | | | | | | | | | | | | | | | |8650/003|Japan |88-10 |N573 |89-01 |N654|-- |-- |-- |-- |-- |-- |Closed:Editorial| | | | | | | | | | | | | |change already | | | | | | | | | | | | | |in IS text | | | | | | | | | | | | | | | |8650/004|Editor|88-12 |-- |88-12 |-- |-- |-- |N3475 |89-08 |N4286 |N4286|Closed: Part of | | | | | | | | | | | | | |8650/TC1 | | | | | | | | | | | | | | | |8650/005|-- | | | | | | | | | | |Number not used | | | | | | | | | | | | | | | |8650/006|CCITT |90-10 |N915 |91-01-11|tbd |-- |-- |-- |-- |-- |-- |Closed: Not | | | | | | | | | | | | | |recommended for | | | | | | | | | | | | | |progression | | | | | | | | | | 7 Part 5 - Upper Layers June 1994 (Stable) | | | | | |8650/007|CCITT |90-10 |N916 |91-01-11|-- |-- |-- |N6338 |91-12-10|N6629 |Ed 2 |Closed: Add to | | | | | | | | | | | | | |Edition 2 of | | | | | | | | | | | | | |8650 | | | | | | | | | | | | | | | |8650/008|Editor|90-06 |-- |90-06 |N911|-- |-- |-- |-- |-- |-- |Closed: Response| | | | | | | | | | | | | |only - did not | | | | | | | | | | | | | |change text | | | | | | | | | | | | | | | |8650/009|Editor|93-?? |N??? |93-03 |-- |-- |-- |Nxxxx |93-12 |tbd |tbd |Open: under | | | | | | | | | | | | | |discussion | | | | | | | | | | | | | |preparing for | | | | | | | | | | | | | |DTC text | | | | | | | | | | | | | | | +--------+------+-------+---------+--------+----+----+------+---- ---+--------+------+-----+----------------+ 4.3 Exception Handling For those cases where backwards compatibility cannot be assured due to a Technical Corrigenda (see clause 4.6), interoperability will be maintained by requiring existing implementations to incorporate the change within 12 months after it has been registered as a Technical Corriagenda. The registration authority for conformance testing will determine in each case whether or not recertification is necessary. 8 Part 5 - Upper Layers June 1994 (Stable) 5 Association Control Service Element 5.1 Introduction This clause details the implementation requirements for the Association Control Service Element (ACSE) of the Application layer as defined in ISO 8649 and ISO 8650. 5.2 Services All ACSE services are within the possible scope of a workshop- conformant system. 5.3 Protocol Agreements 5.3.1 Application Context Values for and uses of Application Context names are determined by specific ASEs. Values used by ASE SIGS are listed in the clause entitled "Specific ASE Requirements." 5.3.2 AE Title Support of AE-Title-form1, the Name form, or AE-Title-form2, the Object Identifier form for sending, is dependent on the referencing specification. NOTE - AE_Title-form1 is a directory name that has to be allocated by an authorized naming authority. It is part of the responsibilities of the naming authority to determine how this name is built from its two constituents, AP-Title- form1 and AE-Qualifier-form1. NOTE - AE-Title-form2 is an Object Identifier registered by an authorized Registration Authority. It is part of that registration to determine how this Object Identifier is built from its two constituents, AP-Title-form2 and AE- Qualifier-form2. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 6.1. 9 Part 5 - Upper Layers June 1994 (Stable) 5.3.3 Peer Entity Authentication If supported, peer-entity authentication during association establishment shall be implemented as specified in Addendum 1 to ISO 8650 (ISO 8650/DAD1). 5.4 ASN.1 Encoding Rules When the Abort APDU is used during the association establishment phase, the Presentation layer negotiation is considered complete. Therefore, a PDV-list presentation-context-identifier has been assigned to the association and it should be used in the indirect-reference component of the Association Information parameter. The direct-reference component shall not be present. NOTE - The presentation context negotiation is completed by the presentation context identifier list of the ARU PPDU. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 6.2. 5.5 Connectionless The connectionless ACSE protocol shall be implemented as specified in ISO IS 10035. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 6 ROSE ROSE shall be implemented as specified in ISO DIS 9072-1.2 and ISO DIS 9072-2.2. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 10 Part 5 - Upper Layers June 1994 (Stable) 7 RTSE RTSE shall be implemented as specified in ISO 9066-1 and ISO 9066-2. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. NOTE - "If checkpointing is not used, the VALUE of windowsize is not meaningful and shall be ignored." 8 Presentation 8.1 Introduction This clause details the implementation requirements for the Presentation layer as defined in the Presentation Service Definition, ISO 8822, and the Presentation Protocol Definition, ISO 8823. The task of the Presentation layer is to carry out the negotiation of transfer syntaxes and to provide for the transformation to and from transfer syntaxes. The transformation to and from a particular transfer syntax is a local implementation issue and is not discussed within this clause. This clause is concerned with the protocol agreements, and thus is entirely devoted to the issues involved with the negotiation of transfer syntaxes and the responsibilities of the Presentation protocol. NOTE - The complete size of encoding of the CP PPDU, CPA PPDU, and CPR PPDU is derived from the SS user-data size restricted to 10 K such as specified in 9.3.5. This limitation applies also to the ARP and ARU PPDUs. 8.2 Service (Refer to clause 11.1) 11 Part 5 - Upper Layers June 1994 (Stable) 8.3 Protocol Agreements 8.3.1 Transfer Syntaxes The following transfer syntax must be supported for all mandatory abstract syntaxes; the basic encoding rules for ASN.1. This syntax is derived by applying the basic encoding rules for ASN.1 to the abstract syntax (see the Basic Encoding Rules for ASN.1, ISO 8825). The number of transfer syntaxes proposed is dependent upon the recognized transfer syntaxes which are available to support the particular abstract syntaxes used by an Application Entity. 8.3.2 Presentation Context Identifier A conformant implementation shall not encode Presentation context identifiers outside the range of 0 to 32,767. Implementations must be able to handle a minimum of two Presentation contexts per connection. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.1. 8.3.3 Default Context If the Presentation expedited data service is required, the default context must be explicitly present in the P-CONNECT PPDU at Presentation connect time. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.6. 8.3.4 P-Selectors Local P-selectors shall be a maximum of four octets. This applies only to P-selectors in PPDUs whose receipt by a workshop- conformant system normally results in either a P-CONNECT indication or a P-CONNECT confirmation being issued. If the Responding P-Selector of the CPA-PPDU is not present, it is assumed to have a value equivalent to that of the Called P- Selector of the CP-PPDU. Table 1 summarizes the handling of the 12 Part 5 - Upper Layers June 1994 (Stable) Responding-presentation selector parameters of the CP-PPDU and CPA-PPDUs. Table 1 - Called and Responding P-Selectors Responding P-Sel of CPA- PPDU Not present Length= Length>0 0 Not Note 1 Note 1 Note 2 Called P-Sel present of CP-PPDU Length=0 Note 1 Note 1 Note 2 Length>0 Note 3 Note 3 Note 2 Note 1 - The resulting value is assumed to be a null value. Note 2 - The resulting value is assumed to be the Responding P-Sel value. Note 3 - The resulting value is assumed to be the Called P-Sel value of the CP-PPDU. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.2. 8.3.5 Provider Abort Parameters (Refer to clause 11.2) 8.3.6 Provider Aborts and Session Version The Presentation Provider Abort PPDU (ARP-PPDU) shall be present regardless of the Session version in effect for a given association. This precludes the use of indefinite length encoding of an ARP-PPDU when Session Version 1 is in effect. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.7. 13 Part 5 - Upper Layers June 1994 (Stable) 8.3.7 CPC-Type Implementations shall not use any CPC-type values in the SS-user data parameter of the S-CONNECT unless more than one transfer syntax is proposed for a single Presentation context of the Presentation data values. Each CPC-type represents a unique transfer syntax, so if more than one transfer syntax is proposed, CPC-type values may appear in that SS-user data parameter. For a Presentation context for which the Basic encoding Rules are a proposed transfer syntax, all PDVs in the user data parameter of the CP PPDU must be encoded first using the Basic Encoding Rules and must be examined by the receiving Presentation protocol machine. Following CPC-type values may be examined or ignored at the receiver's option see ISO 8823, clause 6.2.5.3). Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.3. 8.3.8 Presentation-context-definition-result-list No semantics are implied by the absence of the optional Presentation-context-definition-result-list component of the CPR- PPDU. This component is required if the Provider-reason is absent in the CPR-PPDU. If the Provider-reason is present, then the Presentation-context-definition-result-list is optional. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.5. 8.3.9 RS-PPDU The Presentation-context-identifier-list shall not be present when only the kernel functional unit is in effect. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.8. 14 Part 5 - Upper Layers June 1994 (Stable) 8.4 Presentation ASN.1 Encoding Rules If a received PPDU contains any improperly encoded data values (including data values embedded within the User data field of a PPDU) and an abort is issued, then either an ARU or an ARP PPDU shall be issued. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.9. 8.5 Presentation Data Value (PDV) A Presentation data value (PDV) is a value of a type in an abstract syntax, e.g., a value of an ASN.1 type. A PDV may contain embedded PDVs in different contexts. A change of context within a PDV is indicated by an EXTERNAL. EXTERNAL implies an embedded PDV. A PDV cannot be split across PDV-lists in fully-encoded user data. Fully-encoded-data that is a series of PDVs in the same Presentation context (e.g., grouped FTAM PDUs) shall be encoded either as a single PDV-list (using the octet-aligned choice) or as a series of PDV-lists, each encoding either a single PDV (using the single-ASN1-type choice) or multiple PDVs (using the octet-aligned choice). Note that receivers must accept any of the above encodings. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.10. 8.6 Connection Oriented The Transfer-syntax-name component of a PDV-list value shall be present in a CP PPDU if and only if more than one transfer syntax name was proposed for the Presentation context of the Presentation data values. The Transfer-syntax-name component of a PDV-list value shall always be present in a CPC-type. If only the Kernel functional unit is negotiated, then the Transfer-syntax- name component of a PDV-list value shall only appear in the CP PPDU and CPC-type. Editor's Note - This clause is technically equivalent to the 15 Part 5 - Upper Layers June 1994 (Stable) Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.3. 8.7 Connectionless The connectionless Presentation protocol shall be implemented as specified in ISO 9576. The Transfer-syntax-name component of a PDV-list value shall be present in a UD PPDU if and only if more than one transfer syntax name was proposed for the Presentation context of the Presentation data values. The Transfer-syntax-name component of a PDV-list value shall always be present in a UDC-type. The Transfer-syntax-name component of a PDV-list value shall only appear in the UD PPDU and UDC-type. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 9 Session 9.1 Introduction This clause details the implementation requirements for the Session layer as defined in the Session Service Definition, ISO 8326 and the Session Protocol Definition, ISO 8327. 9.2 Services The following functional units are within the scope of a workshop-conformant system: a) Kernel; b) Duplex; c) Expedited Data; d) Resynchronize; e) Exceptions; f) Activity Management; g) Half-duplex; 16 Part 5 - Upper Layers June 1994 (Stable) h) Minor Synchronize; i) Major Synchronize; j) Typed Data; k) Data Separation. 9.3 Protocol Agreements 9.3.1 Concatenation (Refer to clause 11.3) 9.3.2 Segmenting (Refer to clause 11.4) 9.3.3 Reuse of Transport Connection (Refer to clause 11.5) 9.3.4 Use of Transport Expedited Data (Refer to clause 11.6) 9.3.5 Use of Session Version Number 9.3.5.1 Selection of session version Session versions 1 and 2 are recognized. The referencing specification shall specify in its specific upper layer requirements section which version of session is required. NOTE - Session version 2 specifies the use of unlimited user data as dictated by Addendum 2 to ISO 8327. All session version 1 implementations must be able to negotiate version 1 operation when responding to a CN SPDU proposing both version 1 and version 2. At least session version 2 shall be proposed with ACSE normal mode. With ACSE normal mode, a receiver shall support session 17 Part 5 - Upper Layers June 1994 (Stable) version 2, but may reject a proposal requesting only session version 1. NOTE - Between two conformant implementations supporting ACSE normal mode, session version 2 will be used. All session version 1 implementations, upon receipt of a CN SPDU proposing only version 2, should respond with an RF SPDU containing a reason code indicating that the proposed version is not supported. If session version 1 and 2 are both proposed in the CN SPDU, then the maximum length if the user data parameter in the CN SPDU shall be 512 octets. NOTE - In that case a PGI field of 193 will be associated with this parameter. This implies that an implementation supporting both session version 1 and 2 can establish a connection with an implementation supporting only version 1. 9.3.5.2 User data in session version 2 If only session version 2 is proposed in the CN SPDU, then a size larger than 10,240 octets of the session user data parameter value of the S-CONNECT request primitive is out of scope. This implies that sending the OA and CDO SPDUs is out of scope. Receiving the OA and CDO SPDUs is mandatory but storing and using them is out of scope. If a CDO SPDU is received but not stored or used, an RF SPDU should be issued by the responder. If an OA SPDU is received but not stored or used, a P-Abort SPDU should be issued by the initiator. NOTE - If the length of the user data parameter value is not greater than 512 octets, then an associated PGI field of 193 is used. Otherwise, a PGI field of 194 is used. When session version 2 is negotiated, then in all subsequent SPDUs a data length exceeding 10,240 octets of the user data parameter value with an associated PGI field of 193, reason code parameter value (PI = 50) for RF SPDU and user data parameter value (PI = 46) for MIA SPDU is out of scope. Session version 2 implementations need only support the maximum data lengths specified in the specific upper layer requirements section of the referencing specification, which may be less than 10,240 octets. 18 Part 5 - Upper Layers June 1994 (Stable) NOTE - For session expedited data the limit for user data is 14 octets. NOTE - These agreements impose no limitation on the size of the user information parameter of DT, TD, and CD SPDUs. Therefore, the user data of P-DATA, P-TYPED-DATA, and P- CAPABILITY-DATA is unconstrained. 9.3.6 Receipt of Invalid SPDUs Upon receipt of an invalid SPDU, the SPM shall take any action in A.4.3 of the Session Protocol Definition ISO/IS 8327 except Action d. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 9.1. 9.3.7 Invalid SPM Intersections If the conditions described in A.4.1.2 of the Session Protocol Definition ISO/IS 8327 are satisfied, the SPM shall always take the actions described by A.4.1.2 a. This implies that no S-P-EXCEPTION-REPORT indications will be generated nor EXCEPTION REPORT SPDUs sent due to invalid intersections of the Session state table resulting from received SPDUs. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 9.4. 9.3.8 S-Selectors The absence of the Called or Calling S-Sel parameter of the CN SPDU shall be treated equivalent to a zero length Called or Calling S-Sel parameter value. The absence of the Responding S-Sel parameter of the AC SPDU shall be treated as though its value were equivalent to that of the Called S-Sel parameter of the CN SPDU, i.e., the Responding S-Sel is zero length if the Called S-Sel is either absent or zero length. The Responding S-Sel parameter's value is equal to that of the Called S-Sel parameter's value if it is absent and the Called S-Sel parameter's value is greater than zero. The Responder may change the value of the Called S-Sel parameter 19 Part 5 - Upper Layers June 1994 (Stable) value of the CN SPDU by responding with the Responding S-Sel value of the AC SPDU. The absence of the Calling S-Sel parameter of the AC SPDU indicates that its value is assumed to be equivalent to the value of the Calling S-Sel parameter of the CN SPDU. Tables 2 and 3 summarize the handling of the Session Selector parameters of the CN and AC SPDUs (see also ISO 8327 8.3.1.12, 8.3.1.14, 8.3.2.14, 8.3.2.15). 20 Part 5 - Upper Layers June 1994 (Stable) Table 2 - Called and Responding S-Selectors Responding S-Sel of AC SPDU Not present Length= Length>0 0 Not Note 1 Note 1 Note 2 Called S-Sel present of CN SPDU Length=0 Note 1 Note 1 Note 2 Length>0 Note 3 Note 3 Note 2 Note 1 - The resulting value is assumed to be a null value. Note 2 - The resulting value is assumed to be the Responding S-Sel value. Note 3 - The resulting value is assumed to be the Called S-Sel value of the CN SPDU. Table 3 - Calling S-Selectors Calling S-Sel of AC SPDU Not present Length= Length>0 0 Not Note 4 Note 4 Invalid Calling S-Sel present of CN SPDU Length=0 Note 4 Note 4 Invalid Length>0 Note 5 Note 6 Invalid Note 4 - The calling S-Sel has a null value. Note 5 - The calling S-Sel has the value as indicated in the CN SPDU. Note 6 - Valid if and only if both values are identical. 21 Part 5 - Upper Layers June 1994 (Stable) 9.4 Connectionless The connectionless Session protocol shall be implemented as specified in ISO 9548. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 10 UNIVERSAL ASN.1 ENCODING RULES 10.1 TAGS The maximum value of an ASN.1 basic encoding tag that need be handled by a workshop-conformant implementation shall be 16,383. This is the maximum unsigned number that can be represented in 14 bits, therefore, the maximum encoding of a tag occupies 3 octets. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.1. 10.2 Definite Length Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.2. 10.3 External It is assumed that "Presentation layer negotiation of encoding rules" is always in effect, and therefore clause 32.5 of the Specification of ASN.1, ISO 8824 never applies. If a data value to be encapsulated in an EXTERNAL type is an instance of a single ASN.1 type encoded according to the Basic Encoding Rules for ASN.1, then the option "single-ASN.1-type" shall be chosen as its encoding. If a data value to be encapsulated in an EXTERNAL type is encoded as an integral number of octets, and the above does not apply, then the option "octet-aligned" shall be chosen as its encoding. Editor's Note - This clause is technically equivalent to the 22 Part 5 - Upper Layers June 1994 (Stable) Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.5. 10.4 Integer Any incidence of an ASN.1 INTEGER type defined in an abstract syntax describing protocol control information must be encoded so that the length of its contents octets is no more than four octets, unless an explicit Workshop agreement to the contrary is made for a specific INTEGER type. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.3. 10.5 String Types The contents octets for a constructed encoding of a BIT STRING, OCTET STRING, or character string value consists of the complete encoding of zero, one, or more data values, and the encoding of these data values must be primitive. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.6. 10.6 Extensibility For data values that are ultimately carried on the user data of the CONNECT SPDU (i.e., Presentation CP, ACSE AARQ and any APDU in the user information field of AARQ) a receiver shall a) ignore any undefined element, b) ignore all unknown bit name assignments within a bit string. NOTE - Referencing specifications may apply similar requirements to other protocol elements. 23 Part 5 - Upper Layers June 1994 (Stable) 11 Additions to ISP on Common Upper Layer Requirements 11.1 Service Only the Kernel functional unit need be supported. The Context Management and Context Restoration functional units are outside the scope of these agreements. The requirement that the Presentation kernel functional unit be implemented does not imply that any of the Session functional units for expedited data, typed data, and capability data and the corresponding Presentation service primitives are required to be implemented. 11.2 Provider Abort Parameters No conformance requirements are implied by the use of either the Abort-reason or the Event-identifier component of the ARP-PPDU. The decision to include these parameters is left up to the implementation issuing the abort. 11.3 Concatenation When a category 0 SPDU is concatenated with a category 2 SPDU, the category 0 SPDU shall not contain User Data.Extended concatenation is not required and can be refused using the normal negotiation mechanisms of the Session protocol. 11.4 Segmenting Session segmenting is not required and can be refused using the normal negotiation mechanisms of the Session protocol. All conformant implementations shall be able to interwork without Session segmenting. 11.5 Reuse of Transport Connection Reuse of a Transport connection is not required and can be refused. 24 Part 5 - Upper Layers June 1994 (Stable) 11.6 Use of Transport Expedited Data The Session use of Transport expedited service is optional. 12 Character Sets (Refer to Part 21 -- a new chapter expressly for character sets.) 13 Conformance In order for an implementation to be in conformance with the Implementors' agreements, the rules below shall be followed: a) A conformant implementation must meet all of the requirements of this specification. All documents referenced in the Upper Layers part shall be used as the supporting documents for all implementations of ACSE, ROSE, RTSE, Presentation, or Session. The full references for these documents are in clause 2. b) Workshop-conformant implementations shall be ISO conformant. PICS may contain limitations on length or value aspects of a protocol. PICS of workshop-conformant systems shall not contain restrictions more severe than those in these implementation agreements. NOTE - An implementation may abort a connection if the constraints specified in these agreements are violated. 14 Specific ASE Requirements The following list for each ASE the corresponding SIG's requirements of and restrictions on ACSE, ROSE, RTSE, Presentation, and Session. All listed requirements and restrictions shall be included in an NIST-conformant system and shall be implemented in accordance with these Implementor's agreements. 14.1 FTAM Phase 2 14.1.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: "ISO FTAM" { iso(1) standard(0) 8571 application-context iso-ftam(1) } - implies the use of the ACSE and the FTAM ASE. 25 Part 5 - Upper Layers June 1994 (Stable) A value is defined for the AE Title only to satisfy the FTAM requirement for exchanging fields of this type. This value does not identify an Application Entity and carries no semantics. If the AE title is used, AE-title-form2 shall be supported. Support of AE-title-form2 includes support of AP-title-form2 and AE-qualifier-form2. The value for the AP title is { 1 3 9999 1 ftam-nil-ap-title (7) } at this time. Values for the AE qualifier are outside the scope of these agreements. The use of AP invocation identifiers and AE invocation identifiers by FTAM is outside the scope of these agreements. 14.1.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: At least 3 Presentation Contexts must be supported. Abstract Syntaxes: a) Abstract Syntaxes for conformant Implementations 1) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } 2) "FTAM-PCI" { iso(1) standard(0) 8571 abstract-syntax(2) ftam-pci(1) } 3) "FTAM unstructured binary abstract syntax" { iso(1) standard(0) 8571 abstract-syntax(2) unstructured-binary(4) } Editor's Note - In Definitions below, "NBS" designation will be preserved. b) Abstract Syntaxes Depending on Implementation Profile 1) "FTAM-FADU" { iso(1) standard(0) abstract-syntax(2) ftam-fadu(2) } 2) "FTAM unstructured text abstract syntax" { iso(1) standard(0) 8571 abstract-syntax(2) unstructured-text(3) } 26 Part 5 - Upper Layers June 1994 (Stable) 3) "NBS abstract syntax AS1" { iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-as1(1) } 4) "NBS file directory entry abstract syntax" { iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-as2(2) } c) Associated Transfer Syntax: 1) "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1)} Editor's Note - The changes above involving "OIW(14)" were not explicitly mentioned at the March 1990 Plenary, but were implied from a correspondingly approved FTAM motion. 14.1.3 Session Requirements Session Functional Units: a) kernel b) duplex Version Number: 2 Maximum size of User Data parameter field: 10,240 14.1.4 Session Options Session Functional Units: a) resynchronize - only a Resynchronize Type value of "abandon" b) minor synchronize NOTES 1 The minor synchronize functional unit is required whenever the resynchronize functional unit is available. 2 The default value for Minor Sync Point Sync type item PV- field shall be absent if explicit confirmation is required (per ISO 8327, 8.3.20.3) (SIA->value of $). 27 Part 5 - Upper Layers June 1994 (Stable) 14.1.5 ASN.1 Encoding Requirements Some INTEGER types of the FTAM PCI may exceed the maximum size specified in the UNIVERSAL ASN.1 ENCODING Rules. See the Range of values for INTEGER type Parameters of the FTAM part. 14.2 MHS 14.2.1 Phase 1 (1984 X.400) Session Requirements Session Functional Units: a) kernel b) half-duplex c) exceptions d) activity management e) minor synchronize Version Number: 1 Maximum size of User Data parameter field: 512 NOTES 1 Restricted use is made by the RTS of the Session services implied by the functional units selected. Specifically, 1) No use is made of S-TOKEN-GIVE, and 2) S-PLEASE-TOKENS only asks for the data token. 2 In the S-CONNECT SPDU, the Initial Serial Number should not be present. 3 The format of the Connection Identifier in the S-CONNECT SPDU is described in Version 5 of the X.400-Series Implementors' Guide. 14.2.2 Phase 2, Protocol P1 (1988 X.400) 14.2.2.1 ROSE Requirements ROSE is not used. 28 Part 5 - Upper Layers June 1994 (Stable) 14.2.2.2 RTSE Requirements The RTSE requirements are: a) Monologue b) TWA - optional c) checkpointing: 1) minimum checkpointsize = 1 2) minimum windowsize = 1 d) no checkpointing For the Monologue Association: a) initiator keeps initial turn b) APDUs are transferred from initiator to responder only c) no turn passing d) only the initiator effects the orderly release of an association For the two way alternate Association a) the initiator may keep or pass the initial turn, at binding b) APDUs are transferred by the holder of the turn c) only the initiator effects the orderly release of an association, when it possesses the turn 14.2.2.3 ACSE Requirements As per Phase 2, Protocol P7. Application Contexts: a) "MTS-transfer-protocol-1984" - mandatory b) "MTS-transfer-protocol" - mandatory c) "MTS-transfer" - mandatory 29 Part 5 - Upper Layers June 1994 (Stable) 14.2.2.4 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 3 must be supported Abstract Syntaxes: a) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "MTS-RTSE" c) "MTSE" d) Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 14.2.2.5 Session Requirements As per Phase 2, Protocol P7. 14.2.3 Phase 2, Protocol P7 (1988 X.400) 14.2.3.1 ROSE Requirements Operation and association classes are used as per the standard. 14.2.3.2 RTSE Requirements The RTSE requirements are: a) TWA b) normal-mode c) checkpointing d) minimum checkpointsize = 1 e) minimum windowsize = 1 f) no checkpointing For the Monologue Association: 30 Part 5 - Upper Layers June 1994 (Stable) a) initiator keeps initial turn b) APDUs are transferred from initiator to responder only c) no turn passing d) only the initiator effects the orderly release of an association For two way alternate Association: a) the initiator may keep or pass the initial turn, at binding b) APDUs are transferred by the holder of the turn c) only the initiator effects the orderly release of an association, when it possesses the turn 14.2.3.3 ACSE Requirements ACSE Functional Requirements: Kernel The use of AP-TITLE, AE-QUALIFIER, AP-INVOCATION-ID, and AE- INVOCATION-ID is not recommended; however, a receiving entity must be capable of ignoring them (if present) without refusing the connection. Application Contexts: a) "MS-access" - mandatory; normal mode b) "MS-reliable-access" - optional; normal mode 14.2.3.4 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 5 Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) MSBind/MSUnbind (with or without RTSE) 31 Part 5 - Upper Layers June 1994 (Stable) c) MSSE (Message Submission) d) MASE (Message Administration) e) MRSE (Message Retrieval) Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 14.2.3.5 Session Requirements Session Functional Units: a) kernel b) half-duplex (if RTSE is supported) c) full-duplex (if RTSE is not supported) d) exceptions e) activity management f) minor synchronize Version Number: 2 Maximum size of User Data parameter field: 10,240 NOTES 1 MHS proposes both versions 1 and 2 for pass through mode (X.410 mode), but only version 2 for normal mode. 2 Restricted use is made by the RTS of the Session services implied by the functional units selected. Specifically, no use is made of S-TOKEN-GIVE, and S-PLEASE-TOKENS only asks for the data token. 3 In the S-CONNECT SPDU, the Initial Serial Number should not be present. 4 The format of the Connection Identifier in the S-CONNECT SPDU is described in Version 5 of the X.400-Series Implementors' Guide. 32 Part 5 - Upper Layers June 1994 (Stable) 14.2.4 Phase 2, Protocol P3 (1988 X.400) 14.2.4.1 ROSE Requirements As per Phase 2, P7. 14.2.4.2 RTSE Requirements As per Phase 2, P7. 14.2.4.3 ACSE Requirements As per Phase 2, P7. Application Contexts: a) "MTS-access" - mandatory b) "MTS-reliable-access" - optional c) "MTS-forced-access" - mandatory d) "MTS-forced-reliable-access" - optional 14.2.4.4 Presentation Requirements As per Phase 2, P7. 14.2.4.5 Session Requirements As per Phase 2, P7. 14.3 DS Phase 1 14.3.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: a) "id-ac-directoryAccessAC" { joint-iso-ccitt(2) ds(5) 3 1 } 33 Part 5 - Upper Layers June 1994 (Stable) b) "id-ac-directorySystemAC" { joint-iso-ccitt(2) ds(5) 3 2 } 14.3.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: At least 2 Presentation Contexts must be supported. Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "id-as-directoryAccessAS" joint-iso-ccitt(2) ds(5) 9 1 } c) "id-as-directorySystemAS" { joint-iso-ccitt(2) ds(5) 9 2 } Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 14.3.3 Session Requirements Session Functional Units: a) kernel b) duplex Version Number: 2 Maximum size of User Data parameter field: 10,240 14.4 Virtual Terminal 14.4.1 Phase 1a 14.4.1.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: "ISO VT" { iso(1) standard(0) 9041 34 Part 5 - Upper Layers June 1994 (Stable) application-context(1) }- implies the use of the ACSE and the VT ASE 14.4.1.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 2 must be supported Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "VT Basic" { iso(1) standard(0) 9041 abstract-syntax(2) } Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 14.4.1.3 Session Requirements Session Functional Units: a) kernel b) duplex c) expedited data d) major synchronize e) resynchronize - only a Resynchronize Type value of "restart" f) typed data Version Number: 2 Maximum size of User Data parameter field: 10,240 Session Options: expedited data 35 Part 5 - Upper Layers June 1994 (Stable) 14.4.2 Phase 1b 14.4.2.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: "ISO VT" { iso(1) standard(0) 9041 application-context(1) } - implies the use of the ACSE and the VT ASE 14.4.2.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 2 must be supported Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "VT Basic" { iso(1) standard(0) 9041 abstract-syntax(2) } Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 14.4.2.3 Session Requirements Session Functional Units: a) kernel b) duplex c) half-duplex d) expedited data e) major synchronize f) resynchronize - only a Resynchronize Type value of "restart" g) typed data 36 Part 5 - Upper Layers June 1994 (Stable) Version Number: 2 Maximum size of User Data parameter field: 10,240 Session Options: expedited data 14.5 MMS 14.5.1 ACSE Requirements ACSE Functional Units: Kernel Application Context: "ISO MMS" { iso(1) standard(0) 9506 part(2) mms-application-context-version1(3)} - implies use of ACSE and MMS ASE 14.5.2 Constructed Encodings Constructed encodings shall not be used for bit strings shorter than 256 bits, nor for octet strings (or types derived from octet strings by tagging) shorter than 1024 octets. For such strings, only primitive encodings shall be used. Upon receipt of a constructed bit string or octet string that violates this restriction, the receiving implementation may reject the corresponding PDU, but shall not send a P-P-Abort. 14.5.3 Presentation Requirements Presentation Functional Units: Kernel At least 2 Presentation Contexts must be supported. Abstract Syntaxes: a) "mms-abstract-syntax-major-version1" { iso(1) standard(0) 9506 part(2) mms-abstract-syntax-major-version1 (1)} b) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association- control(2) abstract-syntax(1) apdus(0) version1(1)} Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" {joint-iso-ccitt(2) asn1(1) basic-encoding(1)} 37 Part 5 - Upper Layers June 1994 (Stable) 14.5.4 Session Requirements Session Functional Units: a) Kernel b) Duplex Version Number: 2 Maximum size of User Data parameter field: 10,240 14.6 Transaction Processing 14.6.1 ACSE Requirements ACSE Functional Units: Kernel The application context is user-defined. 14.6.2 Presentation Requirements Presentation Functional Units: Kernel Presentation Contexts: a) At least 3 must be supported if the commit functional unit of TP is not supported. b) At least 4 must be supported if the commit functional unit of TP is supported. Abstract Syntaxes: "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } Associated Transfer Syntax: a) "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } b) "ISO 10026-TP" { joint-iso-ccitt(2) transaction- processing(?) abstract-syntax(2) tp-apdus(1) } c) If required, "ISO 9804-CCR" (TBD) d) At least one user-defined abstract syntax. 38 Part 5 - Upper Layers June 1994 (Stable) 14.6.3 Session Requirements Session Functional Units: a) kernel b) duplex c) Others as required by CCR (TBD) if the commit functional unit of TP is supported. Version Number: 2 Maximum size of User Data parameter field: 10,240 14.7 Network Management 14.7.1 ROSE Requirements The Rose requirements are as specified in ISO 9596 section 5.2: Underlying Services, and section 6.2 Remote Operations. Operations Classes: 1, 2, and 5 Association Classes: 3 14.7.2 ACSE Requirements ACSE Functional Units: kernel Application Contexts: as defined by [SMO] AE-Title: The association responder shall support both forms of the AE-Title. The association requestor may use either form of the AE-Title. 14.7.3 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: At least 2 must be supported. Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) 39 Part 5 - Upper Layers June 1994 (Stable) version1(1) } b) "CMIP-PCI" {joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1) abstractSyntax(4)} Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 14.7.4 Session Requirements Session Functional Units: a) kernel b) duplex Version Number: 2 Maximum size of User Data parameter field: 10,240. 14.8 Remote Database Access Editor's Note - Refer to the Working Agreements Document. The intent is replace clause 14.8 with completed tables from ISO DISP 11188-3. 14.8.1 ACSE Requirements ACSE Functional Units: Kernel Application Contexts: a) "RDA-SQL-BASIC-APPL-CONTEXT-V1" {iso(1) standard(0) rda(9579) part-2(2) basic-ac(2) version-1(1)} implies use of the ACSE and RDA SQL ASEs; b) "RDA-SQL-TP-APPL-CONTEXT-V1" {iso(1) standard(0) rda(9579) part-2(2) tp-ac(3) version-1(1)} implies use of the ACSE, RDA SQL, TP, and optionally CCR ASEs. 14.8.2 Presentation Requirements Presentation Functional Units: Kernel 40 Part 5 - Upper Layers June 1994 (Stable) 14.8.2.1 Presentation Contexts for the RDA Basic Application Context At least 2 presentation contexts must be supported; Abstract Syntaxes: a) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association- control(2) abstract-syntax(1) apdus(0) version1(1)}; b) "RDA-SQL-ABSTRACT-SYNTAX-V1" {iso(1) standard(0) rda(9579) part-2(2) abstract-syntax(1) version-1(1)}; Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type"{joint-iso-ccitt(2) asn1(1)basic-encoding(1)}; 14.8.2.2 Presentation Contexts for the RDA TP Application Context At least 3 presentation contexts must be supported, if the commit functional unit of TP is not supported. At least four presentation contexts must be supported, if the commit functional unit of TP is supported. Abstract Syntaxes: a) "ISO 8650-ACSE1" {joint--iso-ccitt(2) association- control(2) abstract-syntax(1) apdus(0) version1(1)}; b) "RDA-SQL-ABSTRACT-SYNTAX-V1" {iso(1) standard(0) rda(9579) part-2(2) abstract-syntax(1) version-1(1)}; c) "ISO 10026-TP" {joint-iso-ccitt(2) transaction processing(10) modules(1) apdus-abstract-syntax(1) version1 (0)}; d) If required, "ISO 9805-CCR" {joint-iso-ccitt(2) ccr(7) abstract-syntax(2) apdus(1) version1 (1)}. Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" {joint-iso-ccitt(2) asn1(1) basic-encoding(1)}. 14.8.3 Session Requirements Session Functional Units: a) Kernel; 41 Part 5 - Upper Layers June 1994 (Stable) b) Duplex; Version: 2: Maximum size of User Data parameter field: 10,240. 42 Part 5 - Upper Layers June 1994 (Stable) Annex A (normative) Object Identifier Register Editor's Note - Annexes A and B have been switched to place the informative annex after the normative annex. A.1 Register Index Each entry in the index contains an object identifier value and a reference to the clause describing the object identifier's use: a) { iso(1) identified-organization(3) oiw(14) ulsig(8) application-context(1) nil(1) } is defined in 14.2; b) { iso(1) identified-organization(3) oiw(14) ulsig(8) abstract-syntax(2) octet-string(1) } is defined in 14.2. A.2 Object Identifier Descriptions { iso(1) identified-organization(3) oiw(14) ulsig(8) application-context(1) nil(1) } This application context may be used by applications having a prior agreement regarding the application context. NOTE - This value is intended to be used by private applications that have an a priori agreement concerning the set of ASEs, related options, and any other information necessary for the interworking of AEs on an application association. This value does not identify any specific application context and cannot be used to identify the intended communications environment for the application association. Therefore, it is strongly recommended that private applications define and register an object identifier for their application context. { iso(1) identified-organization(3) oiw(14) ulsig(8) abstract-syntax(2) octet-string(1) } 43 Part 5 - Upper Layers June 1994 (Stable) +---------------------------------------------------------+ | NIST-OIW-ULSIG-AS-octet-string | | DEFINITIONS ::= BEGIN | | | | Single-octet-string ::= OCTET STRING | | END | +---------------------------------------------------------+ This abstract syntax may be used by applications having a prior agreement regarding the content of the octet string. 44 Part 5 - Upper Layers June 1994 (Stable) Annex B (informative) Recommended Practices Editor's Note - Annexes A and B have been switched to place the informative annex after the normative annex. The optional "Reflect Parameter Values" parameter in the Provider ABORT SPDU shall be encoded so as to represent the Session connection state, the incoming event and the first invalid SPDU field exactly at the moment a protocol error was detected. The first octet encodes the Session state as a number relative to 0 as detailed in table 1. The second octet encodes the incoming event as a number relative to 0 as detailed in table 2. The third octet contains the SI, PGI, or PI Code of any SI field, PGI unit or PI unit in error. NOTE - The remaining 6 octets are undefined herein. 45 Part 5 - Upper Layers June 1994 (Stable) Table A.1 - Session States +-------+-----+--------------------------------------------------------------+ | State | Rel | Description | +-------+-----+--------------------------------------------------------------+ | 1 | 0 | Idle, no transport connection | | 1B | 1 | Wait for T-connect confirm | | 1C | 2 | Idle, transport connected | | 2A | 3 | Wait for the ACCEPT SPDU | | 3 | 4 | Wait for the DISCONNECT SPDU | | 8 | 5 | Wait for the S-CONNECT response | | 9 | 6 | Wait for the S-RELEASE response | | 16 | 7 | Wait for the T-DISCONNECT indication | | 713 | 8 | Data Transfer state | | 1A | 9 | Wait for the ABORT ACCEPT SPDU | | 4A | 10 | Wait for the MAJOR SYNC ACK SPDU or PREPARE SPDU | | 4B | 11 | Wait for the ACTIVITY END ACK SPDU or PREPARE SPDU | | 5A | 12 | Wait for the RESYNCHRONIZE ACK SPDU or PREPARE SPDU | | 5B | 13 | Wait for the ACTIVITY INTERRUPT SPDU or PREPARE SPDU | | 5C | 14 | Wait for the ACTIVITY DISCARD ACK SPDU or PREPARE SPDU | | 6 | 15 | Wait for the RESYNCHRONIZE SPDU or PREPARE SPDU | | 10A | 16 | Wait for the S-SYNC-MAJOR response | | 10B | 17 | Wait for the S-ACTIVITY-END response | | 11A | 18 | Wait for the S-RESYNCHRONIZE response | | 11B | 19 | Wait for the S-ACTIVITY-INTERRUPT response | | 11C | 20 | Wait for the S-ACTIVITY-DISCARD response | | 15A | 21 | After PREPARE, wait for the MAJOR SYNC ACK SPDU | | | | or the ACTIVITY END ACK | | 15B | 22 | After PREPARE, wait for the RESYNCHRONIZE SPDU | | | | or the ACTIVITY DISCARD SPDU | | 15C | 23 | After PREPARE, wait for the RESYNCHRONIZE ACK SPDU, | | | | or the ACTIVITY INTERRUPT ACK SPDU | | | | or the ACTIVITY DISCARD ACK SPDU | | 18 | 24 | Wait for GIVE TOKENS ACK SPDU | | 19 | 25 | Wait for a recovery request or SPDU | | 20 | 26 | Wait for a recovery SPDU or request | | 21 | 27 | Wait for the CAPABILITY DATA ACK SPDU | | 22 | 28 | Wait for the S-CAPABILITY-DATA response | | 1D | 29 | Wait for the CONNECT DATA OVERFLOW SPDU | | 2B | 30 | Wait for the OVERFLOW ACCEPT SPDU | | 15D | 31 | After PREPARE, wait for the ABORT SPDU | +-------+-----+--------------------------------------------------------------+ 46 Part 5 - Upper Layers June 1994 (Stable) Table A.2 - Incoming Events +-------------+-----+----------------------------------------------+ | Event | Rel | Description | +-------------+-----+----------------------------------------------+ | SCONreq | 0 | S-CONNECT request | | SCONrsp | 1 | S-CONNECT accept response | | SCONrsp | 2 | S-CONNECT reject response | | SDTreq | 3 | S-DATA request | | SRELreq | 4 | S-RELEASE request | | SRELrsp | 5 | S-RELEASE accept response | | SUABreq | 6 | S-U-ABORT request | | TCONcnf | 7 | T-CONNECT confirmation | | TCONind | 8 | T-CONNECT indication | | TDISind | 9 | T-DISCONNECT indication | | TIM | 10 | Time out | | AA | 11 | ABORT ACCEPT | | AB-nr | 12 | ABORT - no reuse | | AC | 13 | ACCEPT | | CN | 14 | CONNECT | | DN | 15 | DISCONNECT | | DT | 16 | DATA TRANSFER | | FN-nr | 17 | FINISH - no reuse | | RF-nr | 18 | REFUSE - no reuse | | SACTDreq | 19 | S-ACTIVITY-DISCARD request | | SACTDrsp | 20 | S-ACTIVITY-DISCARD response | | SACTEreq | 21 | S-ACTIVITY-END request | | SACTErsp | 22 | S-ACTIVITY-END response | | SACTIreq | 23 | S-ACTIVITY-INTERRUPT request | | SACTIrsp | 24 | S-ACTIVITY-INTERRUPT response | | SACTRreq | 25 | S-ACTIVITY-RESUME request | | SACTSreq | 26 | S-ACTIVITY-START request | | SCDreq | 27 | S-CAPABILITY-DATA request | | SCDrsp | 28 | S-CAPABILITY-DATA response | | SCGreq | 29 | S-CONTROL-GIVE request | | SEXreq | 30 | S-EXPEDITED-DATA request | | SGTreq | 31 | S-TOKEN-GIVE request | | SPTreq | 32 | S-TOKEN-PLEASE request | | SRELrsp | 33 | S-RELEASE response reject | | SRSYNreq(a) | 34 | S-RESYNCHRONIZE request abandon | | SRSYNreq(r) | 35 | S-RESYNCHRONIZE request restart | | SRSYNreq(s) | 36 | S-RESYNCHRONIZE request set | | SRSYNrsp | 37 | S-RESYNCHRONIZE response | | SSYNMreq | 38 | S-SYNC-MAJOR request | | SSYNMrsp | 39 | S-SYNC-MAJOR response | | SSYNmreq | 40 | S-SYNC-MINOR request | | SSYNmrsp | 41 | S-SYNC-MINOR response | | STDreq | 42 | S-TYPED-DATA request | | SUERreq | 43 | S-U-EXCEPTION-REPORT request | +-------------+-----+----------------------------------------------+ 47 Part 5 - Upper Layers June 1994 (Stable) Table A.2 - Incoming Events (continued) +-------------+-----+----------------------------------------------+ | Event | Rel | Description | +-------------+-----+----------------------------------------------+ | AB-r | 44 | ABORT - reuse SPDU | | AD | 45 | ACTIVITY DISCARD SPDU | | ADA | 46 | ACTIVITY DISCARD ACK SPDU | | AE | 47 | ACTIVITY END SPDU | | AEA | 48 | ACTIVITY END ACK SPDU | | AI | 49 | ACTIVITY INTERRUPT SPDU | | AIA | 50 | ACTIVITY INTERRUPT ACK SPDU | | AR | 51 | ACTIVITY RESUME SPDU | | AS | 52 | ACTIVITY START SPDU | | CD | 53 | CAPABILITY DATA SPDU | | CDA | 54 | CAPABILITY DATA ACK SPDU | | ED | 55 | EXCEPTION DATA SPDU | | ER | 56 | EXCEPTION REPORT SPDU | | EX | 57 | EXPEDITED DATA SPDU | | FN-r | 58 | FINISH - reuse SPDU | | GT | 59 | GIVE TOKENS SPDU | | GTA | 60 | GIVE TOKENS ACK SPDU | | GTC | 61 | GIVE TOKENS CONFIRM SPDU | | MAA | 62 | MAJOR SYNC ACK SPDU | | MAP | 63 | MAJOR SYNC POINT SPDU | | MIA | 64 | MAJOR SYNC ACK SPDU | | MIP | 65 | MINOR SYNC POINT SPDU | | NF | 66 | NOT FINISHED SPDU | | PR-MAA | 67 | PREPARE (MAJOR SYNC ACK) SPDU | | PR-RA | 68 | PREPARE (RESYNCHRONIZE ACK) SPDU | | PR-RS | 69 | PREPARE (RESYNCHRONIZE) SPDU | | PT | 70 | PLEASE TOKENS SPDU with Token Item Paramet r | | RA | 71 | RESYNCHRONIZE ACK SPDU | | RF-r | 72 | REFUSE - reuse SPDU | | RS-a | 73 | RESYNCHRONIZE - abandon SPDU | | RS-r | 74 | RESYNCHRONIZE - restart SPDU | | RS-s | 75 | RESYNCHRONIZE - set SPDU | | TD | 76 | TYPED DATA SPDU | | CDO | 77 | CONNECT DATA OVERFLOW SPDU | | OA7 | 8O | VERFLOW ACCEPT SPDU | | PR-AB | 79 | PREPARE (ABORT) SPDU | +-------------+-----+----------------------------------------------+ 48 Part 5 - Upper Layers June 1994 (Stable) Annex C (normative) Draft of new ISP on Minimal OSI facilities Editor's Note - This annex contains the stable text of ISO/IEC DISP 11188- 3. Editor's Note - Electronic readers should refer to the Word for Windows 2.0 document, mosi_jul.doc for the contents of the profile. WordPerfect 5.1 formatted focuments mosi_exr.w51, mosi-iss.w51, and culr-sch.w51 contain text related to the mOSI ISP. mosi_exr.w51 contains the Explanatory Report which is submitted to SGFS. mosi-iss.w51 contains the issues for the profile. culr-sch.w51 contans the current schedule for progression of all common upper layer ISPs. 49