Working Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers Output from the June 1994 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: James Quigley, Hewlett Packard SIG Editors: Debbie Britt, NCTS Laura Emmons, Telenex Part 5 - Upper Layers June 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 June 1994 are being printed. Please refer to the March 1994 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 June 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 June 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 June 1994 (Working) Object Identifier Register . . . . . . . . . . . . . . . . . 15 A.1 Register Index . . . . . . . . . . . . . . . . . . . 15 A.2 Object Identifier Descriptions . . . . . . . . . . . 15 Annex B (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 16 Annex C (informative) Backward Compatibility . . . . . . . . . . . . . . . . . . . 17 Annex D (normative) Working Draft of new ISP on CL-CULR Specification . . . . . . 28 Annex E (informative) Upper Layer SIG Registered Questions List . . . . . . . . . . 29 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 June 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 June 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 June 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 June 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 June 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 June 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 June 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 June 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 June 1994 (Working) 14.8 Remote Database Access (Refer to Stable Agreements Document) Table Profile requirements list proforma Item / Complian Specification's Constraint / variable t choice value choice Client Server 1 Establis m; o; i M I Both shall hment- not be "i". initiato r 2 Establis m; o; i I M hment- responde r 3 Establis m; o; i I M The value hment- shall be "i" responde if r-reject Establishmen t-responder has the value "i" 4 Normal- m; o; i M M Both may be data- "i". requesto r 5 Normal- m; o; i M M data- acceptor 6 Release- m; o; i M I Both may be requesto "i". r 7 Release- m; o; i I M acceptor 8 Authenti m; o; i O O cation 10 Part 5 - Upper Layers June 1994 (Working) 9 Applicat m; o; i O O ion- context- negotiat ion 1 Transpor m; o; i I I 0 t- expedite d 1 Number 1 or 2 2 The value 1 of more chosen presenta includes the tion- presentation contexts -context required used for ACSE PDUs. 1 ISO/IEC yes Yes Yes If the 2 ISP answer is 11188-1 not "yes", complian the ce?1 referencing specificatio n may not claim mOSI compliance 1 Status all "m"; Mixed Mixed If the 3 values all "o"; answer is for all all "i"; "mixed" open (*) or (i.e. not paramete "mixed" all "m" and rs (see " ", or not table all "o" and D.2) " ", or not all "i" and " "), details shall be given in table D.2 1 See clause 2 and ISO/IEC ISP 11188-1, annex B. 11 Part 5 - Upper Layers June 1994 (Working) 12 Part 5 - Upper Layers June 1994 (Working) Table Open parameters (*) Refere Parameter Specifi Specifi Constraint / nced cation' cation' value table s s (in stateme stateme annexe nt nt s A, B Sender Receive and C) r [a] [a] 1 A.6.1 Calling AE Includes both the title AP title and AE 2 [AARQ] qualifier for Called AE each title 3 Includes both the Calling AP invocation invocation identifier and ids the AE invocation 4 identifier for Called each invocation ids 5 User Informatio n 6 A.6.2 Responding Includes both the AE title AP title and AE qualifier 7 [AARE] Includes both the Responding AP invocation Invocation identifier and Identifier the AE invocation s identifier 8 User Informatio n 13 Part 5 - Upper Layers June 1994 (Working) 9 A.6.3 Reason 1 [RLRQ] User 0 Informatio n 1 A.6.4 Reason 1 1 [RLRE] User 2 Informatio n 1 A.6.5 User 3 [ABRT] Informatio n 1 A.7.1 Form 1 For Receiver, 4 [AARQ (Directory compliant answer and name) is "m" or " ". That is, if AE titles 1 AARE] are supported for Form 2 5 receiving, both (Object forms are id+integer mandatory. ) 1 B.4.1 Default May be used for 6 [CP] context simple encoding name of ACSE and user PCI 1 B.4.3 Default 7 [CPR] context result [a]Compliant answer for each row is "m", "o", "i" or " ", unless indicated otherwise. 14 Part 5 - Upper Layers June 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) 15 Part 5 - Upper Layers June 1994 (Working) Annex B (informative) Recommended Practices (Refer to Stable Agreements Document.) 16 Part 5 - Upper Layers June 1994 (Working) Annex C (informative) Backward Compatibility 17 Part 5 - Upper Layers June 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.] | +----------------------------+---------------+-------------------------------+ | Restrictions on encoding | V2E1 section | Interworking 18 Part 5 - Upper Layers June 1994 (Working) problems may | | of "Presentation Context | 5.8.3.3 | occur since implementations | | Identifier." | | could encode negative | | | | numbers. [An implementation | | | | that conforms to versions | | | | previous to V2E1 as a | | | | responder and V3E1 as an | | | | initiator will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ | Mode selector as first | V1E4 section | This will cause interworking | | element in set | 5.6.3.4 | problems for those | | | | implementations that don't | | | | encode "mode selector" as the | | | | first element in the set. [An | | | | implementation that conforms | | | | to versions previous to V1E4 | | | | as an initiator and V3E1 as | | | | a responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ 19 Part 5 - Upper Layers June 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 | 20 Part 5 - Upper Layers June 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 | 21 Part 5 - Upper Layers June 1994 (Working) | | | versions previous to V3E1 as | | | | a responder will be able to | | | | interoperate.] | +----------------------------+---------------+------------------- ------------+ 22 Part 5 - Upper Layers June 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 | 23 Part 5 - Upper Layers June 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 | 24 Part 5 - Upper Layers June 1994 (Working) | proposed. | | receivers that do not examine | | | | them. | +----------------------------+---------------+------------------- ------------+ 25 Part 5 - Upper Layers June 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. | 26 Part 5 - Upper Layers June 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.] | +----------------------------+---------------+------------------- ------------+ 27 Part 5 - Upper Layers June 1994 (Working) Annex D (normative) Working Draft of new ISP on CL-CULR Specification Editor's Note - This annex contains the draft proposed text for a new ISP on connectionless upper layer facilities. Electronic readers should refer to the Word for Windows 2.0 formatted document culr4.doc. 28 Part 5 - Upper Layers June 1994 (Working) Annex E (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' 29 Document No.ULSIG-96-06/94 Date:September 6, 1994 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) page 23 for a description of the EXTERNAL. Section 34.7 of 8824 says that: "If the data value is the value f 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 30 30 Document No.ULSIG-96-06/94 Date:September 6, 1994 layer agreements within the next year. "1" 31 81 84 a0 03 80 01 01 a2 7d 81 02 04 00 82 02 00 01 a4 23 30 10 02 01 01 06 05 28 ca 22 02 01 30 04 06 02 51 01 30 0f 02 01 03 06 04 52 01 00 01 30 04 060 02 51 01 88 02 06 00 89 03 05 40 00 61 45 30 43 02 01 03 "2" a0 3e 60 3c a1 07 06 05 28 ca 22 01 01 "3" be 31 28 2f 06 02 51 01 02 01 01 "4" 81 26 a8 24 80 02 20 00 ..... Responses: From Laura Emmons (laurae@ar.telenex.com) May 10 1993: 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: The data value of the instance of the Association- information element should be encoded as a single-ASN1-type. Status: OIW: Closed - Accepted 03/94 EWOS: AOW: 31 31 Document No.ULSIG-96-06/94 Date:September 6, 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 this 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 32 32 Document No.ULSIG-96-06/94 Date:September 6, 1994 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 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: Closed - Accepted 09/93 EWOS: AOW: 33 33 Document No.ULSIG-96-06/94 Date:September 6, 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: From Klaus Truoel (truoel@gmd.de) Mar 17, 1994: Section 8.5 in Part 5 of the OIW Stable Implementor's Agreements (as well as the FTAMISP 10607-1, 7.3 and CULR-1, 7.10 state: "... shall be encoded either as a single PDV-list (using the octet-aligned choice) or as a series of PDV-lists, ..." The FTAM Stable Agreements have the same text. Therefore, encoding as grouped PDUs using a single PDV-list and the single-ASN1-type of encoding is not valid. Solution: Encoding grouped PDUs using a single PDV-list with the single-ASN1- type choice of encoding is not valid. Status: OIW: Closed - Accepted 03/94 EWOS: AOW: 34 34 Document No.ULSIG-96-06/94 Date:September 6, 1994 (4) Summary: Ed Kelley question on whether FTAM can directly use P-U-ABORT. Source: Date Raised: Issue: Responses: Solution: Status: OIW: Open - pending EWOS: AOW: (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: Open - pending EWOS: AOW: 35 35 Document No.ULSIG-96-06/94 Date:September 6, 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 or an ARP shall be issued." 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 36 36 Document No.ULSIG-96-06/94 Date:September 6, 1994 that would result in an ARU. This is what the clause expresses. 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: In the above reference to the base standard 8823, the terms "Invalid or unexpected PPDU" and "Invalid parameter" are both defined as PCI errors. The standard does not discuss the handling of errors found on user-data. Therefore there is no issue. However, it is expected that X3T5 will submit a ballot comment on CULR-1 asking that clarifying text be added to 7.9 staing that "(via an A-ABRT)" be added after the phrase "an ARU". Status: OIW: Closed - Accepted 03/94 EWOS: AOW: 37 37 Document No.ULSIG-96-06/94 Date:September 6, 1994 (7) Summary: X/Open ROSE PCI must be in BER. Source: Date Raised: Issue: Responses: Solution: Status: OIW: Open - pending EWOS: AOW: 38 38 Document No.ULSIG-96-06/94 Date:September 6, 1994 (8) Summary: Discrepency in usage of Exception Report SPDU causes conformance testing problems.. Source: Lee Chastain, JITC (lee@huachuca-jitcosi.army.mil) Date Raised: 14 December 1993 Issue: ISO 8327, sec. 7.25: The EXCEPTION REPORT SPDU is used to report that a protocol error has been detected within the SPM. ISO 8327, sec. A.4.1.2: NOTE It should be noted that sending an EXCEPTION REPORT SPDU may lead to an SPM deadlock. It is therefore advised to send the ABORT SPDU rather than the EXCEPTION REPORT SPDU, especially in the case of protocol errors. If an implementor were to take the above advice, under what circumstances would their Session ever send an ER? ISO 8327-2 (PICS) A.7.12.2/1 If you claim support for the Exceptions functional unit, the requirement to send the ER is mandatory. This appears to be in contradition to the note in the standard. Given that the note above is not an error in the standard, shouldn't the capability to send the ER be optional rather than mandatory? Responses: A discrency exists between ISO/IEC 8327 parts 1 and 2. ISO/IEC 8327-1 1994 (E), sec. 7.27 states: the EXCEPTION REPORT SPDU is used to report that a protocol error has been detected within the SPM. The note in section A.4.1.2 of the same document states: It should be noted that noted that sending an EXCEPTION REPORT SPDU may lead to an SPM deadlock. It is therefore advised to send the ABORT SPDU rather than the EXCEPTION REPORT SPDU, especially in the case of protocol errors. In ISO/IEC DIS 8327-2, sec. A.7.12.2/1, if support is claimed for the exceptions functional unit, the requirement to send the ER SPDU should be optional. It appears that there is no need for the ER SPDU 39 39 Document No.ULSIG-96-06/94 Date:September 6, 1994 in 8327. Further study should be given to the elimination of the ER SPDU. Solution: A defect report will be submitted sugessting the following change to ISO/IEC DIS 8327-2, sec. A.7.12.2: Exceptions functional unit SPDU Status Support Comment Sdr Rcv Sdr Rcv Exception Report (ER) c32 c33 Exception Data (ED) c33 c33 c32: if [S-FU(EXCEP)] then o else n/a c33: if [S-FU(EXCEP)] then m else n/a Status: OIW: Closed - Accepted 03/94 EWOS: AOW: 40 40 Document No.ULSIG-96-06/94 Date:September 6, 1994 (9) Summary: Discrepancy between ISO 8823-2 and ISP 10607-1 in the Presentation Context Identifier List parameter of the RS and RSA PPDUs Source: Lee Chastain, JITC (lee@huachuca-jitcosi.army.mil) Date Raised: 6 January 1994 Issue: There appears to be a discrepancy between ISO 8823-2 and ISp 10607-1 in the Presentation Context Identifier List parameter of the RS and RSA PPDUs. In the ISO (A.7.13/1 and A.7.14/1) the parameter is conditional, which can evaluate to mandatory. The ISP, however, claims the base standard has it as optional and for the profile makes it out of scope. Which is correct? Do we need (or already have) a defect report? Responses: From Noel Albertson (noel@nsilsun1.Tredydev.Unisys.com): It appears that the ISP is incorrect in stating the 'Presentation Context Identifier List' as optional in the base standard, since it would be required if the implementation supports the 'Context Restoration' functional unit. However, "outside of scope" may still be the correct status for the profile since (I believe) the functional unit is also outside the scope. Solution: ISP 10607-1 table A.2 column D under resynchronization does have a typo, and should be conditional. Since the new version of the ISP does not have a column D, the typo has been fixed. Status: OIW: Closed - Not an issue 03/94 EWOS: AOW: 41 41 Document No.ULSIG-96-06/94 Date:September 6, 1994 (10) Summary: Need for clarification on when Presentation Context negotiation is complete during association establishment using RTSE. Source: Brenda Troisi, Tandem Computers (troisi_brenda@tandem.com) Date Raised: 20 January 1994 Issue: The issue is concerned with whether the absence of direct reference from the EXTERNAL type of the RTSE APDU (user data of AARQApdu - RTORQApdu) in an association connect request should be considered as an error, or whether the indirect reference alone is sufficient. The answer to the above question revolves around the related question: "When is presentation context negotiation complete?" This is the question raised to the OIW. The current OIW response is as follows: Presentation context negotiation is complete when the presentation "confirm" is complete, and the negotiated context result is conveyed to the Presentation user. Note that the Presentation user may choose to reject the result. Company A's interpretation: Company A's RTSE implementation is a client of ACSE and sends its RTORQ-apdu in the ACSE AARQ user-information field. The RTSE implementation uses a single transfer syntax, BER, and performs the encoding/decoding of the EXTERNAL that will be passed as user-information in the AARQ PDU. Given the similarity of EXTERNAL and PDV-list, the author apparently concluded that the rukes for the PDV-list applied to the EXTERNAL as well (see Attchment 3). Therefore, the author did not include the direct-reference in that EXTERNAL. Company B's interpretation: Company B agrees that the standard contains no definitive description. They have apparently discounted the similarity between PDV-list and the EXTERNAL, decided that X.208 section 34.6 is the only relevant text, and that negotiation is complete when the responder issues the CPA or CPR 42 42 Document No.ULSIG-96-06/94 Date:September 6, 1994 PPDU. Thus negotiation is incomplete at the point that the P-CONNECT indication's user data is decoded and they want the EXTERNAL value to contain the direct reference field. Since Company A's RTORQ-apdus don't, they reject connect requests from Company A's MTA. Implication of the OIW decision: The OIW place the completion of negotiation after the point of time under discussion. In fact, it is later than either company chose. If they choose to recognize the authority of this group to make this ruling, then Company A's AARQ/CP PPDU is not in accordance with their decision and ought to change. In fact, from reading the OIW statement, both company's AARE/CPA PPDUs could be considered wrong even though their implementations of these PDUs match that in all the implementations we could find to check. Remaining ambiguity: Both Company B and the OIW state that construction of the 3 Presentation Connection PDUs precede completion of presentation context negotiation. Each considers only one side of the connection (e.g. the responding side cannot know when the confirm is delivered). Both statements put together could be the correct answer - that is, the two parties to the connection each have a different view of when it is complete. But neither statement addressed the issue of encoding vs. decoding. It would seem most logical that the state of negotiation at the time of encoding should be the correct one to consider. Yet that is not what anyone does for the AARE! -------------------------------------------------- -------------------------------------------------- ----- ATTACHMENT 3: Details on the ambiguity Relevant sections of the standards: The problem occurs on association establishment. The application's connect (or bind) primitive becomes the content of the user-information field of the ACSE AARQ-apdu. This field is defined in X.227 as: user-information IMPLICIT Association- information and that data type is 43 43 Document No.ULSIG-96-06/94 Date:September 6, 1994 Association-information ::= SEQUENCE OF EXTERNAL the EXTERNAL data type is defined in X.208 section 34: EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE { direct-reference OBJECT IDENTIFIER OPTIONAL, indirect-reference INTEGER OPTIONAL, data-value-descriptor Object Descriptor OPTIONAL, encoding CHOICE { single-ASN1-type [0] ANY, octet-aligned [1] IMPLICIT OCTET STRING, arbitrary [2] IMPLICIT BIT STRING } } X.208 section 34.6 explains that the presence of the direct-reference field in this type is conditional on the state of the presentation context negotiation (i.e. whether or not the negotiation is complete). Unfortunately, neither this text nor X.216/X.226 (Presentation specs) definitively state when negotiation is complete. In addition, the text does not state whose point of view is relevant. That is, do you decide what value to use based on the state of negotiation when the value is encoded or when it will be decoded? The entire AARQ-apdu is then passed as user data in the P-Connect req. The P-Connect req. user data becomes the user data field of the CP PPDU and that is defined in X.226 as a choice of Simply- encoded -data or Fully-encoded-data. Fully- encoded-data is the case that applies to this discussion: Fully-encoded-data ::= SEQUENCE OF PDV-list PDV-list ::= SEQUENCE { Transfer-syntax-name OPTIONAL, Presentation-context-identifier, presentation-data-values ::= CHOICE { single-ASN.1-type [0] ANY, octet-aligned [1] IMPLICIT OCTET STRING, arbitrary [2] 44 44 Document No.ULSIG-96-06/94 Date:September 6, 1994 IMPLICIT BIT STRING } } Section 8.4.2.7 states "The transfer-syntax-name component of a PDV-list value in a CP PPDU shall be present when more than one transfer syntax name was proposed for the presentation context of the presentation data values. The NIST/OIW Stable Implementor's Agreements on Upper Layers (see 12/92 edition, Volume 1, Chapter 5, section 8.6) goes on to say that the transfer syntax name shall be present IF AND ONLY IF more than one transfer syntax name was proposed. [Since the definition of the PDV-list and EXTERNAL fields look the same, and, in the case of an AARQ, an EXTERNAL is embedded in a PDV-list, one could extrapolate that this rule would apply to both data types. Does it? Should it?] Implementation Status A quick check was made against interworking protocol traces that we had handy to see what various (FTAM, X.500, X.400) implementations and conformance testers are doing in this area. For the AARQ/CP PPDU, 3 of the 4 possible combinations of absence/presence of the two transfer syntax components were found. Everyone implemented a single combination (no transfer syntax components) in the AARE/CPA PPDU BUT this particular combination is in contradiction of the OIW clarification in Appendix 1. That is, everyone unanimously decided to consider negotiation complete when encoding the EXTERNAL in the AARE rather than upon delivery of the P-Connect Conf. Status in the Standard's World These issues have long been known and discussed but no definitive action has been taken. According to a member of the ISO Presentation group, the similarity between the EXTERNAL and PDV-list data type has been discussed in the past and the (unrecorded) consensus appears to be that the rules to PDV-list do not apply to EXTERNAL despite their similarity. A defect report was filed against X.208/8824 in June 93 which questions the text in X.208 section 34.6. The implementor's groups seem to be the best available forum for 45 45 Document No.ULSIG-96-06/94 Date:September 6, 1994 addressing this issue. Proposed Solution: This is clearly a complex issue which is hard to understand and hard to explain. Simplification would enhance clarity. A simple solution would be to alter the context of X.208 section 34.6 to refer to the text ruling the construction of the Presentation PDV-list. And then to clarify that PDV-list description. There are two possibilities for the clarification of the PDV-list: - Most unambiguous: the transfer syntax component is always (and only) included in any exchange (all 4 primitives and both PDUs - a list could be included for clarity) which can only modify the Defined Context Set (DCS). This DCS. This would be a departure from current practice and the OIW statement. - Perhaps better: the transfer syntax component may always be included but is only used when necessary i.e. when the PCID does not unambiguously identify a transfer syntax because the DCS is incomplete and more than one transfer syntax was defined. This is closer to the current practice but perhaps harder to explain to anyone unfamiliar with the DCS. In either case, the value of the field would not be checked when it was not used which would introduce a level of tolerance to achieve backward compatibility. The solution should both clarify the issue AND accomodate existing implementations. Unfortunately, it is probably too late (both for this round of standardization and with respect to all the extant implementations) to achieve this level of clarification. So the ambiguities will remain and be a source of confusion and question amongst implementors (while researching this issue, I found 4 other companies who shared our confusion). Thus a recorded statement from the OIW acknowledging the ambiguities with some resolution would be helpful. At a minimum, implementors should be encouraged to make their protocol implementations "tolerant" in this murky area. I would define tolerance in the following way: "absence or presence of the transfer syntax 46 46 Document No.ULSIG-96-06/94 Date:September 6, 1994 component in the PDV-list or ACSE user data in primitives/PDUs which define or modify the DCS should not be considered a protocol violation unless the corresponding PCID does not resolve to a single transfer syntax at the required time. Responses: A concensus at the June OIW was the following: On the Negotiation question: The transfer syntax rule is stated in the Stable Agreements Part 5 - 8.6. After long discussions, talks with experts and more research, we were convinced that "prior agreement" means agreements between the implementors (through standards and implementors agreements). It does not mean actual negotiation between systems. Since the base standards and agreements can specify a single transfer syntax, use of the direct-reference component would not be appropriate. On the question of EXTERNAL VS PDV-list: These entities are different and should not be confused. From: Laura Emmons (laurae@ar.telenex.com): >When is Presentation layer negotiation complete? According to the state tables in X.226 for the initiator of a connection, it is complete after the P-CONcnf is issued to the PS-user; for the responder of a connection, it is complete when either the CPA or CPR is sent. >The issue is concerned with whether the absence of direct reference from the >EXTERNAL type of the RTSE APDU (user data of AARQApdu - RTORQApdu) in an >association connect request should be considered as an error, or whether the indirect >reference alone is sufficient. I could not find an EXTERNAL data type in the RTORQApdu so I assume you mean the EXTERNAL component of the Association-information component of the AARQ-apdu. The use of the transfer syntax name described in 8.6 of Part 5 of the SIA is in reference to the PDV-list of the CP PPDU and has absolutely nothing to do with this issue. The critical text is in X.208 34.6. It states "If 47 47 Document No.ULSIG-96-06/94 Date:September 6, 1994 presentation layer negotiation is not complete, an object identifier value is also needed which identifies the encoding rules (transfer syntax) used for the encoding. Where presentation layer negotiation is in use, and where the direct- reference OBJECT IDENTIFIER element is allowed or is required to carry such a value, this shall be identified by a comment associated with the use of the EXTERNAL notation, otherwise the field shall be absent." It does not say that the object identifier value identifying the transfer syntax must be the direct reference component. Since there is no comment associated with the notation for the Association-information element in the ACSE, and since the transfer syntax was conveyed in the presentation context identifier list, the direct reference component of this particular EXTERNAL should not be present. Solution: The direct reference component of the EXTERNAL in the Association- information element of both the AARQ and AARE APDUs should not be present. Its absence is not an error. Status: OIW: Closed - Accepted 13 June 1994 EWOS: AOW: 48 48 Document No.ULSIG-96-06/94 Date:September 6, 1994 (11) Summary: Issue on Checkpoint Size and RTTR APDU Source: Brenda Troisi, Tandem Computers (troisi_brenda@tandem.com) Date Raised: 3 February 1994 Issue: About Checkpoint Size and RTTR APDU - 2/3/94 THE QUESTION: RTTR APDUs are used to convey the X.400 P1 MPDU. If Checkpointing is used, then the MPDU will be conveyed in one or more RTTR APDUs the size of each of which is constrained by the Checkpoint size (if checkpointing is not in use, a single, unlimited size RTTR APDU is used). A question has arisen about the meaning of the checkpoint size value and its relationship to the RTTR APDU. Specifically, should that size include or exclude the encoding of the OCTET STRING. X.228 is not crystal clear on this point and the text could be interpreted in at least two different ways. RELEVANT FACTS: This issue came up during the 1988 study period and was addressed by the 1984 Implementor's Guide. The first paragraph of X.410 section 4.3.2 (Transmitting an APDU) is the relevant text and it was amended as indicated in the "[]" below (this clarification appeared as bullet E28 in the 1984 IG). Remember that in 1984, RTS was mapped directly to session, hence the RTS APDU is sent as an SSDU. "The maximum SSDU size [(same as the maximum checkpoint size)], as stated previously, will have been negotiated during the connection phase. The sending RTS must submit in S-DATA.request, SSDUs that conform to that agreement." In X.228, this text becomes section 8.2.1.2.1 (use of P-Data user data): "The maximum User data size (number of octets of the RTTR APDU value) will have been negotiated during the association-establishment procedure. The sending RTPM shall submit User data that 49 49 Document No.ULSIG-96-06/94 Date:September 6, 1994 conforms to that agreement." Question: why was this clarifying text not included in 1988? Was it considered to be self-evident or was an explict repudiation of this position intended? If the latter, then should that fact be noted in X.228 Annex B (differences between X.228 and X.410-1984)? One problem here seems to be the interpretation of the "value" in this previous paragraph. One possibility is to take it literally and equate "value" with "content" (as in type/length/value -> identifier/length/content) of the BER encoding. Another possibility is to interpret it as the right hand side of the ASN.1 definition for RTTRapdu e.g. OCTET STRING. As I sit here late tonite, I realize that I cannot find any mention of the OCTET STRING in the 1984 X.410 standard. Perhaps that is the key to this. If the OCTET STRING is new in 1988, then a position compatible with the 1984 IG bullet is to say that the 1984 content of the SSDU has now become the content of the 1988 OCTET STRING and therefore, the checkpoint size now applies to the content of the OCTET STRING. That is, don't count the OCTET STRING encoding in the checkpoint size. This raises a new question which is "how is 1984 compatibility achieved with that OCTET STRING in place?". OTHER RELEVANT SECTIONS OF X.228: The RTTR APDU is defined as: RTTRapdu ::= OCTET STRING The content of the OCTET STRING is all or a piece of the MPDU which is encapsulated in the OCTET STRING encoding. The RTTRapdu is then passed in the P-Data request to the other side. section 7.3.2 (APDUs used in transfer procedure): "The RTSE-user APDU value is transformed into the encoded-APDU-value and vice versa by means of the local syntax-matching services. The transfer 50 50 Document No.ULSIG-96-06/94 Date:September 6, 1994 procedure uses the RT-TRANSFER (RTTR) APDU. The transfer procedure supports segmenting and reassembling of the encoded-APDU-value into/from one or more RTTR APDUs. An encoded-APDU-value is transferred as a single RTTR APDU if checkpointing is not used. Otherwise, the encoded-APDU-value is transferred as a series of RTTR APDUs, the maximum size (ie number of octets forming the RTTR APDU value) of each being the negotiated checkpoint-size. The concatenation of the RTTR APDU values is the encoded-APDU-value." Again, there is the question of how literally to take the term "value" in the phrase "number of octets forming the RTTR APDU value". There is also room for interpretation of the last sentence. One can take the "concatenation" phrase literally or one can take it as a logical concatenation (e.g. strip the octet string and then concatenate). Another possible area of confusion is usage of the term APDU. When does it refer to the user data passed in the RTS primitive (i.e. the data that will be encapsulated in the RTS APDU) and when does it refer to the user data which will be passed in the presentation primitive (i.e. the encoded RTS APDU). It would seem most logical for it to always refer to the latter case since the former case would be be better referred to as UserData. X.228 Sect 6.2.2 Use of Presentation-service p386 "The RTPM requires access to local syntax-matching-services provided by the presentation-service provider. This syntax-matching-service consists of: a) an encoding service enabling the transformation from the local representation of an APDU value into an encoded-APDU-value of type OCTET-STRING the value of which is the representation of the APDU value specified by the negotiated transfer syntax; b) a decoding service enabling the transformation from an encoded-APDU-value into the local representation of the APDU value. 51 51 Document No.ULSIG-96-06/94 Date:September 6, 1994 If X.410-1984 mode or simple encoding is used by the Presentation Layer, the APDU value is encoded as ASN1.type ANY. If full encoding is used by the Presentation Layer, the APDU value is encoded as ASN.1 type EXTERNAL. (For X.410-1984 mode, single encoding and full encoding see Recommendation X.226)." Note: None of these sections appear to distinguish between normal and X.410-1984 mode when dealing with checkpoint size. Thus the two cases must be dealt with in the same way. Given that X.410-1984 mode is to be bitwise compatible with a 1984 X.410 implemenation.... Responses: Concensus from the June OIW: There is no room for interpreting the term "value" used above. Value is defined in X.208 12.7. The value of the RTTRapdu is the whole OCTET STRING value, i.e. identifier, length, and contents. Solution: See above Status: OIW: Closed - Accepted 13 June 1994 EWOS: AOW: 52 52 Document No.ULSIG-96-06/94 Date:September 6, 1994 (12) Summary: RTS (X.228) Ambiguity on CallingSSUseReference Source: Charlie Combs, MCI Date Raised: 11 March 1994 Issue: Introduction Implementations of the 1988 version of the X.400 series of CCITT Recommendations are becoming operational. It has been discovered through interworking testing that some implementations are not compatible with 1984-based implementations. The incompatibility is due to an ambiguity in the Reliable Transfer: Protocol Specification Recommendation X.228 (1988). This contribution identifies the interworking problem and proposes a solution. It is hoped that the OIW will agree on a solution at the March 1994 meeting. Problem Description Recommendation X.410 (1984) as amended by X.400- Series Implementor's Guide(version 5, clarification E17) states in section 4.2.1 (S- CONNECT) the following for the Session Connection Identifier: "Note 1 - The initiating RTS will supply a Session Connection Identifier, which will be used to uniquely identify the connection. The identifier is formed of the following components: Calling SS- user Reference, Common Reference, and, optionally, Additional Reference Information. The identifier is returned unchanged by the responding RTS, except that the Calling SS-user Reference supplied by the initiator is conveyed as the Called SS-user Reference. Each Component, when present, will contain a data element of the appropriately named type from the following definitions: CallingSSUserReference ::= SSAPAddress -- of the initiator CommonReference ::= UTCTime 53 53 Document No.ULSIG-96-06/94 Date:September 6, 1994 AdditionalReferenceInformation :: T61String The syntax of the SSAP address T.61 String in the CallingSSUserReference is not defined by this Recommendation, but is a local matter. This information shall only be used to compare two Session Connection Identifiers octet by octet. Note: this allows both X.409 encoding (Identifier, Length, and Contents) and Session Layer Protocol rules (Contents only) for the Session Connection Identifier." Recommendation X.228 (1988) Annex B (Differences between this Recommendation and Recommendation X.410-1984) states the intent of the X.410-1984 mode is to support 1984-vintage implementations with the statement: "In X.410-1984 mode this Recommendation and its use of ACSE and Presentation service is bit- compatible to Recommendation X.410-1984 under consideration of the clarifications and errata of the X.400-series Implementors Guide V.5." Responses: Solution: Therefore, it is concluded that Recommendation X.228 section 8.1.1.1.3.5 (Session connection identifier) is contradictory and should, as a minimum, be interpreted as: CallingSSuserReference ::= CHOICE{ --local matter, solely in X.410-1984 mode -- OCTET STRING --solely in normal mode --} CommonReference ::= UTCTime AdditionalReferenceInformation ::= T61String Additionally, it needs to be made clear that, in the context of the PConnect and PAccept (in 1984, RTORQapdu and RTOACapdu in 1988), the present definition of SessionConnectionIdentifier is not altered by the above interpretations. Defect Report on X.228 is being submitted. 54 54 Document No.ULSIG-96-06/94 Date:September 6, 1994 Status: OIW: Closed - accepted EWOS: AOW: 55 55