home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
05s_9403.txt
< prev
next >
Wrap
Text File
|
1994-05-22
|
106KB
|
3,631 lines
Stable Implementation
Agreements for Open Systems
Interconnection Protocols:
Part 5 - Upper Layers
Output from the March 1994 Open Systems Environment Implementors'
Workshop (OIW)
SIG Chair: James Quigley, Hewlett-Packard
SIG Editors: Debra Britt, NCTS Laura Emmons, Telenex
Part 5 - Upper Layers March 1994 (Stable)
Foreword
This part of the Stable Implementation Agreements was prepared by
the Upper Layers Special Interest Group (ULSIG) of the Open
Systems Environment Implementors' Workshop (OIW). The charter
for the OIW is located in Part 1 - Workshop Policies and
Procedures of the "Draft Working Implementation Agreements
Document."
The text in this part has been approved by the Plenary of the
OIW. This part replaces the previously existing part on the Upper
Layers.
Annex B is for information purposes only. Annex A forms an
integral part of these Implementor Agreements.
Future changes and additions to these Implementor Agreements will
be published as change pages. Deleted and replaced text will be
shown as struck. New and replacement text will be shown as
shaded.
ii
Part 5 - Upper Layers March 1994 (Stable)
Table of Contents
Part 5 - Upper Layers . . . . . . . . . . . . . . . . . . . . 1
0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative References . . . . . . . . . . . . . . . . . . 1
2.1 Session Layer . . . . . . . . . . . . . . . . . . . 1
2.2 Presentation Layer . . . . . . . . . . . . . . . . . 2
2.3 Application Layer . . . . . . . . . . . . . . . . . 3
2.4 Application Layer - ASE/ACSE . . . . . . . . . . . . 3
3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Technical Corriagenda and Defect Reports . . . . . . 4
4.2 Defect Registers . . . . . . . . . . . . . . . . . . 5
4.3 Exception Handling . . . . . . . . . . . . . . . . . 8
5 Association Control Service Element . . . . . . . . . . . 9
5.1 Introduction . . . . . . . . . . . . . . . . . . . . 9
5.2 Services . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Protocol Agreements . . . . . . . . . . . . . . . . 9
5.3.1 Application Context . . . . . . . . . . . . 9
5.3.2 AE Title . . . . . . . . . . . . . . . . . 9
5.3.3 Peer Entity Authentication . . . . . . . . 10
5.4 ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 10
5.5 Connectionless . . . . . . . . . . . . . . . . . . . 10
6 ROSE . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7 RTSE . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8 Presentation . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Introduction . . . . . . . . . . . . . . . . . . . . 11
8.2 Service . . . . . . . . . . . . . . . . . . . . . . 11
8.3 Protocol Agreements . . . . . . . . . . . . . . . . 12
8.3.1 Transfer Syntaxes . . . . . . . . . . . . . 12
8.3.2 Presentation Context Identifier . . . . . . 12
8.3.3 Default Context . . . . . . . . . . . . . . 12
8.3.4 P-Selectors . . . . . . . . . . . . . . . . 12
8.3.5 Provider Abort Parameters . . . . . . . . . 13
8.3.6 Provider Aborts and Session Version . . . . 13
8.3.7 CPC-Type . . . . . . . . . . . . . . . . . 14
8.3.8 Presentation-context-definition-result-list 14
8.3.9 RS-PPDU . . . . . . . . . . . . . . . . . . 14
iii
Part 5 - Upper Layers March 1994 (Stable)
8.4 Presentation ASN.1 Encoding Rules . . . . . . . . . 15
8.5 Presentation Data Value (PDV) . . . . . . . . . . . 15
8.6 Connection Oriented . . . . . . . . . . . . . . . . 15
8.7 Connectionless . . . . . . . . . . . . . . . . . . . 16
9 Session . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Introduction . . . . . . . . . . . . . . . . . . . . 16
9.2 Services . . . . . . . . . . . . . . . . . . . . . . 16
9.3 Protocol Agreements . . . . . . . . . . . . . . . . 17
9.3.1 Concatenation . . . . . . . . . . . . . . . 17
9.3.2 Segmenting . . . . . . . . . . . . . . . . 17
9.3.3 Reuse of Transport Connection . . . . . . . 17
9.3.4 Use of Transport Expedited Data . . . . . . 17
9.3.5 Use of Session Version Number . . . . . . . 17
9.3.5.1 Selection of session version . . . . . . . 17
9.3.5.2 User data in session version 2 . . . . . . 18
9.3.6 Receipt of Invalid SPDUs . . . . . . . . . 19
9.3.7 Invalid SPM Intersections . . . . . . . . . 19
9.3.8 S-Selectors . . . . . . . . . . . . . . . . 19
9.4 Connectionless . . . . . . . . . . . . . . . . . . . 22
10 UNIVERSAL ASN.1 ENCODING RULES . . . . . . . . . . . . . 22
10.1 TAGS . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 Definite Length . . . . . . . . . . . . . . . . . . 22
10.3 External . . . . . . . . . . . . . . . . . . . . . . 22
10.4 Integer . . . . . . . . . . . . . . . . . . . . . . 23
10.5 String Types . . . . . . . . . . . . . . . . . . . . 23
10.6 Extensibility . . . . . . . . . . . . . . . . . . . 23
11 Additions to ISP on Common Upper Layer Requirements . . . 24
11.1 Service . . . . . . . . . . . . . . . . . . . . . . 24
11.2 Provider Abort Parameters . . . . . . . . . . . . . 24
11.3 Concatenation . . . . . . . . . . . . . . . . . . . 24
11.4 Segmenting . . . . . . . . . . . . . . . . . . . . . 24
11.5 Reuse of Transport Connection . . . . . . . . . . . 24
11.6 Use of Transport Expedited Data . . . . . . . . . . 25
12 Character Sets . . . . . . . . . . . . . . . . . . . . . 25
13 Conformance . . . . . . . . . . . . . . . . . . . . . . . 25
14 Specific ASE Requirements . . . . . . . . . . . . . . . . 25
14.1 FTAM Phase 2 . . . . . . . . . . . . . . . . . . . . 25
14.1.1 ACSE Requirements . . . . . . . . . . . . . 25
14.1.2 Presentation Requirements . . . . . . . . . 26
14.1.3 Session Requirements . . . . . . . . . . . 27
14.1.4 Session Options . . . . . . . . . . . . . . 27
14.1.5 ASN.1 Encoding Requirements . . . . . . . . 28
14.2 MHS . . . . . . . . . . . . . . . . . . . . . . . . 28
14.2.1 Phase 1 (1984 X.400) Session Requirements . 28
iv
Part 5 - Upper Layers March 1994 (Stable)
14.2.2 Phase 2, Protocol P1 (1988 X.400) . . . . . 28
14.2.2.1
ROSE Requirements . . . . . . . . . . . . . 28
14.2.2.2
RTSE Requirements . . . . . . . . . . . . . 29
14.2.2.3
ACSE Requirements . . . . . . . . . . . . . 29
14.2.2.4
Presentation Requirements . . . . . . . . . 30
14.2.2.5
Session Requirements . . . . . . . . . . . 30
14.2.3 Phase 2, Protocol P7 (1988 X.400) . . . . . 30
14.2.3.1
ROSE Requirements . . . . . . . . . . . . . 30
14.2.3.2
RTSE Requirements . . . . . . . . . . . . . 30
14.2.3.3
ACSE Requirements . . . . . . . . . . . . . 31
14.2.3.4
Presentation Requirements . . . . . . . . . 31
14.2.3.5
Session Requirements . . . . . . . . . . . 32
14.2.4 Phase 2, Protocol P3 (1988 X.400) . . . . . 33
14.2.4.1
ROSE Requirements . . . . . . . . . . . . . 33
14.2.4.2
RTSE Requirements . . . . . . . . . . . . . 33
14.2.4.3
ACSE Requirements . . . . . . . . . . . . . 33
14.2.4.4
Presentation Requirements . . . . . . . . . 33
14.2.4.5
Session Requirements . . . . . . . . . . . 33
14.3 DS Phase 1 . . . . . . . . . . . . . . . . . . . . . 33
14.3.1 ACSE Requirements . . . . . . . . . . . . . 33
14.3.2 Presentation Requirements . . . . . . . . . 34
14.3.3 Session Requirements . . . . . . . . . . . 34
14.4 Virtual Terminal . . . . . . . . . . . . . . . . . . 34
14.4.1 Phase 1a . . . . . . . . . . . . . . . . . 34
14.4.1.1
ACSE Requirements . . . . . . . . . . . . . 34
14.4.1.2
Presentation Requirements . . . . . . . . . 35
14.4.1.3
Session Requirements . . . . . . . . . . . 35
14.4.2 Phase 1b . . . . . . . . . . . . . . . . . 36
14.4.2.1
ACSE Requirements . . . . . . . . . . . . . 36
14.4.2.2
Presentation Requirements . . . . . . . . . 36
v
Part 5 - Upper Layers March 1994 (Stable)
14.4.2.3
Session Requirements . . . . . . . . . . . 36
14.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . 37
14.5.1 ACSE Requirements . . . . . . . . . . . . . 37
14.5.2 Constructed Encodings . . . . . . . . . . . 37
14.5.3 Presentation Requirements . . . . . . . . . 37
14.5.4 Session Requirements . . . . . . . . . . . 38
14.6 Transaction Processing . . . . . . . . . . . . . . . 38
14.6.1 ACSE Requirements . . . . . . . . . . . . . 38
14.6.2 Presentation Requirements . . . . . . . . . 38
14.6.3 Session Requirements . . . . . . . . . . . 39
14.7 Network Management . . . . . . . . . . . . . . . . . 39
14.7.1 ROSE Requirements . . . . . . . . . . . . . 39
14.7.2 ACSE Requirements . . . . . . . . . . . . . 39
14.7.3 Presentation Requirements . . . . . . . . . 39
14.7.4 Session Requirements . . . . . . . . . . . 40
14.8 Remote Database Access . . . . . . . . . . . . . . . 40
14.8.1 ACSE Requirements . . . . . . . . . . . . . 40
14.8.2 Presentation Requirements . . . . . . . . . 40
14.8.2.1
Presentation Contexts for the RDA Basic
Application Context . . . . . . . . . . . . 40
14.8.2.2
Presentation Contexts for the RDA TP
Application Context . . . . . . . . . . . . 41
14.8.3 Session Requirements . . . . . . . . . . . 41
Annex A (normative)
Object Identifier Register . . . . . . . . . . . . . . . . . 43
A.1 Register Index . . . . . . . . . . . . . . . . . . . 43
A.2 Object Identifier Descriptions . . . . . . . . . . . 43
Annex B (informative)
Recommended Practices . . . . . . . . . . . . . . . . . . . . 45
vi
Part 5 - Upper Layers March 1994 (Stable)
List of Tables
Table ISO Defect Reports . . . . . . . . . . . . . . . . . . 6
Table 1 - Called and Responding P-Selectors . . . . . . . . . 13
Table 2 - Called and Responding S-Selectors . . . . . . . . . 21
Table 3 - Calling S-Selectors . . . . . . . . . . . . . . . . 21
Table A.1 - Session States . . . . . . . . . . . . . . . . . 46
Table A.2 - Incoming Events . . . . . . . . . . . . . . . . . 47
vii
Part 5 - Upper Layers
0 Introduction
In this portion of the Implementors' Agreements, the Upper
Layers SIG is primarily concerned with providing implementation
agreements for ACSE, ROSE, RTSE, and the Presentation and Session
layers, so that systems implemented according to these agreements
can successfully interoperate.
1 Scope
The agreements in this part apply to all ASE agreements in this
document.
A referencing specification may use the requirements in this part
in one of the following ways:
a) The referencing specification does not duplicate any of the
requirements of this part of the document within its own
specifications and instead requires an implementation to conform
to the requirements of this part. This is the preferred method.
b) The referencing specification duplicates all of the
requirements of this part of the document as part of its
requirements and related conformance statements.
Each ASE SIG supplements the common requirements in this part of
the document by a statement in the "Specific ASE Requirements"
clause of this part which outlines the ASE's specific
requirements for the use of the ACSE, presentation and session
protocol standards.
2 Normative References
2.1 Session Layer
[1] ISO 8326: 1987 (E), Information Processing Systems - Open
Systems Interconnection - Basic Connection Oriented Session
Service Definition.
[2] ISO 8327: 1987 (E), Information Processing Systems - Open
Systems Interconnection - Basic Connection Oriented Session
Protocol Specification.
[3] ISO/IEC JTC1/SC21 N2494, Information Processing Systems -
Open Systems Interconnection - Basic Connection Oriented
Session Service Definition-AD 2 to ISO 8326 to Incorporate
Unlimited User Data.
1
Part 5 - Upper Layers March 1994 (Stable)
[4] ISO/IEC JTC1/SC21 N2495, Information Processing Systems -
Open Systems Interconnection - Basic Connection Oriented
Session Protocol Specification - AD 2 to ISO 8327 to
Incorporate Unlimited User Data.
[5] ISO/AD3 8326, Information Processing Systems - Open Systems
Interconnection-Session Service Definition: Addendum 3
Covering Connectionless-Mode Session Service.
[6] ISO/IS 9548, Information Processing Systems - Open Systems
Interconnection-Connectionless Session Protocol to Provide
the Connectionless-Mode Session Service.
2.2 Presentation Layer
[7] ISO 8822: 1988 (ISO/IEC JTC1/SC21 N2335), Information
Processing Systems - Open Systems Interconnection -
Connection-Oriented Presentation Service Definition.
[8] ISO 8823: 1988 (ISO/IEC JTC1/SC21 N2336), Information
Processing Systems - Open Systems Interconnection -
Connection Oriented Presentation Protocol Specification.
[9] ISO 8824: 1990 (E), Information Processing Systems - Open
Systems Interconnection - Specification of Abstract Syntax
Notation One (ASN.1).
[10] ISO 8825: 1990 (E), Information Processing Systems - Open
Systems Interconnection - Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1).
[11] ISO/DAD1 8822: 1989-02-15(e) (ISO/IEC JTC1/SC21 N 3171),
Information Processing Systems - Open Systems
Interconnection - Presentation Service Definition: Draft
Addendum 1 Covering Connectionless-Mode Presentation
Service.
[12] ISO/IS 9576: 1989-02-25 5(E) (ISO/IEC JTC1/SC21 N 3172),
Information Processing Systems - Open Systems
Interconnection - Connectionless Presentation Protocol to
Provide the Connectionless-Mode Presentation Service.
2
Part 5 - Upper Layers March 1994 (Stable)
2.3 Application Layer
[13] ISO/DP 9545, ISO/TC97/SC21/N1743, July 24, 1987, revised
November 1987, Information Processing Systems - Open Systems
Interconnection - Application Layer Structure.
2.4 Application Layer - ASE/ACSE
[14] ISO 8649: 1987 (E) (ISO/IEC JTC1/SC21 N2326), Information
Processing Systems - Open Systems Interconnection - Service
Definition for the Association Control Service Element.
[15] ISO 8650: 1987 (E) (ISO/IEC JTC1/SC21 N2327), Information
Processing Systems - Open Systems Interconnection - Protocol
Specification for the Association Control Service Element.
[16] ISO 8649/DAD2, Information Processing System - Open Systems
Interconnection - ACSE Service Definition: Draft Addendum 2
Covering Connectionless-Mode ACSE Service.
[17] ISO 8649/DAD1 (ISO/IEC JTC1/SC21 N3771), Information
Processing Systems - Open Systems Interconnection - Service
Definition for the Association Control Service Element -
Addendum 1: Peer-Entity Authentication During Association
Establishment
[18] ISO 8650/DAD1 (ISO/IEC JTC1/SC21 N3772), Information
Processing Systems - Open Systems Interconnection - Protocol
Specification for the Association Control Service Element -
Addendum 1: Peer-Entity Authentication During Association
Establishment
[19] ISO 8649/Cor.1: 1991 (E) (ISO/IEC JTC1/SC21 N5630),
Information Processing Systems - Open Systems
Interconnection - Technical Corrigendum 1 to ACSE Service
(ISO 8649: 1988) Covering Defects 8649/001, 8649/002 and
8649/003.
[20] ISO 8650/Cor.1: 1991 (E) (ISO/IEC JTC1/SC21 N5631),
Information Processing Systems - Open Systems
Interconnection - Technical Corrigendum 1 to ACSE Protocol
(ISO 8650: 1988) Covering Defects 8650/001, 8649/004.
[21] ISO IS 10035: 1989-02-25 (ISO/IEC JTC1/SC21 N 3456),
Information Processing Systems - Open Systems
Interconnection - Connectionless ACSE Protocol to Provide
the Connectionless-Mode ACSE Service.
3
Part 5 - Upper Layers March 1994 (Stable)
3 Status
This text is stable.
NOTE - Changes due to errata are summarized in clause 4
4 Errata
In accordance with FIPS 146-1, with specific exceptions as noted
below, this edition of the Part 5 - Stable Implementation
Agreements remains backwardly compatible with Part 5 - Stable
Implementation Agreements, Version 3, Edition 1. The method for
assuring continued interoperability when these specific
exceptions occur is detailed below and has been approved by the
plenary of the OIW. Therefore, this edition of Part 5 - Stable
Implementation Agreements supersedes all previous versions and
editions of the Part 5 - Stable Implementation Agreements.
4.1 Technical Corriagenda and Defect Reports
An existing ISO base standard (e.g., ISO 8649 -- ACSE service)
may be modified by an approved/registered Technical Corriagenda
(TC) that fixes problems as reported in one or more Defect
Reports (DR).
An error or request for clarification concerning a base standard
is brought to the attention of ISO by a Defect Report. Defect
Reports may be submitted to ISO by the OIW or by national bodies
such as ANSI X3T5 task group in the USA.
A Defect Report is processed by the Defect Editing Group of the
base standard as part of the ISO "Rapid Amendment Process." If
the Defect Editing Group agrees that the Defect Report concerns
an error in the base standard, the Defect Editing Group prepares
a fix to the error in the form of a Draft Technical Corrigenda
(DTC). A DTC is not used to add new or revised facility to the
base standard. The purpose of the DTC is to rectify
inconsistencies and or mechanisms that do not provide the defined
facility.
NOTE - The amendment procedure is not used to add facility
to a base standard.
A DTC undergoes a 3-month draft ballot by national bodies. An
editing meeting may be necessary to resolve national body
comments.
4
Part 5 - Upper Layers March 1994 (Stable)
An accepted/registered DTC becomes a TC. A TC immediately
becomes a part of the base standard that it references. For a
referencing standard or profile, the modification by a TC or an
errata immediately takes effect unless it applies to an option
that is "out-of-scope" or prohibited by the referencing standard
or profile.
A TC may impact the interoperability of a base standard. In some
cases, recertification may be necessary.
4.2 Defect Registers
5
Part 5 - Upper Layers March 1994 (Stable)
Table ISO Defect Reports
+--------+------+-------+---------+--------+---------------------
---+--------+------+-----+----------------+
|Defect |Source|Circ. |Distr. as|Resp to |Returned to Editor
for -|Ballot |Voting|Final|Remarks |
| | | | |
+----+----+------+-------+ | | | |
| | |by Sec.| WG doc. |Sec. by
|info|actn|DTC/49|DTC/50 |ends |Sum'ry|text | |
+--------+------+-------+---------+--------+----+----+------+----
---+--------+------+-----+----------------+
|8649/001|Editor|88-12 |-- |89-11 |-- |-- |N4447 |--
|90-05-15|N4687 |N5630|Closed: Part of |
| | | | | | | | |
| | | |8649/TC1 |
|8649/002|Editor|89-11 |-- |89-11 |-- |-- |N4448 |--
|90-05-15|N4688 |N5630|Closed: Part of |
| | | | | | | | |
| | | |8649/TC1 |
| | | | | | | | |
| | | | |
|8649/003|Editor|89-11 |-- |89-11 |-- |-- |N4449 |--
|90-05-15|N4689 |N5630|Closed: Part of |
| | | | | | | | |
| | | |8649/TC1 |
| | | | | | | | |
| | | | |
|8649/004|Editor|90-02 |N765 |90-05-30|-- |yes |tbd |tbd
|tbd |tbd |tbd |Open: ULA advice|
| | | | | | | | |
| | | |- wait for XALS |
| | | | | | | | |
| | | |developments |
| | | | | | | | |
| | | | |
|8649/005|-- | | | | | | |
| | | |Number not used |
| | | | | | | | |
| | | | |
|8649/006|Japan |90-03 |N782 |90-06 |-- |-- |N5320 |--
|91-01 |N5690 |-- |Referred back to|
| | | | | | | | |
| | | |WG6 ULA group; |
| | | | | | | | |
| | | |response Nxxxx |
| | | | | | | |N6336
|N6336 |91-12-10|N6627 |-- |AFNOR: no vote |
| | | | | | | |tbd |tbd
|tbd |tbd |tbd |Revised DTC due |
| | | | | | | | |
6
Part 5 - Upper Layers March 1994 (Stable)
| | | |from Editor |
| | | | | | | | |
| | | | |
|8649/007|CCITT |90-12 |N962 |91-03-25|-- |-- | |
| |N6628 |Ed 2 |Closed: DTC text|
| | | | | | | | |
| | | |unchanged; add |
| | | | | | | | |
| | | |to Edition 2 |
| | | | | | | | |
| | | | |
|8650/001|Editor|88-08 |N533 |89-11 |-- |-- |--
|N3473 |89-08 |N3862 |N4286|Closed: Part of |
| | | | | | | | |
| | | |8650/TC1 |
| | | | | | | | |
| | | | |
|8650/002|Editor|88-08 |N534 |89-11 |N653|-- |-- |--
|-- |-- |-- |Closed: Not |
| | | | | | | | |
| | | |recommended for |
| | | | | | | | |
| | | |progression |
| | | | | | | | |
| | | | |
|8650/003|Japan |88-10 |N573 |89-01 |N654|-- |-- |--
|-- |-- |-- |Closed:Editorial|
| | | | | | | | |
| | | |change already |
| | | | | | | | |
| | | |in IS text |
| | | | | | | | |
| | | | |
|8650/004|Editor|88-12 |-- |88-12 |-- |-- |--
|N3475 |89-08 |N4286 |N4286|Closed: Part of |
| | | | | | | | |
| | | |8650/TC1 |
| | | | | | | | |
| | | | |
|8650/005|-- | | | | | | |
| | | |Number not used |
| | | | | | | | |
| | | | |
|8650/006|CCITT |90-10 |N915 |91-01-11|tbd |-- |-- |--
|-- |-- |-- |Closed: Not |
| | | | | | | | |
| | | |recommended for |
| | | | | | | | |
| | | |progression |
| | | | | | | | |
7
Part 5 - Upper Layers March 1994 (Stable)
| | | | |
|8650/007|CCITT |90-10 |N916 |91-01-11|-- |-- |--
|N6338 |91-12-10|N6629 |Ed 2 |Closed: Add to |
| | | | | | | | |
| | | |Edition 2 of |
| | | | | | | | |
| | | |8650 |
| | | | | | | | |
| | | | |
|8650/008|Editor|90-06 |-- |90-06 |N911|-- |-- |--
|-- |-- |-- |Closed: Response|
| | | | | | | | |
| | | |only - did not |
| | | | | | | | |
| | | |change text |
| | | | | | | | |
| | | | |
|8650/009|Editor|93-?? |N??? |93-03 |-- |-- |--
|Nxxxx |93-12 |tbd |tbd |Open: under |
| | | | | | | | |
| | | |discussion |
| | | | | | | | |
| | | |preparing for |
| | | | | | | | |
| | | |DTC text |
| | | | | | | | |
| | | | |
+--------+------+-------+---------+--------+----+----+------+----
---+--------+------+-----+----------------+
4.3 Exception Handling
For those cases where backwards compatibility cannot be assured
due to a Technical Corrigenda (see clause 4.6), interoperability
will be maintained by requiring existing implementations to
incorporate the change within 12 months after it has been
registered as a Technical Corriagenda. The registration
authority for conformance testing will determine in each case
whether or not recertification is necessary.
8
Part 5 - Upper Layers March 1994 (Stable)
5 Association Control Service Element
5.1 Introduction
This clause details the implementation requirements for the
Association Control Service Element (ACSE) of the Application
layer as defined in ISO 8649 and ISO 8650.
5.2 Services
All ACSE services are within the possible scope of a workshop-
conformant system.
5.3 Protocol Agreements
5.3.1 Application Context
Values for and uses of Application Context names are determined
by specific ASEs. Values used by ASE SIGS are listed in the
clause entitled "Specific ASE Requirements."
5.3.2 AE Title
Support of AE-Title-form1, the Name form, or AE-Title-form2, the
Object Identifier form for sending, is dependent on the
referencing specification.
NOTE - AE_Title-form1 is a directory name that has to be
allocated by an authorized naming authority. It is part of
the responsibilities of the naming authority to determine
how this name is built from its two constituents, AP-Title-
form1 and AE-Qualifier-form1.
NOTE - AE-Title-form2 is an Object Identifier registered by
an authorized Registration Authority. It is part of that
registration to determine how this Object Identifier is
built from its two constituents, AP-Title-form2 and AE-
Qualifier-form2.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 6.1.
9
Part 5 - Upper Layers March 1994 (Stable)
5.3.3 Peer Entity Authentication
If supported, peer-entity authentication during association
establishment shall be implemented as specified in Addendum 1 to
ISO 8650 (ISO 8650/DAD1).
5.4 ASN.1 Encoding Rules
When the Abort APDU is used during the association establishment
phase, the Presentation layer negotiation is considered complete.
Therefore, a PDV-list presentation-context-identifier has been
assigned to the association and it should be used in the
indirect-reference component of the Association Information
parameter. The direct-reference component shall not be present.
NOTE - The presentation context negotiation is completed by
the presentation context identifier list of the ARU PPDU.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 6.2.
5.5 Connectionless
The connectionless ACSE protocol shall be implemented as
specified in ISO IS 10035.
No further agreements beyond those specified elsewhere in this
part have been made regarding this standard.
6 ROSE
ROSE shall be implemented as specified in ISO DIS 9072-1.2 and
ISO DIS 9072-2.2.
No further agreements beyond those specified elsewhere in this
part have been made regarding this standard.
10
Part 5 - Upper Layers March 1994 (Stable)
7 RTSE
RTSE shall be implemented as specified in ISO 9066-1 and ISO
9066-2.
No further agreements beyond those specified elsewhere in this
part have been made regarding this standard.
NOTE - "If checkpointing is not used, the VALUE of
windowsize is not meaningful and shall be ignored."
8 Presentation
8.1 Introduction
This clause details the implementation requirements for the
Presentation layer as defined in the Presentation Service
Definition, ISO 8822, and the Presentation Protocol Definition,
ISO 8823.
The task of the Presentation layer is to carry out the
negotiation of transfer syntaxes and to provide for the
transformation to and from transfer syntaxes. The transformation
to and from a particular transfer syntax is a local
implementation issue and is not discussed within this clause.
This clause is concerned with the protocol agreements, and thus
is entirely devoted to the issues involved with the negotiation
of transfer syntaxes and the responsibilities of the Presentation
protocol.
NOTE - The complete size of encoding of the CP PPDU, CPA
PPDU, and CPR PPDU is derived from the SS user-data size
restricted to 10 K such as specified in 9.3.5. This
limitation applies also to the ARP and ARU PPDUs.
8.2 Service
(Refer to clause 11.1)
11
Part 5 - Upper Layers March 1994 (Stable)
8.3 Protocol Agreements
8.3.1 Transfer Syntaxes
The following transfer syntax must be supported for all mandatory
abstract syntaxes; the basic encoding rules for ASN.1. This
syntax is derived by applying the basic encoding rules for ASN.1
to the abstract syntax (see the Basic Encoding Rules for ASN.1,
ISO 8825).
The number of transfer syntaxes proposed is dependent upon the
recognized transfer syntaxes which are available to support the
particular abstract syntaxes used by an Application Entity.
8.3.2 Presentation Context Identifier
A conformant implementation shall not encode Presentation context
identifiers outside the range of 0 to 32,767.
Implementations must be able to handle a minimum of two
Presentation contexts per connection.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.1.
8.3.3 Default Context
If the Presentation expedited data service is required, the
default context must be explicitly present in the P-CONNECT PPDU
at Presentation connect time.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.6.
8.3.4 P-Selectors
Local P-selectors shall be a maximum of four octets. This applies
only to P-selectors in PPDUs whose receipt by a workshop-
conformant system normally results in either a P-CONNECT
indication or a P-CONNECT confirmation being issued.
If the Responding P-Selector of the CPA-PPDU is not present, it
12
Part 5 - Upper Layers March 1994 (Stable)
is assumed to have a value equivalent to that of the Called P-
Selector of the CP-PPDU. Table 1 summarizes the handling of the
Responding-presentation selector parameters of the CP-PPDU and
CPA-PPDUs.
Table 1 - Called and Responding P-Selectors
Responding P-Sel of CPA-
PPDU
Not
present Length= Length>0
0
Not Note 1 Note 1 Note 2
Called P-Sel present
of CP-PPDU Length=0 Note 1 Note 1 Note 2
Length>0 Note 3 Note 3 Note 2
Note 1 - The resulting value is assumed to be a null
value.
Note 2 - The resulting value is assumed to be the
Responding P-Sel value.
Note 3 - The resulting value is assumed to be the Called
P-Sel value of the CP-PPDU.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.2.
8.3.5 Provider Abort Parameters
(Refer to clause 11.2)
8.3.6 Provider Aborts and Session Version
The Presentation Provider Abort PPDU (ARP-PPDU) shall be present
regardless of the Session version in effect for a given
association. This precludes the use of indefinite length encoding
of an ARP-PPDU when Session Version 1 is in effect.
13
Part 5 - Upper Layers March 1994 (Stable)
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.7.
8.3.7 CPC-Type
Implementations shall not use any CPC-type values in the SS-user
data parameter of the S-CONNECT unless more than one transfer
syntax is proposed for a single Presentation context of the
Presentation data values. Each CPC-type represents a unique
transfer syntax, so if more than one transfer syntax is proposed,
CPC-type values may appear in that SS-user data parameter.
For a Presentation context for which the Basic encoding Rules are
a proposed transfer syntax, all PDVs in the user data parameter
of the CP PPDU must be encoded first using the Basic Encoding
Rules and must be examined by the receiving Presentation protocol
machine. Following CPC-type values may be examined or ignored at
the receiver's option see ISO 8823, clause 6.2.5.3).
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.3.
8.3.8 Presentation-context-definition-result-list
No semantics are implied by the absence of the optional
Presentation-context-definition-result-list component of the CPR-
PPDU. This component is required if the Provider-reason is absent
in the CPR-PPDU. If the Provider-reason is present, then the
Presentation-context-definition-result-list is optional.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.5.
8.3.9 RS-PPDU
The Presentation-context-identifier-list shall not be present
when only the kernel functional unit is in effect.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.8.
14
Part 5 - Upper Layers March 1994 (Stable)
8.4 Presentation ASN.1 Encoding Rules
If a received PPDU contains any improperly encoded data values
(including data values embedded within the User data field of a
PPDU) and an abort is issued, then either an ARU or an ARP PPDU
shall be issued.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.9.
8.5 Presentation Data Value (PDV)
A Presentation data value (PDV) is a value of a type in an
abstract syntax, e.g., a value of an ASN.1 type.
A PDV may contain embedded PDVs in different contexts. A change
of context within a PDV is indicated by an EXTERNAL. EXTERNAL
implies an embedded PDV.
A PDV cannot be split across PDV-lists in fully-encoded user
data.
Fully-encoded-data that is a series of PDVs in the same
Presentation context (e.g., grouped FTAM PDUs) shall be encoded
either as a single PDV-list (using the octet-aligned choice) or
as a series of PDV-lists, each encoding either a single PDV
(using the single-ASN1-type choice) or multiple PDVs (using the
octet-aligned choice). Note that receivers must accept any of the
above encodings.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1
7.10.
8.6 Connection Oriented
The Transfer-syntax-name component of a PDV-list value shall be
present in a CP PPDU if and only if more than one transfer syntax
name was proposed for the Presentation context of the
Presentation data values. The Transfer-syntax-name component of a
PDV-list value shall always be present in a CPC-type. If only the
Kernel functional unit is negotiated, then the Transfer-syntax-
name component of a PDV-list value shall only appear in the CP
PPDU and CPC-type.
Editor's Note - This clause is technically equivalent to the
15
Part 5 - Upper Layers March 1994 (Stable)
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 7.3.
8.7 Connectionless
The connectionless Presentation protocol shall be implemented as
specified in ISO 9576.
The Transfer-syntax-name component of a PDV-list value shall be
present in a UD PPDU if and only if more than one transfer syntax
name was proposed for the Presentation context of the
Presentation data values. The Transfer-syntax-name component of a
PDV-list value shall always be present in a UDC-type. The
Transfer-syntax-name component of a PDV-list value shall only
appear in the UD PPDU and UDC-type.
No further agreements beyond those specified elsewhere in this
part have been made regarding this standard.
9 Session
9.1 Introduction
This clause details the implementation requirements for the
Session layer as defined in the Session Service Definition, ISO
8326 and the Session Protocol Definition, ISO 8327.
9.2 Services
The following functional units are within the scope of a
workshop-conformant system:
a) Kernel;
b) Duplex;
c) Expedited Data;
d) Resynchronize;
e) Exceptions;
f) Activity Management;
g) Half-duplex;
16
Part 5 - Upper Layers March 1994 (Stable)
h) Minor Synchronize;
i) Major Synchronize;
j) Typed Data;
k) Data Separation.
9.3 Protocol Agreements
9.3.1 Concatenation
(Refer to clause 11.3)
9.3.2 Segmenting
(Refer to clause 11.4)
9.3.3 Reuse of Transport Connection
(Refer to clause 11.5)
9.3.4 Use of Transport Expedited Data
(Refer to clause 11.6)
9.3.5 Use of Session Version Number
9.3.5.1 Selection of session version
Session versions 1 and 2 are recognized. The referencing
specification shall specify in its specific upper layer
requirements section which version of session is required.
17
Part 5 - Upper Layers March 1994 (Stable)
NOTE - Session version 2 specifies the use of unlimited user
data as dictated by Addendum 2 to ISO 8327. All session
version 1 implementations must be able to negotiate version
1 operation when responding to a CN SPDU proposing both
version 1 and version 2.
At least session version 2 shall be proposed with ACSE normal
mode. With ACSE normal mode, a receiver shall support session
version 2, but may reject a proposal requesting only session
version 1.
NOTE - Between two conformant implementations supporting
ACSE normal mode, session version 2 will be used.
All session version 1 implementations, upon receipt of a CN SPDU
proposing only version 2, should respond with an RF SPDU
containing a reason code indicating that the proposed version is
not supported.
If session version 1 and 2 are both proposed in the CN SPDU, then
the maximum length if the user data parameter in the CN SPDU
shall be 512 octets.
NOTE - In that case a PGI field of 193 will be associated
with this parameter. This implies that an implementation
supporting both session version 1 and 2 can establish a
connection with an implementation supporting only version 1.
9.3.5.2 User data in session version 2
If only session version 2 is proposed in the CN SPDU, then a size
larger than 10,240 octets of the session user data parameter
value of the S-CONNECT request primitive is out of scope. This
implies that sending the OA and CDO SPDUs is out of scope.
Receiving the OA and CDO SPDUs is mandatory but storing and using
them is out of scope. If a CDO SPDU is received but not stored or
used, an RF SPDU should be issued by the responder. If an OA SPDU
is received but not stored or used, a P-Abort SPDU should be
issued by the initiator.
NOTE - If the length of the user data parameter value is not
greater than 512 octets, then an associated PGI field of 193
is used. Otherwise, a PGI field of 194 is used.
When session version 2 is negotiated, then in all subsequent
SPDUs a data length exceeding 10,240 octets of the user data
parameter value with an associated PGI field of 193, reason code
parameter value (PI = 50) for RF SPDU and user data parameter
18
Part 5 - Upper Layers March 1994 (Stable)
value (PI = 46) for MIA SPDU is out of scope.
Session version 2 implementations need only support the maximum
data lengths specified in the specific upper layer requirements
section of the referencing specification, which may be less than
10,240 octets.
NOTE - For session expedited data the limit for user data is
14 octets.
NOTE - These agreements impose no limitation on the size of
the user information parameter of DT, TD, and CD SPDUs.
Therefore, the user data of P-DATA, P-TYPED-DATA, and P-
CAPABILITY-DATA is unconstrained.
9.3.6 Receipt of Invalid SPDUs
Upon receipt of an invalid SPDU, the SPM shall take any action in
A.4.3 of the Session Protocol Definition ISO/IS 8327 except
Action d.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 9.1.
9.3.7 Invalid SPM Intersections
If the conditions described in A.4.1.2 of the Session Protocol
Definition ISO/IS 8327 are satisfied, the SPM shall always take
the actions described by A.4.1.2 a.
This implies that no S-P-EXCEPTION-REPORT indications will be
generated nor EXCEPTION REPORT SPDUs sent due to invalid
intersections of the Session state table resulting from received
SPDUs.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1 9.4.
9.3.8 S-Selectors
The absence of the Called or Calling S-Sel parameter of the CN
SPDU shall be treated equivalent to a zero length Called or
Calling S-Sel parameter value.
The absence of the Responding S-Sel parameter of the AC SPDU
19
Part 5 - Upper Layers March 1994 (Stable)
shall be treated as though its value were equivalent to that of
the Called S-Sel parameter of the CN SPDU, i.e., the Responding
S-Sel is zero length if the Called S-Sel is either absent or zero
length. The Responding S-Sel parameter's value is equal to that
of the Called S-Sel parameter's value if it is absent and the
Called S-Sel parameter's value is greater than zero.
The Responder may change the value of the Called S-Sel parameter
value of the CN SPDU by responding with the Responding S-Sel
value of the AC SPDU.
The absence of the Calling S-Sel parameter of the AC SPDU
indicates that its value is assumed to be equivalent to the value
of the Calling S-Sel parameter of the CN SPDU.
Tables 2 and 3 summarize the handling of the Session Selector
parameters of the CN and AC SPDUs (see also ISO 8327 8.3.1.12,
8.3.1.14, 8.3.2.14, 8.3.2.15).
20
Part 5 - Upper Layers March 1994 (Stable)
Table 2 - Called and Responding S-Selectors
Responding S-Sel of AC SPDU
Not
present Length= Length>0
0
Not Note 1 Note 1 Note 2
Called S-Sel present
of CN SPDU Length=0 Note 1 Note 1 Note 2
Length>0 Note 3 Note 3 Note 2
Note 1 - The resulting value is assumed to be a null
value.
Note 2 - The resulting value is assumed to be the
Responding S-Sel value.
Note 3 - The resulting value is assumed to be the Called
S-Sel value of the CN SPDU.
Table 3 - Calling S-Selectors
Calling S-Sel of AC SPDU
Not
present Length= Length>0
0
Not Note 4 Note 4 Invalid
Calling S-Sel present
of CN SPDU
Length=0 Note 4 Note 4 Invalid
Length>0 Note 5 Note 6
Invalid
Note 4 - The calling S-Sel has a null value.
Note 5 - The calling S-Sel has the value as indicated in
the CN SPDU.
Note 6 - Valid if and only if both values are identical.
21
Part 5 - Upper Layers March 1994 (Stable)
9.4 Connectionless
The connectionless Session protocol shall be implemented as
specified in ISO 9548.
No further agreements beyond those specified elsewhere in this
part have been made regarding this standard.
10 UNIVERSAL ASN.1 ENCODING RULES
10.1 TAGS
The maximum value of an ASN.1 basic encoding tag that need be
handled by a workshop-conformant implementation shall be 16,383.
This is the maximum unsigned number that can be represented in 14
bits, therefore, the maximum encoding of a tag occupies 3 octets.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1
8.1.1.
10.2 Definite Length
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1
8.1.2.
10.3 External
It is assumed that "Presentation layer negotiation of encoding
rules" is always in effect, and therefore clause 32.5 of the
Specification of ASN.1, ISO 8824 never applies.
If a data value to be encapsulated in an EXTERNAL type is an
instance of a single ASN.1 type encoded according to the Basic
Encoding Rules for ASN.1, then the option "single-ASN.1-type"
shall be chosen as its encoding.
If a data value to be encapsulated in an EXTERNAL type is encoded
as an integral number of octets, and the above does not apply,
then the option "octet-aligned" shall be chosen as its encoding.
Editor's Note - This clause is technically equivalent to the
22
Part 5 - Upper Layers March 1994 (Stable)
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1
8.1.5.
10.4 Integer
Any incidence of an ASN.1 INTEGER type defined in an abstract
syntax describing protocol control information must be encoded so
that the length of its contents octets is no more than four
octets, unless an explicit Workshop agreement to the contrary is
made for a specific INTEGER type.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1
8.1.3.
10.5 String Types
The contents octets for a constructed encoding of a BIT STRING,
OCTET STRING, or character string value consists of the complete
encoding of zero, one, or more data values, and the encoding of
these data values must be primitive.
Editor's Note - This clause is technically equivalent to the
Common Upper Layers Requirements Profile (ISO DISP 11188-1)
and will be replaced by a reference to ISO DISP 11188-1
8.1.6.
10.6 Extensibility
For data values that are ultimately carried on the user data of
the CONNECT SPDU (i.e., Presentation CP, ACSE AARQ and any APDU
in the user information field of AARQ) a receiver shall
a) ignore any undefined element,
b) ignore all unknown bit name assignments within a bit string.
NOTE - Referencing specifications may apply similar
requirements to other protocol elements.
23
Part 5 - Upper Layers March 1994 (Stable)
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.
11.5 Reuse of Transport Connection
Reuse of a Transport connection is not required and can be
refused.
24
Part 5 - Upper Layers March 1994 (Stable)
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
In order for an implementation to be in conformance with the
Implementors' agreements, the rules below shall be followed:
a) A conformant implementation must meet all of the
requirements of this specification. All documents referenced
in the Upper Layers part shall be used as the supporting
documents for all implementations of ACSE, ROSE, RTSE,
Presentation, or Session. The full references for these
documents are in clause 2.
b) Workshop-conformant implementations shall be ISO
conformant. PICS may contain limitations on length or value
aspects of a protocol. PICS of workshop-conformant systems
shall not contain restrictions more severe than those in
these implementation agreements.
NOTE - An implementation may abort a connection if the
constraints specified in these agreements are violated.
14 Specific ASE Requirements
The following list for each ASE the corresponding SIG's
requirements of and restrictions on ACSE, ROSE, RTSE,
Presentation, and Session.
All listed requirements and restrictions shall be included in an
NIST-conformant system and shall be implemented in accordance
with these Implementor's agreements.
14.1 FTAM Phase 2
14.1.1 ACSE Requirements
ACSE Functional Requirements: Kernel
Application Contexts: "ISO FTAM" { iso(1) standard(0) 8571
application-context iso-ftam(1) } - implies the use of the ACSE
and the FTAM ASE.
25
Part 5 - Upper Layers March 1994 (Stable)
A value is defined for the AE Title only to satisfy the FTAM
requirement for exchanging fields of this type. This value does
not identify an Application Entity and carries no semantics.
If the AE title is used, AE-title-form2 shall be supported.
Support of AE-title-form2 includes support of AP-title-form2 and
AE-qualifier-form2.
The value for the AP title is { 1 3 9999 1 ftam-nil-ap-title (7)
} at this time. Values for the AE qualifier are outside the scope
of these agreements.
The use of AP invocation identifiers and AE invocation
identifiers by FTAM is outside the scope of these agreements.
14.1.2 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: At least 3 Presentation Contexts must be
supported.
Abstract Syntaxes:
a) Abstract Syntaxes for conformant Implementations
1) "ISO 8650-ACSE1" {joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
version1(1) }
2) "FTAM-PCI" { iso(1) standard(0) 8571
abstract-syntax(2) ftam-pci(1) }
3) "FTAM unstructured binary abstract syntax" { iso(1)
standard(0) 8571 abstract-syntax(2)
unstructured-binary(4) }
Editor's Note - In Definitions below, "NBS" designation will
be preserved.
b) Abstract Syntaxes Depending on Implementation Profile
1) "FTAM-FADU" { iso(1) standard(0) abstract-syntax(2)
ftam-fadu(2) }
2) "FTAM unstructured text abstract syntax" { iso(1)
standard(0) 8571 abstract-syntax(2)
unstructured-text(3) }
26
Part 5 - Upper Layers March 1994 (Stable)
3) "NBS abstract syntax AS1" { iso
identified-organization oiw(14) ftamsig(5)
abstract-syntax(2) nbs-as1(1) }
4) "NBS file directory entry abstract syntax" { iso
identified-organization oiw(14) ftamsig(5)
abstract-syntax(2) nbs-as2(2) }
c) Associated Transfer Syntax:
1) "Basic Encoding of a single ASN.1 type" {
joint-iso-ccitt(2) asn1(1) basic-encoding(1)}
Editor's Note - The changes above involving "OIW(14)" were
not explicitly mentioned at the March 1990 Plenary, but were
implied from a correspondingly approved FTAM motion.
14.1.3 Session Requirements
Session Functional Units:
a) kernel
b) duplex
Version Number: 2
Maximum size of User Data parameter field: 10,240
14.1.4 Session Options
Session Functional Units:
a) resynchronize - only a Resynchronize Type value of
"abandon"
b) minor synchronize
NOTES
1 The minor synchronize functional unit is required
whenever the resynchronize functional unit is available.
2 The default value for Minor Sync Point Sync type item PV-
field shall be absent if explicit confirmation is
required (per ISO 8327, 8.3.20.3) (SIA->value of $).
27
Part 5 - Upper Layers March 1994 (Stable)
14.1.5 ASN.1 Encoding Requirements
Some INTEGER types of the FTAM PCI may exceed the maximum size
specified in the UNIVERSAL ASN.1 ENCODING Rules. See the Range of
values for INTEGER type Parameters of the FTAM part.
14.2 MHS
14.2.1 Phase 1 (1984 X.400) Session Requirements
Session Functional Units:
a) kernel
b) half-duplex
c) exceptions
d) activity management
e) minor synchronize
Version Number: 1
Maximum size of User Data parameter field: 512
NOTES
1 Restricted use is made by the RTS of the Session services
implied by the functional units selected. Specifically, 1)
No use is made of S-TOKEN-GIVE, and 2) S-PLEASE-TOKENS only
asks for the data token.
2 In the S-CONNECT SPDU, the Initial Serial Number should
not be present.
3 The format of the Connection Identifier in the S-CONNECT
SPDU is described in Version 5 of the X.400-Series
Implementors' Guide.
14.2.2 Phase 2, Protocol P1 (1988 X.400)
14.2.2.1 ROSE Requirements
ROSE is not used.
28
Part 5 - Upper Layers March 1994 (Stable)
14.2.2.2 RTSE Requirements
The RTSE requirements are:
a) Monologue
b) TWA - optional
c) checkpointing:
1) minimum checkpointsize = 1
2) minimum windowsize = 1
d) no checkpointing
For the Monologue Association:
a) initiator keeps initial turn
b) APDUs are transferred from initiator to responder only
c) no turn passing
d) only the initiator effects the orderly release of an
association
For the two way alternate Association
a) the initiator may keep or pass the initial turn, at
binding
b) APDUs are transferred by the holder of the turn
c) only the initiator effects the orderly release of an
association, when it possesses the turn
14.2.2.3 ACSE Requirements
As per Phase 2, Protocol P7.
Application Contexts:
a) "MTS-transfer-protocol-1984" - mandatory
b) "MTS-transfer-protocol" - mandatory
c) "MTS-transfer" - mandatory
29
Part 5 - Upper Layers March 1994 (Stable)
14.2.2.4 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: at least 3 must be supported
Abstract Syntaxes:
a) "ISO 8650-ACSE1" {joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
version1(1) }
b) "MTS-RTSE"
c) "MTSE"
d) Associated Transfer Syntax: "Basic Encoding of a single
ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) }
14.2.2.5 Session Requirements
As per Phase 2, Protocol P7.
14.2.3 Phase 2, Protocol P7 (1988 X.400)
14.2.3.1 ROSE Requirements
Operation and association classes are used as per the standard.
14.2.3.2 RTSE Requirements
The RTSE requirements are:
a) TWA
b) normal-mode
c) checkpointing
d) minimum checkpointsize = 1
e) minimum windowsize = 1
f) no checkpointing
For the Monologue Association:
30
Part 5 - Upper Layers March 1994 (Stable)
a) initiator keeps initial turn
b) APDUs are transferred from initiator to responder only
c) no turn passing
d) only the initiator effects the orderly release of an
association
For two way alternate Association:
a) the initiator may keep or pass the initial turn, at
binding
b) APDUs are transferred by the holder of the turn
c) only the initiator effects the orderly release of an
association, when it possesses the turn
14.2.3.3 ACSE Requirements
ACSE Functional Requirements: Kernel
The use of AP-TITLE, AE-QUALIFIER, AP-INVOCATION-ID, and AE-
INVOCATION-ID is not recommended; however, a receiving entity
must be capable of ignoring them (if present) without refusing
the connection.
Application Contexts:
a) "MS-access" - mandatory; normal mode
b) "MS-reliable-access" - optional; normal mode
14.2.3.4 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: at least 5
Abstract Syntaxes:
a) "ISO 8650-ACSE1" { joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
version1(1) }
b) MSBind/MSUnbind (with or without RTSE)
31
Part 5 - Upper Layers March 1994 (Stable)
c) MSSE (Message Submission)
d) MASE (Message Administration)
e) MRSE (Message Retrieval)
Associated Transfer Syntax: "Basic Encoding of a single ASN.1
type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) }
14.2.3.5 Session Requirements
Session Functional Units:
a) kernel
b) half-duplex (if RTSE is supported)
c) full-duplex (if RTSE is not supported)
d) exceptions
e) activity management
f) minor synchronize
Version Number: 2
Maximum size of User Data parameter field: 10,240
NOTES
1 MHS proposes both versions 1 and 2 for pass through mode
(X.410 mode), but only version 2 for normal mode.
2 Restricted use is made by the RTS of the Session services
implied by the functional units selected. Specifically, no
use is made of S-TOKEN-GIVE, and S-PLEASE-TOKENS only asks
for the data token.
3 In the S-CONNECT SPDU, the Initial Serial Number should
not be present.
4 The format of the Connection Identifier in the S-CONNECT
SPDU is described in Version 5 of the X.400-Series
Implementors' Guide.
32
Part 5 - Upper Layers March 1994 (Stable)
14.2.4 Phase 2, Protocol P3 (1988 X.400)
14.2.4.1 ROSE Requirements
As per Phase 2, P7.
14.2.4.2 RTSE Requirements
As per Phase 2, P7.
14.2.4.3 ACSE Requirements
As per Phase 2, P7.
Application Contexts:
a) "MTS-access" - mandatory
b) "MTS-reliable-access" - optional
c) "MTS-forced-access" - mandatory
d) "MTS-forced-reliable-access" - optional
14.2.4.4 Presentation Requirements
As per Phase 2, P7.
14.2.4.5 Session Requirements
As per Phase 2, P7.
14.3 DS Phase 1
14.3.1 ACSE Requirements
ACSE Functional Requirements: Kernel
Application Contexts:
a) "id-ac-directoryAccessAC" { joint-iso-ccitt(2) ds(5) 3 1
}
33
Part 5 - Upper Layers March 1994 (Stable)
b) "id-ac-directorySystemAC" { joint-iso-ccitt(2) ds(5) 3 2
}
14.3.2 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: At least 2 Presentation Contexts must be
supported.
Abstract Syntaxes:
a) "ISO 8650-ACSE1" { joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
version1(1) }
b) "id-as-directoryAccessAS" joint-iso-ccitt(2) ds(5) 9 1 }
c) "id-as-directorySystemAS" { joint-iso-ccitt(2) ds(5) 9 2
}
Associated Transfer Syntax: "Basic Encoding of a single ASN.1
type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) }
14.3.3 Session Requirements
Session Functional Units:
a) kernel
b) duplex
Version Number: 2
Maximum size of User Data parameter field: 10,240
14.4 Virtual Terminal
14.4.1 Phase 1a
14.4.1.1 ACSE Requirements
ACSE Functional Requirements: Kernel
Application Contexts: "ISO VT" { iso(1) standard(0) 9041
34
Part 5 - Upper Layers March 1994 (Stable)
application-context(1) }- implies the use of the ACSE and the VT
ASE
14.4.1.2 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: at least 2 must be supported
Abstract Syntaxes:
a) "ISO 8650-ACSE1" { joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
version1(1) }
b) "VT Basic" { iso(1) standard(0) 9041 abstract-syntax(2)
}
Associated Transfer Syntax: "Basic Encoding of a single ASN.1
type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) }
14.4.1.3 Session Requirements
Session Functional Units:
a) kernel
b) duplex
c) expedited data
d) major synchronize
e) resynchronize - only a Resynchronize Type value of
"restart"
f) typed data
Version Number: 2
Maximum size of User Data parameter field: 10,240
Session Options: expedited data
35
Part 5 - Upper Layers March 1994 (Stable)
14.4.2 Phase 1b
14.4.2.1 ACSE Requirements
ACSE Functional Requirements: Kernel
Application Contexts: "ISO VT" { iso(1) standard(0) 9041
application-context(1) } - implies the use of the ACSE and the VT
ASE
14.4.2.2 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: at least 2 must be supported
Abstract Syntaxes:
a) "ISO 8650-ACSE1" { joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
version1(1) }
b) "VT Basic" { iso(1) standard(0) 9041 abstract-syntax(2)
}
Associated Transfer Syntax: "Basic Encoding of a single ASN.1
type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) }
14.4.2.3 Session Requirements
Session Functional Units:
a) kernel
b) duplex
c) half-duplex
d) expedited data
e) major synchronize
f) resynchronize - only a Resynchronize Type value of
"restart"
g) typed data
36
Part 5 - Upper Layers March 1994 (Stable)
Version Number: 2
Maximum size of User Data parameter field: 10,240
Session Options: expedited data
14.5 MMS
14.5.1 ACSE Requirements
ACSE Functional Units: Kernel
Application Context: "ISO MMS" { iso(1) standard(0) 9506 part(2)
mms-application-context-version1(3)} - implies use of ACSE and
MMS ASE
14.5.2 Constructed Encodings
Constructed encodings shall not be used for bit strings shorter
than 256 bits, nor for octet strings (or types derived from octet
strings by tagging) shorter than 1024 octets. For such strings,
only primitive encodings shall be used. Upon receipt of a
constructed bit string or octet string that violates this
restriction, the receiving implementation may reject the
corresponding PDU, but shall not send a P-P-Abort.
14.5.3 Presentation Requirements
Presentation Functional Units: Kernel
At least 2 Presentation Contexts must be supported.
Abstract Syntaxes:
a) "mms-abstract-syntax-major-version1" { iso(1)
standard(0) 9506 part(2) mms-abstract-syntax-major-version1
(1)}
b) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-
control(2) abstract-syntax(1) apdus(0) version1(1)}
Associated Transfer Syntax: "Basic Encoding of a single ASN.1
type" {joint-iso-ccitt(2) asn1(1) basic-encoding(1)}
37
Part 5 - Upper Layers March 1994 (Stable)
14.5.4 Session Requirements
Session Functional Units:
a) Kernel
b) Duplex
Version Number: 2
Maximum size of User Data parameter field: 10,240
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.
38
Part 5 - Upper Layers March 1994 (Stable)
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
14.7.1 ROSE Requirements
The Rose requirements are as specified in ISO 9596 section 5.2:
Underlying Services, and section 6.2 Remote Operations.
Operations Classes: 1, 2, and 5
Association Classes: 3
14.7.2 ACSE Requirements
ACSE Functional Units: kernel
Application Contexts: as defined by [SMO]
AE-Title: The association responder shall support both forms of
the AE-Title. The association requestor may use either form of
the AE-Title.
14.7.3 Presentation Requirements
Presentation Functional Units: kernel
Presentation Contexts: At least 2 must be supported.
Abstract Syntaxes:
a) "ISO 8650-ACSE1" { joint-iso-ccitt(2)
association-control(2) abstract-syntax(1) apdus(0)
39
Part 5 - Upper Layers March 1994 (Stable)
version1(1) }
b) "CMIP-PCI" {joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1)
abstractSyntax(4)}
Associated Transfer Syntax: "Basic Encoding of a single
ASN.1 type" { joint-iso-ccitt(2) asn1(1) basic-encoding(1) }
14.7.4 Session Requirements
Session Functional Units:
a) kernel
b) duplex
Version Number: 2
Maximum size of User Data parameter field: 10,240.
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;
40
Part 5 - Upper Layers March 1994 (Stable)
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)};
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:
41
Part 5 - Upper Layers March 1994 (Stable)
Maximum size of User Data parameter field: 10,240.
42
Part 5 - Upper Layers March 1994 (Stable)
Annex A (normative)
Object Identifier Register
Editor's Note - Annexes A and B have been switched to place
the informative annex after the normative annex.
A.1 Register Index
Each entry in the index contains an object identifier value and a
reference to the clause describing the object identifier's use:
a) { iso(1) identified-organization(3) oiw(14) ulsig(8)
application-context(1) nil(1) } is defined in 14.2;
b) { iso(1) identified-organization(3) oiw(14) ulsig(8)
abstract-syntax(2) octet-string(1) } is defined in 14.2.
A.2 Object Identifier Descriptions
{ iso(1) identified-organization(3) oiw(14) ulsig(8)
application-context(1) nil(1) }
This application context may be used by applications having a
prior agreement regarding the application context.
NOTE - This value is intended to be used by private
applications that have an a priori agreement concerning the
set of ASEs, related options, and any other information
necessary for the interworking of AEs on an application
association. This value does not identify any specific
application context and cannot be used to identify the
intended communications environment for the application
association. Therefore, it is strongly recommended that
private applications define and register an object
identifier for their application context.
{ iso(1) identified-organization(3) oiw(14) ulsig(8)
abstract-syntax(2) octet-string(1) }
43
Part 5 - Upper Layers March 1994 (Stable)
+---------------------------------------------------------+
| NIST-OIW-ULSIG-AS-octet-string |
| DEFINITIONS ::= BEGIN |
| |
| Single-octet-string ::= OCTET STRING |
| END |
+---------------------------------------------------------+
This abstract syntax may be used by applications having a prior
agreement regarding the content of the octet string.
44
Part 5 - Upper Layers March 1994 (Stable)
Annex B (informative)
Recommended Practices
Editor's Note - Annexes A and B have been switched to place
the informative annex after the normative annex.
The optional "Reflect Parameter Values" parameter in the Provider
ABORT SPDU shall be encoded so as to represent the Session
connection state, the incoming event and the first invalid SPDU
field exactly at the moment a protocol error was detected.
The first octet encodes the Session state as a number relative to
0 as detailed in table 1.
The second octet encodes the incoming event as a number relative
to 0 as detailed in table 2.
The third octet contains the SI, PGI, or PI Code of any SI field,
PGI unit or PI unit in error.
NOTE - The remaining 6 octets are undefined herein.
45
Part 5 - Upper Layers March 1994 (Stable)
Table A.1 - Session States
+-------+-----+--------------------------------------------------------------+
| State | Rel | Description |
+-------+-----+--------------------------------------------------------------+
| 1 | 0 | Idle, no transport connection |
| 1B | 1 | Wait for T-connect confirm |
| 1C | 2 | Idle, transport connected |
| 2A | 3 | Wait for the ACCEPT SPDU |
| 3 | 4 | Wait for the DISCONNECT SPDU |
| 8 | 5 | Wait for the S-CONNECT response |
| 9 | 6 | Wait for the S-RELEASE response |
| 16 | 7 | Wait for the T-DISCONNECT indication |
| 713 | 8 | Data Transfer state |
| 1A | 9 | Wait for the ABORT ACCEPT SPDU |
| 4A | 10 | Wait for the MAJOR SYNC ACK SPDU or PREPARE SPDU |
| 4B | 11 | Wait for the ACTIVITY END ACK SPDU or PREPARE SPDU |
| 5A | 12 | Wait for the RESYNCHRONIZE ACK SPDU or PREPARE SPDU |
| 5B | 13 | Wait for the ACTIVITY INTERRUPT SPDU or PREPARE SPDU |
| 5C | 14 | Wait for the ACTIVITY DISCARD ACK SPDU or PREPARE SPDU |
| 6 | 15 | Wait for the RESYNCHRONIZE SPDU or PREPARE SPDU |
| 10A | 16 | Wait for the S-SYNC-MAJOR response |
| 10B | 17 | Wait for the S-ACTIVITY-END response |
| 11A | 18 | Wait for the S-RESYNCHRONIZE response |
| 11B | 19 | Wait for the S-ACTIVITY-INTERRUPT response |
| 11C | 20 | Wait for the S-ACTIVITY-DISCARD response |
| 15A | 21 | After PREPARE, wait for the MAJOR SYNC ACK SPDU |
| | | or the ACTIVITY END ACK |
| 15B | 22 | After PREPARE, wait for the RESYNCHRONIZE SPDU |
| | | or the ACTIVITY DISCARD SPDU |
| 15C | 23 | After PREPARE, wait for the RESYNCHRONIZE ACK SPDU, |
| | | or the ACTIVITY INTERRUPT ACK SPDU |
| | | or the ACTIVITY DISCARD ACK SPDU |
| 18 | 24 | Wait for GIVE TOKENS ACK SPDU |
| 19 | 25 | Wait for a recovery request or SPDU |
| 20 | 26 | Wait for a recovery SPDU or request |
| 21 | 27 | Wait for the CAPABILITY DATA ACK SPDU |
| 22 | 28 | Wait for the S-CAPABILITY-DATA response |
| 1D | 29 | Wait for the CONNECT DATA OVERFLOW SPDU |
| 2B | 30 | Wait for the OVERFLOW ACCEPT SPDU |
| 15D | 31 | After PREPARE, wait for the ABORT SPDU |
+-------+-----+--------------------------------------------------------------+
46
Part 5 - Upper Layers March 1994 (Stable)
Table A.2 - Incoming Events
+-------------+-----+----------------------------------------------+
| Event | Rel | Description |
+-------------+-----+----------------------------------------------+
| SCONreq | 0 | S-CONNECT request |
| SCONrsp | 1 | S-CONNECT accept response |
| SCONrsp | 2 | S-CONNECT reject response |
| SDTreq | 3 | S-DATA request |
| SRELreq | 4 | S-RELEASE request |
| SRELrsp | 5 | S-RELEASE accept response |
| SUABreq | 6 | S-U-ABORT request |
| TCONcnf | 7 | T-CONNECT confirmation |
| TCONind | 8 | T-CONNECT indication |
| TDISind | 9 | T-DISCONNECT indication |
| TIM | 10 | Time out |
| AA | 11 | ABORT ACCEPT |
| AB-nr | 12 | ABORT - no reuse |
| AC | 13 | ACCEPT |
| CN | 14 | CONNECT |
| DN | 15 | DISCONNECT |
| DT | 16 | DATA TRANSFER |
| FN-nr | 17 | FINISH - no reuse |
| RF-nr | 18 | REFUSE - no reuse |
| SACTDreq | 19 | S-ACTIVITY-DISCARD request |
| SACTDrsp | 20 | S-ACTIVITY-DISCARD response |
| SACTEreq | 21 | S-ACTIVITY-END request |
| SACTErsp | 22 | S-ACTIVITY-END response |
| SACTIreq | 23 | S-ACTIVITY-INTERRUPT request |
| SACTIrsp | 24 | S-ACTIVITY-INTERRUPT response |
| SACTRreq | 25 | S-ACTIVITY-RESUME request |
| SACTSreq | 26 | S-ACTIVITY-START request |
| SCDreq | 27 | S-CAPABILITY-DATA request |
| SCDrsp | 28 | S-CAPABILITY-DATA response |
| SCGreq | 29 | S-CONTROL-GIVE request |
| SEXreq | 30 | S-EXPEDITED-DATA request |
| SGTreq | 31 | S-TOKEN-GIVE request |
| SPTreq | 32 | S-TOKEN-PLEASE request |
| SRELrsp | 33 | S-RELEASE response reject |
| SRSYNreq(a) | 34 | S-RESYNCHRONIZE request abandon |
| SRSYNreq(r) | 35 | S-RESYNCHRONIZE request restart |
| SRSYNreq(s) | 36 | S-RESYNCHRONIZE request set |
| SRSYNrsp | 37 | S-RESYNCHRONIZE response |
| SSYNMreq | 38 | S-SYNC-MAJOR request |
| SSYNMrsp | 39 | S-SYNC-MAJOR response |
| SSYNmreq | 40 | S-SYNC-MINOR request |
| SSYNmrsp | 41 | S-SYNC-MINOR response |
| STDreq | 42 | S-TYPED-DATA request |
| SUERreq | 43 | S-U-EXCEPTION-REPORT request |
+-------------+-----+----------------------------------------------+
47
Part 5 - Upper Layers March 1994 (Stable)
Table A.2 - Incoming Events (continued)
+-------------+-----+----------------------------------------------+
| Event | Rel | Description |
+-------------+-----+----------------------------------------------+
| AB-r | 44 | ABORT - reuse SPDU |
| AD | 45 | ACTIVITY DISCARD SPDU |
| ADA | 46 | ACTIVITY DISCARD ACK SPDU |
| AE | 47 | ACTIVITY END SPDU |
| AEA | 48 | ACTIVITY END ACK SPDU |
| AI | 49 | ACTIVITY INTERRUPT SPDU |
| AIA | 50 | ACTIVITY INTERRUPT ACK SPDU |
| AR | 51 | ACTIVITY RESUME SPDU |
| AS | 52 | ACTIVITY START SPDU |
| CD | 53 | CAPABILITY DATA SPDU |
| CDA | 54 | CAPABILITY DATA ACK SPDU |
| ED | 55 | EXCEPTION DATA SPDU |
| ER | 56 | EXCEPTION REPORT SPDU |
| EX | 57 | EXPEDITED DATA SPDU |
| FN-r | 58 | FINISH - reuse SPDU |
| GT | 59 | GIVE TOKENS SPDU |
| GTA | 60 | GIVE TOKENS ACK SPDU |
| GTC | 61 | GIVE TOKENS CONFIRM SPDU |
| MAA | 62 | MAJOR SYNC ACK SPDU |
| MAP | 63 | MAJOR SYNC POINT SPDU |
| MIA | 64 | MAJOR SYNC ACK SPDU |
| MIP | 65 | MINOR SYNC POINT SPDU |
| NF | 66 | NOT FINISHED SPDU |
| PR-MAA | 67 | PREPARE (MAJOR SYNC ACK) SPDU |
| PR-RA | 68 | PREPARE (RESYNCHRONIZE ACK) SPDU |
| PR-RS | 69 | PREPARE (RESYNCHRONIZE) SPDU |
| PT | 70 | PLEASE TOKENS SPDU with Token Item Paramet r |
| RA | 71 | RESYNCHRONIZE ACK SPDU |
| RF-r | 72 | REFUSE - reuse SPDU |
| RS-a | 73 | RESYNCHRONIZE - abandon SPDU |
| RS-r | 74 | RESYNCHRONIZE - restart SPDU |
| RS-s | 75 | RESYNCHRONIZE - set SPDU |
| TD | 76 | TYPED DATA SPDU |
| CDO | 77 | CONNECT DATA OVERFLOW SPDU |
| OA7 | 8O | VERFLOW ACCEPT SPDU |
| PR-AB | 79 | PREPARE (ABORT) SPDU |
+-------------+-----+----------------------------------------------+
48
