Working Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers Output from the March 1994 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: James Quigley, Hewlett Packard SIG Editors: Debbie Britt, NCTS Laura Emmons, Telenex Part 5 - Upper Layers March 1994 (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 Part 1 - Workshop Policies and Procedures in the "Draft Working Implementation Agreements Document" for the 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 March 1994 are being printed. Please refer to the December 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 March 1994 (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 Technical Corriagenda and Defect Reports . . . . . . 1 4.3 Defect Registers . . . . . . . . . . . . . . . . . . 2 4.4 Exception Handling . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . 3 8.3.1 Transfer Syntaxes . . . . . . . . . . . . . 3 8.3.2 Presentation Context Identifier . . . . . . 3 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 . . . . 4 8.3.7 CPC-Type . . . . . . . . . . . . . . . . . 4 8.3.8 Presentation-context-definition-result-list 4 8.3.9 RS-PPDU . . . . . . . . . . . . . . . . . . 4 8.4 Presentation ASN.1 Encoding Rules . . . . . . . . . 4 8.5 Presentation Data Value (PDV) . . . . . . . . . . . 5 8.6 Connection Oriented . . . . . . . . . . . . . . . . 5 iii Part 5 - Upper Layers March 1994 (Working) 8.7 Connectionless . . . . . . . . . . . . . . . . . . . 5 9 Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1 Introduction . . . . . . . . . . . . . . . . . . . . 5 9.2 Services . . . . . . . . . . . . . . . . . . . . . . 5 9.3 Protocol Agreements . . . . . . . . . . . . . . . . 5 9.3.1 Concatenation . . . . . . . . . . . . . . . 5 9.3.2 Segmenting . . . . . . . . . . . . . . . . 5 9.3.3 Reuse of Transport Connection . . . . . . . 6 9.3.4 Use of Transport Expedited Data . . . . . . 6 9.3.5 Use of Session Version Number . . . . . . . 6 9.3.5.1 Selection of session version . . . . . . . 6 9.3.5.2 User data in session version 2 . . . . . . 6 9.3.6 Receipt of Invalid SPDUs . . . . . . . . . 6 9.3.7 Invalid SPM Intersections . . . . . . . . . 6 9.3.8 S-Selectors . . . . . . . . . . . . . . . . 6 9.4 Connectionless . . . . . . . . . . . . . . . . . . . 7 10 Universal ASN.1 Encoding Rules . . . . . . . . . . . . . 7 10.1 Tags . . . . . . . . . . . . . . . . . . . . . . . . 7 10.2 Definite Length . . . . . . . . . . . . . . . . . . 7 10.3 External . . . . . . . . . . . . . . . . . . . . . . 7 10.4 Integer . . . . . . . . . . . . . . . . . . . . . . 7 10.5 String Types . . . . . . . . . . . . . . . . . . . . 7 10.6 Extensibility . . . . . . . . . . . . . . . . . . . 7 11 Additions to ISP on Common Upper Layer Requirements . . . 8 11.1 Service . . . . . . . . . . . . . . . . . . . . . . 8 11.2 Provider Abort Parameters . . . . . . . . . . . . . 8 11.3 Concatenation . . . . . . . . . . . . . . . . . . . 8 11.4 Segmenting . . . . . . . . . . . . . . . . . . . . . 8 11.5 Reuse of Transport Connection . . . . . . . . . . . 8 11.6 Use of Transport Expedited Data . . . . . . . . . . 8 12 Character Sets . . . . . . . . . . . . . . . . . . . . . 8 13 Conformance . . . . . . . . . . . . . . . . . . . . . . . 9 14 Specific ASE Requirements . . . . . . . . . . . . . . . . 9 14.1 FTAM Phase 2 . . . . . . . . . . . . . . . . . . . . 9 14.2 MHS . . . . . . . . . . . . . . . . . . . . . . . . 9 14.3 DS Phase 1 . . . . . . . . . . . . . . . . . . . . . 9 14.4 Virtual Terminal . . . . . . . . . . . . . . . . . . 9 14.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . 9 14.6 Transaction Processing . . . . . . . . . . . . . . . 9 14.7 Network Management . . . . . . . . . . . . . . . . . 9 14.8 Remote Database Access . . . . . . . . . . . . . . . 10 Annex A (normative) iv Part 5 - Upper Layers March 1994 (Working) Object Identifier Register . . . . . . . . . . . . . . . . . 11 A.1 Register Index . . . . . . . . . . . . . . . . . . . 11 A.2 Object Identifier Descriptions . . . . . . . . . . . 11 Annex B (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 12 Annex C (informative) Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 Annex D (normative) Working Draft of new ISP on mOSI Specification . . . . . . . 24 Annex E (normative) Working Draft of new ISP on CL-CULR Specification . . . . . . 41 Annex F (informative) Upper Layer SIG Registered Questions List . . . . . . . . . . 42 v Part 5 - Upper Layers Editor's Note - All references to Stable Agreements in this section are to Version 8. 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 Implementation Agreements). 4.2 Technical Corriagenda and Defect Reports (Refer to Stable Implementation Agreements). 1 Part 5 - Upper Layers March 1994 (Working) 4.3 Defect Registers (Refer to Stable Implementation Agreements). 4.4 Exception Handling (Refer to Stable Implementation Agreements). 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) 5.3.3 Peer Entity Authentication (Refer to Stable Agreements Document) 2 Part 5 - Upper Layers March 1994 (Working) 5.4 Abort APDU (Refer to Stable Agreements Document) 5.5 Connectionless (Refer to Stable Agreements Document) 6 ROSE (Refer to Stable Agreements Document) 7 RTSE (Refer to Stable Agreements Document) 8 Presentation 8.1 Introduction (Refer to Stable Agreements Document) 8.2 Service (Refer to Stable Implementation Agreements). 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) 3 Part 5 - Upper Layers March 1994 (Working) 8.3.3 Default Context (Refer to Stable Agreements Document) 8.3.4 P-Selectors (Refer to the Stable Agreements Document) 8.3.5 Provider Abort Parameters (Refer to Stable Implementation Agreements). Editor's Note - 8.3.6 Provider Aborts and Session Version (Refer to the Stable Agreements Document) 8.3.7 CPC-Type (Refer to the Stable Agreements Document) 8.3.8 Presentation-context-definition-result-list (Refer to the Stable Agreements Documents) 8.3.9 RS-PPDU (Refer to the Stable Agreements Documents) 8.4 Presentation ASN.1 Encoding Rules (Refer to the Stable Agreements Document) 4 Part 5 - Upper Layers March 1994 (Working) 8.5 Presentation Data Value (PDV) (Refer to the Stable Agreements Document) 8.6 Connection Oriented (Refer to the Stable Agreements Document) 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 (Refer to Stable Implementation Agreements). Editor's Note - 9.3.2 Segmenting (Refer to Stable Implementation Agreements). Editor's Note - 5 Part 5 - Upper Layers March 1994 (Working) 9.3.3 Reuse of Transport Connection (Refer to Stable Implementation Agreements). Editor's Note - 9.3.4 Use of Transport Expedited Data (Refer to Stable Implementation Agreements). Editor's Note - 9.3.5 Use of Session Version Number 9.3.5.1 Selection of session version (Refer to the Stable Agreements Documents) 9.3.5.2 User data in session version 2 (Refer to the Stable Agreements Document) 9.3.6 Receipt of Invalid SPDUs (Refer to the Stable Agreements Document) 9.3.7 Invalid SPM Intersections (Refer to the Stable Agreements Document) 9.3.8 S-Selectors (Refer to the Stable Agreements Document) 6 Part 5 - Upper Layers March 1994 (Working) 9.4 Connectionless (Refer to Stable Agreements Document) 10 Universal ASN.1 Encoding Rules 10.1 Tags (Refer to the Stable Agreements Document) 10.2 Definite Length (Refer to the Stable Agreements Document) 10.3 External (Refer to the Stable Agreements Document) 10.4 Integer (Refer to the Stable Agreements Document) 10.5 String Types (Refer to the Stable Agreements Document) 10.6 Extensibility (Refer to the Stable Agreements Document) 7 Part 5 - Upper Layers March 1994 (Working) 11 Additions to ISP on Common Upper Layer Requirements 11.1 Service (Refer to Stable Agreements Document) 11.2 Provider Abort Parameters (Refer to Stable Agreements Document) 11.3 Concatenation (Refer to Stable Agreements Document) 11.4 Segmenting (Refer to Stable Agreements Document) 11.5 Reuse of Transport Connection (Refer to Stable Agreements Document) 11.6 Use of Transport Expedited Data (Refer to Stable Agreements Document) 12 Character Sets (Refer to part 21 -- a new chapter expressly for character sets.) 8 Part 5 - Upper Layers March 1994 (Working) 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) 14.5 MMS (Refer to Stable Agreements Document) 14.6 Transaction Processing (Refer to Stable Agreements Document) 14.7 Network Management (Refer to Stable Agreements Document) 9 Part 5 - Upper Layers March 1994 (Working) 14.8 Remote Database Access (Refer to Stable Agreements Document) 10 Part 5 - Upper Layers March 1994 (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) 11 Part 5 - Upper Layers March 1994 (Working) Annex B (informative) Recommended Practices (Refer to Stable Agreements Document.) 12 Part 5 - Upper Layers March 1994 (Working) Annex C (informative) Backward Compatibility 13 Part 5 - Upper Layers March 1994 (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.] | +----------------------------+---------------+------------------- ------------+ 14 Part 5 - Upper Layers March 1994 (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.] | +----------------------------+---------------+------------------- ------------+ 15 Part 5 - Upper Layers March 1994 (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 | 16 Part 5 - Upper Layers March 1994 (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 | 17 Part 5 - Upper Layers March 1994 (Working) | | | versions previous to V3E1 as | | | | a responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ 18 Part 5 - Upper Layers March 1994 (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 | 19 Part 5 - Upper Layers March 1994 (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 | 20 Part 5 - Upper Layers March 1994 (Working) | proposed. | | receivers that do not examine | | | | them. | +----------------------------+---------------+------------------- ------------+ 21 Part 5 - Upper Layers March 1994 (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. | 22 Part 5 - Upper Layers March 1994 (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.] | +----------------------------+---------------+------------------- ------------+ 23 Part 5 - Upper Layers March 1994 (Working) Annex D (normative) Working Draft of new ISP on mOSI Specification 24 ULSIG-74-12/93 May 22, 1994 TITLE: Explanatory Report for PDISP 11188-3 for Common Upper Layer Requirements - Part 3: Minimal OSI upper layer facilities SOURCE: OIW Laura Emmons DATE: May 22, 1994 STATUS: Draft report for information to the Regional OSI/OSE workshops and for submission to SGFS together with PDISP 11188-3 a) General Profile Information 1) Profile Identifier This profile does not specify a full A-profile, and therefore has no place within the taxonomy of TR 10000-2. 2) Profile Title Common Upper Layer Requirements Part 3: Minimal OSI upper layer facilities 3) Submitting Organization Open Systems Environmental Implementor's Workshop (OIW) Laura Emmons Telenex, Inc. 7401 Boston Blvd. Springfield, VA 22153 USA Tel: (703) 644-9113 Fax: (703) 644-9011 e-mail: laurae@ar.telenex.com 4) Date of notification to SGFS 25 ULSIG-74-12/93 May 22, 1994 5) Maintenance Commitment The OIW ULSIG will ensure on behalf of the three regional OSI/OSE workshops that the maintenance of PDISP 11188-3 will be done. James Quigley is the project manager. b) Base Standards Referenced 1) List of ISO/IEC standards, technical reports and CCITT recommendations Editor's note: These references will be updated in the course of DISP to ISP progression. 1.1 Identical Recommendations | International Standards CCITT Recommendation X.227 (1993) | ISO 8650: 1993,1 Information processing systems Open Systems Interconnection Protocol specification for the Association Control Service Element. 1.2 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 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 1 Currently under ISO/IEC national body review 26 ULSIG-74-12/93 May 22, 1994 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. 1.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- oriented requirements.2 2) TR 10000-1 Conformance The documentation requirements of ISO/IEC TR 10000-1 on conformance are not met. 2Currently at level of working draft 27 ULSIG-74-12/93 May 22, 1994 The Profile Requirements List of PDISP 11188-3 consist of several tables which specify the profile requirements. They currently refer to the DIS versions of the PICS proforma of the base standards of the ACSE, Presentation, and Session service definitions. A proforma for determining compliance to this profile is presented in Annex D. 3) Aspects of non-compliance with standards No such aspects. 4) Ammendments, corrigenda to base standards None in addition to clause 3 of PDISP 11188-3 (see also editor's note above). c) Registration requirements None d) Other publications Draft IETF RFC "ThinOSI upper layers cookbook", P. Furniss (London: 1993) "X/Open Transport Interface Appendix for Minimal OSI Functionality", H. Lowe (Cambridge, MA: 1993) e) Profile purpose 1) Executive Summary ISO/IEC ISP 11188 as a multi-part ISP specifies general requirements on the use of OSI upper layer 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 28 ULSIG-74-12/93 May 22, 1994 specifications which specify A-profiles. In addition to simplifying their drafting, it also facilitates the common implementation of the protocols for their use in different A-profile contexts. This part of ISO/IEC ISP 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. 2) Relationship to other ISPs PDISP 11188-3 is specified as a common basis to be referenced and used by application ISPs for A- profiles, e.g. ISPs for the AFT or AOM profiles. This profile would be referenced in place of PDISP 11188-1 Coomon upper layer requirements: Basic connection- oriented requirements. f) PDISP development process 1) Editor: OSI ULSIG (Laura Emmons) History: Draft 1 OIW/ULSIG-33-03/93First OIW draft of mOSI ISP written in ISP format and based on the CULR-1. Circulated for comments to the regional workshops. Added as annex to working Implementor's Agreements of the OIW. Draft 2 OIW/ULSIG-33-06/93 Revisions made after comments were obtained from OIW and EWOS. Draft 3 OIW/ULSIG-33-09/93 Further revisions made after comments were obtained from OIW and EWOS. Draft 4 OIW/ULSIG-33-12/93 Further revisions were made after issues were raised by OIW and EWOS. 2) Degree of Openess and Harmonization 29 ULSIG-74-12/93 May 22, 1994 The working drafts of PDISP 11188-3 have been circulated to all three regional workshops. 3) Joint planning operation The PDISP was developed under the coordination of RWS-CC. g) PDISP content and format 1) TR 10000-1-1 Requirements These requirements have/have not been met. 2) Divergence from TR 10000 3) Multi-part structure This PDISP is structured as a multi- part ISP to meet the requirements of various A-profiles. Additional parts: Draft for PDISP 11188-1: Common upper layer requirements - Part 1: Basic connection- oriented requirements Draft for PDISP 11188-2: Common upper layer requirements - Part 2: Basic connection- oriented requirements for ROSE based profiles h) Any other information None 30 Document No.ULSIG-71-12/93 Date:May 22, 1994 mOSI Issues List (10) Reference: New Annex Issue: An informative bibliography should be added which would contain non-normative references. Source: OIW ULSIG Date Raised: December 7, 1993 Solution: Added new annex I. Status: OIW:Accepted December 10, 1993 EWOS: AOW: (11) Reference: Clauses 2 and 8 Issue: All information on compliance and conformance should be combined into clause 2. Source: OIW ULSIG Date Raised: December 7, 1993 Solution: Combine relevant parts of clause 8 into clause 2. Status: OIW:Accepted December 10, 1993 EWOS: AOW: 31 Document No.ULSIG-71-12/93 Date:May 22, 1994 (12) Reference: Annexes A, B and C. Issue: It was felt that since the definition of category 1 compliance/conformance implies that all facilities are mandatory for sending, it is not necessary to have separate column for category 1 and 2 in the tables. Source: OIW ULSIG Date Raised: December 7, 1993 Solution: Removed category 1 column from all tables. Status: OIW:Accepted December 10, 1993 EWOS: AOW: (13) Reference: Annexes A and B. Issue: In order to align with AOM1n (CMISE) and AFTnn (FTAM) profiles, the following facilities/parameters should be made optional in the tables: RLRQ and RLRE reason code, CPR and ARP provider reason, and CPR Responding Presentation selector. Source: OIW ULSIG Date Raised: December 7, 1993 Solution: Tables have been changed. Status: OIW:Accepted December 10, 1993 EWOS: AOW: 32 Document No.ULSIG-71-12/93 Date:May 22, 1994 (14) Reference: Clause 6 Issue: There should be a new table which outlines the definitions of mandatory, optional, out- of-scope, and excluded for the cases of compliance and conformance. Source: OIW ULSIG Date Raised: December 7, 1993 Solution: Table added to clause 6. Status: OIW:Accepted December 10, 1993 EWOS: AOW: (15) Reference: All Issue: All information in CULR- 1 should be replicated in this document so that people do not have to read so many speciifications. Source: OIW ULSIG Date Raised: December 9, 1993 Solution: Open. Will be discussed at next workshop. Status: OIW: EWOS: AOW: 33 Document No.ULSIG-71-12/93 Date:May 22, 1994 (16) Reference: Clause 6 Issue: Review the definitions in clause 6 for accuracy. Source: OIW ULSIG Date Raised: December 9, 1993 Solution: Open. Status: OIW: EWOS: AOW: (4) Reference: Introduction Issue: Add expalnatory report and executive summary to document. Source: OIW ULSIG Date Raised: September 13, 1993 Solution: Added Foreword, Explanatory Report, changed Introduction. Status: OIW:AcceptedSeptember 16, 1993 EWOS: AOW: (5) Reference: Clause 8 Issue: Compliance clause should be in same section in both CULR-1 and this document. Source: EWOS TLG Date Raised: July 13, 1993 Solution: Moved 8.1 - 8.2 to new clause 2. Moved 8.3 and 8.4 to new Annex D. Status: OIW:AcceptedSeptember 16, 1993 EWOS: AOW: 34 Document No.ULSIG-71-12/93 Date:May 22, 1994 (6) Reference: Clause 5, Table 1 Issue: Issue on whether the definition of mandatory is correct. Source: OIW ULSIG Date Raised: June 10, 1993 Solution: After joint meeting with the OIW CT SIG, added new note under table 1. Comments requested. Status: OIW:Accepted September 16, 1993 EWOS: AOW: (7) Reference: 2.1 Annex D, Tables 2 and 3 Issue: Issue on the correctness of tables 2 and 3 (and their corresponding documentation in 2.1) when used as a proforma by a referencing standalone application specification. Source: OIW ULSIG Date Raised: 15 September 1993 Solution: Jim Quigley has supplied new text in clause 2 and annexes D and E.. Status: OIW:Accepted December 10, 1993 EWOS: AOW: 35 Document No.ULSIG-71-12/93 Date:May 22, 1994 (8) Reference: 3.7 Issue: Add definitions for category 1 and 2. Source: OIW ULSIG Date Raised: 13 September 1993 Solution: Done. Section number has changed to 4.7. Status: OIW:AcceptedSeptember 16, 1993 EWOS: AOW: (9) Reference: None. Issue: Issue on whether to add section on use of transport services, especially the Reuse of Transport Connection service. Source: Kedem Kaminsky Date Raised: 14 September 1993 Solution: Mr. Kaminsky was specifically interested in the use of mOSI by network management profiles. The AOM1n profile is the most widely used network management profile. It explicitly states that reuse of the transport connection is out of scope. CULR-3 also states this in Annex C. The AOM1n profile makes no other comments on the use of the Transport service. This is not an issue. Status: OIW:Accepted December 7, 1993 EWOS: AOW: 36 Document No.ULSIG-71-12/93 Date:May 22, 1994 (1) Reference: B.3.1 line 2 C.4.1.3 line 3 Issue: Called (N)-selectors should be optional for sending in Catagory II compliance. Source: OIW ULSIG Date Raised: June 10, 1993 Solution: Cat II "m" should be changed to "o". Status: OIW: AcceptedJune 10, 1993 EWOS: AOW: (2) Reference: D.2 Issue: Clause D.2 is not written clearly. Source: OIW ULSIG Date Raised: June 10, 1993 Solution: Rewritten to say the following: "Transfer-syntax is the representation of the abstract-syntax during data transfer. If an application does not make a distinction between the abstract and transfer syntax, the same object identifier should be used to denote both syntaxes. In the case where: a) the abstract and transfer syntax are not the same; and b) the default abstract syntax object identifier has been used (see D.1 above) the following default transfer syntax object identifier may be used..." Status: OIW:AcceptedJune 10, 1993 37 Document No.ULSIG-71-12/93 Date:May 22, 1994 EWOS: AOW: 38 Document No.ULSIG-71-12/93 Date:May 22, 1994 (3) Reference: Annex E Issue: There is no text for Annex E. It should be removed. Source: OIW ULSIG Date Raised: June 10, 1993 Solution: Removed. Status: OIW:AcceptedJune 10, 1993 EWOS: AOW: 39 ULSIG-85-09/93 May 22, 1994 Schedule for Progression of CULR Milestone CULR-1 CULR-2 CULR-3 Informal SC21 May 92/ Jun 93 N/A Jun 93 review EWOS Sep 93 Nov 93 May 94 endorsement OIW Sep 93 Dec 93 Mar 94 endorsement AOW Oct 93 Dec 93 - Feb Apr 94 endorsement 94 by correspondence pDISP Nov 93/ Mar 94 Apr 94/Aug 94 May 94/ Aug 94 submission DISP Ballot Dec 93 - Apr Sep 94 - Jan Sep 94 - Jan 94 95 95 EDIT Meeting Jul 94 Feb 95 Feb 95 FINAL TEXT Oct 94 Mar 95 Mar 95 40 ULSIG-85-09/93 May 22, 1994 Annex E (normative) Working Draft of new ISP on CL-CULR Specification (This is ONLY a placeholder for anticipated work on a new profile for connectionless upper layer facilities) 41 ULSIG-85-09/93 May 22, 1994 Annex F (informative) Upper Layer SIG Registered Questions List ULSIG Registered Question List (1) Summary: Herb Falk's question on ACSE Association Info. Source: Herb Falk Date Raised: 26 April, 1993 Issue: Copy of message follows: The problem is specifically that the ACSE "Association-information", which is an ASN.1 EXTERNAL, has taken the CHOICE of octet-aligned. The ISO specifications and NIST stable agreements seem to be clear on this matter. We will try to explain them as best we can. A hard copy of the Presentation-Connect PDU follows on a separate page. Note that the item circled and marked "1" is the beginning of the PDV-list. Note "2" is the beginning of the Presentation Data List encoded as Single-ASN1- type. Note "3" is the beginning of the Association-Information encoded as an EXTERNAL. Note "4" is the beginning of the External encoding tagged as octet-aligned. Please reference page 31 of ISO specification ISO-8823 (IS). At the top of the page is found a definition for the PDV-list. Legal presentation data values are a CHOICE of { Single-ASN1-type, octet- aligned, and arbitrary}. This CHOICE is further qualified in section 8.4.2.5, on the following page, to say that the single-ASN1-type shall be used if the PDV-list contains exactly one presentation data value. The ACSE Assocaite-Request PDU shown in the trace has exactly one presentation data value, therefore this encoding rule applies. The PDU conforms to this specification and may be verified in note "2" to be the value 0xA0. Please refer to page 18 of ISO specification 8650 for a description of the AARQ-apdu. Towards the bottom of the page there is a description of "user-information". It states that "user-information" is IMPLICIT "Association-information" OPTIONAL. 3 pages later in the same specification is the definition for "Association-information". It states that an "Association-information" field may only be a SEQUENCE OF EXTERNAL. An EXTERNAL is not defined in the ACSE Protocol specification. It is found in the ASN.1 Protocol Specification ISO 8824. Please refer to ISO specification 8824 (Abstract Syntax Notation One) 42 Document No.ULSIG-96-12/93 Date:May 22, 1994 page 23 for a description of the EXTERNAL. Section 34.7 of 8824 says that: "If the data value is the value of a single ASN.1 data-type, and if the encoding is an integral number of octets, then the sending implementation shall use any of the encoding choices: single-ASN1-type octet-aligned arbitrary" According to ISO 8824 it would be legal to send "Associate- information" as octet-aligned at note "4". However, we believe that there is an implementation agreement on this CHOICE of encoding. If you look at the NIST stable agreements on page 12 in section 10.3 there is an implementors agreement on which choice to use in the EXTERNAL. The second sentence in that paragraph reads as follows: "If a data value to be encapsulated in an EXTERNAL type is an instance of a single ASN.1 type encoded to the basic encoding rules for ASN.1 then the option "single-ASN1-type" shall be chosen as encoding." We believe that this sentence is why the byte in note "4" should be the value 0xA0 instead of 0x81. This seems to be self-explanatory. However, to make sure that we are not taking this sentence out of context or misinterpreting it, we have placed a call to the Upper Layers chairman of NIST and are asking for a clarification. Remember that NIST stable agreements are not binding which means that the Computrol MMS is still within the guidelines for this encoding at the current time. But also be advised that these stable agreements are being moved into the upper layer agreements within the next year. Responses: From Laura Emmons (laurae@ar.telenex.com) May 10: I took a look at Herb Falk's defect report and I don't think there is any problem with any of the standards or our position on the use of the EXTERNAL data type. His description of the encoding of the encoding of his layer 6 header seems to be irrelevant. If the MMS- InitiateRequest is a single ASN.1 element (I haven't seen this protocol, but it seems that it is), then the data value of the instance of the Association-information element should be encoded as a single-ASN1-type. Therefore, in his pdu Note 4 should be an 0xA0. Solution: Status: OIW: EWOS: 43 Document No.ULSIG-96-12/93 Date:May 22, 1994 AOW: 44 Document No.ULSIG-96-12/93 Date:May 22, 1994 (2) Summary: PGI PI issue from Japan Source: Jun Yamaguchi (junichi@vnet.ibm.com) Date Raised: July 22, 1993 Issue: Copy of message follows: I have a question about ISO 8327. I would like you to clarify an interpretation of this standard. Base standard states "PGI units and PI units within the same nesting level shall be ordered in increasing value of their PGI and PI codes." in the clause 8.2.6 of ISO 8327. There are several interpretations for thsi statement: 1. PGI units shall be ordered in increasing value of their PGI codes. PI units in the same PGI unit shall be ordered in increasing value of their PI codes. PI units without PGI code have the same nesting level with PGI units, and this kind of PI units and PGI units shall be ordered in increasing value of their PGI and PI codes. 2. PGI units shall be ordered in increasing value of their PGI codes. PI units in the same PGI unit shall be ordered in increasing value of their PI codes. PI units without PGI code shall be ordered in increasing value of their PI codes. There are no relationship between PGI units and PI units about the order. 3. PGI units shall be ordered in increasing order of their PGI codes. PI units in the same PGI unit shall be ordered in increasing value of their PI codes. PI units without PGI code have no relationship with other units. So, this kind of PI units may be placed in any position. Which interpretation is correct, or all wrong? Responses: From Bob Baker (baker@uxdp5.Tredydev.Unisys.com) July 26: I reviewed Jun Yamaguchi's session question which you forwarded to the OIW members. We had the same question years ago when we were implementing our Session layer, and I talked with Kim Banker at the time. He was very helpful and we finished our implementation based on his suggestions. We believe interpretation #1 is the only correct interpretation of the session specification. This interpretation is consistent with what Kim told us and also with our implementation...Interpretations #2 and #3 45 Document No.ULSIG-96-12/93 Date:May 22, 1994 would permit any of the PI codes which have no PGI code to be present after PGI 193 (User Data) in an SPDU. This is annoying at best, and would probably cause many implementations severe problems. From Andrew Chandler (a.chandler@xopen.co.uk) August 17 My interpretation is as follows (essentially this is interpretation 1 above): PGI units shall be ordered in increasing value of their PGI codes. PI units in the same PGI unit shall be ordered in increasing value of their PI codes. PGI units and PI units at the same level of nesting shall be ordered in icreasing value of their PGI and PI codes. Solution: Interpretation 1 is correct. Status: OIW:Accepted 09/93 EWOS: AOW: 46 Document No.ULSIG-96-12/93 Date:May 22, 1994 (3) Summary: Encoding FTAM single PDV list Source: Kevin Bohan (0004141431@mcimail.com) Date Raised: July 29, 1993 Issue: Copy of message follows: I have a question as to what is meant in section 8.5 of the NIST Stable Agreements. Proginet has an FTAM product that sends back an F-Begin-Group- Response, F-Deselect-Response, F-Close-Response, F-End-Group-Response. This is done using a single PDV list. We have encoded this PDV-List using the single-ASN1-type. The remote site is kicking this out and they claim that this is not valid. Is this Valid? Responses: Solution: Status: OIW: EWOS: AOW: (4) Summary: Ed Kelley question on whether FTAM can directly use P-U-ABORT. Source: Date Raised: Issue: Responses: Solution: Status: OIW: EWOS: AOW: 47 Document No.ULSIG-96-12/93 Date:May 22, 1994 (5) Summary: new MMS issue on CUL for Security Source: MMS SIG Date Raised: 16 September, 1993 Issue: Copy of liason: The MMS SIG is investigating the use of various OSI protocols and features for achieving different security requirements for MMS. With further discussion with the Security SIG, it appears that concepts in GULS are adequate for our needs. In particular, the use of the ACSE Functional Unit for Authentication. As it is likely, that all of the SIGs will need similar requirements for upper layers, we are asking for you to investigate the common needs and, if warrented, develop a version of the Common Upper Layer Requirements that address security. Responses: Solution: Status: OIW: EWOS: AOW: 48 Document No.ULSIG-96-12/93 Date:May 22, 1994 (6) Summary: Gary Williams issue on p-u- abort on bad encoding. Source: Date Raised: 9 September 1993 Issue: The problem is that we believe that there is a possible contradiction between clause 7.9 of Draft Version 12 of pDISP 11188-1, 1993-01-22 (ISP:Common Upper Layer Requirements) which states: "If a received PPDU contains improperly encoded data values(including data values embedded with the user data field of a PPDU) and if an abort is issued, then either an ARU shall beissued." and ISO 8823: 1988, clause's 6.4.4.2 and 6.4.4.3 which state that the only response is a P-P-ABORT. The information that we require is how to start the procedure to address this issue, possibly obtain a contact name, or how to get in touch with he/she in order to resolve the issue. Responses: From Klaus Truoel (truoel@gmd.de) Aug 8, 1993: The current draft of Common Upper Layer Requirements is draft 14, and it will hopefully get the approval as PDISP by the Regional Workshops in Sept and Oct. Of course, after that approval it will not be too late to fix bugs if there are any. The clause which you are questionning is the same also in the latest version. Actually, it is a clause which is in that document (and in the European FTAM ENVs) since many years. It passed several ISO ballots, reviews and discussions with ISO experts. The reason behind that clause, as far as I can remember the history, is the often discussed problem, which OSI layer would be responsible to detect "improperly encoded data values". Is it the presentation layer or can it in many cases only be done by the application ? In the latter case, the application would initiate the Abort and that would result in an ARU. This is what the clause expresses. 49 Document No.ULSIG-96-12/93 Date:May 22, 1994 And, by the way, the clauses in ISO 8823 which you reference, specify "if possible". Sometimes it may not be possible if only the application can detect the bug. As I myself am the editor of the PDISP, you may send all comments or questions to me. In case you are not satisfied with my above explanation and if you want to raise the issue to a broader audience for consideration, I am prepared to take the issue with me to the forthcoming OIW (beginning of Sept.) and to EWOS (Oct.). Solution: Status: OIW: EWOS: AOW: 50 Document No.ULSIG-96-12/93 Date:May 22, 1994 (7) Summary: X/Open ROSE PCI must be in BER. Source: Date Raised: Issue: Responses: Solution: Status: OIW: EWOS: AOW: 51