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