Working Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers Output from the September 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: James Quigley, Hewlett Packard SIG Editors: Debbie Britt, NCTS Laura Emmons, Telenex Part 5 - Upper Layers September 1993 (Working) Foreword This part of the Working Implementation Agreements was prepared by the Upper Layers Special Interest Group (ULSIG) of the for Open Systems Environment Implementors' Workshop (OIW). See Procedures Manual for Workshop charter. Text in this part has been approved by the Plenary of the above- mentioned Workshop. This part replaces the previously existing chapter on this subject. Only the pages that were changed in September 1993 are being printed. Please refer to the June 1993 Working Document for additional information. Future changes and additions to this version of these Implementor Agreements will be published as a new part. Deleted and replaced text will be shown as struck. New and replacement text will be shown as shaded. ii Part 5 - Upper Layers September 1993 (Working) Table of Contents Part 5 - Upper Layers . . . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 1 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 1 4.1 ISO Defect Solutions . . . . . . . . . . . . . . . . 1 4.2 Session Defect Solutions Correcting CCITT X.215 and X.225 . . . . . . . . . . . . . . . . . . . . . . . 1 5 Association Control Service Element . . . . . . . . . . . 2 5.1 Introduction . . . . . . . . . . . . . . . . . . . . 2 5.2 Services . . . . . . . . . . . . . . . . . . . . . . 2 5.3 Protocol Agreements . . . . . . . . . . . . . . . . 2 5.3.1 Application Context . . . . . . . . . . . . 2 5.3.2 AE Title . . . . . . . . . . . . . . . . . 2 5.3.3 Peer Entity Authentication . . . . . . . . 2 5.4 Abort APDU . . . . . . . . . . . . . . . . . . . . . 2 5.5 Connectionless . . . . . . . . . . . . . . . . . . 3 6 ROSE . . . . . . . . . . . . . . . . . . . . . . . . . . 3 7 RTSE . . . . . . . . . . . . . . . . . . . . . . . . . . 3 8 Presentation . . . . . . . . . . . . . . . . . . . . . . 3 8.1 Introduction . . . . . . . . . . . . . . . . . . . . 3 8.2 Service . . . . . . . . . . . . . . . . . . . . . . 3 8.3 Protocol Agreements . . . . . . . . . . . . . . . . 4 8.3.1 Transfer Syntaxes . . . . . . . . . . . . . 4 8.3.2 Presentation Context Identifier . . . . . . 4 8.3.3 Default Context . . . . . . . . . . . . . . 4 8.3.4 P-Selectors . . . . . . . . . . . . . . . . 4 8.3.5 Provider Abort Parameters . . . . . . . . . 4 8.3.6 Provider Aborts and Session Version . . . . 5 8.3.7 CPC-Type . . . . . . . . . . . . . . . . . 5 8.3.8 Presentation-context-definition-result-list 5 8.3.9 RS-PPDU . . . . . . . . . . . . . . . . . . 5 8.4 Presentation ASN.1 Encoding Rules . . . . . . . . . 5 8.5 Presentation Data Value (PDV) . . . . . . . . . . . 5 8.6 Connection Oriented . . . . . . . . . . . . . . . . 6 8.7 Connectionless . . . . . . . . . . . . . . . . . . . 6 iii Part 5 - Upper Layers September 1993 (Working) 9 Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1 Introduction . . . . . . . . . . . . . . . . . . . . 6 9.2 Services . . . . . . . . . . . . . . . . . . . . . . 6 9.3 Protocol Agreements . . . . . . . . . . . . . . . . 6 9.3.1 Concatenation . . . . . . . . . . . . . . . 6 9.3.2 Segmenting . . . . . . . . . . . . . . . . 6 9.3.3 Reuse of Transport Connection . . . . . . . 7 9.3.4 Use of Transport Expedited Data . . . . . . 7 9.3.5 Use of Session Version Number . . . . . . . 7 9.3.5.1 Selection of session version . . . . . . . 7 9.3.5.2 User data in session version 2 . . . . . . 7 9.3.6 Receipt of Invalid SPDUs . . . . . . . . . 7 9.3.7 Invalid SPM Intersections . . . . . . . . . 7 9.3.8 S-Selectors . . . . . . . . . . . . . . . . 8 9.4 Connectionless . . . . . . . . . . . . . . . . . . . 8 10 Universal ASN.1 Encoding Rules . . . . . . . . . . . . . 8 10.1 Tags . . . . . . . . . . . . . . . . . . . . . . . . 8 10.2 Definite Length . . . . . . . . . . . . . . . . . . 8 10.3 External . . . . . . . . . . . . . . . . . . . . . . 8 10.4 Integer . . . . . . . . . . . . . . . . . . . . . . 8 10.5 String Types . . . . . . . . . . . . . . . . . . . . 9 10.6 Extensibility . . . . . . . . . . . . . . . . . . . 9 11 Additions to ISP on Common Upper Layer Requirements . . . 9 11.1 Service . . . . . . . . . . . . . . . . . . . . . . 9 11.2 Provider Abort Parameters . . . . . . . . . . . . . 9 11.3 Concatenation . . . . . . . . . . . . . . . . . . . 9 11.4 Segmenting . . . . . . . . . . . . . . . . . . . . . 10 11.5 Reuse of Transport Connection . . . . . . . . . . . 10 11.6 Use of Transport Expedited Data . . . . . . . . . . 10 12 Character Sets . . . . . . . . . . . . . . . . . . . . . 10 13 Conformance . . . . . . . . . . . . . . . . . . . . . . . 10 14 Specific ASE Requirements . . . . . . . . . . . . . . . . 10 14.1 FTAM Phase 2 . . . . . . . . . . . . . . . . . . . . 10 14.2 MHS . . . . . . . . . . . . . . . . . . . . . . . . 10 14.3 DS Phase 1 . . . . . . . . . . . . . . . . . . . . . 11 14.4 Virtual Terminal . . . . . . . . . . . . . . . . . . 11 14.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . 11 14.6 Transaction Processing . . . . . . . . . . . . . . . 11 14.6.1 ACSE Requirements . . . . . . . . . . . . . 11 14.6.2 Presentation Requirements . . . . . . . . . 11 14.6.3 Session Requirements . . . . . . . . . . . 12 14.7 Network Management . . . . . . . . . . . . . . . . . 12 14.8 Remote Database Access . . . . . . . . . . . . . . . 12 14.8.1 ACSE Requirements . . . . . . . . . . . . . 12 14.8.2 Presentation Requirements . . . . . . . . . 12 iv Part 5 - Upper Layers September 1993 (Working) 1 4 . 8 . 2 . 1 Presentation Contexts for the RDA Basic Application Context . . . . . . . . . . . . . . . . . . . 12 1 4 . 8 . 2 . 2 Presentation Contexts for the RDA TP Application Context . . . . . . . . . . . . . . . . . . . 13 14.8.3 Session Requirements . . . . . . . . . . . 13 Annex A (normative) Object Identifier Register . . . . . . . . . . . . . . . . . 14 A.1 Register Index . . . . . . . . . . . . . . . . . . . 14 A.2 Object Identifier Descriptions . . . . . . . . . . . 14 Annex B (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 15 Annex C (informative) Backward Compatibility . . . . . . . . . . . . . . . . . . . 16 Annex D (normative) Working Draft of new ISP on mOSI Specification . . . . . . . 20 v Part 5 - Upper Layers Editor's Note - All references to Stable Agreements in this section are to Version 5. Editor's Note - Clauses 1 through 12 will be replaced by appropriate references to ISP 11188-1 (Common Upper Layers Requirements). 0 Introduction (Refer to Stable Agreements Document) 1 Scope (Refer to Stable Agreements Document) 2 Normative References (Refer to Stable Agreements Document) 3 Status This version of the upper layer agreements is under development. 4 Errata 4.1 ISO Defect Solutions (Refer to Stable Agreements Document) 4.2 Session Defect Solutions Correcting CCITT X.215 and X.225 (Refer to Stable Agreements Document) 1 Part 5 - Upper Layers September 1993 (Working) 5 Association Control Service Element 5.1 Introduction (Refer to Stable Agreements Document) 5.2 Services (Refer to Stable Agreements Document) 5.3 Protocol Agreements 5.3.1 Application Context (Refer to Stable Agreements Document) 5.3.2 AE Title (Refer to Stable Agreements Document) Editor's Note - 5.3.3 Peer Entity Authentication (Refer to Stable Agreements Document) 5.4 Abort APDU (Refer to Stable Agreements Document) Editor's Note - 2 Part 5 - Upper Layers September 1993 (Working) 5.5 Connectionless (Refer to Stable Agreements Document) 6 ROSE (Refer to Stable Agreements Document) 7 RTSE (Refer to Stable Agreements Document) NOTE - "If checkpointing is not used, the VALUE of windowsize is not meaningful and shall be ignored." 8 Presentation 8.1 Introduction (Refer to Stable Agreements Document) NOTE - 8.2 Service Editor's Note - Refer to Clause 11.1 of the Working Agreements Document. 3 Part 5 - Upper Layers September 1993 (Working) 8.3 Protocol Agreements 8.3.1 Transfer Syntaxes (Refer to the Stable Agreements Document) 8.3.2 Presentation Context Identifier (Refer to Stable Agreements Document) Editor's Note - 8.3.3 Default Context (Refer to Stable Agreements Document) Editor's Note - 8.3.4 P-Selectors (Refer to the Stable Agreements Document) Editor's Note - 8.3.5 Provider Abort Parameters Editor's Note - See Clause 11.2 of the Working Agreements Document. 8.3.6 Provider Aborts and Session Version (Refer to the Stable Agreements Document) Editor's Note - 4 Part 5 - Upper Layers September 1993 (Working) 8.3.7 CPC-Type (Refer to the Stable Agreements Document) Editor's Note - 8.3.8 Presentation-context-definition-result-list (Refer to the Stable Agreements Documents) Editor's Note - 8.3.9 RS-PPDU (Refer to the Stable Agreements Documents) Editor's Note - 8.4 Presentation ASN.1 Encoding Rules (Refer to the Stable Agreements Document) Editor's Note - 8.5 Presentation Data Value (PDV) (Refer to the Stable Agreements Document) Editor's Note - 8.6 Connection Oriented (Refer to the Stable Agreements Document) Editor's Note - 5 Part 5 - Upper Layers September 1993 (Working) 8.7 Connectionless (Refer to Stable Agreements Document) 9 Session 9.1 Introduction (Refer to Stable Agreements Document) 9.2 Services (Refer to Stable Agreements Document) 9.3 Protocol Agreements 9.3.1 Concatenation Editor's Note - Refer to Clause 11.3 of the Working Agreements Document. 9.3.2 Segmenting Editor's Note - Refer to Clause 11.4 of the Working Agreements Document. 9.3.3 Reuse of Transport Connection Editor's Note - Refer to Clause 11.5 of the Working Agreements Document. 6 Part 5 - Upper Layers September 1993 (Working) 9.3.4 Use of Transport Expedited Data Editor's Note - Refer to Clause 11.6 of the Working Agreements Document. 9.3.5 Use of Session Version Number 9.3.5.1 Selection of session version (Refer to the Stable Agreements Documents) NOTE - 9.3.5.2 User data in session version 2 (Refer to the Stable Agreements Document) NOTE - 9.3.6 Receipt of Invalid SPDUs (Refer to the Stable Agreements Document) Editor's Note - 9.3.7 Invalid SPM Intersections (Refer to the Stable Agreements Document) Editor's Note - 9.3.8 S-Selectors (Refer to the Stable Agreements Document) 7 Part 5 - Upper Layers September 1993 (Working) 9.4 Connectionless (Refer to Stable Agreements Document) 10 Universal ASN.1 Encoding Rules 10.1 Tags (Refer to the Stable Agreements Document) Editor's Note - 10.2 Definite Length (Refer to the Stable Agreements Document) 10.3 External (Refer to the Stable Agreements Document) Editor's Note - 10.4 Integer (Refer to the Stable Agreements Document) Editor's Note - 10.5 String Types (Refer to the Stable Agreements Document) Editor's Note - 8 Part 5 - Upper Layers September 1993 (Working) 10.6 Extensibility (Refer to the Stable Agreements Document) NOTE - 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. 9 Part 5 - Upper Layers September 1993 (Working) 11.5 Reuse of Transport Connection Reuse of a Transport connection is not required and can be refused. 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 (Refer to Stable Agreements Document) 14 Specific ASE Requirements 14.1 FTAM Phase 2 (Refer to Stable Agreements Document) 14.2 MHS (Refer to Stable Agreements Document) 14.3 DS Phase 1 (Refer to Stable Agreements Document) 14.4 Virtual Terminal (Refer to Stable Agreements Document) 10 Part 5 - Upper Layers September 1993 (Working) 14.5 MMS (Refer to Stable Agreements Document) 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. 11 Part 5 - Upper Layers September 1993 (Working) 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 (Refer to Stable Agreements Document) 14.8 Remote Database Access 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 14.8.2.1 Presentation Contexts for the RDA Basic Application Context At least 2 presentation contexts must be supported; Abstract Syntaxes: 12 Part 5 - Upper Layers September 1993 (Working) 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; b) Duplex; Version: 2: Maximum size of User Data parameter field: 10,240. 13 Part 5 - Upper Layers September 1993 (Working) 14 Part 5 - Upper Layers September 1993 (Working) Annex A (normative) Object Identifier Register A.1 Register Index (Refer to Stable Agreements Document) A.2 Object Identifier Descriptions (Refer to Stable Agreements Document) 15 Part 5 - Upper Layers September 1993 (Working) Annex B (informative) Recommended Practices (Refer to Stable Agreements Document.) 16 Part 5 - Upper Layers September 1993 (Working) Annex C (informative) Backward Compatibility 17 Part 5 - Upper Layers September 1993 (Working) +---------------------------------------------------------------- ------------+ | Version & Section | +----------------------------+---------------+------------------- ------------+ | Issue | Changed | Backward Compatibility | +----------------------------+---------------+------------------- ------------+ | Restrictions on minimum | V1E2 5.5.3.2 | Interworking problems may | | number of octets | | occur, since implementations | | implementations shall be | | could send more than 128 | | able to receive. | | octets. [An implementation | | | | that conforms to versions | | | | previous to V1E2 as an | | | | initiator and V3E1 as a | | | | responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ | Agreements on AE Title, | V1E3 section | Interworking problems may | | AP Title, and AE Qualifier | 5.5.3.3 & | occur between implementations | | changed. | V1E4 section | that expect different forms of| | | 5.5.3.3 | AP Title and AE Qualifier | | | | to be used. [Implementations | | | | that accept any form of these | | | | parameters will interwork with| | | | initiators that conform to | | | | earlier versions.] | +----------------------------+---------------+------------------- ------------+ 18 Part 5 - Upper Layers September 1993 (Working) | Restrictions on encoding | V2E1 section | Interworking problems may | | of "Presentation Context | 5.8.3.3 | occur since implementations | | Identifier." | | could encode negative | | | | numbers. [An implementation | | | | that conforms to versions | | | | previous to V2E1 as a | | | | responder and V3E1 as an | | | | initiator will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ | Mode selector as first | V1E4 section | This will cause interworking | | element in set | 5.6.3.4 | problems for those | | | | implementations that don't | | | | encode "mode selector" as the | | | | first element in the set. [An | | | | implementation that conforms | | | | to versions previous to V1E4 | | | | as an initiator and V3E1 as | | | | a responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ 19 Part 5 - Upper Layers September 1993 (Working) +---------------------------------------------------------------- ------------+ | Version & Section | +----------------------------+---------------+------------------- ------------+ | Issue | Changed | Backward Compatibility | +----------------------------+---------------+------------------- ------------+ | Restrictions on encoding | V2E1 section | This will cause interworking | | of "protocol version" and | 5.8.4.2 | problems for those | | "presentation | | implementations expecting | | requirements." | | "protocol version" and | | | | "presentation requirements" | | | | to be encoded in the primitive| | | | form. [An implementation that| | | | conforms to versions previous | | | | to V2E1 as an initiator and | | | | V3E1 as a responder will be | | | | able to interoperate.] | +----------------------------+---------------+------------------- ------------+ | Restrictions on encoding | V2E1 section | This will cause interworking | | of "presentation selector."| 5.8.4.3 | problems for those | | | | implementations expecting | | | | "presentation selector" to be | | | | encoded in the primitive form.| | | | [An implementation that | | | | conforms to versions previous | | | | to V2E1 as an initiator and | 20 Part 5 - Upper Layers September 1993 (Working) | | | V3E1 as a responder will be | | | | able to interoperate with | | | | either version.] | +----------------------------+---------------+------------------- ------------+ | Use of default values for | V2E3 section | No backwards compatibility | | Minor syncpoint changed. | 5.11.1.1.1 | | +----------------------------+---------------+------------------- ------------+ | Addition and deletions | V2E1 section | No backwards compatibility | | of abstract syntaxes. | 5.11.1.3.1 | | +----------------------------+---------------+------------------- ------------+ | Value for session | V2E4 section | No backwards compatibility | | functional unit | 5.11.1.4.1 | | | "resynchronize" | | | | changed. | | | +----------------------------+---------------+------------------- ------------+ | Restrictions on inclusion | V3E1 section | Interworking problems will | | of "Transfer-syntax-name" | 5.8.6 | occur for those | | in CP PPDU and CPC type. | | implementations that expect | | | | "Transfer-syntax- name" | | | | parameter to be present in | | | | the PDV-List even though one | | | | transfer syntax was | | | | negotiated. [An | | | | implementation conforming to | | | | V3E1 as an initiator and | 21 Part 5 - Upper Layers September 1993 (Working) | | | versions previous to V3E1 as | | | | a responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ 22 Part 5 - Upper Layers September 1993 (Working) +---------------------------------------------------------------- ------------+ | Version & Section | +----------------------------+---------------+------------------- ------------+ | Issue | Changed | Backward Compatibility | +----------------------------+---------------+------------------- ------------+ | Encoding restrictions | V3E1 section | Interworking problems will | | on ASN.1 INTEGER type | 5.10.4 | occur since implementations | | describing PCI. | | conforming to previous | | | | versions could encode PCI | | | | integer lengths greater than | | | | 4. [Responders that accept | | | | integers describing PCI that | | | | are encoded in greater than | | | | 4 octets and Initiators that | | | | conform to V3E1 will be able | | | | to interoperate.] | +----------------------------+---------------+------------------- ------------+ | Encoding restrictions | V3E1 section | Implementations that conform | | on BIT STRING, OCTET | 5.10.5 | to previous versions can | | STRING, and CHARACTER | | expect these strings to have | | STRING. | | nested constructed encodings | | | | and therefore interworking | | | | problems will occur. | | | | [Responders that accept | | | | nested constructed encodings | 23 Part 5 - Upper Layers September 1993 (Working) | | | and Initiators that conform | | | | to V3E1 will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ | No extra trailing bits | V3E1 section | Interworking problems will | | allowed in BIT STRING. | 5.10.6 | occur when implementations | | | | that conform to previous | | | | versions send extra trailing | | | | bits. [Responders accepting | | | | extra trailing bits and | | | | Initiators that conform to | | | | V3E1 will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ | Restriction on usage of | V3E1 section | Interworking problems will | | "token item field" and | 5.9.3.1 | occur since implementations | | "user data." | | that conform to V1E1 do not | | | | expect the "token item field" | | | | to be encoded when a category | | | | 0 SPDU is concatenated to a | | | | category 2 SPDU. | +----------------------------+---------------+------------------- ------------+ | Restrictions on CPC-type | V2E2 section | Interworking problems may | | values when multiple | 5.8.3.9 | occur between initiators that | | transfer syntaxes are | | send CPC-type values and | 24 Part 5 - Upper Layers September 1993 (Working) | proposed. | | receivers that do not examine | | | | them. | +----------------------------+---------------+------------------- ------------+ 25 Part 5 - Upper Layers September 1993 (Working) +---------------------------------------------------------------- ------------+ | Version & Section | +----------------------------+---------------+------------------- ------------+ | Issue | Changed | Backward Compatibility | +----------------------------+---------------+------------------- ------------+ | References to ISO 8649 | V1E3 section | Interworking problems will | | and ISO 8650 changed. | "References." | occur for those | | | | implementations that conform | | | | to ISO DIS 8649 and 8650. | | | | V1E3 references IS versions of| | | | 8649 and 8650. | +----------------------------+---------------+------------------- ------------+ | References to ISO 8326, | V1E4 section | Interworking problems will | | ISO 8327, ISO 8822, and | References. | occur for those | | ISO 8823 changed. | | implementations that conform | | | | to 8326/DAD2, 8327/DAD2, DIS | | | | 8822, and DIS 8823. V1E4 | | | | referenced 8326/AD2, 8327/AD2,| | | | IS 8822, and IS 8823. | +----------------------------+---------------+------------------- ------------+ | AE Title changed | V3E1 section | Interworking problems will | | according to | 5.5.3.2 | occur between initiators | | Amendment 1 to | | that use AE-title- form 1 and | | ISO 8650. | | responders that accept only | | | | AE-Title-form 2. | 26 Part 5 - Upper Layers September 1993 (Working) +----------------------------+---------------+------------------- ------------+ | Restrictions on usage | V3E1 section | Interworking problems will | | of "direct references" | 5.5.4 | occur for those | | in ABRT APDU. | | implementations that expect | | | | the "direct reference" | | | | parameter to be included in | | | | the ABRT APDU. [An | | | | implementation that conforms | | | | to V3E1 as an initiator and | | | | versions previous to V3E1 as a| | | | responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ 27 Part 5 - Upper Layers September 1993 (Working) Annex D (normative) Working Draft of new ISP on mOSI Specification ULSIG-33-09/93 TITLE: Information technology -- International Standardized Profile -- Common Upper Layer Requirements -- Part 3: Minimal OSI upper layer facilities SOURCE: OIW ULSIG Editor: Laura Emmons Telenex, Inc. 7401 Boston Blvd. Springfield, VA 22153 USA +1 703 644-9113 fax: +1 703 644-9011 laurae@ar.telenex.com STATUS: Working Draft Version 3-Revision 3 of pDISP 11188-3, 1993-09-21 Submitted to Regional Workshops for review. This document is a draft for the profile of the minimal OSI facilities necessary to support basic connection-oriented communication applications. These facilities are comprised of a subset of the facilities defined in the ACSE, Presentation and Session service definitions. The schedule for the progression of all parts of the Common Upper Layer Requirements to become ISP's is provided in an attachment. i Working Draft ISO/IEC ISP 11188-3 September 1993 International Standardized Profile Common upper layer requirements Part 3: Minimal OSI upper layers facilities Contents Foreword v Introduction vi 1 Scope 1 1.1 General 1 1.2 Position within the taxonomy 2 2 Compliance 2 2.1 Referencing specifications 2 2.1.1 ISP 2 2.1.2 API specification 3 2.1.3 Platform specification 3 2.1.4 Specific basic communications application 4 2.2 Categories, roles and options 5 2.2.1 Association Establishment 5 2.2.2 Normal data transfer 6 2.2.3 Association Release 6 23 Normative References 7 23.1 Identical Recommendations | International Standards 7 2.32 Paired Recommendations | International Standards equivalent in technical content 7 23.3 Additional references 8 34 Definitions 9 34.1 Reference model definitions 9 34.1.1 Basic Reference Model definitions 9 34.1.3 Naming and addressing definitions 10 34.2 Service conventions definitions 10 34.3 Presentation definitions 11 34.4 Session definitions 11 34.5 Application Layer Structure definitions 11 34.6 ACSE service definitions 12 34.7 Definitions of this Profile 12 45 Abbreviations 14 56 Conventions 15 67 Model 17 67.1 Common elements 17 67.2 Standalone applications 19 67.3 Platform-based applications 19 67.3.1Migrant application 19 67.3.2Kernel application 20 78 Summary of specifications 20 78.1 Compliance to this Profile 20 ii September 1993 Working Draft ISO/IEC ISP 11188-3 78.2 ACSE 21 78.3 Presentation Layer 21 78.4 Session Layer 21 78.5 Transport-provider 21 8 Compliance 23 8.1 Referencing specifications 23 8.1.1 ISP 23 8.1.2 API specification 24 8.1.3 Platform specification 24 8.1.4 Specific basic communications application 25 8.2 Categories, roles and options 25 8.3 mOSI compliance proforma 27 8.4 Compliance statement 29 iii Working Draft ISO/IEC ISP 11188-3 September 1993 Annexes A Requirements for ACSE facilities 30 B Requirements for Presentation Layer facilities 36 C Requirements for Session Layer facilities 43 D Profile compliance proforma 51 E Minimal OSI object identifiers 54 F Minimal OSI concepts 56 G Minimal OSI implementation considerations 60 iv September 1993 Working Draft ISO/IEC ISP 11188-3 Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental or non-governmental, in liason with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC1. In addition to developing International Standards, ISO/IEC JTC1 has created a Special Group on Functional Standardization for the elaboration of International Standardized Profiles. An International Standardized Profile is an internationally agreed, harmonized document which identifies a standard or group of standards, together with options and parameters, necessary to accomplish a function or set of functions. Draft International Standardized Profiles are circulated to national bodies for voting. Publication as an International Standardized Profile requires approval by at least 75% of the national bodies casting a vote. This part of ISO/ISP 11188 was prepared with the collaboration of -- Asia-Oceania Workshop (AOW); -- European Workshop for Open Systems (EWOS); -- OSE Implementors Workshop (OIW). Annexes A , B, C , D and E form an integral part of this part of ISO/IEC ISP 11188. Annexes F and G are informative. v Working Draft ISO/IEC ISP 11188-3 September 1993 Introduction This part of ISO/IEC ISP 11188 is defined within the context of Functional Standardization, in accordance with the principles specified by ISO/IEC TR10000, "Framework and Taxonomy of International Standardized Profiles". The context of Functional Standardization is one part of the overall field of Information Technology (IT) standarization activities, covering base standards, profiles, and registration mechanisms. A profile defines a combination of base standards that collectively perform a specific, well- defined IT function. Profiles standardize the use of options and other variations in the base standards, and provide a basis for the development of uniform, internationally recognized system tests. ISO/IEC ISP 11188 as a multi-part ISP specifies general requirements on the use of OSI protocols by A-profiles. These are identified as "Common Upper Layer Requirements". The parts of this multi-part ISP do not contain the definition of any complete profiles, but can be referenced normatively by other ISPs which do define A-profiles. In addition, a referencing ISP may specify further requirements on the protocols, provided it does not contradict this ISP. The purpose of this multi-part ISP is to provide common text for ISPs or other referencing specifications which sopecify A-profiles. In addition to simplifying their drafting, it also facilitates the common implementation of the protocols for use in different A-profile contexts. This part of ISO/IEC 11188 specifies a profile of the minimal OSI facilities to support basic connection-oriented communication applications. These facilities are comprised of a subset of the facilities defined by the ACSE, Presentation, and Session service definitions. vi September 1993 Working Draft ISO/IEC ISP 11188-3 INTERNATIONAL STANDARDIZED PROFILE ISO/IEC 11188-3 Information technologyInternational Standardized Profile Common upper layer requirementsPart 3: Minimal OSI upper layers facilities 1 Scope This part of ISO/IEC ISP 111881 introduces the concept of a minimal set of OSI upper layer facilities for basic communications applications. A basic communications application simply requires the ability to open and close communications with a peer and to send and receive messages with the peer. It is expected that a large portion of potential OSI applications will be basic communications applications. 1.1 General This Profile specifies the minimal set of upper layer functionality for identified categories, options and roles of basic communication applications. It does this by stating requirements for completing identified features of the upper layer PICS proformas the ACSE (ISO/IEC 8650-2), the Presentation Layer (ISO 8823-2), and the Session Layer (ISO 8327-2). This Profile also supports the requirements stated in ISO/IEC ISP 11188- 1, Basic Connection-oriented Requirements. This Profile is not intended for reference by a physical implementation. For this reason, no requirement is made for conformance to this Profile. This Profile is intended for reference by another specification.2 Therefore, this Profile is concerned 1 In the remainder of this document, the term "Profile" is used to denote this "part of ISO/IEC ISP 11188." 2 The following are examples of a specification that may refer to this Profile: the specification of an API; an ISP; the specification of a communications platform; and the specification of a basic communications application. 1 Working Draft ISO/IEC ISP 11188-3 September 1993 with compliance3 rather than conformance. An implementation will not undergo conformance testing to this Profile. Rather, a static comparison may take place between the implementation's completed ACSE, presentation, and session PICSs and this Profile. Conformance testing, as such, is based on the contents of the completed PICSs outside of the scope of this Profile. A specification may claim compliance by referencing this Profile. Clause 82 defines the compliance statement that may be stated and summarizes the requirements for making such a statement. The detailed requirements for completing the ACSE, presentation, and session PICS proformas are stated in Annexes A, B, and C, respectively. Annex D provides a proforma for a profile compliance statement which would specify the compliance of a referencing specification to this profile. Annex E assigns object identifier values for specific generic definitions of application context, abstract syntax, and transfer syntax.1.2 Position within the taxonomy This Profile does not specify a full A-Profile, and therefore has no place within the taxonomy of ISO/IEC TR 10000-2. 2 Compliance This clause presents the compliance statement that a specification may make relative to this Profile. 2.1 Referencing specifications This Profile may be used by the designers of one of the following types of specifications that wish to claim compliance to the minimal OSI upper layers defined in this Profile: a) ISP; or b) API specification; or c) Platform specification; or 3 Compliance deals with one specification referencing another specification; conformance deals with a physical implementation that references one or more specifications. 2 September 1993 Working Draft ISO/IEC ISP 11188-3 d)`Specific basic communications application either a platform-based application or a standalone application. Each type of specification is discussed below. 2.1.1 ISP An ISP is a specification that includes the requirements of the upper layers ACSE, presentation, and session. An ISP that represents a basic communications application may contain a claim of compliance to this Profile. Such a claim indicates that the ISP's requirements for ACSE, presentation, and session features are satisfied by features specified in this Profile. An ISP may claim compliance to this Profile if the ISP: a) requires the Profile's mandatory and some or all optional features for the category, roles and options identified by the ISP; and b) does not require any of the "out of scope" (i) or "excluded" (x) features specified by this Profile. The specifications of an ISP are generic an implementation of the ISP may result in either a standalone or a platform-based application (see clause 6). An ISP may elect to repeat all of the specifications contained in this Profile. To claim compliance to this Profile, such an ISP shall assure that its specification of the ACSE. presentation, and session features does not violate those in this profile. Likewise, an ISP may exclude within it all of the specifications contained in this Profile and reference this Profile. The conformance statement of such an ISP shall require that a referencing implementation of the ISP shall comply to the requirements of this profile when completing the implementation's ACSE, presentation, and session PICSs. 2.1.2 API specification An API specification (or an identified subset of an API 3 Working Draft ISO/IEC ISP 11188-3 September 1993 specification) may claim compliance to this Profile. Such a claim indicates that the API (or API subset) supports the features specified in this Profile. An API specification4 may claim compliance to this Profile if the API specification: a) supports all Profile mandatory features and some or all optional features for the identified roles and categories; and b) can be restricted in the support of the "out of scope" (i) features identified by this Profile. c) excludes all "excludes" (x) features specified by this Profile. 2.1.3 Platform specification A platform specification represents the description of a communications platform implementation. It is not expected that a platform specification would be the subject of International Standardization. Most likely, a platform specification would represent a proprietary (e.g., a Consortium) statement. A platform specification includes the completed PICSs for ACSE, presentation, and session. A platform specification may claim compliance to this Profile. Such a claim indicates that the platform supports the features specified in this Profile. A platform specification that exactly contains the features of this Profile (for the roles and category) selected is considered to define a mOSI platform. A platform specification that contains non-contradictory features in addition to those of this Profile is considered to be a mOSI-compliant platform. A platform specification may claim compliance to this Profile if: 4 The "API specification" claiming compliance may represent the entirety of the API functionality or it may be an identified subset of an API specification. XTI/mOSI is an example of an "entire" API that may claim compliance. A subset of XAP could be an example of a subset of an API that could claim compliance. 4 September 1993 Working Draft ISO/IEC ISP 11188-3 a) the completed ACSE, presentation, and session PICSs for the platform specification include all of the Profile's mandatory features and some or all of identified optional features for the roles and category supported by its API; b) the platform specification includes an API whose specification conforms to this Profile; and c) the platform is capable of operating in a mode whereby all of the "out of scope" (i) and "excluded" (x) features specified by this Profile are not permitted (for a mOSI-complaint platform). 2.1.4 Specific basic communications application For this discussion a specific basic communications application is one that is not addressed by any ISP. That is, a specific basic communications application is not the subject of International Standardization. A platform-based specific basic communications application may reference this Profile to identify itself as a basic communications application. However, its main specification is the identification of a mOSI API. The specification of a standalone specific basic communications application may reference this Profile as done for an ISP. That is, it may a) repeat all of the specifications contained in this Profile; or b) not include any of the specifications contained in this Profile and reference this Profile. 5 Working Draft ISO/IEC ISP 11188-3 September 1993 Figure 1 Compliance possibilities 2.2 Categories, roles and options Figure 2 illustrates the mOSI compliance possibilities. The "foundation" is mOSI compliance (box [a]). This consists of the Kernel functional units of ACSE, presentation, and session. It also includes the session Duplex functional unit. To this, two optional sets of features may be selected: with authentication (the ACSE Authentication functional unit box [b]); and with application context negotiation (the ACSE Application Context Negotiation functional unit box [c]). mOSI compliance contains three sets of optional roles for association establishment, normal data transfer, and association-release. 2.2.1 Association Establishment For association establishment, the following roles are possible [see Annex D]: a) association initiator only; or b) association responder only; or c) both association initiator and association responder. 6 September 1993 Working Draft ISO/IEC ISP 11188-3 For the purposes of this Profile, this set of roles is expressed by the variable Establishment-role. The variable may assume one of the following values: "initiator", or "responder", or "both." This variable is used in Annexes A, B, and C to define conditionally the requirements of ACSE, presentation, and session. 2.2.2 Normal data transfer For normal data transfer, the following roles are possible [see Annex D]: a) normal data requestor only; or b) normal data acceptor only; or c) both normal data requestor and acceptor; or d) neither normal data requestor nor acceptor. For the purposes of this Profile, this set of roles is expressed by the variable Normal-data-role. The variable may either be null or it may assume one of the following values: "requestor", or "acceptor", or "both." The variable is used in Annexes B and C to define conditionally the presentation and session requirements. 2.2.3 Association Release For association release, the following roles are possible [see Annex D]: a) release-requestor only; or b) release-acceptor only; or c) both release-requestor and release-acceptor; or d) neither release-requestor nor release-acceptor. For the purposes of this Profile, this set of roles is expressed by the variable Release-role. The variable may either be null or it may assume one of the following values: "requestor", or "acceptor", or "both." The variable is used in Annexes A and C to define conditionally the ACSE and session requirements. mOSI compliance has two categories: category I and 7 Working Draft ISO/IEC ISP 11188-3 September 1993 category II. Both category I and category II require support for receiving all features of the selected roles. Category I requires support for sending all features of the selected roles. Category II allows that one or more identified features need not be supported for sending (see Annex D). 3Normative ReferencesThe following CCITT Recommendations | International Standards contain provisions which, through reference in this text, constitute provisions of this CCITT Recommendation | International Standard . At the time of publication, the editions indicated were valid. All Recommendation and Standards are subject to revision, and parties to agreements based on this CCITT Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent editions of the CCITT Recommendations | International Standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards. The CCITT Secretariat maintains a list of the currently valid CCITT Recommendations. 3.1 Identical Recommendations | International Standards CCITT Recommendation X.227 (1993) | ISO 8650: 1993,5 Information processing systems Open Systems Interconnection Protocol specification for the Association Control Service Element. 32 Paired Recommendations | International Standards equivalent in technical content CCITT Recommendation X.200 (1984), Reference Model of Open Systems Interconnection for CCITT applications. ISO 7498:1984, Information processing systems Open Systems Interconnection Basic Reference Model. CCITT Recommendation X.210 (1988), OSI Layer Service Definition Conventions for CCITT applications. ISO/TR 8509:1986, OSI Layer Service Definition Conventions. CCITT Recommendation X.214 (1988), Transport service 5 Currently under ISO/IEC national body review 8 September 1993 Working Draft ISO/IEC ISP 11188-3 definition for Open Systems Interconnection for CCITT applications. ISO 8072:1986, Information processing systems Open Systems Interconnection Transport service definition. CCITT Recommendation X.225 (1988), Session protocol specification for Open Systems Interconnection for CCITT applications. ISO 8327:1990, Information processing systems Open Systems Interconnection Connection oriented session protocol specification. CCITT Recommendation X.226 (1988), Presentation protocol specification for Open Systems Connection for CCITT applications. ISO 8822:1988, Information processing systems Open Systems Interconnection Connection oriented presentation protocol specification. 3.3 Additional references ISO 7498-3:1988, Information processing systems Open Systems Interconnection Basic Reference Model Part 3: Naming and Addressing. ISO 8327-2:1992, Information processing systems Open Systems Interconnection Connection oriented session protocol specification Part 2: Protocol Implementation Conformance Statement (PICS) Proforma. ISO 8650-2: 1992, Information processing systems Open Systems Interconnection Protocol specification for the Association Control Service Element Part 2: Protocol Implementation Conformance Statement (PICS) Proforma . ISO 8823:1992, Information processing systems Open Systems Interconnection Connection-oriented Presentation Protocol Specification Part 2: Protocol Implementation Conformance Statement (PICS) Proforma. ISO/IEC 9545:1989, Information technology Open Systems Interconnection Application Layer Structure ISO/IEC TR 10000-1:1992, Information technology Framework of taxonomy of International Standardized Profiles Part 1: Framework. . ISO/IEC TR 10000-2:1992, Information technology Framework of taxonomy of International Standardized Profiles Part 2: Taxonomy of Profiles. ISO/IEC ISP 11188-1, Information technology International Standardized Profile Common upper layer requirements Part 1: Basic connection- 9 Working Draft ISO/IEC ISP 11188-3 September 1993 oriented requirements.6 6Currently at level of working draft 10 September 1993 Working Draft ISO/IEC ISP 11188-3 4 Definitions This Profile makes use of the following definitions. 4.1 Reference model definitions 4.1.1 Basic Reference Model definitions This Profile is based on the concepts developed in CCITT Rec. X.200 | ISO 7498-1 and ISO 7498-1/AD1. It makes use of the following terms defined in them: a) application-entity; b) application-function; c) Application Layer; d) application-process; e) application-protocol-control-information; f) application-protocol-data-unit; g) application-service-element; h) connectionless-mode presentation-service; i) (N)-connectionless-mode transmission; j) (N)-function; k) presentation-connection; l) Presentation Layer; m) presentation-service; n) session-connection; o) session layer; p) session-protocol; q) session-service; r) Transport Layer 4.1.3 Naming and addressing definitions 11 Working Draft ISO/IEC ISP 11188-3 September 1993 This Profile makes use of the following terms defined in ISO 7498-3: a) application-process title; b) application-entity qualifier; c) application-entity title; d) application-process invocation-identifier; e) application-entity invocation-identifier; and f) presentation address. 4.2 Service conventions definitions This Profile makes use of the following terms defined in CCITT Rec. X.210 | ISO/TR 8509: a) service-provider; b) service-user; c) confirmed service; d) non-confirmed service; e) provider-initiated service; f) primitive; g) request (primitive); h) indication (primitive); i) response (primitive); and j) confirm (primitive). 12 September 1993 Working Draft ISO/IEC ISP 11188-3 4.3 Presentation definitions This Profile makes use of the following terms defined in CCITT Rec. X.216 | ISO 8822 and ISO 8822/AD1 and CCITT Rec. X.226 | ISO 8823 and ISO 8823/AD2: a) abstract syntax; b) abstract syntax name; c) connectionless-mode [presentation]; d) default context; e) defined context set; f) functional unit [presentation]; g) normal mode [presentation]; h) presentation context; i) presentation data value; and j) presentation selector 4.4 Session definitions This Profile makes use of the following terms defined in CCITT Rec. X.215 | ISO 8326 and CCITT Rec. X.225 | ISO 8327: a) session selector 4.5 Application Layer Structure definitions This Profile makes use of the following terms defined in ISO/IEC 9545: a) application-context; b) application-entity invocation; c) control function; and d) application-service object. 13 Working Draft ISO/IEC ISP 11188-3 September 1993 4.6 ACSE service definitions This Profile makes use of the following terms defined in ISO/IEC 8649: a) application-association; association b) Association Control Service Element c) ACSE service-user d) ACSE service-provider e) requestor f) acceptor g) association-initiator h) association-responder 4.7 Definitions of this Profile For the purpose of this Profile, the following definitions apply. API specification; application programmatic interface specification: The functional specification of the local manifestation of the facilities of an identified stack specification. An API is normally defined as a set of procedure calls in a particular programming language. API; application programmatic interface: An implementation of an identified API specification. basic communications application: An application program that simply requires the ability to open and close communications with a peer and to send and receive messages with that peer. category 1 compliance: The referencing specification supports all mandatory features listed in the category 1 columns of the tables in Annexes A, B and C. category 2 compliance: The referencing specification supports all mandatory features listed in the category 2 columns of the tables in Annexes A, B, C. mOSI API specification: A functional specification of 14 September 1993 Working Draft ISO/IEC ISP 11188-3 the local manifestation of the facilities of the mOSI stack specification (CULR-3). mOSI specification; mOSI stack specification: This specification that defines the minimal facilities of the Session Layer, Presentation Layer, and ACSE (CULR- 3). mOSI stack; mOSI stack implementation: An implementation that supports, at a minimum, the facilities defined in the mOSI stack specification (CULR-3). mOSI platform specification: The functional specification of a formal programmatic interface and a set of supporting local services for the mOSI stack specification (CULR-3). mOSI platform: An implementation of the mOSI platform specification. non-basic communication application: An application program that requires the ability to support functions other than those specified in the definition a basic communication application. platform: An implementation of an identified platform specification. platform-based application: An application program that conforms to a platform specification. platform specification: The functional specification of a formal programmatic interface and a set of supporting local services for an identified stack specification. specific basic communications application: an application that is not referenced by any ISP. stack; stack implementation: An implementation of an identified stack specification stack specification: The functional specification of a set of interrelated standards for the purpose of providing a common service (set of facilities). standalone application: Any application program which is not a platform-based application. supported as receiver: The specified feature shall be 15 Working Draft ISO/IEC ISP 11188-3 September 1993 acceptable to any receiving mOSI compliant implementation. supported as sender: The specified feature shall be implemented by any sending mOSI compliant implementation. transport-provider: A provider of those transport services which are defined in ISO 8072. 5 Abbreviations The following abbreviations are used in this Profile. ACSE Association Control Service Element APDU application-protocol-data-unit API application programmatic interface ASN.1 Abstract Syntax Notation One BCA basic communications application CCITT International Telegraph and Telephone Consultative Committee CULR Common Upper Layers Requirements ICS implementation conformance statement IEC International Electrotechnical Commission ISO International Organization for Standardization ISP International Standardized Profile mOSI minimal OSI upper layer facilities OSI Open Systems Interconnection PDU protocol-data-unit PICS protocol implementation conformance statement PPDU presentation-protocol-data-unit SPDU session-protocol-data-unit TSDU transport-service-data-unit 16 September 1993 Working Draft ISO/IEC ISP 11188-3 17 Working Draft ISO/IEC ISP 11188-3 September 1993 6 Conventions This Profile defines a minimal set of facilities for basic communications applications. The facilities defined are those of the ACSE (ISO/IEC 8650-1), the Presentation Layer (ISO 8823-1), and the Session Layer (ISO 8327-1). This Profile states the required minimal functionality by stating requirements for completing the PICS Proforma of these three upper layer specifications. The requirements for filling out the PICS Proformas are stated in Annexes A, B, and C. The requirements are specified by means of a series of tables in these annexes. Each table in an annex refers to one, identified table in the referenced PICS Proforma. Each row in an annex table refers to a corresponding row in the referenced PICS table. Each row identifies a particular feature of potential support. In each table, the "Profile" column(s) indicates the requirements of this Profile for the support of a given item. For each item, the "Profile" is described by one of the identifiers ("Id") in table 1. Table 1 Profile column identifiers I Name Comment d 1 m supported Support for the feature is mandatory as sender; as receiver; or as both sender and receiver. When completing the associated PICS Proforma table, the answer for the "Support" column shall be 'Y' yes, the feature has been implemented. 2 o optionally Support for the item is the option of supported the referencing specification as sender; as receiver; or as both sender and receiver. When completing the associated PICS Proforma table, the answer for the "Support" column shall either be: 'Y' yes, the feature has been implemented; or 'N' no, the feature has not been implemented. 18 September 1993 Working Draft ISO/IEC ISP 11188-3 3 c conditionall Support for the feature is further [ y supported defined by a condition ("n") n identified with the table. Depending ] on the condition, when completing the associated PICS Proforma table, the answer for the "Support" column shall either be: 'Y' yes, the feature has been implemented; or 'N' no, the feature has not been implemented; or '-' not applicable. 4 x excluded Support for the feature is not permitted as sender; as receiver; or as both sender and receiver. When completing the associated PICS Proforma table, the answer for the "Support" column shall be 'N' no, the feature has not been implemented. 5 i out of scope The requirement for the support of this feature is not covered by this Profile. When completing the associated PICS Proforma table, the answer for the "Support" column shall either be: 'Y' yes, the feature has been implemented; or 'N' no, the feature has not been implemented. 'out of scope' differs from conditionally supported." The receipt of a semantic of the "out of scope" feature may be treated as a protocol error. 6 n not The feature is not defined by the / applicable base standard in the context where it a is mentioned in a table. Note: [NOTE -- Mandatory support in a receiving column implies that the appropraite action is taken when the value of the feature is received. The appropraite action may be defined by a referencing specification. A default action is defined by the sucessful completion of the processing of the value by the protocol machine, i.e. the connection/association shall not be aborted. ] 19 Working Draft ISO/IEC ISP 11188-3 September 1993 20 September 1993 Working Draft ISO/IEC ISP 11188-3 7 Model Figure 2 mOSI model This clause presents the mOSI model and defines many of the terms used in this Profile. The mOSI model is shown in figure 1. It can be viewed in two contexts: it can be viewed abstractly where the various elements represent abstract "specifications;" or it can be viewed concretely where the elements represent those of an implementation. 7.1 Common elements The common elements of the mOSI model are basic communications application pdv-processor mOSI stack; transport services and transport provider A basic communications application (BCA) simply requires the ability to open and close communications with a peer and to send and receive messages with the peer. This Profile addresses basic communication applications. A stack represents a set of layered, interdependent communication standards (in the abstract sense) and 21 Working Draft ISO/IEC ISP 11188-3 September 1993 their implementation (in the concrete sense). The mOSI stack represents the standards (protocol specifications) or their implementation with the features specified in this Profile. Note: [NOTE A stack does not necessary represent a layered implementation of the layered standards. On the contrary, it is recommended in annex F that the implementation of a mOSI stack is one protocol engine, not three an ACSE protocol engine interfacing to a presentation protocol engine interfacing to a session protocol engine. ] From the perspective of the presentation protocol (ISO 8823), the syntax (encoded data) sent from one application to its connected peer is a series of one or more presentation-data-values (pdv's). The ISO presentation protocol defines the encoding of the outer envelope of a pdv and the encoding for groups of pdv's (if any). The actual contents of a pdv is a function of the mutually agreed upon abstract syntax and transfer syntax of the pdv its presentation context. ASN.1 (ISO 8824 abstract syntax definition and ISO 8825 transfer syntax encoding) is just one possible choice. The selection, definition and encoding of syntax sent between connected applications is outside of the scope of the mOSI stack.7 The pdv-processor represents the wrapping and unwrapping of the "pdv envelope" around the syntax sent or received in the identified presentation context. As shown in figure 1, the pdv- processor could be accomplished in several ways. The mOSI model assumes that pdv encoding and decoding is done outside of the mOSI stack. This Profile does not address the four lower OSI layers (Transport, Network, Link, and Physical Layers). They are considered outside of the scope of this Profile. However, a transport-provider is needed to transport the ACSE, presentation, and session PDUs of an mOSI implementation. As such, the transport-provider supplies transport services equivalent to those defined 7 It is also out of the scope of the presentation protocol (ISO 8823). 22 September 1993 Working Draft ISO/IEC ISP 11188-3 in the OSI Transport Layer service definition (ISO 8072). This specification does not place any requirements on the actual transport provider (layer 4 and below) used as long as the equivalent OSI transport services are provided. 7.2 Standalone applications For the purposes of this Profile, a standalone application is one that includes the mOSI stack and the pdv-processor as an integral part.8 For an implementation, the mOSI stack may be a series of separate modules with its own internal programmatic interface. However, this separation and its interface are no different than any other structural division of the application. 7.3 Platform-based applications A communications platform allows a division between an application program and its communications provider. A platform is the communication aspects of a distributed application in one system. A platform-based application represents the non-communication aspects of a distributed application in one system. An application programmatic interface (API) is the formal interface between a communication platform and its user [platform-based] applications. It is formal in the sense that the API is specified so as to allow the use of the platform by different types of applications most often, in parallel. The programmatic interface represents the mapping of the API to the internals of the supporting system. A mOSI platform consists of a mOSI stack, an API, programmatic-interface and other considerations (see 8.1.3). In figure 1 the mOSI stack is shown as an "egg" within a mOSI platform. This indicates that the mOSI 8 Many ISP are written from the point of view of standalone applications. However, the actual implementation of the ISP could result in a platform- based application. 23 Working Draft ISO/IEC ISP 11188-3 September 1993 stack could be a proper subset of a full OSI upper layer implementation (specification). A mOSI API represents the interface to the mOSI stack (see 2.1.2). It provides the minimal features of the OSI upper layers as defined in this Profile. As discussed in Annex F, mOSI identifies two types of basic communications applications: migrant applications and kernel applications. Depending on the type of application, the pdv-processor could either be a part of the platform or a part of each platform-based application. 7.3.1 Migrant application OSI (and mOSI) has two required features that are not part of other transport providers: a) application context; and b) presentation context abstract syntax name and transfer syntax name pair. Application context names may be hidden from the API user by having the programmatic interface provide default values (see Annex E). A migrant application (see F.2.3.2) is unaware (or at least, not concerned) with identifying the presentation context of the data sent and received. Presentation context names may also be hidden from migrant applications by allowing the programmatic interface to provide default values (see Annex E). The encoding and decoding of the pdv's are hidden by placing the pdv- processor within the platform. 7.3.2 Kernel application A kernel application (see F.2.3.1) is an OSI-based application. It is aware of the required features of application context names and presentation context. Most likely, (but, not necessarily) the application's own protocol will be specified and encoded using ASN.1. For this reason the pdv-processor is shown in Figure 1 within the application itself rather than part of the platform. It is not expected that a kernel application will use the default values for abstract syntax and 24 September 1993 Working Draft ISO/IEC ISP 11188-3 transfer syntax defined in Annex E. 8 Summary of specifications This clause summarizes the set of facilities that constitute the minimal OSI upper layers for Basic Communication applications. 8.1 Compliance to this Profile The facilities defined in this Profile are those of the Session Layer (ISO 8327), the Presentation Layer (ISO 8823), and the ACSE (ISO/IEC 8650). This Profile specifies the minimal set of functionality by stating requirements for completing the PICS proforma of these three upper layer specifications. Another specification may claim compliance9 to this Profile. A specification does this by referencing this Profile. Clause 2 defines the compliance statement that may be stated and summarizes the requirements for making such a statement. The detailed requirements for completing the ACSE, Presentation, and Session PICS proformas are stated in Annexes A, B, and C. Annex D assigns object identifier values for generic definitions of application context, abstract syntax, and transfer syntax. 8.2 ACSE This Profile specifies the Kernel functional unit. Optionally, the Profile also includes the Authentication functional unit and Application Context Name Negotiation Functional unit. The Profile allows the roles for association establishment and release identified in ISO 8650. For ACSE, this specification allows two categories of support (see 2.2). For category I, the sending of all 9 Compliance deals with one specification referencing another specification; conformance deals with a physical implementation that references one or more specifications. 25 Working Draft ISO/IEC ISP 11188-3 September 1993 specified ACSE parameters shall be supported. For category II, identified parameters optionally may not be supported for sending. However, for both categories, support for the receiving of all parameters is required. Specifically, for both categories, support for the receiving of both forms of the AE title datatypes (Directory Name and Object Identifier) is required. The required facilities of ACSE are specified in Annex A. A default value for application context name is defined in Annex E. The requirements expressed in ISO/IEC ISP 11188-1 also apply to the ACSE aspects of this Profile. 8.3 Presentation Layer This Profile specifies the presentation Kernel functional unit. The required facilities of presentation are specified in Annex B. Default values for user abstract syntax name and user transfer syntax name are defined in Annex E. The requirements expressed in ISO/IEC ISP 11188-1 shall also apply to the Presentation Layer aspects of this Profile. 8.4 Session Layer This Profile specifies the session Kernel and Duplex functional units. The required facilities of session are specified in Annex C. The requirements expressed in ISO/IEC ISP 11188-1 shall also apply to the Session Layer aspects of this Profile. 8.5 Transport-provider As mentioned in clause 5 (Model), this Profile does not address the lower four OSI layers (Transport, Network, Link, and Physical Layers). They are considered outside of the scope of this specification. A transport-provider is needed to transport the ACSE, Presentation, and Session PDUs of an mOSI implementation. As such the transport-provider shall supply services equivalent to those defined in the OSI Transport Layer service definition (CCITT Rec. X.214 | 26 September 1993 Working Draft ISO/IEC ISP 11188-3 ISO 8072). 27 Working Draft ISO/IEC ISP 11188-3 September 1993 28 September 1993 Working Draft ISO/IEC ISP 11188-3 29 Working Draft ISO/IEC ISP 11188-3 September 1993 Annex A Requirements for ACSE facilities (Normative) This annex specifies the ACSE requirements for completing the ACSE PICS (ISO 8650-2) for the categories, roles, and options selected (see 8.2). The specifications in this annex are based on the Proforma tables of the ACSE PICS Proforma. The clause numbers and tables referenced in this annex are those of the ISO 8650-2. If a clause number of ISO 8650-2 is not mentioned it is out of the scope of this Profile. It may be ignored and will, therefore, not be subject to the compliance statement of this Profile. The specifications references the following variables: Establishment-role, and Release-role. These are discussed in 8.2. Note: [NOTE PICS clauses A.1-A.4 are outside of the scope of this Profile. ] A.1 Supported roles [PICS clause A.5] A.1.1 Association establishment [PICS A.5.1] Role Pro PICS Comment fil referenc e e 1 Initiator c[1 A.5.1/1 ] 2 Responder c[2 A.5.1/2 ] [1]"m" if Establishment-role is "initiator" or "both"; otherwise "i" [2]"m" if Establishment-role is "responder" or "both"; otherwise "i" A.1.2 Normal release [PICS A.5.2] Role Pro PICS Comment fil referenc e e 1 Requestor c[1 A.5.2/1 ] 30 September 1993 Working Draft ISO/IEC ISP 11188-3 2 Acceptor c[2 A.5.2/2 ] [1]"m" if Release-role is "requestor" or "both"; otherwise "i" [2]"m" if Release-role is "acceptor" or "both"; otherwise "i" Note: [NOTE Allowing neither Requestor nor Acceptor be selected is a violation of the ACSE PICS Proforma currently at the DIS level. This is an arbitrary requirement it is not mandated by ISO 8650-1 If this requirement in 8650-2 is not removed, a conditional similar to that of A.5.1 must be added. Allowing "neither" allows TCP/IP migrant applications that do their own graceful close and then an abort to be mOSI compliant otherwise they are not compliant. XWINDOWS is such an example. ] 31 Working Draft ISO/IEC ISP 11188-3 September 1993 A.2 Protocol mechanisms [PICS clause A.6] Protocol Prof PICS Comment mechanism ile referenc e 1 Normal mode m A.6/1 2 X.410-1984 mode i A.6/2 Not used by BCA 3 Rules of m A.6/3 extensibility 4 Support of m A.6/4 session version 2 A.3 Functional units [PICS clause A.7] ACSE Prof PICS Comment functional ile referenc unit e 1 Kernel m A.7/1 1 AC Name o not in b Negotiation yet 2 Authenticati o A.7/2 on A.4 Supported APDUs [PICS clause A.8] APDU Prof Prof PICS Comment ile: ile: referenc Send Rece e er iver 1 AARQ c[1] c[2] A.8/1 2 AARE c[2] c[1] A.8/2 3 RLRQ c[3] c[4] A.8/3 4 RLRE c[4] c[3] A.8/4 32 September 1993 Working Draft ISO/IEC ISP 11188-3 5 ABRT m m A.8/5 [1]"m" if Establishment-role is "initiator" or "both"; otherwise "i" [2]"m" if Establishment-role is "responder" or "both"; otherwise "i" [3]"m" if Release-role is "requestor" or "both"; otherwise "i" [4]"m" if Release-role is "acceptor" or "both"; otherwise "i" 33 Working Draft ISO/IEC ISP 11188-3 September 1993 A.5 Supporting APDU parameters [PICS clause A.9] A.5.1 A-associate-request (AARQ) [PICS A.9.1] Parameter Prof Prof Prof PICS Comment ile: ile: ile: refe Send Send Rece renc er er iver e Cat Cat [b] I[a] II[a ] 1 Protocol Version o o m A.9. = version 1 1/1 for BCA 2 Application m m m A.9. Context Name 1/2 3 Calling AP Title m o[1] m A.9. 1/3 4 Calling AE m o[1] m A.9. Qualifier 1/4 5 Calling AP m o[2] m A.9. Invocation- 1/5 identifier 6 Calling AE m o[2] m A.9. Invocation- 1/6 identifier 7 Called AP Title m o[1] m A.9. 1/7 8 Called AE m o[1] m A.9. Qualifier 1/8 9 Called AP m o[2] m A.9. Invocation- 1/9 identifier 10 Called AE m o[2] m A.9. Invocation- 1/10 identifier 34 September 1993 Working Draft ISO/IEC ISP 11188-3 11 ACSE Requirements c[3] c[3] m A.9. 1/11 12 Authentication- c[4] c[4] m A.9. mechanism Name 1/12 13 Authentication- c[4] c[4] m A.9. value 1/13 13 Application c[5] c[5] m not b Context List in yet 14 Implementation o o m A.9. Information 1/14 15 User Information m o m A.9. 1/15 [a]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. [1]If either the AP title or AE qualifier is selected for sending, the other must also be selected. [2]This value may be supported for sending only if the associated AP title and AE qualifier are supported for sending. If supported, both the AP invocation identifier and the AE invocation identifier shall be supported for sending. [3]"m" if Authentication or Application Context Name functional unit is supported; otherwise "i" [4]"m" if Authentication functional unit is supported; otherwise "n/a" [5]"m" if Application Context functional unit is supported; otherwise "n/a" 35 Working Draft ISO/IEC ISP 11188-3 September 1993 A.5.2 A-associate-response (AARE) [PICS A.9.2] Parameter Prof Prof Prof PICS Comment ile: ile: ile: refe Send Send Rece renc er er iver e Cat Cat [b] I[a] II[a ] 1 Protocol Version o o m A.9. = version 1 2/1 for BCA 2 Application m m m A.9. Context Name 2/2 3 Responding AP m o[1] m A.9. Title 2/3 4 Responding AE m o[1] m A.9. Qualifier 2/4 5 Responding AP m o[2] m A.9. Invocation- 2/5 identifier 6 Responding AE m o[2] m A.9. Invocation- 2/6 identifier 7 Result m m m A.9. 2/7 8 Result Source- m m m A.9. diagnostic 2/8 9 ACSE Requirements c[3] c[3] m A.9. 2/9 1 Authentication- c[4] c[4] m A.9. 0 mechanism Name 2/10 1 Authentication- c[4] c[4] m A.9. 1 value 2/11 36 September 1993 Working Draft ISO/IEC ISP 11188-3 1 Implementation o o m A.9. 2 Information 2/12 1 User Information m o m A.9. 3 2/13 [a]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. [1]If either the AP title or AE qualifier is selected for sending, the other must also be selected. [2]This value may be supported for sending only if the Responding AP title and AE qualifier are supported for sending. If supported, both the AP invocation identifier and the AE invocation identifier shall be supported for sending. [3]"m" if Authentication or Application Context Name functional unit is supported; otherwise "i" [4]"m" if Authentication functional unit is supported; otherwise "n/a" 37 Working Draft ISO/IEC ISP 11188-3 September 1993 A.5.3 A-release-request (RLRQ) [PICS A.9.3] Parameter Prof Prof Prof PICS Comment ile: ile: ile: referenc Send Send Rece e er er iver Cat Cat [b] I[a] II[a ] 1 Reason m m m A9.3/1 2 User m o m A.9.3/2 Information [a]This entire column has the value of "i" if Release- role is "acceptor" or "neither"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "requestor" or "neither"; otherwise the value is as marked. A.5.4 A-release-response (RLRE) [PICS A.9.4] Parameter Prof Prof Prof PICS Comment ile: ile: ile: referenc Send Send Rece e er er iver Cat Cat [b] I[a] II[a ] 1 Reason m m m A9.4/1 2 User m o m A.9.4/2 Information [a]This entire column has the value of "i" if Release- role is "requestor" or "neither"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "acceptor" or "neither"; otherwise the value is as marked. A.5.5 A-abort (ABRT) [PICS A.9.5] 38 September 1993 Working Draft ISO/IEC ISP 11188-3 Parameter Profi Profi Profi PICS Comment le: le: le: referenc Sende Sende Recei e r r ver Cat I Cat II 1 Abort m m m A.9.5/1 Source 2 Diagnostic m m m A.9.5/2 3 User m o m A.9.5/3 Information 39 Working Draft ISO/IEC ISP 11188-3 September 1993 A.6 Supported parameter forms [PICS clause A.10] A.6.1 AE Title name form [PICS A.10.1] Table A.10.1 need only be filled in if one or more AP Title/AE Qualifier parameters are supported on the AARQ and AARE (see tables A.9.1 and A.9.2). Syntax form Profi Profi Profi PICS Comment le: le: le: refer Sende Sende Recei ence r r ver Cat I Cat II 1 Form 1 m o m A.10. (Directory 1/1 name) 2 Form 2 (Object m o m A.10. identifier and 1/2 integer) NOTE PICS subclause A.10.2 is out of the scope of this Profile. 40 September 1993 Working Draft ISO/IEC ISP 11188-3 Annex B Requirements for Presentation Layer facilities (Normative) This annex specifies the presentation requirements for completing the Presentation PICS (ISO 8823-2) for the categories, roles and options selected (see 2.2). The specifications in this annex are based on the Proforma tables of the Presentation Layer PICS Proforma. The clause numbers and tables referenced in this annex are those of ISO 8823-2. If a clause number of ISO 8823-2 is not mentioned it is out of scope of this Profile. It may be ignored and will, therefore, not be subject to the compliance statement of this Profile. The specifications reference the following variables: Establishment-role, and Normal-data-role. These are discussed in 2.2. NOTE PICS clauses A.1-A.4 are outside of the scope of this Profile. B.1 Protocol mechanisms and functional units [PICS clause A.5] B.1.1 Protocol mechanisms [PICS A.5.1] Protocol Prof PICS Comment mechanism ile referenc e 1 X.410 (1984) i A.5.1/1 Not used by BCA 2 Normal mode m A.5.1/2 B.1.2 Functional units [PICS A.5.2] Presentation Prof PICS Comment functional units ile referenc e 1 Kernel m A.5.2/1 2 Presentation i A.5.2/2 Not used by BCA Context management 41 Working Draft ISO/IEC ISP 11188-3 September 1993 3 Presentation i A.5.2/3 Not used by BCA Context Restoration 42 September 1993 Working Draft ISO/IEC ISP 11188-3 Presentation Prof PICS Comment functional units ile referenc e 4 Negotiated i A.5.2/4 Not used by BCA Release 5 Half Duplex i A.5.2/5 Not used by BCA 6 Duplex m A.5.2/6 7 Expedited Data i A.5.2/7 Not used by BCA 8 Typed Data i A.5.2/8 Not used by BCA 9 Capability Data i A.5.2/9 Not used by BCA Exchange 1 Minor Synchronize i A.5.2/10 Not used by BCA 0 1 Symmetric i A.5.2/11 Not used by BCA 1 Synchronize 1 Major Synchronize i A.5.2/12 Not used by BCA 2 1 Resynchronize i A.5.2/13 Not used by BCA 3 1 Exceptions i A.5.2/14 Not used by BCA 4 1 Activity i A.5.2/15 Not used by BCA 5 Management B.2 Elements of procedure related to the PICS [PICS clause A.6] B.2.1 Kernel functional unit [PICS A.6.1] B.2.1.1 Supported roles [PICS A.6.1.1] B.2.1.1.1 Presentation-connection [PICS A.6.1.1.1] 43 Working Draft ISO/IEC ISP 11188-3 September 1993 Role Pro PICS Comment fil refer- e ence 1 Initiator c[1 A.6.1.1. ] 1/1 2 Responder c[2 A.6.1.1. ] 1/2 [1]"m" if Establishment-role is "initiator" or "both"; otherwise "i" [2]"m" if Establishment-role is "responder" or "both"; otherwise "i" B.2.1.1.2 Normal data [PICS A.6.1.1.2] Role Pro PICS Comment fil refer- e ence 1 Requestor c[1 A.6.1.1. ] 2/1 2 Acceptor c[2 A.6.1.1. ] 2/2 [1]"m" if Normal-data-role is "requestor" or "both"; otherwise "i" [2]"m" if Normal-data-role is "acceptor" or "both"; otherwise "i" 44 September 1993 Working Draft ISO/IEC ISP 11188-3 B.2.1.1.3 Orderly release [PICS A.6.1.1.3] Role Pro PICS Comment fil referenc e e 1 Requestor c[1 A.6.1.1. ] 3/1 2 Acceptor c[2 A.6.1.1. ] 3/2 [1]"m" if Release-role is "requestor" or "both"; otherwise "i" [2]"m" if Release-role is "acceptor" or "both"; otherwise "i" B.2.1.2 Supported PPDUs associated with the kernel service [PICS A.6.1.2] PPDU Prof Prof Prof PICS Comment ile: ile: ile: refer- send send rece ence er er iver Cat Cat I II 1 CP c[1] c[1] c[2] A.6.1.2/ 1 2 CPA c[2] c[2] c[1] A.6.1.2/ 2 3 CPR c[2] c[3] c[1] A.6.1.2/ 3 4 ARP m m m A.6.1.2/ send and 4 receive 5 ARU m m m A.6.1.2/ send and 5 receive 6 TD c[4] c[4] c[5] A.6.1.2/ m 6 [1]"m" if Establishment-role is "initiator" or "both"; otherwise "i" [2]"m" if Establishment-role is "responder" or "both"; 45 Working Draft ISO/IEC ISP 11188-3 September 1993 otherwise "i" [3]"o" if Establishment-role is "responder" or "both"; otherwise "i" [4]"m" if Normal-data-role is "requestor" or "both"; otherwise "i" [5]"m" if Normal-data-role is "acceptor" or "both"; otherwise "i" NOTE--The remainder of the PICS subclauses in A.6 is out of the scope (i) of this Profile. 46 September 1993 Working Draft ISO/IEC ISP 11188-3 B.3 Supported PPDU parameters [PICS clause A.7] B.3.1 Connect presentation (CP) parameters [PICS A.7.1] Parameter Prof Prof Prof PICS Comment ile: ile: ile: refe Send Send Rece r- er er iver ence Cat Cat I II [a] [b] 1 Calling pre- m o m A.7. sentation 1/1 selector 2 Called pre- m m m A.7. sentation 1/2 selector 3 Mode selector m o m A.7. 1/3 4 Presentation m m m A.7. context 1/4 definition list 5 Default context i i m A.7. Not used by name 1/5 BCA 6 Protocol version o o m A.7. = version 1 1/5 for BCA 7 Presentation i i m A.7. Not used by requirements 1/7 BCA 8 User session i i m A.7. requirements 1/8 9 User data m m m A.7. 1/9 [a]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value 47 Working Draft ISO/IEC ISP 11188-3 September 1993 is as marked. NOTE Note: [The X.410 (1984) parameters are out of the scope (i) of this Profile.] B.3.2 Connect presentation accept (CPA) PPDU [PICS A.7.2] Parameter Prof Prof Prof PICS Comment ile: ile: ile: refe Send Send Rece r- er er iver ence Cat Cat I II [a] [b] 1 Responding pre- m o m A.7. sentation 2/1 selector 2 Mode selector m m m A.7. = Normal 2/2 for BCA 3 Presentation m m m A.7. context 2/3 definition result list 4 Protocol version o o m A.7. = version 1 2/4 for BCA 5 Presentation i i m A.7. Not used by requirements 2/5 BCA 6 User session i i m A.7. requirements 2/6 7 User data m m m A.7. 2/7 [a]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. 48 September 1993 Working Draft ISO/IEC ISP 11188-3 NOTE Note: [The X.410 (1984) parameters are out of the scope (i) of this Profile.] 49 Working Draft ISO/IEC ISP 11188-3 September 1993 B.3.3 Connect presentation reject (CPR) PPDU [PICS A.7.3] Parameter Profi Profi PICS Comment le: le: referenc Sende Recei e r ver [a] [b] 1 Responding m m A.7.3/1 presentation selector 2 Presentation m m A.7.3/2 context definition result list 3 Protocol version o m A.7.3/3 = version 1 for BCA 4 Default context i m A.7.3/4 Not used by result BCA 5 Provider reason m m A.7.3/5 limited number are mandatory 6 User data m m A.7.3/6 [a]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. Note: [NOTE The X.410 (1984) parameter is out of the scope (i) of this Profile. ] B.3.4 Abnormal release user (ARU) PPDU [PICS A.7.4] 50 September 1993 Working Draft ISO/IEC ISP 11188-3 Parameter Profi Profi PICS Comment le: le: referenc Sende Recei e r ver 1 Presentation m m A.7.4/1 context identifier list 2 User data m m A.7.4/2 Note: [ NOTE The X.410 (1984) parameters are out of the scope (i) of this Profile. ] B.3.5 Abnormal release provider (ARP) PPDU [PICS A.7.5] Parameter Profi Profi PICS Comment le: le: referenc Sende Recei e r ver 1 Provider reason m m A.7.5/1 2 Event identifier o m A.7.5/2 Note: [ NOTE PICS subclauses A.7.6 through A.7.15 are out of the scope (i) of this Profile.] 51 Working Draft ISO/IEC ISP 11188-3 September 1993 B.4 Support of syntax's [PICS clause A.8] B.4.1 Transfer syntax's supported [PICS A.8.1] Type Detail Prof Refere Refere ile nce to nce to defini restri tion ction 1 Object = {joint-iso-ccitt m ISO ISO identifi asn1(1) basic- 8825 11188- er encoding(1)} 1 2 Object (see Annex E) o ISO none identifi 11188- er 3 Note: [ NOTE Other transfer syntax's may be added to the above table based on the application(s) supported.] B.4.2 Abstract syntax's supported [PICS A.8.2] Type Detail Prof ile 1 Object {joint-iso-ccitt association-control(2) m identifi abstract-syntax(1) apdus(0) version1(1) er 2 Object (see Annex E) o identifi er Note: [ NOTE Other abstract syntax's may be added to the above table based on the application(s) supported. 52 September 1993 Working Draft ISO/IEC ISP 11188-3 ] B.4.3 Use of ASN.1 encoding [PICS A.8.3] The following table is used to indicate any coding restrictions for sending all ACSE's APDUs, PPDUs and User Information on ACSE APDU's (see PICS A.8.3). Restriction Prof Comment ile 1 Only definite form of length ox encoding used 2 Indefinite form of length o encoding used for all constructed types 3 Only minimal number of o octets used for definite form of length encoding 4 Only primitive encoding used o for OCTET STRING 5 Only primitive encoding used o for BITSTRING Note: [ NOTE PICS subclause A.8.4 is out of the scope (i) of this Profile. ] 53 Working Draft ISO/IEC ISP 11188-3 September 1993 Annex C Requirements for Session Layer facilities (Normative) This annex specifies the session requirements for completing the Session PICS (ISO 8327-2) for the categories, roles, and options selected (see 8.2). The specifications in this annex are based on the Proforma tables of the Session Layer PICS Proforma. The clause numbers and tables referenced in this annex are those of ISO 8327-2. If a clause number of ISO 8327-2 is not mentioned it is out of the scope of this Profile. It may be ignored and will, therefore, not be subject to the compliance statement of this Profile. The specifications references the following variables: Establishment-role, Normal-data-role, and Release-role. These are discussed in 8.2. Note: [NOTE PICS clauses A.1-A.4 are outside of the scope of this Profile. ] C.1 Global statement of conformance [PICS A.5] Question Answer PICS reference 1 Are all mandatory features yes A.5/1 implemented? C.2 Supported functional units and protocol mechanisms [PICS A.6] C.2.1 Functional units [PICS A.6.1] Functional unit Prof PICS Comment ile referenc e 1 Kernel m A.6.1/1 2 Negotiated i A.6.1/2 Not used by BCA Release 3 Half Duplex i A.6.1/3 Not used by BCA 4 Duplex m A.6.1/4 54 September 1993 Working Draft ISO/IEC ISP 11188-3 5 Expedited Data i A.6.1/5 Not used by BCA 6 Typed Data i A.6.1/6 Not used by BCA 7 Capability Data i A.6.1/7 Not used by BCA 8 Minor Synchronize i A.6.1/8 Not used by BCA 9 Symmetric i A.6.1/9 Not used by BCA Synchronize 1 Major Synchronize i A.6.1/10 Not used by BCA 0 1 Resynchronize i A.6.1/11 Not used by BCA 1 1 Exceptions i A.6.1/12 Not used by BCA 2 1 Activity i A.6.1/13 Not used by BCA 3 Management 55 Working Draft ISO/IEC ISP 11188-3 September 1993 C.2.2 Protocol mechanism [PICS A.6.2] Mechanism Prof PICS Comment ile referenc e 1 Use of transport o A.6.2/1 expedited data (Extended control Quality Of Service) 2 Reuse of i A.6.2/2 Not required in transport- CULR-1 connection 3 Basic m A.6.2/3 concatenation 4 Extended i A.6.2/4 Not required in concatenation CULR-1 (sending) 5 Extended i A.6.2/5 Not used by BCA concatenation (receiving) 6 Segmenting i A.6.2/6 Not used with BCA (sending) (see CULR-1) 7 Segmenting i A.6.2/7 Not used by BCA (receiving) 8 Max size of SS- x A.6.2/8 user data 512 9 Max size of SS- m A.6.2/9 user data 10240 1 Max size of SS- x A.6.2/10 0 user data 9 C.3 Elements of procedures related to the PICS [PICS A.7] C.3.1 Kernel functional unit [PICS A.7.1] C.3.1.1 Supported roles for the Kernel functional unit 56 September 1993 Working Draft ISO/IEC ISP 11188-3 services [PICS A.7.1.1] C.3.1.1.1 Session-connection [PICS A.7.1.1.1] Role Pro PICS Comment fil referenc e e 1 Initiator c[1 A.7.1.1. ] 1/1 2 Responder c[2 A.7.1.1. ] 1/2 [1]"m" if Establishment-role is "initiator" or "both"; otherwise "i" [2]"m" if Establishment-role is "responder" or "both"; otherwise "i" C.3.1.1.2 Orderly release [PICS A.7.1.1.2] Role Pro PICS Comment fil referenc e e 1 Requestor c[1 A.7.1.1. ] 2/1 2 Acceptor c[2 A.7.1.1. ] 2/2 [1]"m" if Release-role is "requestor" or "both"; otherwise "i" [2]"m" if Release-role is "acceptor" or "both"; otherwise "i" 57 Working Draft ISO/IEC ISP 11188-3 September 1993 C.3.1.1.3 Normal data transfer [PICS A.7.1.1.3] Role Pro PICS Comment fil referenc e e 1 Requestor c[1 A.7.1.1. ] 3/1 2 Acceptor c[2 A.7.1.1. 3/2 [1]"m" if Normal data-role is "requestor" or "both"; otherwise "i" [2]"m" if Normal data-role is "acceptor" or "both"; otherwise "i" C.3.1.2 Support for the SPDUs associated with the Kernel services [PICSA.7.1.2] SPDU Prof Prof PICS Comment ile: ile: referenc Send Rece e er iver 1 Connect (CN) c[1] c[2] A.7.1.2/ 1 2 Overflow accept i i A.7.1.2/ Not used by (OA) 2 BCA 3 Connect Data i i A.7.1.2/ Not used by Overflow (CDO) 3 BCA 4 Accept (AC) c[2] c[1] A.7.1.2/ 4 5 Refuse c[2] c[1] A.7.1.2/ 5 6 Finish c[3] c[4 A.7.1.2/ 6 7 Disconnect (DN) c[4] c[3] A.7.1.2/ 7 58 September 1993 Working Draft ISO/IEC ISP 11188-3 8 Abort (AB) m m A.7.1.2/ 8 9 Abort Accept o o A.7.1.2/ (AA) 9 1 Data Transfer c[5] m A.7.1.2/ 0 (DT) 10 1 Prepare (PR) o c[6] A.7.1.2/ 1 11 [1]"m" if Establishment-role is "initiator" or "both"; otherwise "i" [2]"m" if Establishment-role is "responder" or "both"; otherwise "i" [3]"m" if Release-role is "requestor" or "both"; otherwise "i" [4]"m" if Release-role is "acceptor" or "both"; otherwise "i" [5]"m" if Normal-data-role is "requestor" or "both"; otherwise "i" [6]"m" if mOSI is supported by transport expedited; otherwise "i" Note: [NOTE The remainder of the PICS subclauses in A.7 is out of the scope (i) of this Profile. ] 59 Working Draft ISO/IEC ISP 11188-3 September 1993 C.4 Supported SPDU parameters [PICS A.8] C.4.1 Connect (CN) SPDU [PICS A.8.1] C.4.1.1 Connection Identifier [PICS A.8.1.1] PGI "Connection Profi Profi PICS Comment Identifier" le: le: referenc Sende Recei e r ver [a] [b] 1 Calling SS-user i m A.8.1.1/ Not used by Reference 1 BCA 2 Common Reference i m A.8.1.1/ Not used by 2 BCA 3 Additional i m A.8.1.1/ Not used by Reference 3 BCA Information 60 September 1993 Working Draft ISO/IEC ISP 11188-3 C.4.1.2 Connect/Accept Item [PICS A.8.1.2] C.4.1.2.1 Connect/Accept Item parameters [PICS A.8.1.2.1] PGI Prof Profi PICS Comment "Connect/Ac ile: le: refer cept Send Recei ence Item" er ver [a] [b] 1 Protocol m m A.8.1 For BCA, basic Options .2.1/ concatenation shall 1 be indicated 2 TSDU o m A.8.1 = 0 for BCA maximum .2.1/ size 2 3 Version m m A.8.1 = version 2 for BCA Number .2.1/ 3 4 Initial i m A.8.1 Not used by BCA Serial .2.1/ Number 4 5 Token i m A.8.1 Not used by BCA Setting .2.1/ Item 5 6 Second i m A.8.1 Not used by BCA Initial .2.1/ Serial 6 Number [a]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. C.4.1.2.2 Presence of Connect/Accept Item [PICS A.8.1.2.2] 61 Working Draft ISO/IEC ISP 11188-3 September 1993 Prof Prof PICS Comment ile: ile: referenc Send Rece e er iver [a] [b] 1 Sending m i A.8.1.2. 2/1 2 Receiving i m A.8.1.2. 2/2 [a]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. C.4.1.3 Single Items [PICS A.8.1.3] Single Items Profi Profi Profi PICS Comment le: le: le: refe Sende Sende Recei renc r r ver e Cat I Cat [b] [a] II [a] 1 Session User m m m A.8. For BCA, Requirements 1.3/ shall 1 include duplex 2 Calling o o m A.8. Session 1.3/ Selector 2 3 Called m o m A.8. Session 1.3/ Selector 3 4 Data Overflow i i m A.8. Not used by 1.3/ BCA 4 62 September 1993 Working Draft ISO/IEC ISP 11188-3 5 User Data m m m A.8. 1.3/ 5 6 Extended User m o m A.8. Data 1.3/ 6 [a]This entire column has the value of "i" if Establishment-role is "responder"; otherwise the value is as marked. [b]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. Note: [NOTE The session PICS (ISO 8327-2) mandates that the Called Session Selector be sent. However, the session protocol specification (ISO 8327-1) indicates that this datatype is optional. This Profile has chosen to make this item optional ("o") for category II. ] C.4.2 Accept (AC) SPDU [PICS A.8.4] C.4.2.1 Connection Identifier [PICS A.8.4.1] PGI "Connection Profi Profi PICS Comment Identifier" le: le: referenc Sende Recei e r ver [a] 1 Calling SS-user i m A.8.4.1/ Not used by Reference 1 BCA 2 Common Reference i m A.8.4.1/ Not used by 2 BCA 3 Additional i m A.8.4.1/ Not used by Reference 3 BCA Information [a]This entire column has the value of "i" if Establishment-role is "initiator"; otherwise the value is as marked. C.4.2.2 Connect/Accept Item [PICS A.8.4.2] 63 Working Draft ISO/IEC ISP 11188-3 September 1993 C.4.2.2.1 Connect/Accept Item parameters [PICS A.8.4.2.1] PGI Prof Prof PICS Comment "Connect/A ile: ile: referenc ccept Send Rece e Item" er iver [a] [b] 1 Protocol m m A.8.4.2. Basic concatenation Options 1/1 shall be indicated 2 TSDU o m A.8.4.2. If sent , value shall maximum 1/2 be 0 size 3 Version m m A.8.4.2.1/3 Number 64