Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers Output from the September 1993 Open Systems Environment Implementors' Workshop (OIW) Abstract SIG Chair: James Quigley, Hewlett-Packard SIG Editors: Debra Britt, NCTS Laura Emmons, Telenex Part 5 - Upper Layers September 1993 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Upper Layers Special Interest Group (ULSIG) of the Open Systems Environment Implementors' Workshop (OIW). The charter for the OIW is located in the Procedures Manual. The text in this part has been approved by the Plenary of the OIW. This part replaces the previously existing part on the Upper Layers. Annex B is for information purposes only. Annex A forms an integral part of these Implementor Agreements. Future changes and additions to these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as struck. New and replacement text will be shown as shaded. ii Part 5 - Upper Layers September 1993 (Stable) Table of Contents Part 5 - Upper Layers . . . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 2 2.1 Session Layer . . . . . . . . . . . . . . . . . . . 2 2.2 Presentation Layer . . . . . . . . . . . . . . . . . 2 2.3 Application Layer . . . . . . . . . . . . . . . . . 3 2.4 Application Layer - ASE/ACSE . . . . . . . . . . . . 3 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 ISO Defect Solutions . . . . . . . . . . . . . . . . 4 4.2 Session Defect Solutions Correcting CCITT X.215 and X.225 . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Approved Errata . . . . . . . . . . . . . . . . . . 5 5 Association Control Service Element . . . . . . . . . . . 5 5.1 Introduction . . . . . . . . . . . . . . . . . . . . 5 5.2 Services . . . . . . . . . . . . . . . . . . . . . . 5 5.3 Protocol Agreements . . . . . . . . . . . . . . . . 6 5.3.1 Application Context . . . . . . . . . . . . 6 5.3.2 AE Title . . . . . . . . . . . . . . . . . 6 5.3.3 Peer Entity Authentication . . . . . . . . 6 5.4 ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 7 5.5 Connectionless . . . . . . . . . . . . . . . . . . . 7 6 ROSE . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7 RTSE . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 Presentation . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Introduction . . . . . . . . . . . . . . . . . . . . 8 8.2 Service . . . . . . . . . . . . . . . . . . . . . . 9 8.3 Protocol Agreements . . . . . . . . . . . . . . . . 9 8.3.1 Transfer Syntaxes . . . . . . . . . . . . . 9 8.3.2 Presentation Context Identifier . . . . . . 9 8.3.3 Default Context . . . . . . . . . . . . . . 10 8.3.4 P-Selectors . . . . . . . . . . . . . . . . 10 8.3.5 Provider Abort Parameters . . . . . . . . . 11 8.3.6 Provider Aborts and Session Version . . . . 11 8.3.7 CPC-Type . . . . . . . . . . . . . . . . . 12 8.3.8 Presentation-context-definition-result-list 12 iii Part 5 - Upper Layers September 1993 (Stable) 8.3.9 RS-PPDU . . . . . . . . . . . . . . . . . . 12 8.4 Presentation ASN.1 Encoding Rules . . . . . . . . . 13 8.5 Presentation Data Value (PDV) . . . . . . . . . . . 13 8.6 Connection Oriented . . . . . . . . . . . . . . . . 14 8.7 Connectionless . . . . . . . . . . . . . . . . . . . 14 9 Session . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Introduction . . . . . . . . . . . . . . . . . . . . 15 9.2 Services . . . . . . . . . . . . . . . . . . . . . . 15 9.3 Protocol Agreements . . . . . . . . . . . . . . . . 16 9.3.1 Concatenation . . . . . . . . . . . . . . . 16 9.3.2 Segmenting . . . . . . . . . . . . . . . . 16 9.3.3 Reuse of Transport Connection . . . . . . . 16 9.3.4 Use of Transport Expedited Data . . . . . . 16 9.3.5 Use of Session Version Number . . . . . . . 17 9.3.5.1 Selection of session version . . . . . . . 17 9.3.5.2 User data in session version 2 . . . . . . 17 9.3.6 Receipt of Invalid SPDUs . . . . . . . . . 18 9.3.7 Invalid SPM Intersections . . . . . . . . . 18 9.3.8 S-Selectors . . . . . . . . . . . . . . . . 19 9.4 Connectionless . . . . . . . . . . . . . . . . . . . 21 10 UNIVERSAL ASN.1 ENCODING RULES . . . . . . . . . . . . . 21 10.1 TAGS . . . . . . . . . . . . . . . . . . . . . . . . 21 10.2 Definite Length . . . . . . . . . . . . . . . . . . 21 10.3 External . . . . . . . . . . . . . . . . . . . . . . 22 10.4 Integer . . . . . . . . . . . . . . . . . . . . . . 22 10.5 String Types . . . . . . . . . . . . . . . . . . . . 22 10.6 Bit StringExtensibility . . . . . . . . . . . . . . 23 11 Character Sets . . . . . . . . . . . . . . . . . . . . . 23 12 Conformance . . . . . . . . . . . . . . . . . . . . . . . 24 13 Specific ASE Requirements . . . . . . . . . . . . . . . . 24 13.1 FTAM Phase 2 . . . . . . . . . . . . . . . . . . . . 24 13.1.1 ACSE Requirements . . . . . . . . . . . . . 24 13.1.2 Presentation Requirements . . . . . . . . . 25 13.1.3 Session Requirements . . . . . . . . . . . 26 13.1.4 Session Options . . . . . . . . . . . . . . 26 13.1.5 ASN.1 Encoding Requirements . . . . . . . . 27 13.2 MHS . . . . . . . . . . . . . . . . . . . . . . . . 27 13.2.1 Phase 1 (1984 X.400) Session Requirements . 27 13.2.2 Phase 2, Protocol P1 (1988 X.400) . . . . . 28 13.2.2.1 ROSE Requirements . . . . . . . . . . . . . 28 13.2.2.2 RTSE Requirements . . . . . . . . . . . . . 28 13.2.2.3 ACSE Requirements . . . . . . . . . . . . . 29 iv Part 5 - Upper Layers September 1993 (Stable) 13.2.2.4 Presentation Requirements . . . . . . . . . 29 13.2.2.5 Session Requirements . . . . . . . . . . . 29 13.2.3 Phase 2, Protocol P7 (1988 X.400) . . . . . 30 13.2.3.1 ROSE Requirements . . . . . . . . . . . . . 30 13.2.3.2 RTSE Requirements . . . . . . . . . . . . . 30 13.2.3.3 ACSE Requirements . . . . . . . . . . . . . 31 13.2.3.4 Presentation Requirements . . . . . . . . . 31 13.2.3.5 Session Requirements . . . . . . . . . . . 32 13.2.4 Phase 2, Protocol P3 (1988 X.400) . . . . . 32 13.2.4.1 ROSE Requirements . . . . . . . . . . . . . 32 13.2.4.2 RTSE Requirements . . . . . . . . . . . . . 33 13.2.4.3 ACSE Requirements . . . . . . . . . . . . . 33 13.2.4.4 Presentation Requirements . . . . . . . . . 33 13.2.4.5 Session Requirements . . . . . . . . . . . 33 13.3 DS Phase 1 . . . . . . . . . . . . . . . . . . . . . 33 13.3.1 ACSE Requirements . . . . . . . . . . . . . 33 13.3.2 Presentation Requirements . . . . . . . . . 34 13.3.3 Session Requirements . . . . . . . . . . . 34 13.4 Virtual Terminal . . . . . . . . . . . . . . . . . . 34 13.4.1 Phase 1a . . . . . . . . . . . . . . . . . 34 13.4.1.1 ACSE Requirements . . . . . . . . . . . . . 35 13.4.1.2 Presentation Requirements . . . . . . . . . 35 13.4.1.3 Session Requirements . . . . . . . . . . . 35 13.4.2 Phase 1b . . . . . . . . . . . . . . . . . 36 13.4.2.1 ACSE Requirements . . . . . . . . . . . . . 36 13.4.2.2 Presentation Requirements . . . . . . . . . 36 13.4.2.3 Session Requirements . . . . . . . . . . . 36 13.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . 37 13.5.1 ACSE Requirements . . . . . . . . . . . . . 37 13.5.2 Constructed Encodings . . . . . . . . . . . 37 13.5.3 Presentation Requirements . . . . . . . . . 37 13.5.4 Session Requirements . . . . . . . . . . . 38 v Part 5 - Upper Layers September 1993 (Stable) 13.6 Transaction Processing . . . . . . . . . . . . . . . 38 13.7 Network Management . . . . . . . . . . . . . . . . . 38 13.7.1 ROSE Requirements . . . . . . . . . . . . . 38 13.7.2 ACSE Requirements . . . . . . . . . . . . . 39 13.7.3 Presentation Requirements . . . . . . . . . 39 13.7.4 Session Requirements . . . . . . . . . . . 39 Annex A (normative) Object Identifier Register . . . . . . . . . . . . . . . . . 40 A.1 Register Index . . . . . . . . . . . . . . . . . . . 40 A.2 Object Identifier Descriptions . . . . . . . . . . . 40 Annex B (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 42 vi Part 5 - Upper Layers September 1993 (Stable) List of Tables Table 1 - Called and Responding P-Selectors . . . . . . . . . 10 Table 2 - Called and Responding S-Selectors . . . . . . . . . 20 Table 3 - Calling S-Selectors . . . . . . . . . . . . . . . . 20 Table 1 - Session States . . . . . . . . . . . . . . . . . . 42 Table 2 - Incoming Events . . . . . . . . . . . . . . . . . . 43 vii Part 5 - Upper Layers 0 Introduction In this portion of the Implementors' Agreements, the Upper Layers SIG is primarily concerned with providing implementation agreements for ACSE, ROSE, RTSE, and the Presentation and Session layers, so that systems implemented according to these agreements can successfully interoperate. 1 Scope See Working Implementation Agreements Document. The agreements in this part apply to all ASE agreements in this document. A referencing specification may use the requirements in this part in one of the following ways: a) The referencing specification does not duplicate any of the requirements of this part of the document within its own specifications and instead requires an implementation to conform to the requirements of this part. This is the preferred method. b) The referencing specification duplicates all of the requirements of this part of the document as part of its requirements and related conformance statements. Each ASE SIG supplements the common requirements in this part of the document by a statement in the "Specific ASE Requirements" clause of this part which outlines the ASE's specific requirements for the use of the ACSE, presentation and session protocol standards. 2 Normative References 2.1 Session Layer [1] ISO 8326: 1987 (E), Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Service Definition. [2] ISO 8327: 1987 (E), Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Protocol Specification. [3] ISO/IEC JTC1/SC21 N2494, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented 1 Part 5 - Upper Layers September 1993 (Stable) Session Service Definition-AD 2 to ISO 8326 to Incorporate Unlimited User Data. [4] ISO/IEC JTC1/SC21 N2495, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Protocol Specification - AD 2 to ISO 8327 to Incorporate Unlimited User Data. [5] ISO/AD3 8326, Information Processing Systems - Open Systems Interconnection-Session Service Definition: Addendum 3 Covering Connectionless-Mode Session Service. [6] ISO/IS 9548, Information Processing Systems - Open Systems Interconnection-Connectionless Session Protocol to Provide the Connectionless-Mode Session Service. 2.2 Presentation Layer [7] ISO 8822: 1988 (ISO/IEC JTC1/SC21 N2335), Information Processing Systems - Open Systems Interconnection - Connection-Oriented Presentation Service Definition. [8] ISO 8823: 1988 (ISO/IEC JTC1/SC21 N2336), Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Specification. [9] ISO 8824: 1990 (E), Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). [10] ISO 8825: 1990 (E), Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). [11] ISO/DAD1 8822: 1989-02-15(e) (ISO/IEC JTC1/SC21 N 3171), Information Processing Systems - Open Systems Interconnection - Presentation Service Definition: Draft Addendum 1 Covering Connectionless-Mode Presentation Service. [12] ISO/IS 9576: 1989-02-25 5(E) (ISO/IEC JTC1/SC21 N 3172), Information Processing Systems - Open Systems Interconnection - Connectionless Presentation Protocol to Provide the Connectionless-Mode Presentation Service. 2 Part 5 - Upper Layers September 1993 (Stable) 2.3 Application Layer [13] ISO/DP 9545, ISO/TC97/SC21/N1743, July 24, 1987, revised November 1987, Information Processing Systems - Open Systems Interconnection - Application Layer Structure. 2.4 Application Layer - ASE/ACSE [14] ISO 8649: 1987 (E) (ISO/IEC JTC1/SC21 N2326), Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element. [15] ISO 8650: 1987 (E) (ISO/IEC JTC1/SC21 N2327), Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element. [16] ISO 8649/DAD2, Information Processing System - Open Systems Interconnection - ACSE Service Definition: Draft Addendum 2 Covering Connectionless-Mode ACSE Service. [17] ISO 8649/DAD1 (ISO/IEC JTC1/SC21 N3771), Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element - Addendum 1: Peer-EntityAuthentication During Association Establishment [18] ISO 8650/DAD1 (ISO/IEC JTC1/SC21 N3772), Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element - Addendum 1: Peer-Entity Authentication During Association Establishment [19] ISO 8649/Cor.1: 1991 (E) (ISO/IEC JTC1/SC21 N5630), Information Processing Systems - Open Systems Interconnection - Technical Corrigendum 1 to ACSE Service (ISO 8649: 1988) Covering Defects 8649/001, 8649/002 and 8649/003. [20] ISO 8650/Cor.1: 1991 (E) (ISO/IEC JTC1/SC21 N5631), Information Processing Systems - Open Systems Interconnection - Technical Corrigendum 1 to ACSE Protocol (ISO 8650: 1988) Covering Defects 8650/001, 8649/004. [20] ISO IS 10035: 1989-02-25 (ISO/IEC JTC1/SC21 N 3456), Information Processing Systems - Open Systems Interconnection - Connectionless ACSE Protocol to Provide the Connectionless-Mode ACSE Service. 3 Part 5 - Upper Layers September 1993 (Stable) 3 Status This text is stable. NOTE - Changes due to errata are summarized in clause 4 4 Errata 4.1 ISO Defect Solutions This clause lists the defect solutions from ISO which are currently recognized to be valid for the purposes of conformance. ISO 8326 defect solutions: 023, 024 ISO 8327 defect solutions: 037, 038 4.2 Session Defect Solutions Correcting CCITT X.215 and X.225 The following approved defect solutions have been integrated into the current revisions of ISO 8326 and ISO 8327, but are not part of CCITT X.215 and X.225 (1984). The defect solutions must be incorporated into CCITT Session to insure conformance with ISO Session. ISO 8326 defect solutions: 004, 006, 007, 009, 011, 012, 013, 014, 015, 016, 017, 020. ISO 8327 defect solutions: 001, 003, 004, 005, 006, 007, 008, 009, 010, 012, 017, 018, 019, 026, 027, 030, 034, 035. 4 Part 5 - Upper Layers September 1993 (Stable) 4.3 Approved Errata Errata to this part are marked with change bars; deleted text is marked with strikeouts and new text is indicated by shading. 5 Association Control Service Element 5.1 Introduction This clause details the implementation requirements for the Association Control Service Element (ACSE) of the Application layer as defined in ISO 8649 and ISO 8650. 5.2 Services All ACSE services are within the possible scope of a workshop- conformant system. 5.3 Protocol Agreements 5.3.1 Application Context Values for and uses of Application Context names are determined by specific ASEs. Values used by ASE SIGS are listed in the clause entitled "Specific ASE Requirements." 5.3.2 AE Title See Working Implementation Agreements Document. Support of AE-Title-form1, the Name form, or AE-Title-form2, the Object Identifier form for sending, is dependent on the referencing specification. NOTE - AE_Title-form1 is a directory name that has to be allocated by an authorized naming authority. It is part of the responsibilities of the naming authority to determine how this name is built from its two constituents, AP-Title- form1 and AE-Qualifier-form1. NOTE - AE-Title-form2 is an Object Identifier registered by an authorized Registration Authority. It is part of that registration to determine how this Object Identifier is built from its two constituents, AP-Title-form2 and AE- 5 Part 5 - Upper Layers September 1993 (Stable) Qualifier-form2. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 6.1. 5.3.3 Peer Entity Authentication If supported, peer-entity authentication during association establishment shall be implemented as specified in Addendum 1 to ISO 8650 (ISO 8650/DAD1). 5.4 ASN.1 Encoding Rules See Working Implementation Agreements Document. When the Abort APDU is used during the association establishment phase, the Presentation layer negotiation is considered complete. Therefore, a PDV-list presentation-context-identifier has been assigned to the association and it should be used in the indirect-reference component of the Association Information parameter. The direct-reference component shall not be present. NOTE - The presentation context negotiation is completed by the presentation context identifier list of the ARU PPDU. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 6.2. 5.5 Connectionless The connectionless ACSE protocol shall be implemented as specified in ISO IS 10035. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 6 Part 5 - Upper Layers September 1993 (Stable) 6 ROSE ROSE shall be implemented as specified in ISO DIS 9072-1.2 and ISO DIS 9072-2.2. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 7 RTSE RTSE shall be implemented as specified in ISO 9066-1 and ISO 9066-2. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 8 Presentation 8.1 Introduction This clause details the implementation requirements for the Presentation layer as defined in the Presentation Service Definition, ISO 8822, and the Presentation Protocol Definition, ISO 8823. The task of the Presentation layer is to carry out the negotiation of transfer syntaxes and to provide for the transformation to and from transfer syntaxes. The transformation to and from a particular transfer syntax is a local implementation issue and is not discussed within this clause. This clause is concerned with the protocol agreements, and thus is entirely devoted to the issues involved with the negotiation of transfer syntaxes and the responsibilities of the Presentation protocol. NOTE - The complete size of encoding of the CP PPDU, CPA PPDU, and CPR PPDU is derived from the SS user-data size restricted to 10 K such as specified in 9.3.5. This limitation applies also to the ARP and ARU PPDUs. 7 Part 5 - Upper Layers September 1993 (Stable) 8.2 Service (Refer to Working Agreements Document) 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 serviceprimitives are required tobe implemented. 8.3 Protocol Agreements 8.3.1 Transfer Syntaxes The following transfer syntax must be supported for all mandatory abstract syntaxes; the basic encoding rules for ASN.1. This syntax is derived by applying the basic encoding rules for ASN.1 to the abstract syntax (see the Basic Encoding Rules for ASN.1, ISO 8825). The number of transfer syntaxes proposed is dependent upon the recognized transfer syntaxes which are available to support the particular abstract syntaxes used by an Application Entity. See the aligned section in the Working Document. 8.3.2 Presentation Context Identifier A conformant implementation shall not encode Presentation context identifiers inoutside the range of 0 to 32,767. Implementations must be able to handle a minimum of two Presentation contexts per connection. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.1. 8 Part 5 - Upper Layers September 1993 (Stable) 8.3.3 Default Context If the Presentation expedited data service is required, the default context must be explicitly present in the P-CONNECT PPDU at Presentation connect time. See the aligned section in the Working Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.6. 8.3.4 P-Selectors Local P-selectors shall be a maximum of four octets. This applies only to P-selectors in PPDUs whose receipt by a workshop- conformant system normally results in either a P-CONNECT indication or a P-CONNECT confirmation being issued. See the aligned section of the Working Implementation Agreements Document. If the Responding P-Selector of the CPA-PPDU is not present, it is assumed to have a value equivalent to that of the Called P- Selector of the CP-PPDU. Table 1 summarizes the handling of the Responding-presentation selector parameters of the CP-PPDU and CPA-PPDUs. Table 1 - Called and Responding P-Selectors Responding P-Sel of CPA- PPDU Not present Length= Length>0 0 Not Note 1 Note 1 Note 2 Called P-Sel present of CP-PPDU Length=0 Note 1 Note 1 Note 2 Length>0 Note 3 Note 3 Note 2 9 Part 5 - Upper Layers September 1993 (Stable) Note 1 - The resulting value is assumed to be a null value. Note 2 - The resulting value is assumed to be the Responding P-Sel value. Note 3 - The resulting value is assumed to be the Called P-Sel value of the CP-PPDU. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.2. 8.3.5 Provider Abort Parameters (Refer to the Working Agreements Document) 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. See the aligned section in the Working Implementation Agreements Document. 8.3.6 Provider Aborts and Session Version The Presentation Provider Abort PPDU (ARP-PPDU) shall be present regardless of the Session version in effect for a given association. This precludes the use of indefinite length encoding of an ARP-PPDU when Session Version 1 is in effect. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.7. 10 Part 5 - Upper Layers September 1993 (Stable) 8.3.7 CPC-Type Implementations shall not use any CPC-type values in the SS-user data parameter of the S-CONNECT unless more than one transfer syntax is proposed for a single Presentation context of the Presentation data values. Each CPC-type represents a unique transfer syntax, so if more than one transfer syntax is proposed, CPC-type values may appear in that SS-user data parameter. For a Presentation context for which the Basic encoding Rules are a proposed transfer syntax, all PDVs in the user data parameter of the CP PPDU must be encoded first using the Basic Encoding Rules and must be examined by the receiving Presentation protocol machine. Following CPC-type values may be examined or ignored at the receiver's option see ISO 8823, clause 6.2.5.3). See the aligned section in the Working Agreements Document Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.3. 8.3.8 Presentation-context-definition-result-list No semantics are implied by the absence of the optional Presentation-context-definition-result-list component of the CPR- PPDU. This component is required if the Provider-reason is absent in the CPR-PPDU. If the Provider-reason is present, then the Presentation-context-definition-result-list is optional. See the aligned section in the Working Agreements Document Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.5. 8.3.9 RS-PPDU The Presentation-context-identifier-list shall not be present when only the kernel functional unit is in effect. See the aligned section in the Working Agreements Document Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.8. 11 Part 5 - Upper Layers September 1993 (Stable) 8.4 Presentation ASN.1 Encoding Rules If a received PPDU contains any improperly encoded data values (including data values embedded within the User data field of a PPDU) and an abort is issued, then either an ARU or an ARP PPDU shall be issued. See the aligned section in the Working Agreements Document Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.9. 8.5 Presentation Data Value (PDV) A Presentation data value (PDV) is a value of a type in an abstract syntax, e.g. a value of an ASN.1 type. A PDV may contain embedded PDVs in different contexts. A change of context within a PDV is indicated by an EXTERNAL. EXTERNAL implies an embedded PDV. A PDV cannot be split across PDV-lists in fully-encoded user data. Fully-encoded-data that is a series of PDVs in the same Presentation context (e.g., grouped FTAM PDUs) shall be encoded either as a single PDV-list (using the octet-aligned choice) or as a series of PDV-lists, each encoding either a single PDV (using the single-ASN1-type choice) or multiple PDVs (using the octet-aligned choice). Note that receivers must accept any of the above encodings. See the aligned section in the Working Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.10. 12 Part 5 - Upper Layers September 1993 (Stable) 8.6 Connection Oriented The Transfer-syntax-name component of a PDV-list value shall be present in a CP PPDU if and only if more than one transfer syntax name was proposed for the Presentation context of the Presentation data values. The Transfer-syntax-name component of a PDV-list value shall always be present in a CPC-type. If only the Kernel functional unit is negotiated, then the Transfer-syntax- name component of a PDV-list value shall only appear in the CP PPDU and CPC-type. See the aligned section in the Working Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 7.3. 8.7 Connectionless The connectionless Presentation protocol shall be implemented as specified in ISO 9576. The Transfer-syntax-name component of a PDV-list value shall be present in a UD PPDU if and only if more than one transfer syntax name was proposed for the Presentation context of the Presentation data values. The Transfer-syntax-name component of a PDV-list value shall always be present in a UDC-type. The Transfer-syntax-name component of a PDV-list value shall only appear in the UD PPDU and UDC-type. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 9 Session 9.1 Introduction This clause details the implementation requirements for the Session layer as defined in the Session Service Definition, ISO 8326 and the Session Protocol Definition, ISO 8327. 13 Part 5 - Upper Layers September 1993 (Stable) 9.2 Services The following functional units are within the scope of a workshop-conformant system: a) Kernel; b) Duplex; c) Expedited Data; d) Resynchronize; e) Exceptions; f) Activity Management; g) Half-duplex; h) Minor Synchronize; i) Major Synchronize; j) Typed Data; k) Data Separation. 9.3 Protocol Agreements 9.3.1 Concatenation (Refer to Working Agreements Document) 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. 9.3.2 Segmenting (Refer to Working Agreements Document) 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. 14 Part 5 - Upper Layers September 1993 (Stable) 9.3.3 Reuse of Transport Connection (Refer to Working Agreements Document) Reuse of a Transport connection is not required and can be refused. 9.3.4 Use of Transport Expedited Data (Refer to the Working Agreements Document) The Session use of Transport expedited service is optional. NOTE - A referencing ASE may require that this feature shall be offered by an initiating implementation if it is available, and that it shall be accepted by a responding implementation if it is available and was offered. 9.3.5 Use of Session Version Number See Working Implementation Agreements Document. 9.3.5.1 Selection of session version Session versions 1 and 2 are recognized. The referencing specification shall specify in its specific upper layer requirements section which version of session is required. NOTE - Session version 2 specifies the use of unlimited user data as dictated by Addendum 2 to ISO 8327. All session version 1 implementations must be able to negotiate version 1 operation when responding to a CN SPDU proposing both version 1 and version 2. At least session version 2 shall be proposed with ACSE normal mode. With ACSE normal mode, a receiver shall support session version 2, but may reject a proposal requesting only session version 1. NOTE - Between two conformant implementations supporting ACSE normal mode, session version 2 will be used. All session version 1 implementations, upon receipt of a CN SPDU proposing only version 2, should respond with an RF SPDU containing a reason code indicating that the proposed version is not supported. 15 Part 5 - Upper Layers September 1993 (Stable) If session version 1 and 2 are both proposed in the CN SPDU, then the maximum length if the user data parameter in the CN SPDU shall be 512 octets. NOTE - In that case a PGI field of 193 will be associated with this parameter. This implies that an implementation supporting both session version 1 and 2 can establish a connection with an implementation supporting only version 1. 9.3.5.2 User data in session version 2 If only session version 2 is proposed in the CN SPDU, then a size larger than 10,240 octets of the session user data parameter value of the S-CONNECT request primitive is out of scope. This implies that sending the OA and CDO SPDUs is out of scope. Receiving the OA and CDO SPDUs is mandatory but storing and using them is out of scope. If a CDO SPDU is received but not stored or used, an RF SPDU should be issued by the responder. If an OA SPDU is received but not stored or used, a P-Abort SPDU should be issued by the initiator. NOTE - If the length of the user data parameter value is not greater than 512 octets, then an associated PGI field of 193 is used. Otherwise, a PGI field of 194 is used. When session version 2 is negotiated, then in all subsequent SPDUs a data length exceeding 10,240 octets of the user data parameter value with an associated PGI field of 193, reason code parameter value (PI = 50) for RF SPDU and user data parameter value (PI = 46) for MIA SPDU is out of scope. Session version 2 implementations need only support the maximum data lengths specified in the specific upper layer requirements section of the referencing specification, which may be less than 10,240 octets. NOTE - For session expedited data the limit for user data is 14 octets. NOTE - These agreements impose no limitation on the size of the user information parameter of DT, TD, and CD SPDUs. Therefore, the user data of P-DATA, P-TYPED-DATA, and P- CAPABILITY-DATA is unconstrained. 16 Part 5 - Upper Layers September 1993 (Stable) 9.3.6 Receipt of Invalid SPDUs Upon receipt of an invalid SPDU, the SPM shall take any action in A.4.3 of the Session Protocol Definition ISO/IS 8327 except Action d. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 9.1. 9.3.7 Invalid SPM Intersections If the conditions described in A.4.1.2 of the Session Protocol Definition ISO/IS 8327 are satisfied, the SPM shall always take the actions described by A.4.1.2 a. This implies that no S-P-EXCEPTION-REPORT indications will be generated nor EXCEPTION REPORT SPDUs sent due to invalid intersections of the Session state table resulting from received SPDUs. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 9.4. 9.3.8 S-Selectors S-selectors shall be a maximum of 16 octets. See the aligned section in the Working Implementation Agreements Document. The absence of the Called or Calling S-Sel parameter of the CN SPDU shall be treated equivalent to a zero length Called or Calling S-Sel parameter value. The absence of the Responding S-Sel parameter of the AC SPDU shall be treated as though its value were equivalent to that of the Called S-Sel parameter of the CN SPDU, i.e. the Responding S- Sel is zero length if the Called S-Sel is either absent or zero length. The Responding S-Sel parameter's value is equal to that 17 Part 5 - Upper Layers September 1993 (Stable) of the Called S-Sel parameter's value if it is absent and the Called S-Sel parameter's value is greater than zero. The Responder may change the value of the Called S-Sel parameter value of the CN SPDU by responding with the Responding S-Sel value of the AC SPDU. The absence of the Calling S-Sel parameter of the AC SPDU indicates that its value is assumed to be equivalent to the value of the Calling S-Sel parameter of the CN SPDU. Tables 2 and 3 summarize the handling of the Session Selector parameters of the CN and AC SPDUs (see also ISO 8327 8.3.1.12, 8.3.1.14, 8.3.2.14, 8.3.2.15). 18 Part 5 - Upper Layers September 1993 (Stable) Table 2 - Called and Responding S-Selectors Responding S-Sel of AC SPDU Not present Length= Length>0 0 Not Note 1 Note 1 Note 2 Called S-Sel present of CN SPDU Length=0 Note 1 Note 1 Note 2 Length>0 Note 3 Note 3 Note 2 Note 1 - The resulting value is assumed to be a null value. Note 2 - The resulting value is assumed to be the Responding S-Sel value. Note 3 - The resulting value is assumed to be the Called S-Sel value of the CN SPDU. Table 3 - Calling S-Selectors Calling S-Sel of AC SPDU Not present Length= Length>0 0 Not Note 4 Note 4 Invalid Calling S-Sel present of CN SPDU Length=0 Note 4 Note 4 Invalid Length>0 Note 5 Note 6 Invalid 19 Part 5 - Upper Layers September 1993 (Stable) Note 4 - The calling S-Sel has a null value. Note 5 - The calling S-Sel has the value as indicated in the CN SPDU. Note 6 - Valid if and only if both values are identical. 9.4 Connectionless The connectionless Session protocol shall be implemented as specified in ISO 9548. No further agreements beyond those specified elsewhere in this part have been made regarding this standard. 10 UNIVERSAL ASN.1 ENCODING RULES 10.1 TAGS The maximum value of an ASN.1 basic encoding tag that need be handled by a workshop-conformant implementation shall be 16,383. This is the maximum unsigned number that can be represented in 14 bits, therefore, the maximum encoding of a tag occupies 3 octets. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.1. 10.2 Definite Length See Working Implementation Agreements document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.2. 20 Part 5 - Upper Layers September 1993 (Stable) 10.3 External It is assumed that "Presentation layer negotiation of encoding rules" is always in effect, and therefore clause 32.5 of the Specification of ASN.1, ISO 8824 never applies. If a data value to be encapsulated in an EXTERNAL type is an instance of a single ASN.1 type encoded according to the Basic Encoding Rules for ASN.1, then the option "single-ASN.1-type" shall be chosen as its encoding. If a data value to be encapsulated in an EXTERNAL type is encoded as an integral number of octets, and the above does not apply, then the option "octet-aligned" shall be chosen as its encoding. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.5. 10.4 Integer Any incidence of an ASN.1 INTEGER type defined in an abstract syntax describing protocol control information must be encoded so that the length of its contents octets is no more than four octets, unless an explicit Workshop agreement to the contrary is made for a specific INTEGER type. See the aligned section in the Working Implementation Agreements Document. Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.3. 10.5 String Types The contents octets for a constructed encoding of a BIT STRING, OCTET STRING, or character string value consists of the complete encoding of zero, one, or more data values, and the encoding of these data values must be primitive. See the aligned section in the Working Implementation Agreements Document. 21 Part 5 - Upper Layers September 1993 (Stable) Editor's Note - This clause is technically equivalent to the Common Upper Layers Requirements Profile (ISO DISP 11188-1) and will be replaced by a reference to ISO DISP 11188-1 8.1.6. 10.6 Bit StringExtensibility Unless otherwise specified in the abstract syntax definition, each bit named in a BIT STRING type used in that abstract syntax definition shall be explicitly encoded in the associated BIT STRING value, even if it is part of a string of trailing zero bits. Extra trailing bits beyond the exact number of bits which correspond to the complete list of the named bits specified shall never be encoded. This rule applies to all BIT STRING types unless stated otherwise in the standards. See the aligned section in the Working Implemetation Agreements Document. For data values that are ultimately carried on the user data of the CONNECT SPDU (i.e., Presentation CP, ACSE AARQ and any APDU in the user information field of AARQ) a receiver shall a) ignore any undefined element, b) ignore all unknown bit name assignments within a bit string. NOTE - Referencing specifications may apply similar requirements to other protocol elements. 11 Character Sets See Part 21 of Working Implementation Agreements. 22 Part 5 - Upper Layers September 1993 (Stable) 12 Conformance In order for an implementation to be in conformance with the Implementors' agreements, the rules below shall be followed: a) A conformant implementation must meet all of the requirements of this specification. All documents referenced in the Upper Layers part shall be used as the supporting documents for all implementations of ACSE, ROSE, RTSE, Presentation, or Session. The full references for these documents are in clause 2. b) Workshop-conformant implementations shall be ISO conformant. PICS may contain limitations on length or value aspects of a protocol. PICS of workshop-conformant systems shall not contain restrictions more severe than those in these implementation agreements. NOTE - An implementation may abort a connection if the constraints specified in these agreements are violated. 13 Specific ASE Requirements The following list for each ASE the corresponding SIG's requirements of and restrictions on ACSE, ROSE, RTSE, Presentation, and Session. All listed requirements and restrictions shall be included in an NIST-conformant system and shall be implemented in accordance with these Implementor's agreements. 13.1 FTAM Phase 2 13.1.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: "ISO FTAM" { iso(1) standard(0) 8571 application-context iso-ftam(1) } - implies the use of the ACSE and the FTAM ASE. A value is defined for the AE Title only to satisfy the FTAM requirement for exchanging fields of this type. This value does not identify an Application Entity and carries no semantics. If the AE title is used, AE-title-form2 shall be supported. Support of AE-title-form2 includes support of AP-title-form2 and 23 Part 5 - Upper Layers September 1993 (Stable) AE-qualifier-form2. The value for the AP title is { 1 3 9999 1 ftam-nil-ap-title (7) } at this time. Values for the AE qualifier are outside the scope of these agreements. The use of AP invocation identifiers and AE invocation identifiers by FTAM is outside the scope of these agreements. 13.1.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: At least 3 Presentation Contexts must be supported. Abstract Syntaxes: a) Abstract Syntaxes for conformant Implementations 1) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } 2) "FTAM-PCI" { iso(1) standard(0) 8571 abstract-syntax(2) ftam-pci(1) } 3) "FTAM unstructured binary abstract syntax" { iso(1) standard(0) 8571 abstract-syntax(2) unstructured-binary(4) } Editor's Note - In Definitions below, "NBS" designation will be preserved. b) Abstract Syntaxes Depending on Implementation Profile 1) "FTAM-FADU" { iso(1) standard(0) abstract-syntax(2) ftam-fadu(2) } 2) "FTAM unstructured text abstract syntax" { iso(1) standard(0) 8571 abstract-syntax(2) unstructured-text(3) } 3) "NBS abstract syntax AS1" { iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-as1(1) } 4) "NBS file directory entry abstract syntax" { iso identified-organization oiw(14) ftamsig(5) 24 Part 5 - Upper Layers September 1993 (Stable) abstract-syntax(2) nbs-as2(2) } c) Associated Transfer Syntax: 1) "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1)} Editor's Note - The changes above involving "OIW(14)" were not explicitly mentioned at the March 1990 Plenary, but were implied from a correspondingly approved FTAM motion. 13.1.3 Session Requirements Session Functional Units: a) kernel b) duplex Version Number: 2 Maximum size of User Data parameter field: 10,240 13.1.4 Session Options Session Functional Units: a) resynchronize - only a Resynchronize Type value of "abandon" b) minor synchronize NOTES 1 The minor synchronize functional unit is required whenever the resynchronize functional unit is available. 2 The default value for Minor Sync Point Sync type item PV- field shall be absent if explicit confirmation is required (per ISO 8327, 8.3.20.3) (SIA->value of $). 25 Part 5 - Upper Layers September 1993 (Stable) 13.1.5 ASN.1 Encoding Requirements Some INTEGER types of the FTAM PCI may exceed the maximum size specified in the UNIVERSAL ASN.1 ENCODING Rules. See the Range of values for INTEGER type Parameters of the FTAM part. 13.2 MHS 13.2.1 Phase 1 (1984 X.400) Session Requirements Session Functional Units: a) kernel b) half-duplex c) exceptions d) activity management e) minor synchronize Version Number: 1 Maximum size of User Data parameter field: 512 NOTES 1 Restricted use is made by the RTS of the Session services implied by the functional units selected. Specifically, 1) No use is made of S-TOKEN-GIVE, and 2) S-PLEASE-TOKENS only asks for the data token. 2 In the S-CONNECT SPDU, the Initial Serial Number should not be present. 3 The format of the Connection Identifier in the S-CONNECT SPDU is described in Version 5 of the X.400-Series Implementors' Guide. 13.2.2 Phase 2, Protocol P1 (1988 X.400) 13.2.2.1 ROSE Requirements ROSE is not used. 26 Part 5 - Upper Layers September 1993 (Stable) 13.2.2.2 RTSE Requirements The RTSE requirements are: a) Monologue b) TWA - optional c) checkpointing: 1) minimum checkpointsize = 1 2) minimum windowsize = 1 d) no checkpointing For the Monologue Association: a) initiator keeps initial turn b) APDUs are transferred from initiator to responder only c) no turn passing d) only the initiator effects the orderly release of an association For the two way alternate Association a) the initiator may keep or pass the initial turn, at binding b) APDUs are transferred by the holder of the turn c) only the initiator effects the orderly release of an association, when it possesses the turn 13.2.2.3 ACSE Requirements As per Phase 2, Protocol P7. Application Contexts: a) "MTS-transfer-protocol-1984" - mandatory b) "MTS-transfer-protocol" - mandatory c) "MTS-transfer" - mandatory 27 Part 5 - Upper Layers September 1993 (Stable) 13.2.2.4 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 3 must be supported Abstract Syntaxes: a) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "MTS-RTSE" c) "MTSE" d) Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 13.2.2.5 Session Requirements As per Phase 2, Protocol P7. 13.2.3 Phase 2, Protocol P7 (1988 X.400) 13.2.3.1 ROSE Requirements Operation and association classes are used as per the standard. 13.2.3.2 RTSE Requirements The RTSE requirements are: a) TWA b) normal-mode c) checkpointing d) minimum checkpointsize = 1 e) minimum windowsize = 1 f) no checkpointing For the Monologue Association: 28 Part 5 - Upper Layers September 1993 (Stable) a) initiator keeps initial turn b) APDUs are transferred from initiator to responder only c) no turn passing d) only the initiator effects the orderly release of an association For two way alternate Association: a) the initiator may keep or pass the initial turn, at binding b) APDUs are transferred by the holder of the turn c) only the initiator effects the orderly release of an association, when it possesses the turn 13.2.3.3 ACSE Requirements ACSE Functional Requirements: Kernel The use of AP-TITLE, AE-QUALIFIER, AP-INVOCATION-ID, and AE- INVOCATION-ID is not recommended; however, a receiving entity must be capable of ignoring them (if present) without refusing the connection. Application Contexts: a) "MS-access" - mandatory; normal mode b) "MS-reliable-access" - optional; normal mode 13.2.3.4 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 5 Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) MSBind/MSUnbind (with or without RTSE) 29 Part 5 - Upper Layers September 1993 (Stable) c) MSSE (Message Submission) d) MASE (Message Administration) e) MRSE (Message Retrieval) Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 13.2.3.5 Session Requirements Session Functional Units: a) kernel b) half-duplex (if RTSE is supported) c) full-duplex (if RTSE is not supported) d) exceptions e) activity management f) minor synchronize Version Number: 2 Maximum size of User Data parameter field: 10,240 NOTES 1 MHS proposes both versions 1 and 2 for pass through mode (X.410 mode), but only version 2 for normal mode. 2 Restricted use is made by the RTS of the Session services implied by the functional units selected. Specifically, no use is made of S-TOKEN-GIVE, and S-PLEASE-TOKENS only asks for the data token. 3 In the S-CONNECT SPDU, the Initial Serial Number should not be present. 4 The format of the Connection Identifier in the S-CONNECT SPDU is described in Version 5 of the X.400-Series Implementors' Guide. 30 Part 5 - Upper Layers September 1993 (Stable) 13.2.4 Phase 2, Protocol P3 (1988 X.400) 13.2.4.1 ROSE Requirements As per Phase 2, P7. 13.2.4.2 RTSE Requirements As per Phase 2, P7. 13.2.4.3 ACSE Requirements As per Phase 2, P7. Application Contexts: a) "MTS-access" - mandatory b) "MTS-reliable-access" - optional c) "MTS-forced-access" - mandatory d) "MTS-forced-reliable-access" - optional 13.2.4.4 Presentation Requirements As per Phase 2, P7. 13.2.4.5 Session Requirements As per Phase 2, P7. 13.3 DS Phase 1 13.3.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: a) "id-ac-directoryAccessAC" { joint-iso-ccitt(2) ds(5) 3 1 } 31 Part 5 - Upper Layers September 1993 (Stable) b) "id-ac-directorySystemAC" { joint-iso-ccitt(2) ds(5) 3 2 } 13.3.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: At least 2 Presentation Contexts must be supported. Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "id-as-directoryAccessAS" joint-iso-ccitt(2) ds(5) 9 1 } c) "id-as-directorySystemAS" { joint-iso-ccitt(2) ds(5) 9 2 } Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 13.3.3 Session Requirements Session Functional Units: a) kernel b) duplex Version Number: 2 Maximum size of User Data parameter field: 10,240 13.4 Virtual Terminal 13.4.1 Phase 1a 13.4.1.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: "ISO VT" { iso(1) standard(0) 9041 32 Part 5 - Upper Layers September 1993 (Stable) application-context(1) }- implies the use of the ACSE and the VT ASE 13.4.1.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 2 must be supported Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "VT Basic" { iso(1) standard(0) 9041 abstract-syntax(2) } Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 13.4.1.3 Session Requirements Session Functional Units: a) kernel b) duplex c) expedited data d) major synchronize e) resynchronize - only a Resynchronize Type value of "restart" f) typed data Version Number: 2 Maximum size of User Data parameter field: 10,240 Session Options: expedited data 33 Part 5 - Upper Layers September 1993 (Stable) 13.4.2 Phase 1b 13.4.2.1 ACSE Requirements ACSE Functional Requirements: Kernel Application Contexts: "ISO VT" { iso(1) standard(0) 9041 application-context(1) } - implies the use of the ACSE and the VT ASE 13.4.2.2 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: at least 2 must be supported Abstract Syntaxes: a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "VT Basic" { iso(1) standard(0) 9041 abstract-syntax(2) } Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 13.4.2.3 Session Requirements Session Functional Units: a) kernel b) duplex c) half-duplex d) expedited data e) major synchronize f) resynchronize - only a Resynchronize Type value of "restart" g) typed data 34 Part 5 - Upper Layers September 1993 (Stable) Version Number: 2 Maximum size of User Data parameter field: 10,240 Session Options: expedited data 13.5 MMS 13.5.1 ACSE Requirements ACSE Functional Units: Kernel Application Context: "ISO MMS" { iso(1) standard(0) 9506 part(2) mms-application-context-version1(3)} - implies use of ACSE and MMS ASE 13.5.2 Constructed Encodings Constructed encodings shall not be used for bit strings shorter than 256 bits, nor for octet strings (or types derived from octet strings by tagging) shorter than 1024 octets. For such strings, only primitive encodings shall be used. Upon receipt of a constructed bit string or octet string that violates this restriction, the receiving implementation may reject the corresponding PDU, but shall not send a P-P-Abort. 13.5.3 Presentation Requirements Presentation Functional Units: Kernel At least 2 Presentation Contexts must be supported. Abstract Syntaxes: a) "mms-abstract-syntax-major-version1" { iso(1) standard(0) 9506 part(2) mms-abstract-syntax-major-version1 (1)} b) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association- control(2) abstract-syntax(1) apdus(0) version1(1)} Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" {joint-iso-ccitt(2) asn1(1) basic-encoding(1)} 35 Part 5 - Upper Layers September 1993 (Stable) 13.5.4 Session Requirements Session Functional Units: a) Kernel b) Duplex Version Number: 2 Maximum size of User Data parameter field: 10,240 13.6 Transaction Processing See Working Implementation Agreements Document. 13.7 Network Management 13.7.1 ROSE Requirements The Rose requirements are as specified in ISO 9596 section 5.2: Underlying Services, and section 6.2 Remote Operations. Operations Classes: 1, 2, and 5 Association Classes: 3 13.7.2 ACSE Requirements ACSE Functional Units: kernel Application Contexts: as defined by [SMO] AE-Title: The association responder shall support both forms of the AE-Title. The association requestor may use either form of the AE-Title. 13.7.3 Presentation Requirements Presentation Functional Units: kernel Presentation Contexts: At least 2 must be supported. Abstract Syntaxes: 36 Part 5 - Upper Layers September 1993 (Stable) a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1) } b) "CMIP-PCI" {joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1) abstractSyntax(4)} Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) } 13.7.4 Session Requirements Session Functional Units: a) kernel b) duplex Version Number: 2 Maximum size of User Data parameter field: 10,240. 37 Part 5 - Upper Layers September 1993 (Stable) Annex A (normative) Object Identifier Register Editor's Note - Annexes A and B have been switched to place the informative annex after the normative annex. A.1 Register Index Each entry in the index contains an object identifier value and a reference to the clause describing the object identifier's use: a) { iso(1) identified-organization(3) oiw(14) ulsig(8) application-context(1) nil(1) } is defined in 14.2; b) { iso(1) identified-organization(3) oiw(14) ulsig(8) abstract-syntax(2) octet-string(1) } is defined in 14.2. A.2 Object Identifier Descriptions { iso(1) identified-organization(3) oiw(14) ulsig(8) application-context(1) nil(1) } This application context may be used by applications having a prior agreement regarding the application context. NOTE - This value is intended to be used by private applications that have an a priori agreement concerning the set of ASEs, related options, and any other information necessary for the interworking of AEs on an application association. This value does not identify any specific application context and cannot be used to identify the intended communications environment for the application association. Therefore, it is strongly recommended that private applications define and register an object identifier for their application context. { iso(1) identified-organization(3) oiw(14) ulsig(8) abstract-syntax(2) octet-string(1) } 38 Part 5 - Upper Layers September 1993 (Stable) +---------------------------------------------------------+ | NIST-OIW-ULSIG-AS-octet-string | | DEFINITIONS ::= BEGIN | | | | Single-octet-string ::= OCTET STRING | | END | +---------------------------------------------------------+ This abstract syntax may be used by applications having a prior agreement regarding the content of the octet string. 39 Part 5 - Upper Layers September 1993 (Stable) Annex B (informative) Recommended Practices Editor's Note - Annexes A and B have been switched to place the informative annex after the normative annex. The optional "Reflect Parameter Values" parameter in the Provider ABORT SPDU shall be encoded so as to represent the Session connection state, the incoming event and the first invalid SPDU field exactly at the moment a protocol error was detected. The first octet encodes the Session state as a number relative to 0 as detailed in table 1. The second octet encodes the incoming event as a number relative to 0 as detailed in table 2. The third octet contains the SI, PGI, or PI Code of any SI field, PGI unit or PI unit in error. NOTE - The remaining 6 octets are undefined herein. 40 Part 5 - Upper Layers September 1993 (Stable) Table 1 - Session States +-------+-----+--------------------------------------------------------------+ | State | Rel | Description | +-------+-----+--------------------------------------------------------------+ | 1 | 0 | Idle, no transport connection | | 1B | 1 | Wait for T-connect confirm | | 1C | 2 | Idle, transport connected | | 2A | 3 | Wait for the ACCEPT SPDU | | 3 | 4 | Wait for the DISCONNECT SPDU | | 8 | 5 | Wait for the S-CONNECT response | | 9 | 6 | Wait for the S-RELEASE response | | 16 | 7 | Wait for the T-DISCONNECT indication | | 713 | 8 | Data Transfer state | | 1A | 9 | Wait for the ABORT ACCEPT SPDU | | 4A | 10 | Wait for the MAJOR SYNC ACK SPDU or PREPARE SPDU | | 4B | 11 | Wait for the ACTIVITY END ACK SPDU or PREPARE SPDU | | 5A | 12 | Wait for the RESYNCHRONIZE ACK SPDU or PREPARE SPDU | | 5B | 13 | Wait for the ACTIVITY INTERRUPT SPDU or PREPARE SPDU | | 5C | 14 | Wait for the ACTIVITY DISCARD ACK SPDU or PREPARE SPDU | | 6 | 15 | Wait for the RESYNCHRONIZE SPDU or PREPARE SPDU | | 10A | 16 | Wait for the S-SYNC-MAJOR response | | 10B | 17 | Wait for the S-ACTIVITY-END response | | 11A | 18 | Wait for the S-RESYNCHRONIZE response | | 11B | 19 | Wait for the S-ACTIVITY-INTERRUPT response | | 11C | 20 | Wait for the S-ACTIVITY-DISCARD response | | 15A | 21 | After PREPARE, wait for the MAJOR SYNC ACK SPDU | | | | or the ACTIVITY END ACK | | 15B | 22 | After PREPARE, wait for the RESYNCHRONIZE SPDU | | | | or the ACTIVITY DISCARD SPDU | | 15C | 23 | After PREPARE, wait for the RESYNCHRONIZE ACK SPDU, | | | | or the ACTIVITY INTERRUPT ACK SPDU | | | | or the ACTIVITY DISCARD ACK SPDU | | 18 | 24 | Wait for GIVE TOKENS ACK SPDU | | 19 | 25 | Wait for a recovery request or SPDU | | 20 | 26 | Wait for a recovery SPDU or request | | 21 | 27 | Wait for the CAPABILITY DATA ACK SPDU | | 22 | 28 | Wait for the S-CAPABILITY-DATA response | | 1D | 29 | Wait for the CONNECT DATA OVERFLOW SPDU | | 2B | 30 | Wait for the OVERFLOW ACCEPT SPDU | | 15D | 31 | After PREPARE, wait for the ABORT SPDU | +-------+-----+--------------------------------------------------------------+ 41 Part 5 - Upper Layers September 1993 (Stable) Table 2 - Incoming Events +-------------+-----+----------------------------------------------+ | Event | Rel | Description | +-------------+-----+----------------------------------------------+ | SCONreq | 0 | S-CONNECT request | | SCONrsp | 1 | S-CONNECT accept response | | SCONrsp | 2 | S-CONNECT reject response | | SDTreq | 3 | S-DATA request | | SRELreq | 4 | S-RELEASE request | | SRELrsp | 5 | S-RELEASE accept response | | SUABreq | 6 | S-U-ABORT request | | TCONcnf | 7 | T-CONNECT confirmation | | TCONind | 8 | T-CONNECT indication | | TDISind | 9 | T-DISCONNECT indication | | TIM | 10 | Time out | | AA | 11 | ABORT ACCEPT | | AB-nr | 12 | ABORT - no reuse | | AC | 13 | ACCEPT | | CN | 14 | CONNECT | | DN | 15 | DISCONNECT | | DT | 16 | DATA TRANSFER | | FN-nr | 17 | FINISH - no reuse | | RF-nr | 18 | REFUSE - no reuse | | SACTDreq | 19 | S-ACTIVITY-DISCARD request | | SACTDrsp | 20 | S-ACTIVITY-DISCARD response | | SACTEreq | 21 | S-ACTIVITY-END request | | SACTErsp | 22 | S-ACTIVITY-END response | | SACTIreq | 23 | S-ACTIVITY-INTERRUPT request | | SACTIrsp | 24 | S-ACTIVITY-INTERRUPT response | | SACTRreq | 25 | S-ACTIVITY-RESUME request | | SACTSreq | 26 | S-ACTIVITY-START request | | SCDreq | 27 | S-CAPABILITY-DATA request | | SCDrsp | 28 | S-CAPABILITY-DATA response | | SCGreq | 29 | S-CONTROL-GIVE request | | SEXreq | 30 | S-EXPEDITED-DATA request | | SGTreq | 31 | S-TOKEN-GIVE request | | SPTreq | 32 | S-TOKEN-PLEASE request | | SRELrsp | 33 | S-RELEASE response reject | | SRSYNreq(a) | 34 | S-RESYNCHRONIZE request abandon | | SRSYNreq(r) | 35 | S-RESYNCHRONIZE request restart | | SRSYNreq(s) | 36 | S-RESYNCHRONIZE request set | | SRSYNrsp | 37 | S-RESYNCHRONIZE response | | SSYNMreq | 38 | S-SYNC-MAJOR request | | SSYNMrsp | 39 | S-SYNC-MAJOR response | | SSYNmreq | 40 | S-SYNC-MINOR request | | SSYNmrsp | 41 | S-SYNC-MINOR response | | STDreq | 42 | S-TYPED-DATA request | | SUERreq | 43 | S-U-EXCEPTION-REPORT request | +-------------+-----+----------------------------------------------+ 42 Part 5 - Upper Layers September 1993 (Stable) Table 2 - Incoming Events (continued) +-------------+-----+----------------------------------------------+ | Event | Rel | Description | +-------------+-----+----------------------------------------------+ | AB-r | 44 | ABORT - reuse SPDU | | AD | 45 | ACTIVITY DISCARD SPDU | | ADA | 46 | ACTIVITY DISCARD ACK SPDU | | AE | 47 | ACTIVITY END SPDU | | AEA | 48 | ACTIVITY END ACK SPDU | | AI | 49 | ACTIVITY INTERRUPT SPDU | | AIA | 50 | ACTIVITY INTERRUPT ACK SPDU | | AR | 51 | ACTIVITY RESUME SPDU | | AS | 52 | ACTIVITY START SPDU | | CD | 53 | CAPABILITY DATA SPDU | | CDA | 54 | CAPABILITY DATA ACK SPDU | | ED | 55 | EXCEPTION DATA SPDU | | ER | 56 | EXCEPTION REPORT SPDU | | EX | 57 | EXPEDITED DATA SPDU | | FN-r | 58 | FINISH - reuse SPDU | | GT | 59 | GIVE TOKENS SPDU | | GTA | 60 | GIVE TOKENS ACK SPDU | | GTC | 61 | GIVE TOKENS CONFIRM SPDU | | MAA | 62 | MAJOR SYNC ACK SPDU | | MAP | 63 | MAJOR SYNC POINT SPDU | | MIA | 64 | MAJOR SYNC ACK SPDU | | MIP | 65 | MINOR SYNC POINT SPDU | | NF | 66 | NOT FINISHED SPDU | | PR-MAA | 67 | PREPARE (MAJOR SYNC ACK) SPDU | | PR-RA | 68 | PREPARE (RESYNCHRONIZE ACK) SPDU | | PR-RS | 69 | PREPARE (RESYNCHRONIZE) SPDU | | PT | 70 | PLEASE TOKENS SPDU with Token Item Paramet r | | RA | 71 | RESYNCHRONIZE ACK SPDU | | RF-r | 72 | REFUSE - reuse SPDU | | RS-a | 73 | RESYNCHRONIZE - abandon SPDU | | RS-r | 74 | RESYNCHRONIZE - restart SPDU | | RS-s | 75 | RESYNCHRONIZE - set SPDU | | TD | 76 | TYPED DATA SPDU | | CDO | 77 | CONNECT DATA OVERFLOW SPDU | | OA7 | 8O | VERFLOW ACCEPT SPDU | | PR-AB | 79 | PREPARE (ABORT) SPDU | +-------------+-----+----------------------------------------------+ 43