home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
1993
/
05w_9312.txt
< prev
next >
Wrap
Text File
|
1994-02-09
|
104KB
|
3,894 lines
Working Implementation
Agreements for Open Systems
Interconnection Protocols:
Part 5 - Upper Layers
Output from the December 1993 Open Systems Environment
Implementors' Workshop (OIW)
SIG Chair: James Quigley, Hewlett Packard
SIG Editors: Debbie Britt, NCTS Laura Emmons, Telenex
Part 5 - Upper Layers September 1993 (Working)
Foreword
This part of the Working Implementation Agreements was prepared
by the Upper Layers Special Interest Group (ULSIG) of the for
Open Systems Environment Implementors' Workshop (OIW). See 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 December 1993 are being
printed. Please refer to the September 1993 Working Document for
additional information.
Future changes and additions to this version of these Implementor
Agreements will be published as a new part. Deleted and replaced
text will be shown as struck. New and replacement text will be
shown as shaded.
ii
Part 5 - Upper Layers September 1993 (Working)
Table of Contents
Part 5 - Upper Layers . . . . . . . . . . . . . . . . . . . . 1
0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative References . . . . . . . . . . . . . . . . . . 1
3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 1
4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.1 ISO Defect Solutions . . . . . . . . . . . . . . . . 1
4.2 Technical Corriagenda and Defect Reports . . . . . . 2
4.3 Defect Registers . . . . . . . . . . . . . . . . . . 2
4.4 Exception Handling . . . . . . . . . . . . . . . . . 5
5 Association Control Service Element . . . . . . . . . . . 6
5.1 Introduction . . . . . . . . . . . . . . . . . . . . 6
5.2 Services . . . . . . . . . . . . . . . . . . . . . . 6
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 Abort APDU . . . . . . . . . . . . . . . . . . . . . 6
5.5 Connectionless . . . . . . . . . . . . . . . . . . 6
6 ROSE . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7 RTSE . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8 Presentation . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Introduction . . . . . . . . . . . . . . . . . . . . 7
8.2 Service . . . . . . . . . . . . . . . . . . . . . . 7
8.3 Protocol Agreements . . . . . . . . . . . . . . . . 7
8.3.1 Transfer Syntaxes . . . . . . . . . . . . . 7
8.3.2 Presentation Context Identifier . . . . . . 7
8.3.3 Default Context . . . . . . . . . . . . . . 7
8.3.4 P-Selectors . . . . . . . . . . . . . . . . 7
8.3.5 Provider Abort Parameters . . . . . . . . . 8
8.3.6 Provider Aborts and Session Version . . . . 8
8.3.7 CPC-Type . . . . . . . . . . . . . . . . . 8
8.3.8 Presentation-context-definition-result-list 8
8.3.9 RS-PPDU . . . . . . . . . . . . . . . . . . 8
8.4 Presentation ASN.1 Encoding Rules . . . . . . . . . 8
8.5 Presentation Data Value (PDV) . . . . . . . . . . . 8
8.6 Connection Oriented . . . . . . . . . . . . . . . . 8
iii
Part 5 - Upper Layers September 1993 (Working)
8.7 Connectionless . . . . . . . . . . . . . . . . . . . 8
9 Session . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1 Introduction . . . . . . . . . . . . . . . . . . . . 9
9.2 Services . . . . . . . . . . . . . . . . . . . . . . 9
9.3 Protocol Agreements . . . . . . . . . . . . . . . . 9
9.3.1 Concatenation . . . . . . . . . . . . . . . 9
9.3.2 Segmenting . . . . . . . . . . . . . . . . 9
9.3.3 Reuse of Transport Connection . . . . . . . 9
9.3.4 Use of Transport Expedited Data . . . . . . 9
9.3.5 Use of Session Version Number . . . . . . . 9
9.3.5.1 Selection of session version . . . . . . . 9
9.3.5.2 User data in session version 2 . . . . . . 10
9.3.6 Receipt of Invalid SPDUs . . . . . . . . . 10
9.3.7 Invalid SPM Intersections . . . . . . . . . 10
9.3.8 S-Selectors . . . . . . . . . . . . . . . . 10
9.4 Connectionless . . . . . . . . . . . . . . . . . . . 10
10 Universal ASN.1 Encoding Rules . . . . . . . . . . . . . 10
10.1 Tags . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2 Definite Length . . . . . . . . . . . . . . . . . . 10
10.3 External . . . . . . . . . . . . . . . . . . . . . . 10
10.4 Integer . . . . . . . . . . . . . . . . . . . . . . 11
10.5 String Types . . . . . . . . . . . . . . . . . . . . 11
10.6 Extensibility . . . . . . . . . . . . . . . . . . . 11
11 Additions to ISP on Common Upper Layer Requirements . . . 11
11.1 Service . . . . . . . . . . . . . . . . . . . . . . 11
11.2 Provider Abort Parameters . . . . . . . . . . . . . 11
11.3 Concatenation . . . . . . . . . . . . . . . . . . . 11
11.4 Segmenting . . . . . . . . . . . . . . . . . . . . . 11
11.5 Reuse of Transport Connection . . . . . . . . . . . 11
11.6 Use of Transport Expedited Data . . . . . . . . . . 12
12 Character Sets . . . . . . . . . . . . . . . . . . . . . 12
13 Conformance . . . . . . . . . . . . . . . . . . . . . . . 12
14 Specific ASE Requirements . . . . . . . . . . . . . . . . 12
14.1 FTAM Phase 2 . . . . . . . . . . . . . . . . . . . . 12
14.2 MHS . . . . . . . . . . . . . . . . . . . . . . . . 12
14.3 DS Phase 1 . . . . . . . . . . . . . . . . . . . . . 12
14.4 Virtual Terminal . . . . . . . . . . . . . . . . . . 12
14.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . 12
14.6 Transaction Processing . . . . . . . . . . . . . . . 13
14.7 Network Management . . . . . . . . . . . . . . . . . 13
14.8 Remote Database Access . . . . . . . . . . . . . . . 13
Annex A (normative)
iv
Part 5 - Upper Layers September 1993 (Working)
Object Identifier Register . . . . . . . . . . . . . . . . . 14
A.1 Register Index . . . . . . . . . . . . . . . . . . . 14
A.2 Object Identifier Descriptions . . . . . . . . . . . 14
Annex B (informative)
Recommended Practices . . . . . . . . . . . . . . . . . . . . 15
Annex C (informative)
Backward Compatibility . . . . . . . . . . . . . . . . . . . 16
Annex D (normative)
Working Draft of new ISP on mOSI Specification . . . . . . . 27
Annex E (normative)
Working Draft of new ISP on CL-CULR Specification . . . . . . 44
Annex F (informative)
Upper Layer SIG Registered Questions List . . . . . . . . . . 45
v
Part 5 - Upper Layers
Editor's Note - All references to Stable Agreements in this
section are to Version 7.
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
In accordance with FIPS 146-1, with specific exceptions as noted
below, this edition of the Part 5 - Stable Implementation
Agreements remains backwardly compatible with Part 5 - Stable
Implementation Agreements, Version 3, Edition 1. The method for
assuring continued interoperability when these specific
exceptions occur is detailed below and has been approved by the
plenary of the OIW. Therefore, this edition of Part 5 - Stable
Implementation Agreements supersedes all previous versions and
editions of the Part 5 - Stable Implementation Agreements.
1
Part 5 - Upper Layers September 1993 (Working)
4.2 Technical Corriagenda and Defect Reports
An existing ISO base standard (e.g., ISO 8649 -- ACSE service)
may be modified by an approved/registered Technical Corriagenda
(TC) that fixes problems as reported in one or more Defect
Reports (DR).
An error or request for clarification concerning a base standard
is brought to the attention of ISO by a Defect Report. Defect
Reports may be submitted to ISO by the OIW or by national bodies
such as ANSI X3T5 task group in the USA.
A Defect Report is processed by the Defect Editing Group of the
base standard as part of the ISO "Rapid Amendment Process". If
the Defect Editing Group agrees that the Defect Report concerns
an error in the base standard, the Defect Editing Group prepares
a fix to the error in the form of a Draft Technical Corrigenda
(DTC). A DTC is not used to add new or revised facility to the
base standard. The purpose of the DTC is to rectify
inconsistencies and or mechanisms that do not provide the defined
facility.
NOTE - The amendment procedure is not used to add facility
to a base standard.
A DTC undergoes a 3-month draft ballot by national bodies. An
editing meeting may be necessary to resolve national body
comments.
An accepted/registered DTC becomes a TC. A TC immediately
becomes a part of the base standard that it references. For a
referencing standard or profile, the modification by a TC or an
errata immediately takes effect unless it applies to an option
that is "out-of-scope" or prohibited by the referencing standard
or profile.
A TC may impact the interoperability of a base standard. In some
cases, recertification may be necessary.
4.3 Defect Registers
2
Part 5 - Upper Layers September 1993 (Working)
Table ISO Defect Reports
+--------+------+-------+---------+--------+---------------------
---+--------+------+-----+----------------+
|Defect |Source|Circ. |Distr. as|Resp to |Returned to Editor
for -|Ballot |Voting|Final|Remarks |
| | | | |
+----+----+------+-------+ | | | |
| | |by Sec.| WG doc. |Sec. by
|info|actn|DTC/49|DTC/50 |ends |Sum'ry|text | |
+--------+------+-------+---------+--------+----+----+------+----
---+--------+------+-----+----------------+
|8649/001|Editor|88-12 |-- |89-11 |-- |-- |N4447 |--
|90-05-15|N4687 |N5630|Closed: Part of |
| | | | | | | | |
| | | |8649/TC1 |
|8649/002|Editor|89-11 |-- |89-11 |-- |-- |N4448 |--
|90-05-15|N4688 |N5630|Closed: Part of |
| | | | | | | | |
| | | |8649/TC1 |
| | | | | | | | |
| | | | |
|8649/003|Editor|89-11 |-- |89-11 |-- |-- |N4449 |--
|90-05-15|N4689 |N5630|Closed: Part of |
| | | | | | | | |
| | | |8649/TC1 |
| | | | | | | | |
| | | | |
|8649/004|Editor|90-02 |N765 |90-05-30|-- |yes |tbd |tbd
|tbd |tbd |tbd |Open: ULA advice|
| | | | | | | | |
| | | |- wait for XALS |
| | | | | | | | |
| | | |developments |
| | | | | | | | |
| | | | |
|8649/005|-- | | | | | | |
| | | |Number not used |
| | | | | | | | |
| | | | |
|8649/006|Japan |90-03 |N782 |90-06 |-- |-- |N5320 |--
|91-01 |N5690 |-- |Referred back to|
| | | | | | | | |
| | | |WG6 ULA group; |
| | | | | | | | |
| | | |response Nxxxx |
| | | | | | | |N6336
|N6336 |91-12-10|N6627 |-- |AFNOR: no vote |
| | | | | | | |tbd |tbd
|tbd |tbd |tbd |Revised DTC due |
| | | | | | | | |
3
Part 5 - Upper Layers September 1993 (Working)
| | | |from Editor |
| | | | | | | | |
| | | | |
|8649/007|CCITT |90-12 |N962 |91-03-25|-- |-- | |
| |N6628 |Ed 2 |Closed: DTC text|
| | | | | | | | |
| | | |unchanged; add |
| | | | | | | | |
| | | |to Edition 2 |
| | | | | | | | |
| | | | |
|8650/001|Editor|88-08 |N533 |89-11 |-- |-- |--
|N3473 |89-08 |N3862 |N4286|Closed: Part of |
| | | | | | | | |
| | | |8650/TC1 |
| | | | | | | | |
| | | | |
|8650/002|Editor|88-08 |N534 |89-11 |N653|-- |-- |--
|-- |-- |-- |Closed: Not |
| | | | | | | | |
| | | |recommended for |
| | | | | | | | |
| | | |progression |
| | | | | | | | |
| | | | |
|8650/003|Japan |88-10 |N573 |89-01 |N654|-- |-- |--
|-- |-- |-- |Closed:Editorial|
| | | | | | | | |
| | | |change already |
| | | | | | | | |
| | | |in IS text |
| | | | | | | | |
| | | | |
|8650/004|Editor|88-12 |-- |88-12 |-- |-- |--
|N3475 |89-08 |N4286 |N4286|Closed: Part of |
| | | | | | | | |
| | | |8650/TC1 |
| | | | | | | | |
| | | | |
|8650/005|-- | | | | | | |
| | | |Number not used |
| | | | | | | | |
| | | | |
|8650/006|CCITT |90-10 |N915 |91-01-11|tbd |-- |-- |--
|-- |-- |-- |Closed: Not |
| | | | | | | | |
| | | |recommended for |
| | | | | | | | |
| | | |progression |
| | | | | | | | |
4
Part 5 - Upper Layers September 1993 (Working)
| | | | |
|8650/007|CCITT |90-10 |N916 |91-01-11|-- |-- |--
|N6338 |91-12-10|N6629 |Ed 2 |Closed: Add to |
| | | | | | | | |
| | | |Edition 2 of |
| | | | | | | | |
| | | |8650 |
| | | | | | | | |
| | | | |
|8650/008|Editor|90-06 |-- |90-06 |N911|-- |-- |--
|-- |-- |-- |Closed: Response|
| | | | | | | | |
| | | |only - did not |
| | | | | | | | |
| | | |change text |
| | | | | | | | |
| | | | |
|8650/009|Editor|93-?? |N??? |93-03 |-- |-- |--
|Nxxxx |93-12 |tbd |tbd |Open: under |
| | | | | | | | |
| | | |discussion |
| | | | | | | | |
| | | |preparing for |
| | | | | | | | |
| | | |DTC text |
| | | | | | | | |
| | | | |
+--------+------+-------+---------+--------+----+----+------+----
---+--------+------+-----+----------------+
4.4 Exception Handling
For those cases where backwards compatibility cannot be assured
due to a Technical Corrigenda (see clause 4.6), interoperability
will be maintained by requiring existing implementations to
incorporate the change within 12 months after it has been
registered as a Technical Corriagenda. The registration
authority for conformance testing will determine in each case
whether or not recertification is necessary.
5
Part 5 - Upper Layers September 1993 (Working)
5 Association Control Service Element
5.1 Introduction
(Refer to Stable Agreements Document)
5.2 Services
(Refer to Stable Agreements Document)
5.3 Protocol Agreements
5.3.1 Application Context
(Refer to Stable Agreements Document)
5.3.2 AE Title
(Refer to Stable Agreements Document)
5.3.3 Peer Entity Authentication
(Refer to Stable Agreements Document)
5.4 Abort APDU
(Refer to Stable Agreements Document)
5.5 Connectionless
(Refer to Stable Agreements Document)
6
Part 5 - Upper Layers September 1993 (Working)
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
Editor's Note - Refer to Clause 11.1 of the Working
Agreements Document.
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)
8.3.3 Default Context
(Refer to Stable Agreements Document)
8.3.4 P-Selectors
(Refer to the Stable Agreements Document)
7
Part 5 - Upper Layers September 1993 (Working)
8.3.5 Provider Abort Parameters
Editor's Note - See Clause 11.2 of the Working Agreements
Document.
8.3.6 Provider Aborts and Session Version
(Refer to the Stable Agreements Document)
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)
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)
8
Part 5 - Upper Layers September 1993 (Working)
9 Session
9.1 Introduction
(Refer to Stable Agreements Document)
9.2 Services
(Refer to Stable Agreements Document)
9.3 Protocol Agreements
9.3.1 Concatenation
Editor's Note - Refer to Clause 11.3 of the Working
Agreements Document.
9.3.2 Segmenting
Editor's Note - Refer to Clause 11.4 of the Working
Agreements Document.
9.3.3 Reuse of Transport Connection
Editor's Note - Refer to Clause 11.5 of the Working
Agreements Document.
9.3.4 Use of Transport Expedited Data
Editor's Note - Refer to Clause 11.6 of the Working
Agreements Document.
9.3.5 Use of Session Version Number
9.3.5.1 Selection of session version
(Refer to the Stable Agreements Documents)
9
Part 5 - Upper Layers September 1993 (Working)
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)
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
Part 5 - Upper Layers September 1993 (Working)
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)
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
Part 5 - Upper Layers September 1993 (Working)
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.)
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)
12
Part 5 - Upper Layers September 1993 (Working)
14.6 Transaction Processing
(Refer to Stable Agreements Document)
14.7 Network Management
(Refer to Stable Agreements Document)
14.8 Remote Database Access
(Refer to Stable Agreements Document)
13
Part 5 - Upper Layers September 1993 (Working)
Annex A (normative)
Object Identifier Register
A.1 Register Index
(Refer to Stable Agreements Document)
A.2 Object Identifier Descriptions
(Refer to Stable Agreements Document)
14
Part 5 - Upper Layers September 1993 (Working)
Annex B (informative)
Recommended Practices
(Refer to Stable Agreements Document.)
15
Part 5 - Upper Layers September 1993 (Working)
Annex C (informative)
Backward Compatibility
16
Part 5 - Upper Layers September 1993 (Working)
+----------------------------------------------------------------
------------+
| Version & Section
|
+----------------------------+---------------+-------------------
------------+
| Issue | Changed | Backward
Compatibility |
+----------------------------+---------------+-------------------
------------+
| Restrictions on minimum | V1E2 5.5.3.2 | Interworking
problems may |
| number of octets | | occur, since
implementations |
| implementations shall be | | could send more
than 128 |
| able to receive. | | octets. [An
implementation |
| | | that conforms to
versions |
| | | previous to V1E2
as an |
| | | initiator and V3E1
as a |
| | | responder will be
able to |
| | | interoperate.]
|
+----------------------------+---------------+-------------------
------------+
| Agreements on AE Title, | V1E3 section | Interworking
problems may |
| AP Title, and AE Qualifier | 5.5.3.3 & | occur between
implementations |
| changed. | V1E4 section | that expect
different forms of|
| | 5.5.3.3 | AP Title and AE
Qualifier |
| | | to be used.
[Implementations |
| | | that accept any
form of these |
| | | parameters will
interwork with|
| | | initiators that
conform to |
| | | earlier versions.]
|
+----------------------------+---------------+-------------------------------+
| Restrictions on encoding | V2E1 section | Interworking
17
Part 5 - Upper Layers September 1993 (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.]
|
+----------------------------+---------------+-------------------
------------+
18
Part 5 - Upper Layers September 1993 (Working)
+----------------------------------------------------------------
------------+
| Version & Section
|
+----------------------------+---------------+-------------------
------------+
| Issue | Changed | Backward
Compatibility |
+----------------------------+---------------+-------------------
------------+
| Restrictions on encoding | V2E1 section | This will cause
interworking |
| of "protocol version" and | 5.8.4.2 | problems for those
|
| "presentation | | implementations
expecting |
| requirements." | | "protocol version"
and |
| | | "presentation
requirements" |
| | | to be encoded in
the primitive|
| | | form. [An
implementation that|
| | | conforms to
versions previous |
| | | to V2E1 as an
initiator and |
| | | V3E1 as a
responder will be |
| | | able to
interoperate.] |
+----------------------------+---------------+-------------------
------------+
| Restrictions on encoding | V2E1 section | This will cause
interworking |
| of "presentation selector."| 5.8.4.3 | problems for those
|
| | | implementations
expecting |
| | | "presentation
selector" to be |
| | | encoded in the
primitive form.|
| | | [An implementation
that |
| | | conforms to
versions previous |
| | | to V2E1 as an
initiator and |
19
Part 5 - Upper Layers September 1993 (Working)
| | | V3E1 as a
responder will be |
| | | able to
interoperate with |
| | | either version.]
|
+----------------------------+---------------+-------------------
------------+
| Use of default values for | V2E3 section | No backwards
compatibility |
| Minor syncpoint changed. | 5.11.1.1.1 |
|
+----------------------------+---------------+-------------------
------------+
| Addition and deletions | V2E1 section | No backwards
compatibility |
| of abstract syntaxes. | 5.11.1.3.1 |
|
+----------------------------+---------------+-------------------
------------+
| Value for session | V2E4 section | No backwards
compatibility |
| functional unit | 5.11.1.4.1 |
|
| "resynchronize" | |
|
| changed. | |
|
+----------------------------+---------------+-------------------
------------+
| Restrictions on inclusion | V3E1 section | Interworking
problems will |
| of "Transfer-syntax-name" | 5.8.6 | occur for those
|
| in CP PPDU and CPC type. | | implementations
that expect |
| | | "Transfer-syntax-
name" |
| | | parameter to be
present in |
| | | the PDV-List even
though one |
| | | transfer syntax
was |
| | | negotiated. [An
|
| | | implementation
conforming to |
| | | V3E1 as an
initiator and |
20
Part 5 - Upper Layers September 1993 (Working)
| | | versions previous
to V3E1 as |
| | | a responder will
be able to |
| | | interoperate.]
|
+----------------------------+---------------+-------------------
------------+
21
Part 5 - Upper Layers September 1993 (Working)
+----------------------------------------------------------------
------------+
| Version & Section
|
+----------------------------+---------------+-------------------
------------+
| Issue | Changed | Backward
Compatibility |
+----------------------------+---------------+-------------------
------------+
| Encoding restrictions | V3E1 section | Interworking
problems will |
| on ASN.1 INTEGER type | 5.10.4 | occur since
implementations |
| describing PCI. | | conforming to
previous |
| | | versions could
encode PCI |
| | | integer lengths
greater than |
| | | 4. [Responders
that accept |
| | | integers
describing PCI that |
| | | are encoded in
greater than |
| | | 4 octets and
Initiators that |
| | | conform to V3E1
will be able |
| | | to interoperate.]
|
+----------------------------+---------------+-------------------
------------+
| Encoding restrictions | V3E1 section | Implementations
that conform |
| on BIT STRING, OCTET | 5.10.5 | to previous
versions can |
| STRING, and CHARACTER | | expect these
strings to have |
| STRING. | | nested constructed
encodings |
| | | and therefore
interworking |
| | | problems will
occur. |
| | | [Responders that
accept |
| | | nested constructed
encodings |
22
Part 5 - Upper Layers September 1993 (Working)
| | | and Initiators
that conform |
| | | to V3E1 will be
able to |
| | | interoperate.]
|
+----------------------------+---------------+-------------------
------------+
| No extra trailing bits | V3E1 section | Interworking
problems will |
| allowed in BIT STRING. | 5.10.6 | occur when
implementations |
| | | that conform to
previous |
| | | versions send
extra trailing |
| | | bits. [Responders
accepting |
| | | extra trailing
bits and |
| | | Initiators that
conform to |
| | | V3E1 will be able
to |
| | | interoperate.]
|
+----------------------------+---------------+-------------------
------------+
| Restriction on usage of | V3E1 section | Interworking
problems will |
| "token item field" and | 5.9.3.1 | occur since
implementations |
| "user data." | | that conform to
V1E1 do not |
| | | expect the "token
item field" |
| | | to be encoded when
a category |
| | | 0 SPDU is
concatenated to a |
| | | category 2 SPDU.
|
+----------------------------+---------------+-------------------
------------+
| Restrictions on CPC-type | V2E2 section | Interworking
problems may |
| values when multiple | 5.8.3.9 | occur between
initiators that |
| transfer syntaxes are | | send CPC-type
values and |
23
Part 5 - Upper Layers September 1993 (Working)
| proposed. | | receivers that do
not examine |
| | | them.
|
+----------------------------+---------------+-------------------
------------+
24
Part 5 - Upper Layers September 1993 (Working)
+----------------------------------------------------------------
------------+
| Version & Section
|
+----------------------------+---------------+-------------------
------------+
| Issue | Changed | Backward
Compatibility |
+----------------------------+---------------+-------------------
------------+
| References to ISO 8649 | V1E3 section | Interworking
problems will |
| and ISO 8650 changed. | "References." | occur for those
|
| | | implementations
that conform |
| | | to ISO DIS 8649
and 8650. |
| | | V1E3 references IS
versions of|
| | | 8649 and 8650.
|
+----------------------------+---------------+-------------------
------------+
| References to ISO 8326, | V1E4 section | Interworking
problems will |
| ISO 8327, ISO 8822, and | References. | occur for those
|
| ISO 8823 changed. | | implementations
that conform |
| | | to 8326/DAD2,
8327/DAD2, DIS |
| | | 8822, and DIS
8823. V1E4 |
| | | referenced
8326/AD2, 8327/AD2,|
| | | IS 8822, and IS
8823. |
+----------------------------+---------------+-------------------
------------+
| AE Title changed | V3E1 section | Interworking
problems will |
| according to | 5.5.3.2 | occur between
initiators |
| Amendment 1 to | | that use AE-title-
form 1 and |
| ISO 8650. | | responders that
accept only |
| | | AE-Title-form 2.
|
25
Part 5 - Upper Layers September 1993 (Working)
+----------------------------+---------------+-------------------
------------+
| Restrictions on usage | V3E1 section | Interworking
problems will |
| of "direct references" | 5.5.4 | occur for those
|
| in ABRT APDU. | | implementations
that expect |
| | | the "direct
reference" |
| | | parameter to be
included in |
| | | the ABRT APDU.
[An |
| | | implementation
that conforms |
| | | to V3E1 as an
initiator and |
| | | versions previous
to V3E1 as a|
| | | responder will be
able to |
| | | interoperate.]
|
+----------------------------+---------------+-------------------
------------+
26
Part 5 - Upper Layers September 1993 (Working)
Annex D (normative)
Working Draft of new ISP on mOSI Specification
27
ULSIG-74-12/93
February 10, 1994
TITLE: Explanatory Report for PDISP 11188-3
for Common Upper Layer Requirements - Part 3:
Minimal OSI upper layer facilities
SOURCE: OIW
Laura Emmons
DATE: February 10, 1994
STATUS: Draft report for information to the
Regional OSI/OSE workshops and for submission to SGFS
together with PDISP 11188-3
a) General Profile Information
1) Profile Identifier
This profile does not specify a full
A-profile, and therefore has no place within the taxonomy of TR
10000-2.
2) Profile Title
Common Upper Layer Requirements Part
3: Minimal OSI upper layer facilities
3) Submitting Organization
Open Systems Environmental
Implementor's Workshop (OIW)
Laura Emmons
Telenex, Inc.
7401 Boston Blvd.
Springfield, VA 22153
USA
Tel: (703) 644-9113
Fax: (703) 644-9011
e-mail: laurae@ar.telenex.com
4) Date of notification to SGFS
28
ULSIG-74-12/93
February 10, 1994
5) Maintenance Commitment
The OIW ULSIG will ensure on behalf of
the three regional OSI/OSE workshops that the maintenance of
PDISP 11188-3 will be done. James Quigley is the project manager.
b) Base Standards Referenced
1) List of ISO/IEC standards, technical
reports and CCITT recommendations
Editor's note: These references will be updated in the course of
DISP to ISP progression.
1.1 Identical Recommendations |
International Standards
CCITT Recommendation X.227 (1993) | ISO 8650: 1993,1
Information processing systems Open Systems
Interconnection Protocol specification for the
Association Control Service Element.
1.2 Paired Recommendations | International
Standards equivalent in technical content
CCITT Recommendation X.200 (1984), Reference Model of
Open Systems Interconnection for CCITT applications.
ISO 7498:1984, Information processing systems Open
Systems Interconnection Basic Reference Model.
CCITT Recommendation X.210 (1988), OSI Layer Service
Definition Conventions for CCITT applications.
ISO/TR 8509:1986, OSI Layer Service Definition
Conventions.
CCITT Recommendation X.214 (1988), Transport service
definition for Open Systems Interconnection for CCITT
applications.
ISO 8072:1986, Information processing systems Open
Systems Interconnection Transport service
definition.
CCITT Recommendation X.225 (1988), Session protocol
specification for Open Systems Interconnection for
CCITT applications.
ISO 8327:1990, Information processing systems Open
Systems Interconnection Connection oriented session
1 Currently under ISO/IEC national body review
29
ULSIG-74-12/93
February 10, 1994
protocol specification.
CCITT Recommendation X.226 (1988), Presentation
protocol specification for Open Systems Connection for
CCITT applications.
ISO 8822:1988, Information processing systems Open
Systems Interconnection Connection oriented
presentation protocol specification.
1.3 Additional references
ISO 7498-3:1988, Information processing systems Open
Systems Interconnection Basic Reference Model Part 3:
Naming and Addressing.
ISO 8327-2:1992, Information processing systems Open
Systems Interconnection Connection oriented session
protocol specification Part 2: Protocol Implementation
Conformance Statement (PICS) Proforma.
ISO 8650-2: 1992, Information processing systems Open
Systems Interconnection Protocol specification for the
Association Control Service Element Part 2: Protocol
Implementation Conformance Statement (PICS) Proforma .
ISO 8823:1992, Information processing systems Open
Systems Interconnection Connection-oriented
Presentation Protocol Specification Part 2: Protocol
Implementation Conformance Statement (PICS) Proforma.
ISO/IEC 9545:1989, Information technology Open Systems
Interconnection Application Layer Structure
ISO/IEC TR 10000-1:1992, Information
technology Framework of taxonomy of International
Standardized Profiles Part 1: Framework. .
ISO/IEC TR 10000-2:1992, Information
technology Framework of taxonomy of International
Standardized Profiles Part 2: Taxonomy of Profiles.
ISO/IEC ISP 11188-1, Information
technology International Standardized Profile Common
upper layer requirements Part 1: Basic connection-
oriented requirements.2
2) TR 10000-1 Conformance
The documentation requirements of
ISO/IEC TR 10000-1 on conformance are not met.
2Currently at level of working draft
30
ULSIG-74-12/93
February 10, 1994
The Profile Requirements List of PDISP
11188-3 consist of several tables which specify the profile
requirements. They currently refer to the DIS versions of the
PICS proforma of the base standards of the ACSE, Presentation,
and Session service definitions. A proforma for
determining compliance to this profile is presented in Annex D.
3) Aspects of non-compliance with
standards
No such aspects.
4) Ammendments, corrigenda to base
standards
None in addition to clause 3 of PDISP
11188-3 (see also editor's note above).
c) Registration requirements
None
d) Other publications
Draft IETF RFC "ThinOSI upper layers cookbook", P.
Furniss (London: 1993)
"X/Open Transport Interface Appendix for Minimal OSI
Functionality", H. Lowe (Cambridge, MA: 1993)
e) Profile purpose
1) Executive Summary
ISO/IEC ISP 11188 as a multi-part ISP
specifies general requirements on the use of OSI upper layer
protocols by A-profiles. These are identified as "Common Upper
Layer Requirements".
The parts of this multi-part ISP do
not contain the definition of any complete profiles, but can be
referenced normatively by other ISPs which do define A-profiles.
In addition, a referencing ISP may specify further requirements
on the protocols, provided it does not
contradict this ISP.
The purpose of this multi-part ISP is
to provide common text for ISPs or other referencing
31
ULSIG-74-12/93
February 10, 1994
specifications which specify A-profiles. In addition to
simplifying their drafting, it also facilitates the
common implementation of the protocols for their use in different
A-profile contexts.
This part of ISO/IEC ISP 11188
specifies a profile of the minimal OSI facilities to support
basic connection-oriented communication applications. These
facilities are comprised of a subset of the
facilities defined by the ACSE, Presentation and Session service
definitions.
2) Relationship to other ISPs
PDISP 11188-3 is specified as a common
basis to be referenced and used by application ISPs for A-
profiles, e.g. ISPs for the AFT or AOM profiles. This profile
would be referenced in place of PDISP 11188-1 Coomon upper layer
requirements: Basic connection-
oriented requirements.
f) PDISP development process
1) Editor: OSI ULSIG (Laura Emmons)
History:
Draft 1 OIW/ULSIG-33-03/93First
OIW draft of mOSI ISP written in
ISP format and based on
the CULR-1. Circulated for comments
to the regional workshops. Added as
annex to working Implementor's Agreements
of the OIW.
Draft 2 OIW/ULSIG-33-06/93
Revisions made after comments were obtained from OIW and
EWOS.
Draft 3 OIW/ULSIG-33-09/93
Further revisions made after comments were obtained from OIW
and EWOS.
Draft 4 OIW/ULSIG-33-12/93
Further revisions were made after issues were raised by OIW and
EWOS.
2) Degree of Openess and Harmonization
32
ULSIG-74-12/93
February 10, 1994
The working drafts of PDISP 11188-3
have been circulated to all three regional workshops.
3) Joint planning operation
The PDISP was developed under the
coordination of RWS-CC.
g) PDISP content and format
1) TR 10000-1-1 Requirements
These requirements have/have not been
met.
2) Divergence from TR 10000
3) Multi-part structure
This PDISP is structured as a multi-
part ISP to meet the requirements of various A-profiles.
Additional parts:
Draft for PDISP 11188-1:
Common upper layer requirements - Part 1: Basic connection-
oriented requirements
Draft for PDISP 11188-2:
Common upper layer requirements - Part 2: Basic connection-
oriented requirements for ROSE based profiles
h) Any other information
None
33
Document No.ULSIG-71-12/93
Date:February 10, 1994
mOSI Issues List
(10) Reference: New Annex
Issue: An informative
bibliography should be added which would contain non-normative
references.
Source: OIW ULSIG
Date Raised: December 7, 1993
Solution: Added new annex I.
Status: OIW:Accepted December
10, 1993
EWOS:
AOW:
(11) Reference: Clauses 2 and 8
Issue: All information on
compliance and conformance should be combined into clause 2.
Source: OIW ULSIG
Date Raised: December 7, 1993
Solution: Combine relevant parts
of clause 8 into clause 2.
Status: OIW:Accepted December
10, 1993
EWOS:
AOW:
34
Document No.ULSIG-71-12/93
Date:February 10, 1994
(12) Reference: Annexes A, B and C.
Issue: It was felt that since
the definition of category 1 compliance/conformance
implies that all facilities are mandatory for sending, it is not
necessary to have separate column for category 1 and 2 in the
tables.
Source: OIW ULSIG
Date Raised: December 7, 1993
Solution: Removed category 1
column from all tables.
Status: OIW:Accepted December
10, 1993
EWOS:
AOW:
(13) Reference: Annexes A and B.
Issue: In order to align with
AOM1n (CMISE) and AFTnn (FTAM) profiles, the following
facilities/parameters should be made optional in the tables:
RLRQ and RLRE reason code, CPR and ARP provider reason, and
CPR Responding Presentation selector.
Source: OIW ULSIG
Date Raised: December 7, 1993
Solution: Tables have been
changed.
Status: OIW:Accepted December
10, 1993
EWOS:
AOW:
35
Document No.ULSIG-71-12/93
Date:February 10, 1994
(14) Reference: Clause 6
Issue: There should be a new
table which outlines the definitions of mandatory, optional, out-
of-scope, and excluded for the cases of compliance and
conformance.
Source: OIW ULSIG
Date Raised: December 7, 1993
Solution: Table added to clause 6.
Status: OIW:Accepted December
10, 1993
EWOS:
AOW:
(15) Reference: All
Issue: All information in CULR-
1 should be replicated in this document so that people do not
have to read so many speciifications.
Source: OIW ULSIG
Date Raised: December 9, 1993
Solution: Open. Will be discussed
at next workshop.
Status: OIW:
EWOS:
AOW:
36
Document No.ULSIG-71-12/93
Date:February 10, 1994
(16) Reference: Clause 6
Issue: Review the definitions
in clause 6 for accuracy.
Source: OIW ULSIG
Date Raised: December 9, 1993
Solution: Open.
Status: OIW:
EWOS:
AOW:
(4) Reference: Introduction
Issue: Add expalnatory report
and executive summary to document.
Source: OIW ULSIG
Date Raised: September 13, 1993
Solution: Added Foreword,
Explanatory Report, changed Introduction.
Status: OIW:AcceptedSeptember
16, 1993
EWOS:
AOW:
(5) Reference: Clause 8
Issue: Compliance clause should
be in same section in both CULR-1 and this document.
Source: EWOS TLG
Date Raised: July 13, 1993
Solution: Moved 8.1 - 8.2 to new
clause 2. Moved 8.3 and 8.4 to new
Annex D.
Status: OIW:AcceptedSeptember
16, 1993
EWOS:
AOW:
37
Document No.ULSIG-71-12/93
Date:February 10, 1994
(6) Reference: Clause 5, Table 1
Issue: Issue on whether the
definition of mandatory is correct.
Source: OIW ULSIG
Date Raised: June 10, 1993
Solution: After joint meeting with
the OIW CT SIG, added new note under table 1. Comments
requested.
Status: OIW:Accepted September
16, 1993
EWOS:
AOW:
(7) Reference: 2.1
Annex D, Tables 2 and 3
Issue: Issue on the correctness
of tables 2 and 3 (and their corresponding
documentation in 2.1) when used as a proforma by a referencing
standalone application specification.
Source: OIW ULSIG
Date Raised: 15 September 1993
Solution: Jim Quigley has supplied
new text in clause 2 and annexes D and E..
Status: OIW:Accepted December
10, 1993
EWOS:
AOW:
38
Document No.ULSIG-71-12/93
Date:February 10, 1994
(8) Reference: 3.7
Issue: Add definitions for
category 1 and 2.
Source: OIW ULSIG
Date Raised: 13 September 1993
Solution: Done. Section number has
changed to 4.7.
Status: OIW:AcceptedSeptember
16, 1993
EWOS:
AOW:
(9) Reference: None.
Issue: Issue on whether to add
section on use of transport services, especially the Reuse of
Transport Connection service.
Source: Kedem Kaminsky
Date Raised: 14 September 1993
Solution: Mr. Kaminsky was
specifically interested in the use of mOSI by network management
profiles. The AOM1n profile is the most widely used network
management profile. It explicitly states that reuse of the
transport connection is out of scope. CULR-3 also states this in
Annex C. The AOM1n profile makes no other comments on the use of
the Transport service. This is not an issue.
Status: OIW:Accepted December 7,
1993
EWOS:
AOW:
39
Document No.ULSIG-71-12/93
Date:February 10, 1994
(1) Reference: B.3.1 line 2
C.4.1.3 line 3
Issue: Called (N)-selectors
should be optional for
sending in Catagory II
compliance.
Source: OIW ULSIG
Date Raised: June 10, 1993
Solution: Cat II "m" should be
changed to "o".
Status: OIW: AcceptedJune 10,
1993
EWOS:
AOW:
(2) Reference: D.2
Issue: Clause D.2 is not
written clearly.
Source: OIW ULSIG
Date Raised: June 10, 1993
Solution: Rewritten to say the
following:
"Transfer-syntax is the representation
of the abstract-syntax during data
transfer. If an application does not
make a distinction between the
abstract and transfer syntax, the same
object identifier should be used to
denote both syntaxes. In the case
where: a) the abstract and transfer
syntax are not the same; and b) the
default abstract syntax object
identifier has been used (see D.1
above) the following default transfer
syntax object identifier may be
used..."
Status: OIW:AcceptedJune 10,
1993
40
Document No.ULSIG-71-12/93
Date:February 10, 1994
EWOS:
AOW:
41
Document No.ULSIG-71-12/93
Date:February 10, 1994
(3) Reference: Annex E
Issue: There is no text for
Annex E. It should be removed.
Source: OIW ULSIG
Date Raised: June 10, 1993
Solution: Removed.
Status: OIW:AcceptedJune 10,
1993
EWOS:
AOW:
42
ULSIG-85-09/93
February 10, 1994
Schedule for Progression of CULR
Milestone CULR-1 CULR-2 CULR-3
Informal SC21 May 92/ Jun 93 N/A Jun 93
review
EWOS Sep 93 Nov 93 May 94
endorsement
OIW Sep 93 Dec 93 Mar 94
endorsement
AOW Oct 93 Dec 93 - Feb Apr 94
endorsement 94 by
correspondence
pDISP Nov 93/ Mar 94 Apr 94/Aug 94 May 94/ Aug 94
submission
DISP Ballot Dec 93 - Apr Sep 94 - Jan Sep 94 - Jan
94 95 95
EDIT Meeting Jul 94 Feb 95 Feb 95
FINAL TEXT Oct 94 Mar 95 Mar 95
43
ULSIG-85-09/93
February 10, 1994
Annex E (normative)
Working Draft of new ISP on CL-CULR Specification
(This is ONLY a placeholder for anticipated work on a new profile
for connectionless upper layer facilities)
44
ULSIG-85-09/93
February 10, 1994
Annex F (informative)
Upper Layer SIG Registered Questions List
ULSIG Registered Question List
(1) Summary: Herb Falk's question on ACSE
Association Info.
Source: Herb Falk
Date Raised: 26 April, 1993
Issue: Copy of message follows:
The problem is specifically that the ACSE "Association-information",
which is an ASN.1 EXTERNAL, has taken the CHOICE of octet-aligned. The
ISO specifications and NIST stable agreements seem to be clear on this
matter. We will try to explain them as best we can. A hard copy of the
Presentation-Connect PDU follows on a separate page. Note that the
item circled and marked "1" is the beginning of the PDV-list. Note "2"
is the beginning of the Presentation Data List encoded as Single-ASN1-
type. Note "3" is the beginning of the Association-Information encoded
as an EXTERNAL. Note "4" is the beginning of the External encoding
tagged as octet-aligned.
Please reference page 31 of ISO specification ISO-8823 (IS). At the
top of the page is found a definition for the PDV-list. Legal
presentation data values are a CHOICE of { Single-ASN1-type, octet-
aligned, and arbitrary}. This CHOICE is further qualified in section
8.4.2.5, on the following page, to say that the single-ASN1-type shall
be used if the PDV-list contains exactly one presentation data value.
The ACSE Assocaite-Request PDU shown in the trace has exactly one
presentation data value, therefore this encoding rule applies. The PDU
conforms to this specification and may be verified in note "2" to be
the value 0xA0.
Please refer to page 18 of ISO specification 8650 for a description of
the AARQ-apdu. Towards the bottom of the page there is a description
of "user-information". It states that "user-information" is IMPLICIT
"Association-information" OPTIONAL. 3 pages later in the same
specification is the definition for "Association-information". It
states that an "Association-information" field may only be a SEQUENCE
OF EXTERNAL. An EXTERNAL is not defined in the ACSE Protocol
specification. It is found in the ASN.1 Protocol Specification ISO
8824.
Please refer to ISO specification 8824 (Abstract Syntax Notation One)
45
Document No.ULSIG-96-12/93
Date:February 10, 1994
page 23 for a description of the EXTERNAL. Section 34.7 of 8824 says
that:
"If the data value is the value of a single ASN.1 data-type, and if
the encoding is an integral number of octets, then the sending
implementation shall use any of the encoding choices:
single-ASN1-type
octet-aligned
arbitrary"
According to ISO 8824 it would be legal to send "Associate-
information" as octet-aligned at note "4". However, we believe that
there is an implementation agreement on this CHOICE of encoding. If
you look at the NIST stable agreements on page 12 in section 10.3
there is an implementors agreement on which choice to use in the
EXTERNAL. The second sentence in that paragraph reads as follows:
"If a data value to be encapsulated in an EXTERNAL type is an instance
of a single ASN.1 type encoded to the basic encoding rules for ASN.1
then the option "single-ASN1-type" shall be chosen as encoding."
We believe that this sentence is why the byte in note "4" should be
the value 0xA0 instead of 0x81. This seems to be self-explanatory.
However, to make sure that we are not taking this sentence out of
context or misinterpreting it, we have placed a call to the Upper
Layers chairman of NIST and are asking for a clarification.
Remember that NIST stable agreements are not binding which means that
the Computrol MMS is still within the guidelines for this encoding at
the current time. But also be advised that these stable agreements are
being moved into the upper layer agreements within the next year.
Responses: From Laura Emmons
(laurae@ar.telenex.com) May 10:
I took a look at Herb Falk's defect report and I don't think there is
any problem with any of the standards or our position on the use of
the EXTERNAL data type. His description of the encoding of the
encoding of his layer 6 header seems to be irrelevant. If the MMS-
InitiateRequest is a single ASN.1 element (I haven't seen this
protocol, but it seems that it is), then the data value of the
instance of the Association-information element should be encoded as a
single-ASN1-type. Therefore, in his pdu Note 4 should be an 0xA0.
Solution:
Status: OIW:
EWOS:
46
Document No.ULSIG-96-12/93
Date:February 10, 1994
AOW:
47
Document No.ULSIG-96-12/93
Date:February 10, 1994
(2) Summary: PGI PI issue from Japan
Source: Jun Yamaguchi
(junichi@vnet.ibm.com)
Date Raised: July 22, 1993
Issue: Copy of message follows:
I have a question about ISO 8327. I would like you to clarify an
interpretation of this standard.
Base standard states "PGI units and PI units within the same nesting
level shall be ordered in increasing value of their PGI and PI codes."
in the clause 8.2.6 of ISO 8327.
There are several interpretations for thsi statement:
1. PGI units shall be ordered in increasing value of their PGI codes.
PI units in the same PGI unit shall be ordered in increasing value of
their PI codes. PI units without PGI code have the same nesting level
with PGI units, and this kind of PI units and PGI units shall be
ordered in increasing value of their PGI and PI codes.
2. PGI units shall be ordered in increasing value of their PGI codes.
PI units in the same PGI unit shall be ordered in increasing value of
their PI codes. PI units without PGI code shall be ordered in
increasing value of their PI codes. There are no relationship between
PGI units and PI units about the order.
3. PGI units shall be ordered in increasing order of their PGI codes.
PI units in the same PGI unit shall be ordered in increasing value of
their PI codes. PI units without PGI code have no relationship with
other units. So, this kind of PI units may be placed in any position.
Which interpretation is correct, or all wrong?
Responses: From Bob Baker
(baker@uxdp5.Tredydev.Unisys.com) July 26:
I reviewed Jun Yamaguchi's session question which you forwarded to the
OIW members. We had the same question years ago when we were
implementing our Session layer, and I talked with Kim Banker at the
time. He was very helpful and we finished our implementation based on
his suggestions.
We believe interpretation #1 is the only correct interpretation of the
session specification. This interpretation is consistent with what Kim
told us and also with our implementation...Interpretations #2 and #3
48
Document No.ULSIG-96-12/93
Date:February 10, 1994
would permit any of the PI codes which have no PGI code to be present
after PGI 193 (User Data) in an SPDU. This is annoying at best, and
would probably cause many implementations severe problems.
From Andrew Chandler (a.chandler@xopen.co.uk) August 17
My interpretation is as follows (essentially this is interpretation 1
above):
PGI units shall be ordered in increasing value of their PGI codes.
PI units in the same PGI unit shall be ordered in increasing value of
their PI codes.
PGI units and PI units at the same level of nesting shall be ordered
in icreasing value of their PGI and PI codes.
Solution: Interpretation 1 is correct.
Status: OIW:Accepted 09/93
EWOS:
AOW:
49
Document No.ULSIG-96-12/93
Date:February 10, 1994
(3) Summary: Encoding FTAM single PDV list
Source: Kevin Bohan
(0004141431@mcimail.com)
Date Raised: July 29, 1993
Issue: Copy of message follows:
I have a question as to what is meant in section 8.5 of the NIST
Stable Agreements.
Proginet has an FTAM product that sends back an F-Begin-Group-
Response, F-Deselect-Response, F-Close-Response, F-End-Group-Response.
This is done using a single PDV list. We have encoded this PDV-List
using the single-ASN1-type. The remote site is kicking this out and
they claim that this is not valid.
Is this Valid?
Responses:
Solution:
Status: OIW:
EWOS:
AOW:
(4) Summary: Ed Kelley question on whether
FTAM can directly use
P-U-ABORT.
Source:
Date Raised:
Issue:
Responses:
Solution:
Status: OIW:
EWOS:
AOW:
50
Document No.ULSIG-96-12/93
Date:February 10, 1994
(5) Summary: new MMS issue on CUL for
Security
Source: MMS SIG
Date Raised: 16 September, 1993
Issue: Copy of liason:
The MMS SIG is investigating the use of various OSI protocols and
features for achieving different security requirements for MMS. With
further discussion with the Security SIG, it appears that concepts in
GULS are adequate for our needs. In particular, the use of the ACSE
Functional Unit for Authentication.
As it is likely, that all of the SIGs will need similar requirements
for upper layers, we are asking for you to investigate the common
needs and, if warrented, develop a version of the Common Upper Layer
Requirements that address security.
Responses:
Solution:
Status: OIW:
EWOS:
AOW:
51
Document No.ULSIG-96-12/93
Date:February 10, 1994
(6) Summary: Gary Williams issue on p-u-
abort on bad encoding.
Source:
Date Raised: 9 September 1993
Issue: The problem is that we
believe that there is a possible
contradiction between clause 7.9 of Draft Version 12 of pDISP 11188-1,
1993-01-22 (ISP:Common Upper Layer Requirements)
which states:
"If a received PPDU contains improperly encoded data values(including
data values embedded with the user data field of a PPDU) and if an
abort is issued, then either an ARU shall beissued."
and ISO 8823: 1988, clause's 6.4.4.2 and 6.4.4.3 which state
that the only response is a P-P-ABORT.
The information that we require is how to start the procedure to
address this issue, possibly obtain a contact name, or how to get in
touch with he/she in order to resolve the issue.
Responses: From Klaus Truoel
(truoel@gmd.de) Aug 8, 1993:
The current draft of Common Upper Layer Requirements is draft 14,
and it will hopefully get the approval as PDISP by the Regional
Workshops in Sept and Oct. Of course, after that approval it will
not be too late to fix bugs if there are any.
The clause which you are questionning is the same also in the latest
version. Actually, it is a clause which is in that document (and in
the European FTAM ENVs) since many years. It passed several ISO
ballots, reviews and discussions with ISO experts.
The reason behind that clause, as far as I can remember the history,
is the
often discussed problem, which OSI layer would be responsible to
detect
"improperly encoded data values". Is it the presentation layer or can
it
in many cases only be done by the application ? In the latter case,
the
application would initiate the Abort and that would result in an ARU.
This
is what the clause expresses.
52
Document No.ULSIG-96-12/93
Date:February 10, 1994
And, by the way, the clauses in ISO 8823 which you reference, specify
"if
possible". Sometimes it may not be possible if only the application
can
detect the bug.
As I myself am the editor of the PDISP, you may send all comments or
questions
to me. In case you are not satisfied with my above explanation and if
you want
to raise the issue to a broader audience for consideration, I am
prepared to
take the issue with me to the forthcoming OIW (beginning of Sept.) and
to EWOS
(Oct.).
Solution:
Status: OIW:
EWOS:
AOW:
53
Document No.ULSIG-96-12/93
Date:February 10, 1994
(7) Summary: X/Open ROSE PCI must be in
BER.
Source:
Date Raised:
Issue:
Responses:
Solution:
Status: OIW:
EWOS:
AOW:
54
