NIST

PUBLICATIONS

Computer

§ Systems

Technology

U.S. DEPARTMENT OF

COMMERCE

National Institute of Standards and

Technology

Nisr

NIST Special Publication 500-183

T L INST. OF STAND & TECH R.LC.

A111D3 477fl7M

Stable Implementation Agreements for

Open Systems Interconnection Protocols

Version 4 Edition 1

December 1990

Based on the Proceedings of the NIST Workshop for Implementors of 031

Workshop Chairman

Tim Boland, NIST

NIST Special Publication 500-183

Stable Implementation Agreements for

Open Systems Interconnection Protocols

Version 4 Edition 1

December 1990

Based on the Proceedings of the NIST Workshop for Implementors of OSI

Workshop Chairman

Tim Boland, NIST

Special Interest Group (SIG) Chairs

Directory Services

File Transfer Access Mgmt.

Lower Layers

Manufacturing Message Spec.

Network Management

Office Document Architecture Remote Database Access

Security

Technical Liaison Committee

Transaction Processing

Upper Layers

Virtual Terminal

X400

You-Bong Weon-Yoon

Darryl Roberts

Fred Burg

Herbert Falk George Mouradian

Paul Brusil Frank Dawson

Peter Eng

(for information)

James Galvin

Einar Stefferud

Jeff Hildebrand

Mark Thomas

Luke Lucas

Barbara Nelson

AT&T

Unisys NCG

AT&T

SISCO

AT&T Bell Labs

Mitre IBM

IBM Canada

Trusted Info. Systems

NMA-Northrop

Boeing Computer Serv. AT&T Bell Labs

Control Data Corp. RETIX

Supersedes NiST/SP-500/177

U.S. DEPARTMENT OF COMMERCE

Robert A. Mosbacher, Secretary

NATIONAL INSTITUTE OF STANDARDS

AND TECHNOLOGY

John W. Lyons, Director

Issued March 1991
Reports on Computer Systems Technology

The National Institute of Standards and Technology (NIST) has a unique responsibility for computer

systems technology within the Federal government. NIST's Computer Systems Laboratory (CSL) develops standards and guidelines, provides technical assistance, and conducts research for computers and

related telecommunications systems to achieve more effective utilization of Federal information technology resources. CSL's responsibilities include development of technical, management, physical, and administrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified

information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 500 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and

academia.

National Institute of Standards and Technology Special Publication 500-183

Natl. Inst. Stand. Techno!. Spec. Publ. 500-183, 791 pages (Mar. 1991)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1991

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 1 - General Information

Output from the September 1991 NIST Workshop for

Implementors of OSI

Chair/Editor, OIW Workshop:

Workshop Editor:

Tim Boland

Brenda Gray
Part 1 - General Information September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Chair of the National Institute of

Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection (OSI).

This part replaces the previously existing chapter on this subject. There is no significant technical change

from this text as previously given.

Future changes and additions to this version of these Implementor Agreements will be published as change

pages. Deleted and replaced text will be shown as stri keout. New and replacement text will be shown as

shaded.
Part 1 - General Information

0 Introduction

This document records current stable implementation agreements of OSI protocols among the organizations

participating in the NIST Workshop for Implementors of OSI. Stable in the context of this document means

the following:

a) the agreements are based on final standards (e.g., ISO-IS or CCITT Recommendations) or nearly

final (e.g., ISO-DIS) with no significant changes expected,

b) the agreements have been approved by the NIST Workshop Plenary for progression from the

Working Agreements document to this document after a period of review. These agreements are considered final; the only changes allowed will be clarifications, and certain Technical and Alignment

errata. These changes must have the strong support of vendors, and be justifiable.

For these reasons, the agreements are considered advanced enough for use in product and test suite

development. This means that readers can use this text as a t>asis for procurement references for OSI

products. All of the text in this document is considered stable as defined above.

Future releases of these Stable Agreements will add and/or extend functionality offered by this edition and

version. When required, new versions will be Introduced on a yearly basis. It is the NIST Workshop intent that new versions of this Stable Agreements document will be compatible with the present version. If this proves impractical, the agreements will attempt to provide mechanisms and guidelines which maximize

interoperability. Furthermore, it is the intent that these stable agreements be maintained via the Errata process as long as is appropriate. For the subject area, interworking information and other useful advice

to the reader is given as appropriate. Specific "defect report" information (including extent of applicability)

is provided in designated portions of each Part.

1 Scope

Agreements text is either in this Stable Document (Stable) or in the aligned Working Document (not yet

stable). It is a goal that the same text not appear in the same position in both documents at once (except

for part 1). Modifications to a version reflect very recent stable functionality as well as editorial, technical,

and alignment errata, all applied to the previous edition.

The intended audience for this document is composed of those individuals who are interested in Stable

Implementation Agreements for OSI protocols. Each part of the document covers a different subject area, and the parts are presented so as to present a consistent and unified approach. The format of V4 follows

the ISO directives whenever possible.

The corresponding and aligned document, "Working Implementation Agreements for OSI Protocols dated

Juno 1001 ," records agreements which are not yet considered stable, in the sense described above. This

document will be referenced as the "Working Agreements Document." This Stable document is aligned with

the Working Agreements Document in the sense that the structures are identical, and pointers are given in this Stable Document to work in the Working Agreements Document which could become stable in the

future.

1
Part 1 - General Information September 1991 (Stable)

The benefit of this document to the reader is that it gives a complete accounting of current stable

agreements. Minor changes (Errata) to these agreements will be issued in replacement page format. These

errata will only be applied to the current version.

Currently efforts are underway to define worldwide technically harmonized profiles. The goal is to create a consolidated global market for OSI products. This means that vendors can sell to a larger market, and

users can procure products from a variety of vendors around the world. Agreements in this document are

likely to be used in these alignment efforts.

Version 4 (this version) Is backwards compatible with Version 3 to the maximum extent possible. Version

4 includes all of the material from Version 3, (modified by errata) as well as new stable material from the

previous year; important new functional additions from Version 3 are in the areas of FDDI, Network Layer

aspects, Transport Layer aspects, Network Management, MMS, and features of 1988 based X.400

agreements.

2 Normative References

See succeeding parts.

3 Definitions

See succeeding parts.

4 Purpose of the Workshop

In February, 1983, at the request of industry, NIST organized the NIST Workshop for Implementors of OSI

to bring together future users and potential suppliers of OSI protocols. The Workshop accepts as input the

specifications of emerging standards for protocols and produces as output agreements on the

implementation and testing particulars of these protocols. This process is expected to expedite the

development of OSI protocols and promote interoperability of independently manufactured data

communications equipment.
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 2 - Subnetworks

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Fred Burg, AT&T

Kristy Brown, NSC Workshop Editor: Brenda Gray
Part 2 - Subnetworks September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Lower Layers Special Interest Group

(LLSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI). 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.

Annexes A and B are for information only.

Future changes and additions to this version of these Implementor Agreements will be published as change

pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as

shaded.

ii
Part 2 - Subnetworks September 1991 (Stable)

Table of Contents

Part 2 - Subnetworks 1

0 Intrcxiuction 1

1 Scope 1

2 Normative References 1 2.1 CCITT 1 2.2 ISO 2

2.3 ANSI 2

3 Status 3

4 Errata 4

5 Local Area Networks 4

5.1 IEEE 802.2 Logical Link Control 4

5.2 IEEE 802.3 CSMA/CD Access Method 4

5.3 IEEE 802.4 Token Bus Access Method 6

5.4 IEEE 802.5 Token Ring Access Method 7

5.5 Fiber Distributed Data Interface (FDDI) 8

5.5.1 Token Ring Media Access Control (MAC, X3. 139-1 987) 8

5.5.2 Token Ring Physical Uyer (PHY, X3. 148-1 988) 9

5.5.3 Physical Layer Media Dependent (PMD, X3. 166-1 989) 10

6 Wide Area Networks 10

6.1 CCITT Recommendation X.25 10

6.2 ISO 7776 10

6.3 ISO 8208 11

7 Integrated Services Digital Networks (ISDN) 11

7.1 Introduction 12

7.2 Implementation Agreements 13

7.2.1 Physical Layer, Basic Access at "U" 14

7.2.2 Physical Layer, Basic Access at S and T 14

7.2.3 Physical Layer, Primary Rate at V S,T, arxt U 14

7.2.4 Data Link Layer, D-Channel 16

7.2.5 Signaling 16

7.2.6 Data Link Layer B-Channel 17

7.2.7 Packet Layer 17

Annex A (informative)

Cross Reference Between CCITT and ANSI Text Relating to ISDN Agreements 18

A.1 Data Link Layer, D-Channel 18

iii
Part 2 - Subnetworks

A.2 Signaling

Annex B (informative)

Bibliography

September 1991 (Stable)

18

19

iv

1*1
Part 2 - Subnetworks September 1991 (Stable)

List of Figures

Figure 1 - LSAP bit pattern 4

Figure 2 - l-Field Format 8

Figure 3 - FDDI FRAiy^E FORMAT 9

Figure 4 - Protocol l_ayers at S, T and U reference points when D Cliannel is used in ISDN 13

Figure 5 - Protocol Layers at S, T and U reference points when B Channel is used in ISDN 14

V
Part 2 - Subnetworks September 1991 (Stable)

List of Tables

Table 1 - ANSI-CCITT Cross-References 18

Vi
Part 2 - Subnetworks

0 Introduction

This ohaptor |a| provides agreements about subnetwork services used in support of the OSI Networl< Layer.

1 Scope

These agreements cover subnetwork types including local area networks, packet switched networks, circuit switched networks, ISDN, and others.

2 Normative References

2.1 CCITT

[1] Recommendation 1.231 (Blue Book, 1988), Circuit-Mode Bearer Service Categories.

[2] Recommendation 1.232 (Blue Book, 1988), Packet-Mode Bearer Service Categories.

[3] Recommendation 1.431 (Blue Book, 1988), Primary Rate User-Network Interface - Layer 1 Specification.

[4] Recommendation Q.921 (1.441) (Blue Book, 1988), ISDN User-Network Interface, Data Link Layer

Specification.

[5] Recommendation Q.931 (1.451) (Blue Book, 1988), ISDN User-Network Interface Layer 3

Specification for Basic Call Control.

[6] Recommendation X.25 (Yellow Book 1980), Interface Between Data Terminal Equipment (DTE) and

Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public

Data Networks.

[7] Recommendation X.25 (Blue Book, 1988), Interface Between Data Terminal Equipment (DTE) and

Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and

Connected to Public Data Networks by Dedicated Circuit.

[8] Recommendation X.31 (Blue Book, 1988), Support of Packet Mode Terminal Equipment by an ISDN.

1
Part 2 - Subnetworks March 1991 (Stable)

2.2 ISO

[9] ISO 7776, Information processing systems - Data communication - High-level Data Link Control

Procedures - Description of the X.25 LAPB-compatible DTE data link procedures.

[10] ISO/lEC 8208 Edition 2, Information technology - Data communications - X.25 Packet layer protocol

for data terminal equipment.

[11] ISO 8802-2, Information processing systems - Local area networks - Part 2: Logical link control.

[12] ISO DIS 8802-3, Information processing systems - Local area networks - Part 3: Carrier sense

multiple access method with collision detection (CSMA/CD) and physical layer specifications.

[13] ISO DIS 8802-4, Information processing systems - Local area networks - Part 4: Token-passing bus

access method and physical layer specifications.

[14] ISO 8802-5, Information processing systems - Local area networks - Part 5: Token ring access method and physical layer specifications.

[15] ISO 9314-1 , Information processing systems - Fibre distributed data interface (FDDI) - Part 1: Token

ring physical layer protocol (PHY).

[16] ISO 9314-2, Information processing systems - Fibre distributed data interface (FDDI) - Part 2: Token

ring media access control (MAC).

[17] ISO DIS 9314-3, Information processing systems - Fibre distributed data interface (FDDI) - Part 3: Physical layer medium dependent (PMD).

[10] J$0 10039, tnformatfop Technotogy - LopatAresc N^tworics - MAC Serviv& Q^finMott

2.3 ANSI

[19] ANSI/IEEE 802.2, Logical Link Control, 1987.

[20] ANSI/I EEE 802.3, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) and Physical

Layer Specifications, 1985.

[21] ANSI/IEEE 802.3 Supplement a, MAU and Baseband Medium Specification, Type 10BASE2 (Section

10), 1988.

[22] ANSI /IEEE 802.3 Supplement b. Broadband MAU and Broadband Medium Specifications, Type

10BROAD36 (Section 11), 1988.

[23] ANSI/IEEE 802.3 Supplement c. Repeater Unit for 10 Mb/s Baseband Networks (Section 9), 1988.

[24] ANSI/IEEE 802.3 Supplement e, Physical Signaling, Medium Attachment, and Baseband Medium

Specifications, Type 1BASES (Section 12), 1988.
Part 2 - Subnetworks September 1991 (Stable)

[25] ANSI/IEEE 802.4, Token-Passing Bus Access Method and Physical Layer Specifications, Draft 1987.

[26] ANSI/IEEE 802.5, Token-Ring Access Method and Physical Layer Specifications, 1986.

{27] ANS T1.103, Carrier to Cuotomor Inctallation—DSl Motallic Intorfaco.

{27| ANS Ti.4oa-i^. ISDN Prkmty M&tf^im - Oostomer imt^Us^on M^Mic irtt6rfac0$ - i^^if#lj[

[28] ANS T1.601, Integrated Sen/ices Digital Network (ISDN) - Basic Access Interface for Use on

Metallic Loops for Application on the Network Side of the NT (Layer 1 Specification).

[29] ANS T1 .602, Integrated Sen/ices Digital Network (ISDN) - Data-Link Layer Signalling Specification

for Application at the User-Network Interface.

[30] ANS T1 .605, Integrated Services Digital Network (ISDN) - Basic Access Interface for S and T

Reference Points - Layer 1 Specification.

[31] ANS T1.607, Telecommunications - Digital Subscriber Signaling System #7 - Layer 3 Signaling

Specification for Circuit Switched Bearer Sen/ice.

[32] ANS T1 .608, Telecommunications - Digital Subscriber Signaling System # 7 - Layer 3 Signaling

Specification for Packet Switched Bearer Sen/ice.

[33] ANS X3. 1 39, Fiber distributed data interface (FDDI) - Token ring media access control (MAC) , 1 987.

[34] ANS X3. 1 48, Fiber distributed data interface (FDDI) - Token ring physical layer protocol (PHY) . 1 988.

[35] ANS X3.166, Fiber distributed data interface (FDDI) - Physical layer medium dependent (PMD),

1989.

3 Status

This version was completed in December 1 990.

3
Part 2 - Subnetworks Septemberig91 (Stable)

Errata

NOTE - This clause may contain "defect report" and resolutions material, and the versions of Implementor's

Agreements to which this material applies.

5 Local Area Networks

5.1 IEEE 802.2 Logical Link Control

The following decisions have been reached with respect to this protocol:

a) Link Sen/ice Access Point (LSAP):

1) The code below shall be used to address systenns using Network Layer protocols

identified by ISO TR 9577 (e.g., ISO 8473, ISO 8208). Note that bit zero is transmitted first;

2) The most significant bit is bit 7, thus this bit pattern represents hexadecimal FE (see

figure 1 below);

b) Type and Class:

1) Only the connectionless type 1, class I IEEE 802 link service will be used.

Figure 1 - LSAP bit pattern

5.2 IEEE 802.3 CSMA/CD Access Method

The following implementation agreements have been reached with respect to the IEEE 802.3 CSMA/CD

Access Method and Physical Layer Specifications:

a) The address length shall be 48 bits;

b) For a data packet of LLC data length of n octets, the length of the pad field is as follows:

1) max(0, minFrameSize-(8n + 2(addressSize) + 48)) bits.

The following implementation agreements have been reached with respect to 10 BROAD 36 Networks:

a) Single Cable Networks:

1) The translator frequency shall be 192.25 Mhz;
Part 2 - Subnetworks

2) The channel allocations are as follows:

a) Reverse Channels:

1) T12. T13, T14

September 1 991 (Stable)

4-1
I
Part 2 - Subnetworks June 1991 (Stable)

2) T13. T14. 2'

3) T14, 2', 3'

4) 2', 3", 4"

5) 3', 4", 4A*

6) 4', 4A', 5'

b) Forward Channels:

1) L, M, N

2) M, N. 0

3) N, O, P

4) O, P, Q

5) P, Q. R

6) Q, R. S

b) Dual Cable Networks:

For nontranslated dual cable networks forward and reverse frequencies are the same. Permissible

channel allocations are listed below:

1) T12, T13, T14

2) T13, T14. 2'

3) T14, 2', 3'

4) 2', 3', 4'

5) 3', 4', 4A'

6) 4', 4A', 5'

7) L, M, N

8) M, N. 0

9) N, 0, P

10) 0, P, Q

5
Part 2 - Subnetworks June "^QQI (Stable)

11) Q, R. S

c) When both IEEE 802.4 and IEEE 802.3 10 BROAD 36 networks coexist on the broadband cable

system the preferred channel allocations are as follows:

1) Reverse:

a) T12, T13, T14 - IEEE 802.3;

b) 6', FM1' - IEEE 802.4;

c) 3', 4'- Channels reserved for future use;

d) 4A', 5' - Channels reserved for future use;

2) Forward:

a) L, M, N - IEEE 802.3;

b) T, U - IEEE 802.4;

c) P, Q - Channels reserved for future use;

d) R, S - Channels reserved for future use.

The following Implemer^tatjon agreements have been reached with respect to 10 BASE-T netw<wks;

a) Auto«par "'^peater port wluch connects 10 BASE-T links eltfjer through an external or mptement thd autc^-partltlon dhd rdconrtdctiorts algorithm &^ d^n&d \t\ IEEE

5.3 IEEE 802.4 Token Bus Access Method

The following options are agreed to with respect to Draft J of token bus:

a) Data Rate:

1) 10 Mb (Broadband);

2) 5 Mb (Carrierband);

b) Addressing: 48 bit;

c) The ImeOption, Priority Mechanism, shall be implemented;

6
PART 2 - SUBNETWORKS December 1 990 (Stable)

d) Broadband Channel Assignments are as follows:

1) Forward:

a) P

b) Q

0) R

d) S

e) T

f) U

2) Reverse:

a) 3'

b) 4'

c) 4A'

d) 5'

e) 6'

f) FM1'.

5.4 IEEE 802.5 Token Ring Access Method

The following implementation agreements have been reached with respect to the IEEE Standard 802.5,

Token Passing Ring Access Method and Physical Layer specification:

a) The data signalling rate shall be 4 Mbit/s;

b) The address length shall be 48 bits;

c) The message priority (PM) of the AMP data unit shall be 7;

d) The ALL_STATIONS_THIS_RING_ADDRESS shall be X'COOOFFFFFFFF';

7
PART 2 - SUBNETWORKS December 1 990 (Stable)

e) The TRR value shall be 4 milliseconds;

f) The THT value shall be 8.9 milliseconds;

g) The TQP value shall be 20 milliseconds;

h) The TVX value shall be 10 milliseconds;

i) The TNT value shall be 2.6 milliseconds;

j) The TAM value shall be 7 seconds;

k) The TSM value shall be 15 seconds;

I) The MAC Information field (l-field) shall be defined as follows in figure 2 below.

Sequences are as follows:

1) Starting Sequence includes: SD, AC, FC, DA, SA;

2) Ending Sequence includes: FCS, ED, FS;

m) With the above timer and MAC l-field definitions, the following limits are defined:

1) Protocol limits the l-field to a maximum of 4425 bytes;

2) All stations shall support l-fields that have a minimum of one byte and a maximum of at least 2000 bytes.

starting Sequence I-Field End Sequence

Figure 2 - l-Field Format

5.5 Fiber Distributed Data Interface (FDDI)

5.5.1 Token Ring Media Access Control (MAC, X3.1 39-1 987)

The following are implementation agreements with respect to FDDI MAC:

a) The address length shall be 48 bits;

b) There shall be some manual or programmatic means of resetting stations and

concentrators to the values specified as defaults herein or in X3. 139-1 987;

8
Part 2 - Subnetworks March 1991 (Stable)

c) The default value of T_Max shall be at least 165 milliseconds and not more than 200

milliseconds;

d) The default value of T_Req shall be equal to either T_MAX or T_Req_f\/lax^ whichever is less;

e) All FDDI stations shall process lnfo_Fields of 0 to 4478 bytes. The frame is defined as follows

in Figure 3:

f) Stations shall not use restricted token service.

SD FC DA SA Info PCS ED FS

Figure 3 - FDDI FRAME FORMAT

P: Preamble

- 16 Idle Symbols for Transmitting

- > = 6 Idle Symbols for Copying

- > = 2 Idle Symbols for Repeating

SD: Starting Delimiter (2 Symbols, JK)

FC: Frame Control (2 Symbols)

DA: Destination Address (12 Symbols)

SA: Source Address (12 Symbols)

INFO: Information Field (= <8956 Symbols)

PCS: Frame Check Sequence (8 Symbols)

ED: Ending Delimiter (1 Symbol)

FS: Frame Status (3 Symbols)

5.5.2 Token Ring Physical Layer (PHY, X3.1 48-1 988)

The following implementation agreement is with respect to the FDDI PHY specifications:

T_Req_Max is defined in the Ring Management (RMT) section of Station Management. It is used

in the resolution of duplicate address problems which prevent ring initialization. Stations which have

detected that they are duplicates during ring initialization take action to make sure that they lose

the Claim process to other stations having a T_Req value less the jthan T_Req_Max. T_Req_Max

is specified in SMT to have a value ^ « 167.8 milliseconds.

9
Part 2 - Subnetworks March 1991 (Stable)

1 The average delay, that is the time between when a station receives a Starting Delimiter (JK symbol

pair) beginning a valid frame until it repeats that Starting Delimiter, when that Starting Delimiter is preceded by a sequence of a valid frame followed by 50 Idle Symbols shall not exceed:

1 microsecond in a station, and

1 microsecond times the number of ports in a concentrator, in addition to the delays

contributed by the active slaves of the concentrator.

The measurement method described above allows a consistent repeatable measurement, however

it does not measure maximum possible delay. When the delay is one microsecond as measured

above, the maximum effective delay contribution component which can result is 1.164

microseconds. This number, not one microsecond, should be used per PHY to compute maximum

possible network delay.

5.5.3 Physical Layer Media Dependent (PMD, X3.1 66-1 989)

The following implementation agreements are with respect to the FDDI PMD specification:

1 Stations shall repeat all valid packets under all signal conditions specified in section 5.2 of X3.166-

1989, "Active Input Interface", with a bit error rate (BER) of not more than 2.5 x 10'^°;

2 Stations shall repeat all valid packets under all signal conditions specified in section 5.2, "Active

Input Interface", except that the Minimum Average Power shall be -29 dBm (2 dB above the

specified minimum), with a BER of not more than lO 'l

6 Wide Area Networks

6.1 CCITT Recommendation X.25

The procedures required to describe the DTE side of a DTE/DCE interface for systems attached to subnetworks providing an X.25 interface shall be as defined in ISO 7776 and ISO 8208 and as supplemented

below. (These procedures shall also apply to a DTE operating on a DTE/DTE interface.)

6.2 ISO 7776

ISO 7776 is used as the Layer 2 Protocol with the agreements defined below:

a) Address assignment information is as follows:

10
PART 2 - SUBNETWORKS December 1990 (Stable)

1) DTE = A (=11000000 binary);

2) DCE = B (=10000000 binary);

3) On a DTE/DTE interface, one of the DTEs, by a prior agreement, shall use

the DCE address;

b) The modulus shall be 8;

c) A window size (k) of 7 shall be supported. In addition, other window sizes may

also be supported;

d) The Multilink Procedures are excluded.

6.3 ISO 8208

The elements of ISO 8208 applicable for use depend on the OSI role of ISO 8208 (i.e., provision of CONS, support of CLNP). Independent of the role, ISO 8208 is used as the Layer 3 protocol, with the

following agreements:

a) Virtual Call Service;

b) any mutually agreed window and packet size, however, all DTEs must be capable

of supporting a window size of 2, a packet size of 128 octets, and a sequence number

modulus of 8;

c) a DTE must be capable of receiving the Flow Control Parameter Negotiation

Facility and responding appropriately (per ISO 8208);

d) The Basic RPOA Selection Facility shall be implemented and its use or non-use

selectable on a per virtual call basis.

When ISO 8208 is used to support CONS, the optional user facilities in Clause 5.1 of ISO 8878 shall also be supported.

When ISO 8208 is used to support CLNP (when providing the CLNS), Permanent Virtual Circuit Service

may also be used.

7 Integrated Services Digital Networks (ISDN)

11
PART 2 - SUBNETWORKS December 1990 (Stable)

7.1 Introduction

This clause defines Implementation Agreements for packet-data transfer in an ISDN context. The

agreements provide a set of procedures for accessing an ISDN so that end systems implemented

according to these agreements can obtain ISDN services and can successfully interoperate.

The agreements are not meant to preclude vendors from implementing additional procedures as long as

they do not create system interoperability problems. Capabilities will vary from ISDN to ISDN and

procedures beyond those included here may be necessary to request and utilize network services more

effectively and fully.

The agreements cover two fundamental ISDN services for X.25 packet mode ISDN terminals, namely,

The ISDN provides a circuit-mode (Layer 1) connection either on demand ("switched") or permanently ("dedicated circuit"). A general description of the corresponding ISDN 64

Kbps circuit-mode bearer service is described in CCITT Recommendation 1.231. The

circuit-mode connection is between an X.25 ISDN terminal and (i) a PSPDN, or (ii) another X.25 ISDN terminal. The circuit-mode connection to a PSPDN corresponds to CASE A of CCITT Recommendation X.31.

The ISDN provides the X.25 virtual circuit service. A general description of this service is given in CCITT Recommendation 1.232. This case corresponds to CASE B of CCITT

Recommendation X.31.

Figures 4 and 5 give the agreed stacks for X.25 packet transfer over D and B channels, respectively.

Some particular aspects are given below:

a) The packet data transfer is on a B channel of a Basic Access or a Primary Rate

Interface, in CASE II, it can be on a D channel of a Basic Access Interface;

b) The layer 2 procedures are LAPB (ISO 7776) on a B channel and LAPD (CCITT

Recommendation Q.921) on a D channel;

c) X.25 PLP (ISO 8208) procedures are used, including the setting up and clearing of

virtual calls;

d) Q.921 and Q.931 procedures on a D channel are used for access signaling, when

appropriate, to select the B or D channel for packet data transfer and for establishing

and releasing a physical path in the ISDN;

e) Refer to part 3 for the specification of methods for providing OSI Network Services.

12

CASE I:

CASE II:
Part 2 - Subnetworks September 1991 (Stable)

7.2 Implementation Agreements

This clause gives Implementation Agreements for individual ISDN-related protocols. The relevant protocol

stacks are given in figures 4 and 5.

OSI LAYER

Q.931 ISO 8208

(1.451) (X.25 PLP)

Q.921 (1.441)

(LAPD)

1 1 ^'l D CHANNEL

ANS Tl. 601-1988, ANS Tl. 605-1988

ADDITIONAL SIGNALING PACKET SWITCHED

FOR INCOMING PACKET* SIGNALING AND INFORMATION

CALLS TRANSFER

* MAY BE NULL

Figure 4 - Protocol Layers at S, T and U reference points when D Channel is used in ISDN

13
Part 2 - Subnetworks September 1991 (Stable)

OS I LAYER

Q.931

(1.451)

ISO 8208

(X.25 PLP)

Q.921

(LAPD)

ISO 7776

(X.25 LAPS)

D CHANNEL B CHANNEL

ANS Tl. 601-1988, ANS Tl. 605-1988

and for Primary Rate ANS T1.40|-19i|i

I I Note 1 Note 2

Figure 5 - Protocol Layers at S, T and U reference points when B Channel is used in ISDN

NOTES

1 This refers to signaling for circuit switched access (may be null), as well as additional signaling for incoming

packet calls (may be null).

2 This refers to packet switched signaling and information transfer.

7.2.1 Physical Layer, Basic Access at "U"

ANS T1 .601 -1988. "Integrated Services Digital Network-Basic Access Interface for Use on Metallic Loops for Application on the Network Side of the NT (Layer 1 Specification)" applies.

7.2.2 Physical Layer, Basic Access at S and T

ANS T1 .605-1 988, "Integrated Services Digital Network-Basic Access Interface for S and T Reference PointsLayer 1 Specification" applies.

7.2.3 Physical Layer, Primary Rate at

^

S, T, and U

fi^^ Tt,408-t99a, "ISDN Primary Rate - Customer Installation Metallic Interfaces - Layer 1 Specifrca^orf*

14

/
Part 2 • Subnetworks September 1991 (Stable)

Tho phyoi cal l ayor i s govornod! by ANS T1. 403 1080, "Carri er to Cuotomor I nstall ati on—Motalli o I ntorfaoo",

and CCI TT Rocommondati on 1 . 431 1088, "Pri mary Rate User Network I ntorfacc—Layer 1 Specifi cation"

subject to the excepti ons gi ven bel ow:

Tho foll owi ng porti ons of ANS J-\A09 1080 shall bo del eted:

a) Secti on 5.3.1: The bit rate tol erance opti on of ^ / 200 bps;

b) Secti on 5.6: Tho mi ni mum pulse density of thi s secti on;

c) Section 6.1: Tho superframo format;

d) Section 6.3: Tho compl ete secti on;

0) Section 8.0: Tho reference to tho SF format;

f) Secti on 8.3: Tho text i n paragraph 8.3.1.1 and footnote 7 (8.3.1.2);

g) Secti on 8.4.1: Footnote 0;

h) Section 0/figure 0: Provi si ons for tho use of tho f^J48M connector;

1 ) Table 2: Thi s tabl e;

j) Table 3: The ill ustrati on i n tabl e 3 of

" Robbed Bi t Si gnali ng".

The fol lowing porti ons of ANS T1. 403 1080 shall bo modi fied:

a) Secti on 5.3.2: Tho text of th i s secti on i s repl aced by:

1) "The l ine code is B8ZS except as noted i n secti on 7";

b) Section 7.0: The referenco to the pul se density requi rements of section 5.6 is i nappropri ate. Tho

text i s repl aced by:

r ANSI accred i ted subcommi ttee T1E1 is developing a standard for tho I SDN pri mary rato i ntorfaoo at roforoncG

\ poi nts "S" and "T" as well as "U". Ono of tho aoooptod gui deli nes for tho standard i s consi stency wi th ANS

^^.A03 1089. I t i s i ntended that, when this now I SDN- unique standard i s adopted, th i s agreement will bo modifi ed

to roforonce i t and will bo extended to cover i ntorfaoos at roforonco poi nts "S" and "T" as well as "U". Tho current

: standard menti oned i s at the defaul t l etter ball ot level of the draft document: T1E1 2/80 016R1. "

I SDN Pri mary

I Rato Customer I nstall ation I ntorfaoos Layor 1 Spoci fioation".

15
Part 2 - Subnetworks September1991 (Stable)

1) 'Tho provi oi onc of Cl oar Channel Capabi l i ty (CCC) dopondo upon tho uoo of tho B8ZS

li no oodo, though tho uoo of ZBTSI io ono intori m mothod that may bo ompl oyod by

agroomont of tho network and tho uoor".

Tho provi oiono of ANS T1.103 1080 ohall bo ouppl omontod by tho provi oi onc of CCI TT Roconnmondati on

ir4d4

Gooti on 4. 4.

7.2.4 Data Link Layer, D-Channel

CCITT Recommendation Q.921 (1.441 ). "ISDN User-Network Interface, Data Link Layer Specification" applies.

7.2.5 Signaling

CCITT Recommendation Q.931 (1.451), "ISDN User-Network Interface Layer 3 Specification for Basic Call Control" applies.

The following agreements have been reached concerning the use of Q.931

a) On a Basic Rate Interface supporting the ISDN virtual circuit sery/ice, all of Q.931 section 6

except for 6.1.1 and 6.2.1 (the sections covering the circuit-switched access case) shall apply. The

following sections also apply: 2.2, packet mode access connection states; 3.2, messages for packet

mode access connection control; 4-4.5, section specifying general information element handling and

encoding; 4.7, information elements for packet communications;

b) On a Primary Rate Interface supporting the ISDN virtual circuit service all of Q.931 section 6 shall apply except for 6.1.1 and 6.2.1 (the sections specifying the circuit switched access case), 6.1.2.2, 6.2.2.2 and 6.4.2 (the sections specifying D-Channel ISDN Virtual Circuit service case). The following

sections also apply: 2.2, packet mode access connection states; 3.2, messages for packet mode

access connection control; 4-4.5, sections specifying general information element handling and

encoding; 4.7, information elements for packet communications;

c) On a Basic or Primary Rate Interface supporting the unrestricted 64-Kbps circuit-mode service,

Q.931 sections 6.1 .1 , 6.2.1 , 6.4.1 and 6.4.3 shall apply. The following sections also apply: 2.1 , circuit mode connection states; 3.1, messages for circuit mode connection control; 4-4.5, sections

specifying general information element handling and encoding.

16
PART 2 - SUBNETWORKS December 1990 (Stable)

7.2.6 Data Link Layer B-Channel

The agreements on ISO 7776 specified in 6.2 shall apply here.

If the ISDN provides a circuit-mode service between two ISDN packet-mode devices, then the layer 2

address shall be assigned as follows:

a) For permanent ("non-switched") circuit-mode service, one terminal uses address A

and the other terminal uses address B, as arranged by prior agreement;

b) For demand ("switched") circuit-mode service, the terminal originating the circuit- mode call uses address A and the other terminal uses address B.

7.2.7 Packet Layer

The agreements on ISO 8208 specified in 6.3 shall apply here. When ISO 8208 is used on the DChannel, the maximum DATA packet size (i.e., actually the maximum size of the User Data Field in a DATA packet) shall be limited to 256 octets.

17
PART 2 - SUBNETWORKS December 1 990 (Stable)

Annex A (informative)

Cross Reference Between CCiTT and ANSI Text Relating to ISDN

Agreements

This annex provides a cross-reference listing between those sections of the CCITT ISDN

Recommendations given in clause 7 of this document and the sections of the corresponding ANSI ISDN

Standards. This appendix does not supersede clause 7 but merely provides a pointer to those who wish

to implement the ISDN procedures based on ANSI Standards.

A.1 Data Link Layer, D-Channel

CCITT Recommendation Q.921, which is referenced in 7.2.4 of this document, is identical to ANSI

Standard T1.602.

A.2 Signaling

The following table provides the cross-references between those sections of CCITT Recommendation

Q.931 referenced in 7.2.5 of this document and the corresponding ANSI ISDN Standards.

Table 1 - ANSI-CCITT Cross-References

CCITT RECOMMENDATION Q.931 ANSI T1.608

Section 2.1 Section 4.1 (refers to sec. Section

Section

2.2

3.1

2.1.1 of ANSI T1.607)

Section 4.2

Section 5.1 (refers to sec. Section

Section

Section

Section

Section

Section

Section

Section

Section

Section

Section

Section

Section

Section

Section

3.2

4.1

4.2

4.3

4.4

4.5

4.7

6

6.1.1

6.1.2.2

6.2.1

6.2.2.2

6.4.1

6.4.2

6.4.3

3 of ANSI T1.607)

Section 5.2

Section 6.1

Section 6.2

Section 6.3

Section 6.4

Section 6.5

Section 6.5

Section 7 Section 7.1.1

Section 7.1.2.2

Section 7.2.1

Section 7.2.2.3

Section 7.4.1

Section 7.4.2

Section 7.4.3

18
PART 2 - SUBNETWORKS December 1990 (Stable)

Annex B (informative)

Bibliography

ANS 11.607-1989, Telecommunications - Digital Subscriber Signaling System #1 - l_ayer 3 Signaling

Specification for Circuit Switched Bearer Sen/ice.

ANS T1 .608-1 989, Telecommunications - Digital Subscriber Signaling System #1 - Layer 3 Signaling

Specification for Packet Switched Bearer Service.

CCITT Recommendation 1.430 (Blue Book), Basic User-Network Interface - Layer 1 Specification.

FIPS 107, Local Area Networks: Baseband Carrier Sense Multiple Access with Collision Detection

Access Method and Physical Layer Profiles and Link Layer Protocol, NTIS, U.S. Department of Commerce, 5285 Port Royal Road, Springfield, VA 22161.

19

stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 3 - Network Layer

Output from the June 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Fred Burg

Kristy Brown Workshop Editor: Brenda Gray
Part 3 - Network Layer June 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Lower Layers Special Interest Group

(LLSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI). 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. Significant technical changes from this text as previously

given are routi ng addfiassincj-related. References are made to Part 2 in this part.

Annex A is for information only.

Future changes and additions to this version of these Implementor Agreements will be published as change

pages. Deleted and replaced text will be shown as stri keout. New and replacement text will be shown as shaddd.

ii
Part 3 - Network Layer

NOTE - The term "Ongoing" used in this document refers to the Working Implementation Agreements dated

December 1990.

0 Introduction

This part presents agreennents for providing the OSI network sen/ice. AJso contained here are agreements

on network layer addressing and routing.

1 Scope

These agreements cover both connectionless-mode and connection-mode network sen/ices.

2 Normative References

2.1 CCITT

[1] Recommendation X.213 (Blue Book, 1988), Network Sen/ice Definition for Open Systems

Interconnection for CCITT Applications.

2.2 ISO

[2] ISO 8348, Information processing systems - Data communications - Network service defintion.

[3] ISO 8348 Addendum 1 , Information processing systems - Data communications - Network sen/ice

definition - Addendum 1: Connectionless-mode transmission.

[A] ISO 8348 Addendum 2, Information processing systems - Data communications - Network sen/ice

definition - Addendum 2: Network layer addressing.

[5] ISO 8473, Information processing systems - Data communications - Protocol for providing the

connectionless-mode network service.

[6] ISO 8648, Information processing systems - Open systems interconnection - Internal organization

of tfie Network Layer.

[7] ISO 8878, Information processing systems - Data communications - Use ofX.25 to provide the OSI

connection-mode network sen/ice.

[8] ISO 8881 , Information processing systems - Data communications - Use of the X.25 packet level protocol in local area networks.

[9] ISO 9542, Information processing systems - Telecommunications and information exchange

1
Part 3 - Network Layer March 1991 (Stable)

between systems - End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode sen/ice (ISO 8473).

[10] I SO/I EC 9574, Information technology - Telecommunications and information exchange between

systems - Provision of the OSI connection-mode network service by packet mode terminal

equipment connected to an integrated sen/ices digital network (ISDN).

[11] I SO/I EC TR 9577, Information technology - Telecommunications and information exchange between

systems - Protocol identification in the network layer.

[12] ISO/IEC TR 10029, Information technology - Telecommunications and information exchange

tyetween systems - Operation of an X.25 interworking unit.

[13] ISO/IEC 10030, Information processing systems - Telecommunications and information exchange

between systems - End system routeing information exchange protocol for use in conjunction with

ISO 8878.

3 Status

This version of the agreements was completed in December 1990.

4 Errata

This clause may contain "Defect Report" and resolutions material, and the versions of implementor

agreements to which this material applies.

The following defects are being progressed in ISO:

a) ISO 9542, defect 1, Parts 1-13.

5 Connectionless-Mode Network Service (CLNS)

5.1 ISO 8473

Subsets of the protocol are as follows:

a) Implementations will not transmit PDUs encoded using the inactive subset. Received PDUs

encoded using the inactive subset will be discarded;

b) The non-segmenting subset will not be used. Implementations will not generate data PDUs

without a segmentation part. However, implementations will receive and correctly process PDUs

which do not contain the segmentation part.

Mandatory Functions of ISO 3473 are as follows:

2
Part 3 - Network Layer March 1991 (Stable)

a) The lifetime parameter sliall be used as specified in ciause 6.4 of iSO 8473. Tine parameter shaii have an initial value of at least three times the network span or three times the maximum transit delay (in units of 500 milliseconds), whichever is greater;

b) The reassembly timer for an initial PDU at the reassembly point shall be no greater than the

largest value of all lifetime parameters contained in all derived PDUs;

c) The use/non-use of checksums shall be capable of being configured. The default setting shall be non-use;

d) If the implementation supports the generation of an ER PDU, the system shall insert in the

destination address field of the ER PDU the contents of the source address field of the PDU that generated the error;

e) For the purposes of relaying and routing, a protocol entity need not verify the correctness of ISO

8348/Add. 2 semantics carried in NPAI of received PDUs.

Optional Functions of ISO 8473 are as follows:

a) The Security parameter is not defined by these Agreements. Implementations shall not transmit

the parameter except where defined by bilateral agreements;

b) Partial and complete source routing will not be supported;^

c) Parti al record of route will bo supported by I ntormodi ato GyGtomo;

d) ISO 8473 will be followed with respect to QOS;

e) For systems implementing the congestion notification function, the following applies:

1) A Globally Unique QOS Maintenance parameter shall be included in all PDU originated

by End Systems. As specified in ISO 8473, the initial value of the Congestion Experienced

flag (CE flag) within the Globally Unique QOS Maintenance Parameter shall be set by the

originating End System to zero. All other flags within the Globally Unique QOS Maintenance

Parameter shall be set based on the specific local needs of the originating End System;

2) Intermediate systems not implementing queue length averaging shall leave the CE flag

in the same state as it was received. In particular, no intermediate system (IS) shall ever

clear (set to zero) the CE flag. All intermediate systems shall monitor all incoming and

outgoing queues and compute average queue lengths as shown by example in figure 1

The averaging is done from the beginning of the previous cycle to the current time. A cycle

begins at the instant of the first NSDU arrival after an idle period;

3) An IS should set the CE flag in all NSDUs forwarded on a queue which has an average

queue length greater than one;

A defect exists with the Partial Source Routing option which can cause PDUs to loop in the

network until their lifetime expires.

3
Part 3 - Network Layer March 1991 (Stable)

4) The queue length averaging algorithm computes the average queue length over two

cycles, where the two cycles are:

a) the "previous cycle", which is the interval from when the IS becomes busy, until

it t>ecomes idle and the idle ends (indicated by the instant the first packet arrives to the idle IS);

b) the "current cycle", which is the interval from the end of the idle interval to the

current time instant when the average queue length is computed;

5) An embodiment of the averaging algorithm is shown in figure 1

;

f) Refer to the Ongoing Implementation Agreements document for additional optional functions.

The algorithm makes use of the following variables:

t = Current time

tj = time of i^" arrival or departure event

= number of packets in the system after the event

Tq = time at the beginning of the previous cycle

T-j^ = time at the beginning of the current cycle

The algorithm consists of three components:

1. Queue Lenath Update: Beginning with qQ = 0,

If the i^f^ event is an arrival event, q^^ = q^_2^+l

If the i'-" event is a departure event, q^ = qj^_3^-l

2. Queue Area (integral) update:

Area of the previous cycle = 2 qi-iCt^-t

tie{To,Ti)

Area of the current cycle - Z ^i-1 ( ^i~^i-l

)

3. Average Queue Length Update:

Average Queue length over the two cycles

Area of the two cycles Area of the two cycles

Time of the two cycles t-T 0

Figure 1 - Queue Length Averaging Algorithm.

4
Part 3 - Network Layer March 1991 (Stable)

The algorithm makes use o£ the following variables:

t = Current time

tj^ = time of i^" arrival or departure event

qj^ = number of packets in the system after the event

Tq = time at the beginning of the previous cycle

T-^ = time at the beginning of the current cycle

The algorithm consists of three components:

1. Queue Length Update: Beginning with qQ = 0,

If the i^l* event is an arrival event, q^ = qj^_2^+l

If the i*-" event is a departure event, q^^ = qj^_j^-l

2. Queue Area (integral) update:

Area of the previous cycle = E ) ti£{To,Ti)

Area of the current cycle = Z q^^ l(*^i~*^i-l)

3. Average Queue Length Update:

Average Queue length over the two cycles

Area of the two cycles Area of the two cycles

Time of the two cycles t-^Q

Figure 1 - Queue Length Averaging Algorithm.

5.2 Provision of CLNS over Local Area Networl<s (LANS)

When providing CLNS over a LAN subnetwork, the following shall apply:

a) The definition of CLNS shall be as specified in ISO 8348/Add. 1;

b) The protocol used to provide CLNS shall be ISO 8473 with agreements as specified in 5.1;

c) The necessary subnetwork dependent convergence function shall be as defined in ISO 8473

Clause Br&A- 8,4.2, SNDCF used with ISO 8802/2 sub-networks".

5
Part 3 - Network Layer March 1991 (Stable)

5.3 Provision of CLNS over X.25 Subnetworks

When providing CLNS over X.25 subnetworks, the following shall apply:

a) The definition of CLNS shall be as specified in ISO 8348/Add. 1

;

b) The protocol used to provide CLNS shall be ISO 8473 with agreements as specified in 5.1;

c) The necessary subnetwork dependent convergence function shall be as defined in ISO 8473 - clause &t&t2 8^4,3, "SNDCF used with ISO 8208 subnetworks for operation over X.25 subnetworks",

and the default throughput class shall be used if this facility is available;

d) The X.25 PLP shall be as specified in part 2 clause 6.3.

5.4 Provision of CLNS over ISDN

When providing CLNS over an ISDN, the following shall apply:

a) The definition of CLNS shall be as specified in ISO 8348/Add. 1;

b) The protocol used to provide CLNS shall be ISO 8473 with agreements as specified in 5.1;

c) The necessary Sub-network Dependent Convergence function shall be as defined in:

1) ISO 8473 for operation of CLNP over X.25 with agreements as specified in 5.3;

2) ISO 9574 for control of the B and D channels;

3) The X.25 PLP shall be as specified in part 2, clause 6.3;

4) The agreements for the ISDN-related protocols are specified in part 2, clause 7. NOTE - The stated scope of ISO 9574 does not explicitly cover the operation of CLNP over an ISDN. However, the procedure identified for operating X.25 in conjunction w/ith 1.451 is still applicable. The procedures

in ISO 9574 that correspond to 8878 are not utilized w/hen providing CLNS.
PART 3 - NETWORK LAYER December 1 990 (Stable)

5.5 Provision of CLNS over Point-to-Point Links

(Refer to the Ongoing Implementation Agreements document).

6 Connection-Mode Network Service (CONS)

The following agreements concern provision of the connection-mode Network Service.

6.1 Mandatory Method of Providing CONS

6.1.1 General

Independent of the subnetwork type (of part 2), when providing the CONS using X.25-1984, the following

shall apply as described below:

a) The definition of the CONS Is as specified in ISO 8348, Network Service Definition:

b) The mapping of the elements of the CONS to the elements of the X.25 Packet

Layer Protocol (PLP) is as specified in 6.3.1;

c) The general procedures and formats of the X.25 PLP are as specified in ISO 8208,

X.25 Packet Layer Protocol for Data Terminal Equipment.

6.1.2 X.25 WAN

No provisions additional to those In 6.1.1 apply in an X.25 WAN.

6.1.3 LMls

When providing the CONS in a Local Area Network, the following aspects of ISO 8881, in addition to the

documents listed in 6.1.1, shall apply:

a) Clauses 1-6 and 9-11 for LLC Type 1 operation, including the additional

nonstandard default packet size listed in Clause 6.3, Note 2.

NOTE - Operation of ISO 8208 in conjunction with LLC Type 2 requires agreement on LLC Type 2

procedures.

7
PART 3 - NETWORK LAYER December 1990 (Stable)

6.1.4 ISDN

When providing the CONS in an ISDN, the considerations for control of a B and D channel in ISO 9574,

in addition to those provided in 6.1.1, shall apply.

6.2 Additional Option: Provision of CONS over X.25 1980

Subnetworks

When providing CONS over an X.25 1980 subnetwork, the following shall apply:

a) The definition of the CONS is as specified in ISO 8348, Netv^ork Service Definition :

b) The subnetwork dependent convergence protocol required to provide CONS shall

be as specified in ISO 8878 Annex A, and referred to as the Alternative Procedures for

Network Connection Establishment and Release, with agreements as defined in 6.3.2.

6.3 Agreements on Protocols

6.3.1 ISO 8878

ISO 8878 Clauses 1-1 1 shall apply with the following exception:

a) Where the ISO 8208 diagnostic codes are not provided, all Cause/Diagnostic

code combinations can be mapped to the Originator/Reason code of "Undefined".

6.3.2 Subnetwork Dependent Convergence Protocol (ISO 8878/Annex A)

The Receipt Confirmation service will not be provided, so the corresponding protocol elements need not be implemented.

The Expedited Data sen/ice will not be provided, so the corresponding protocol elements need not be

implemented.

6.4 Interworking

Interworking between subnetworks whose End Systems use ISO 8208 to provide the CONS as specified

in 6.1 shall be performed as specified in ISO TR 10029. That is, an Intermediate System connecting two

such subnetworks shall operate ISO 8208 on both subnetworks and shall relay information from one

subnetwork to the other as described in ISO TR 10029.

8
Part 3 - Network Layer June 1991 (Stable)

7 Addressing

NSAP address formats supported will conform to Addendum 2 of ISO 8348 as follows:

a) NSAP address formats will have a hierarchical structure. This will reduce the size of routing

tables;

b) If used in the Domain Specific Part (DSP), an NSAP selector shall be the least significant

component in the hierarchy, and shall be encoded as the last octet of the DSP. The NSAP

selector shall not be used to perform routing; it is simply intended to identify the network service user at the destination end system. For those implementations using an NSAP selector, there

shall be one and only one selector for each NSAP within the end system. All NSAP addresses

identifying a given NSAP will use the same NSAP selector value.

c) In routlnq erwlronm^ts in which $ystems support NSAP addresses containing

specters as specified in b). ttie corresponding Network Entity Titles shall have the same

fonmat with the NSAP selector set to zero.

NOTE » This may be incompatible wth syslmis imf^tem^ntecl accorcttng to previous versions of these

8 Routing

The basic principles of Network Layer routing are defined in the OSI Routing Framework ISO/IEC TR

9575. These principles state that:

a) The global OSI environment will consist of a number of Administrative Domains, An

Administrative Domain consists of a collection of End Systems (ESs) and Intermediate Systems

(ISs), and subnetworks operated by a single organization or Administrative Authority. The

Administrative Authority is responsible for: the organization of ESs and ISs into Routing

Domains; the assignments of NSAP and SNPA addresses; the policies that govern resource

usage; the policies that govern the information that is collected and disseminated both internally

and externally to the Administrative Domain; and the establishment of subdomains and the

corresponding delegation of responsibilities;

b) A Routing Domain is a set of ESs and ISs which operate according to the same routing

procedures and which is wholly contained within a single Administrative Domain. An

Administrative Authority may delegate to the entity responsible for a Routing Domain the

responsibilities to further structure and assign NSAP and SNPA addresses. The hierarchical

decomposition of Routing Domains into subdomains may greatly reduce the resources required

in the maintenance, computation, and storage of routing information;

c) The OSI routing problem, and consequently OSI routing protocols, has been decomposed

into three distinct classes:

9
Part 3 - Network Layer June 1991 (Stable)

1) End System (ES) to Intermediate System (IS) routing within a single subnetwork;

2) IS to IS routing within a single routing domain (Intra-domain);

3) IS to IS routing between routing domains (Inter-domain).

8.1 ISO 9542 End System to Intermediate System Routing

For use in conjunction with ISO 8473 over LANs (refer to part 2, clause 5) and point-to-point links, ISO

9542 shall be used to provide the routing exchange protocol.

Additionally, a management mechanism capable of adding and deleting entries into the Routing

Information Base (RIB) is recommended. When using the management mechanism to add an entry,

there should be no holding timer, and the entry should be write protected from alteration by the ES-IS

protocol. This mechanism enables routing table entries to be made which are static in nature.

The agreements below apply to the use of ISO 9542:

a) Implementors shall support any valid NSAP format. For the purposes of the protocol, NSAP

addresses are treated simply as octet strings;

b) For LANs, implementors shall support both Configuration Information and Route Redirection

Information; no subsets are permitted;

c) All timer values shall be configurable;

d) Use or non-use of checksums shall be configurable. It is recommended not to use ISO 9542

checksums when originating PDUs;

e) The QOS, Security and Priority parameters should not be used for routing. For conformance,

intermediate systems must transmit these parameters in RD PDUs if they are present in the data

PDU which generated the redirect. However, end systems must ignore them in received RD

PDUs;

f) If the configuration notification function described in 6.7 of the protocol specification is implemented, a mechanism shall be provided to enable/disable this function on broadcast

networks. If supported in end systems listening to both ISHs and ESHs, this function shall only

be invoked upon receipt of an ISH. Alternate mechanisms for ISs and ESs are described in 8.1.1 and 8.1.2.

g) For LANs, this protocol employs the same LSAP as ISO 8473;

10
Part 3 - Network Layer June 1991 (Stable)

h) The encoding of the BSNPA address follows the syntax rules for the data link being used. On

a LAN, for example, it is a 48-bit MAC address encoded as specified in clause 12.2.1.4 of ISO

10039;

i) The multicast addresses corresponding to "All Intermediate Systems on the Network"

(ALLJSN) and "All End Systems on the Network" (ALL_ESN) shall default to the following on

IEEE802.3 and IEEE802.4 subnetworks:

1) ALL_ESN = 09-00-2B-00-00-04, ALLJSN = 09-00-2B-00-00-05;

2) It is understood that the hexadecimal octets shown are transmitted onto the medium

from left most octet to right most octet. Within each hexadecimal octet the least

significant bit is transmitted first;

j) The multicast addresses corresponding to "All Intermediate Systems on the Network"

(ALLJSN) and "All End Systems on the Network" (ALL_ESN) shall default to the following two

functional addresses on IEEE802.5 subnetworks:

1) ALL_ESN = COOO 0000 4000, ALLJSN - COOO 0000 8000;

2) It is understood that the hexadecimal octets shown are transmitted onto the medium

from left most octet to right most octet. Within each hexadecimal octet the most

significant bit is transmitted first;

Editor's Note - Note that in the hexadecimal representation defined in ISO 10039, these addresses would

be:

1) ALL_ESN = 03-00-00-00-02-00

2) ALLJSN = 03-00-00-00-01-00

NOTE - This notation presents the octet values such that the least significant bit is that transmitted first.

k) The Error Report flag shall be set to zero (0) for NPDUs sent as a result of invoking the

QUERY Configuration Function.

I) ISO 8473 PDUs multicast as a result of the Query Configuration function shall use the

Network Layer Protocol ID (NLPID) assigned to ISO 8473.

m) An ISO 8473 PDU received as a result of another ES having performed the Query

Configuration function shall be processed as follows:

1) If the ISO 8473 PDU is addressed to one of the NSAPs present in the ES, the End

System shall process the PDU according to the applicable clauses of ISO 8473 and

Invoke the Configuration Response Function (clause 6.6 of ISO 9542);

2) If the ISO 8473 PDU is not addressed to one of the NSAPs present in the ES, the

11
Part 3 - Network Layer June 1991 (Stable)

End System shall discard the PDU without generating an ISO 8473 Error Report;

n) For purposes of address matching and SNPA extraction, the first octet of the option

parameter value of an address (clause 7.4.5) or SNPA Mask (clause 7.4.6) shall be aligned with

the first octet (API) of the encoded trial NSAP Address.

The following Items represent proposed solutions to defects in ISO 9542. These solutions are being

progressed as defect reports to ISO 9542. These Items will be deleted when the corresponding defect

report Is approved:

a) An End System may choose to ignore an RD PDU received for a destination to which the ES

has not sent traffic for some period of time. An ES must record redirection information only for those other systems with which it Is in active communication;

b) A holding time value of zero is permitted. When configuration and/or redirection information

with a zero holding time Is received, prior Information shall be replaced, thus causing the system

to set Its holding timer to zero and discard the corresponding Information;

c) If one or more ISs suggested an ESCT, the minimum of the non-zero suggested values

replaces the current value of the ES's CT.

8.1 .1 Alternative Configuration Mechanism - IS Actions

An alternative mechanism for achieving rapid configuration which is scaleable to large broadcast

networks Is described below. This mechanism makes use of the Suggested ES Configuration Timer.

Implementation of this mechanism is optional.

When an Intermediate system wants to quickly acquire the End system configuration (for example, when

a broadcast circuit is enabled on the IS or the topology changes because of a failure of a bridge or

repeater), it initiates a "poll" of the End system configuration by performing the following actions:

a) Delay a random interval between 0 and PollESHelloRate seconds. (This is to avoid

synchronization with other ISs which have detected a change.);

b) In order to rapidly time out any End systems which are no longer present on the broadcast

circuit (for example, after a LAN partition), reset the entryRemainingTlme in the Routing

Information Base for all End systems on this circuit to the value: (ISHelloTimer +

PollESHelloRate) * HoldingMultlplier or the existing value whichever is lowest. Where

ISHelloTimer Is the Intermediate system's configuration timer, HoldingMultlplier is a predefined

number (for example, 2) which multiplied by ISHelloTimer gives the value for the Holding Time

field of IS Helios;

c) Then transmit HoldingMultlplier IS Helios with a Suggested ES Configuration Timer value of PollESHelloRate seconds with an inten/al of ISHelloTimer seconds between each and setting the

Holding Time field to ISHelloTimer * HoldingMultlplier;

d) Then start sending IS Helios with a Suggested ES Configuration Timer of DefaultESHelloRate

seconds (where DefaultESHelloRate Is larger than PollESHelloRate).

12
Part 3 - Network Layer March 1991 (Stable)

8.1.2 Alternate Configuration Mechanism - ES Actions

An End system maintains for each circuit a list (CTList) wfiich has HoldingMultiplier elements each of which stores a received value of the Suggested ES Configuration Timer. The function SaveCT(t) adds the

value t as the first element of CTList and discards the last element. The function MinCT delivers the

minimum value in CTList. When the circuit is enabled all the elements of CTList are initialized to PollESHelloRate.

An End system also maintains for each circuit the variables currentSuggestedHelloTimer and its associated lifetime currentSuggestedHelloTimerLifetime. These are both initialized to PollESHelloRate.

When the circuit is enabled the Configuration Timer is started by setting the entryRemainingTime to random (PollESHelloRate).

On Configuration Timer expiry the following actions are performed:

a) SaveCT(currentSuggestedHelloTimer);

b) Transmit an ES Hello with Holding Time field set to MinCT * HoldingMultiplier;

c) Set entryRemainingTime to MinCT - random(MinCT * 0.25). (The random element ensures

that End systems do not become synchronized.)

When an End system receives an IS Hello which contains a Suggested ES Configuration Timer, it is processed as follows (where suggestedESCT is the value contained in the option):

a) If suggestedESCT is less than or equal to currentSuggestedHelloTimer then set curentSuggestedHelloTimerLifetime to the value of the Holding Time field of the IS Hello;

b) If suggestedESCT is less than currentSuggestedHelloTimer then set currentSuggestedHelloTimer to suggestedESCT and reset entryRemainingTime to the smaller of

its current value and random(currentSuggestedHelloTimer * 0.75).

When the currentSuggestedHelloTimerLifetime expires, set the currentSuggestedHelloTimer to DefaultESHelloTimer.

8.2 ISO 10030 End System to Intermediate System Routing

The protocol used to provide End System to Intermediate System routing in support of the CONS (refer to 3.6) shall be ISO 10030.

The following agreements apply to the use of ISO 10030:

a) A management mechanism capable of adding and deleting entries in the Routing Information

Base (RIB) of both SNAREs and End Systems is recommended. When using the management

mechanism to add an entry it should not be timed out, and the entry should be write protected

from alteration by the ISO 10030 protocol.

13
Part 3 - Network Layer March 1991 (Stable)

h) Thfif fmilSc^ a<ldr6$$6$ fiOftespondlng to *M OOMS End ^ysieras" and '^All CONS mmE^''

shad de^ult to Ibe following on IEEE 80^.3 and JEEE S02:^4 suljnelworkK

1> Ail CONS End Systems 01-80<:a-00^»16

Z) M com SNARE: - O1^^2h00HDD*17

8.3 Intra-Domain Intermediate Systems to Intermediate Systems

Routing

Intermediate systems shall provide mechanisms to create and update the required Routing Information Base.

8.4 Inter-Domain Intermediate Systems to Intermediate Systems

Routing

An Administrative Authority shall determine the procedures and policies that govern the exchange of routing information with other routing domains.

Intermediate systems shall provide management mechanisms to configure the required inter-domain

routing information.

9 Procedures for OSI Network Service/Protocol Identification

9.1 General

The Protocol Identifiers specified in ISO TR 9577 ("Protocol Identification in the OSI Network Layer")

provide a basis from which OSI systems (both end systems and intermediate systems) may derive a set

of procedures for indicating which OSI protocols are used in a particular instance of communication. As

such, these procedures are only concerned with Initial Protocol Identifiers (IPIs) and Subsequent

Protocol Identifiers (SPIs) that identify OSI protocols and pertain to the following types of systems:

a) systems providing/supporting only CONS (using ISO 8208/8878);

b) systems providing/supporting only CLNS (using ISO 8473);

c) systems providing/supporting both CONS and CLNS.

From this set of definitions, the following possibilities for success (S) or failure (F) of an instance of communication can be defined, as shown in the table below:

14
PART 3 - NETWORK LAYER December 1990 (Stable)

Table 1 - End Systems Communications

Originating Destination End System Type

End System Type A B C

A S F S

B F S S

C S S S

9.2 Processing of Protocol Identifiers

The usage of Protocol Identifiers in Network Protocol Data Units (NPDUs) depends on several factors:

a) the OSI Network Service to be provided;

b) the protocol to be used in providing this service;

c) the role the protocol is to be used in (per the Internal Organization of the Network

Layer);

d) the type of subnetwork to which the system is connected.

9.2.1 Originating NPDUs

The use of a particular OSI Network Service depends on the capabilities of both the origination and

destination end systems. It is not the intent of this clause to provide guidelines on how to make this choice except for simple obvious criteria; rather, it is intended only to provide guidance on how to convey this choice to the destination system.

Where a priori knowledge exists in the originating end system about the capabilities (with respect to OSI

Network Services available) of the destination end system, it should be used. This may result in no

communication if the two end systems involved only provide Network Services of different types. A

selection is required in cases where both end systems provide both types of network sen/ices; this selection is conveyed by the use of the I PI and SPI (but the selection process is an implementation

matter). Alternatively, where a priori knowledge does not exist, then the selection of a sen/ice to use in an instance of communication depends solely on the capabilities of the originating end system as

described below:

a) If only CONS-related protocols (e.g., ISO 8208) are available, then this should be

used and the Protocol Identifiers specified so as to reflect the chosen protocol (s) and

service;

15
PART 3 - NETWORK LAYER December 1990 (Stable)

b) If only CLNS-related protocols (e.g., ISO 8473) are available, then this should be

used and the Protocol Identifiers specified so as to reflect the chosen protocol (s) and

service;

c) If both services are available, then other criteria are used in deciding which to use

in an instance of communication.

NOTE - The choice of OSI Network Service to be used in an instance of communication is reflected in the Network Service primitives issued by the Network Service user.

Once a selection of Network Service has been made, the use of particular protocols depend on, for example, the subnetwork to which the originating End System is attached. Some specific cases are

given in Annex A of ISO TR 9577. Another case involves use of the Protocol for Providing the

Connectionless Network Service directly over the Data Link Sen/ice, as given in ISO 8473 (e.g., in a

LAN). In this case, the IPI indicates ISO 8473.

9.2.2 Destination System Processing

A system receiving an NPDU must first be concerned with the protocol identified by the IPI. Valid values

are given in table 2 of ISO TR 9577. If the protocol is recognized as one supported by the system,

further processing of the protocol is performed according to the rules of that protocol. If not, an error

is recognized and may be conveyed to the originating peer entity. With respect to ISO 8208 and ISO

8473, the following would apply for such error conditions:

a) For ISO 8208, the condition is classified as an "invalid General Format Identifier",

for which a DIAGNOSTIC packet may be returned. If DIAGNOSTIC packets are not

used by the system, the NPDU is discarded without any further action;

b) For ISO 8473, the NPDU is discarded without any further action.

Given acceptance of the protocol identified by the IPI, the system must also determine the acceptability

of the subsequent protocols and OSI Network Service being requested. Use of ISO 8473 implies CLNS;

however, use of ISO 8208 can imply either CONS or CLNS, as identified by the SPI. In the case of ISO

8208, therefore, further processing is needed to determine the acceptability of the requested

protocol/service. If these are not acceptable (e.g., not supported by the system), the call should be

cleared with a diagnostic code of "Connection Rejection - unrecognizable protocol identifier in user

data" (decimal 249).

NOTE - In ISO 8208, a call may be refused for reasons other than non-support of the requested OSI

Network Service.

16
PART 3 - NETWORK LAYER

9.2.3 Further Processing in Originating End System

December 1990 (Stable)

Further processing on receipt of an NPDU in response to an initial attempt to communicate may be

necessary/useful to determine the success of such an attempt.

For ISO 8473, when used directly over the Data Link Service, the success or failure of an attempt to communicate may not t>e visible/obvious within the Network Layer. On the other hand, use of ISO 8473

over ISO 8208 may provide, via the diagnostic code in a received CLEAR INDICATION packet, an

indication of failure to communicate (e.g., the remote system does not support CLNS).

When using ISO 8208 to provide the CONS, the diagnostic code in a received CLEAR INDICATION

packet may provide the necessary indication of why a call was refused. In cases where an ISO 8208 call

is refused with diagnostic #249, it would not be desirable to re-attempt such calls with the exact same

set of parameters; however, how the originating system ensures this is a local matter.

In cases where an originating system is capable of supporting both OSI Network Services, it may wish

to re-attempt communications using the other mode of Network Service than that initially attempted.

9.3 Applicable Protocol Identifiers

The protocol identifiers applicable to these agreements are given in table 2 and table 3.

Table 2 - IPI Values

Bit Pattern 87654321 Protocol

00001000

10000001

10000010

xxOlxxxx

xxlOxxxx

OOllxxxx

CCITT I.451/Q.931

ISO 8473 (excluding the

inactive subset)

ISO 9542

ISO 8208/CCITT X.25-Modulo 8

ISO 8208/CCITT X.25-Modulo 128

ISO 8208/CCITT X.25-GFI Extension

17
PART 3 - NETWORK LAYER December 1990 (Stable)

Table 3 - SPI Values

Bit Pattern^ 87654321 Protocol

00000000

thru 00111111

10000001

10000100

ISO 8073 ADDl/CCITT X.224

See table 4.1

ISO 8473

ISO 8878/Annex A

NOTES

1 A null SPI value (e.g., no Call User Data Field in an

ISO 8208/CCITT X.25 Call Request/Incoming Call packet)

shall indicate ISO 8073/CCITT X.224.

When using ISO 8208, values other than one of those listed In table 3 are outside the scope of these

agreements.

10 Migration Considerations

This clause considers problems arising from evolving OSI standards and Implementations based on

earlier versions of OSI standards.

Until there Is widespread availability of 1984 X.25 service, it will be necessary for X.400 systems to use

those existing packet-switched public data networks which offer only pre-1984 X.25 service. While 1980

X.25 does not provide the CONS as defined by ISO 8348, there is no implication of non-conformance to these Agreements resulting therefrom for systems using 1980 X.25 to interchange data at the Network

Layer, provided they conform in all other respects.

This is an exception to the Agreements for providing the OSI Network Service, granted temporarily for

practical reasons. This exception will be removed when it is deemed to be no longer necessary, in the

judgement of the Workshop. While this provision is in effect, it provides an alternative method of using

1980 X.25 to the provisions of 6.2.

1 1 Use of Priority

Refer to the Ongoing Implementation Agreements document.

18
PART 3 - NETWORK LAYER

11.1 Introduction

Refer to the Ongoing ImpSementation Agreements document.

1 1 .2 Overview

Refer to the Ongoing Implementation Agreements document.

12 Conformance

Refer to the Ongoing Implementation Agreements document.

December 1990 (Stable)

19
PART 3 - NETWORK LAYER December 1990 (Stable)

Annex A (informative)

Bibliography

CCITT Recommendation X.223 - 1988, Use of X.25 to Provide tlie OSI Connection-mode Networl<

Service for CCITT Applications.

FIPS 100, Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment

(DCE) for Operation with Packet-Switched Data Communications Networks, NTIS, U.S. Department of Commerce, 5285 Port Royal Road, Springfield, VA 22161.

ISO/IEC 8880-1, Information Processing Systems - Data Communications - Protocol Combinations to Provide and Support the OSI Network Service - Part 1 : General Principles.

ISO/IEC 8880-2, Information Processing Systems - Data Communications - Protocol Combinations to Provide and Support the OSI Network Service - Part 2: Provision and Support of the Connection-mode

Network Service.

ISO/IEC 8880-3, Information Processing Systems - Data Communications - Protocol Combinations to Provide and Support the OSI Network Service - Part 3: Provision and Support of the Connectionlessmode Network Sen/ice.

ISO/IEC TR 9575, Information Technology - Telecommunications and Information Exchange Between

Systems - OSI Routing Framework.

20
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 4 - Transport

Output from the June 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Fred Burg

Kristy Brown Workshop Editor: Brenda Gray
PART 4 - TRANSPORT June 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Lower Layers Special Interest Group

(LLSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI). 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. Si gnificant toohnioal changes from th i s text ao provi ouol y

given arc i n class 4 protocol (

i ncl udi ng rotranomi osi on t i mer), and i n cl ass 0 protocol .

Future changes and additions to this version of these Implementor Agreements will be published as change

pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded.

ii
Part 4 - Transport

0 Introduction

These agreements support the integration of U^Ns, pacl<et networks, and other WANs with the smallest

possible set of mandatory protocol sets, in accordance with the other agreements already reached. Nothing

here shall preclude vendors from implementing protocol suites in addition to the ones described in this document.

1 Scope

This chapter presents agreements for providing the OSI Transport layer services over both connection mode

and connectionless mode services.

2 Normative References

2.1 CCITT

{1| ReconimendatloR X214 (Blue Book, 1988), TransfiOft Service Definition for Open Systems

tntercoan^tton for CCfTTAppiicaffotm,

|2| flect3fT)mendatlor» X^224 (Blue Book, 1986), Tmn$poH Proibco? Specifioniton for Open Systems

tniercomectim far CCfTTAppitcathns.

(3| \B0 8072^ fntormatfon processing systems - Opert systems interconnection - Transport sen^fce

defMmi

J4| ISO 8072 Acki^dum 1, information processing systems - Open systems interconnection - Addendum 1: Transport sen/ic& definition * ComQcffoniess-mode wansmission.

m ISO 6073 Edition 2, information processing systems * Open systems intercomection * Connection

Ortmted tratisport protocoi ^ecification.

m i$0 8073 Addendum 1, tnfonmtion processing systems - Open systems interconnection - Cmnection oriented ^nspott proiooot speciffcatii}n - Addendum 1: Netwoiit connection

msmg:^ei^sttlbpmt0mii

in ISO BQ7$ Addendum 2, information processing systems - Open systems interconnection

Connection oriented timtsport protocoi ^deification -' Add&ndum 2: Class four operation over connectionless network sermce>

{8| iSO 8602, information processing sy^ems - Opei? systems imerconnection - Protocoi for providing

1
PART 4 - TRANSPORT

th6 conmcti0f}i0$&^o<:i6 tran^rt $0f\4c$.

June 1991 (Stable)

3 Status

Completed December 1990.

4 Errata

NOTE - This clause may contain "defect report" and resolutions material, and the versions of implementor

agreements to which this material applies.

5 Provision of Connection Mode Transport Service

Three connection mode protocol classes have been identified for implementation. Transport classes 0, 2 and

4 of X.224 (1988)^ have been endorsed for use over CONS. Only Transport Class 4 of ISO 8073/Add. 2

^ has been endorsed for use over CLNS. The following class combinations are endorsed for CONS: (0), (0,2) or (0,2,4).

5.1 Transport Class 4

5.1.1 Transport Class 4 Overview

Transport Class 4 is mandatory for communication between systems using the OSI CLNS and may also be

used for systems using the OSI CONS (e.g., a private MHS, etc.).

Where a OR TPDU proposing Class 2 or 4 is initiated. Class 0 shall be explicitly indicated as an

alternative class except if there is already one (or several) transport connection(s) assigned to the

network connection (multiplexing being possible).

In general, references to ISO 8073 in ISO 8073/Add. 2 should be interpreted as applying to X.224

(1988); however, the reference to Clause 14.6.a in Clause 14 of ISO 8073/Add. 2 should be

interpreted as a reference to Clause 14.5.a of X.224(1988).

2
PART 4 - TRANSPORT March 1991 (Stable)

5.1.2 Protocol Agreements

A disconnect request shall be Issued In response to a connect request when the maximum number of Transport connections is reached or exceeded.

5.1.2.1 General Rules

The rules are as follows:

a) All Implementations shall request "use of extended formats" in the CR TPDU. Implementations

shall accept the "use of extended formats" in the CC TPDU if it was proposed In the CR TPDU.

Implementations shall accept "use of normal formats" if it was proposed In the CR TPDU;

b) Negotiation of protection is outside the scope of these agreements. If negotiation of protection

is not supported, receipt of the protection parameters In CR TPDU and CC TPDU shall be Ignored;

c) Implementations shall be capable of proposing and accepting the non-use of checksums;

d) Use of the acknowledgment time parameter Is optional. If an implementation Is operating any

policy which delays the transmission of AK TPDUs, the maximum amount of time by which a single

AK TPDU may be delayed shall be Indicated to the peer Transport service provider using the

acknowledgment time parameter. The value transmitted should be expressed in units of milliseconds

and rounded up to the nearest whole millisecond;

e) QoS negotiation is outside the scope of these agreements. If QoS negotiation Is not supported,

receipt of the parameters "throughput", "residual error rate", "priority", and "transit delay" in the CR

and CC TPDUs shall be ignored;

f) It is recommended that implementations not send user data in the CR TPDU or the CC TPDU.

The disposition of any user data received in a CR TPDU or CC TPDU is Implementation dependent;

g) It is recommended that implementations not send user data In the DR TPDU. The disposition

of any user data received in a DR TPDU is implementation dependent;

h) An unknown parameter in any received CR TPDU shall be Ignored;

i) A Transport entity shall accept a DR TPDU and a corresponding DC TPDU with or without a checksum In response to a CR or CC TPDU;

3
PART 4 - TRANSPORT December 1990 (Stable)

j) Transmitted DR TPDUs shall carry a disconnect reason code which pertains to the actual cause

of the disconnect. A DR TPDU may carry a reason code of "0" (unspecified) if an appropriate reason code is not defined;

k) Known parameters with valid lengths but with invalid values in a CR TPDU shall be handled as

follows:

1) Parameter: 2) Action:

a) TSAP id a) Send DR TPDU

b) TPDU size b) ignore parameter, use default

c) Version c) ignore parameter, use default

d) Checksum d) discard CR TPDU

e) Alternate Protocol Classes e) Protocol Error

I) Unrecognized or not applicable bits of the Additional Options parameter shall be ignored.

m) It is recommended that the capability of request acknowledgments be supported and proposed

in CR TPDUs. If request acknowledgments are supported, then if the implementation delays

acknowledgments it shall:

1) request use of request acknowledgments in the CR TPDU;

2) accept the use of request acknowledgments in the CC TPDU if It was proposed in the

CR TPDU.

n) It is recommended that implementations send both the preferred and existing TPDU size parameters in the CR TPDU.

o) It is recommended that inactivity timer values be exchanged during connection establishment.

This may be mandatory in the future. If the "exchange of inactivity timers" capability is supported,

the implementation shall send its minimum inactivity timer in the CR TPDU. If a CR TPDU is received

, with this timer value and the capability is supported, the responding CC TPDU shall contain the

inactivity time.

If the Inactivity time is received and the capability is supported, the following shall be used as an upper

bound for w il:

(Ir-Elr)/N>W N>2
PART 4 - TRANSPORT December 1990 (Stable)

List of Tables

Table 1 - Protocol Identification TPDU Values 14

V
PART 4 - TRANSPORT December 1990 (Stable)

j

Foreword

This part of the Stable Implementation Agreements was prepared by the Lower Layers Special Interest Group (LLSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors

of Open Systems Interconnection (OSI). 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. Significant technical changes

from this text as previously given are in class 4 protocol (including retransmission timer), and

in class 0 protocol.

vi
Part 4 - Transport

0 Introduction

These agreements support the integration of LANs, packet networks, and other WANs with the smallest

possible set of mandatory protocol sets, in accordance with the other agreements already reached. Nothing

here shall preclude vendors from implementing protocol suites in addition to the ones described in this document.

1 Scope

This chapter presents agreements for providing the OSI Transport layer services over both connection mode

and connectionless mode services.

2 Normative References

CCITT

1. Recommendation X.214 (Blue Book, 1988), Transport Service Definition for Open Systems

Interconnection for CCITT Applications.

2. Recommendation X.224 (Blue Book, 1988), Transport Protocol Specification for Open Systems

Interconnection for CCITT Applications.

ISO

1 . ISO 8072, Information processing systems Open systems interconnection -- Transport service defintion.

2. ISO 8072 Addendum 1, Information processing systems -- Open systems interconnection -- Addendum

1 : Transport service definition -- Connectionless-mode transmission.

3. ISO 8073 Edition 2, Information processing systems -- Open systems interconnection -- Connection

oriented transport protocol specification.

4. ISO 8073 Addendum 1, Information processing systems -- Open systems interconnection -- Connection

oriented transport protocol specification -- Addenum 1: Network connection management subprotocol.

5. ISO 8073 Addendum 2, Information processing systems -- Open systems interconnection -- Connection

oriented transport protocol specification -- Addendum 2: Class four operation over connectionless network

service.

6. ISO 8602, Information processing systems -- Open systems interconnection -- Protocol for providing the

connectionless-mode transport service.

1
PART 4 - TRANSPORT December 1990 (Stable)

3 Status

Completed December 1990.

4 Errata

NOTE - This clause may contain "defect report" and resolutions material, and the versions of implementor

agreements to which this materia! applies.

5 Provision of Connection Mode Transport Service

Three connection mode protocol classes have been identified for implementation. Transport classes 0, 2

and 4 of X.224 (1988)^ have been endorsed for use over CONS. Only Transport Class 4 of ISO

8073/Add. 2 ^ has been endorsed for use over CLNS. The following class combinations are endorsed

for CONS: (0), (0,2) or (0,2,4).

Transport Class 4 is mandatory for communication between systems using the OSI CLNS and may also

be used for systems using the OS! CONS (e.g., a private MHS, etc.).

Where a CR TPDU proposing Class 2 or 4 is initiated, Class 0 shall be explicitly indicated as an

alternative class except if there is already one (or several) transport connection(s) assigned to the

network connection (multiplexing being possible).

In general, references to ISO 8073 in ISO 8073/Add. 2 should be interpreted as applying to X.224

(1988); however, the reference to Clause 14.6.a in Clause 14 of ISO 8073/Add. 2 should be

interpreted as a reference to Clause 14.5.a of X.224(1988).

5.1 Transport Class 4

5.1.1 Transport Class 4 Overview

2
PART 4 - TRANSPORT March 1991 (Stable)

5.1.2 Protocol Agreements

A disconnect request shall be Issued In response to a connect request when the maximum number of Transport connections is reached or exceeded.

5.1.2.1 General Rules

The rules are as follows:

a) All implementations shall request "use of extended formats" in the CR TPDU. Implementations

shall accept the "use of extended formats" in the CC TPDU if it was proposed in the CR TPDU.

Implementations shall accept "use of normal formats" if it was proposed in the CR TPDU;

b) Negotiation of protection is outside the scope of these agreements. If negotiation of protection

is not supported, receipt of the protection parameters in CR TPDU and CC TPDU shall be ignored;

c) Implementations shall be capable of proposing and accepting the non-use of checksums;

d) Use of the acknowledgment time parameter is optional. If an implementation is operating any

policy which delays the transmission of AK TPDUs, the maximum amount of time by which a single

AK TPDU may be delayed shall be indicated to the peer Transport service provider using the

acknowledgment time parameter. The value transmitted should be expressed in units of milliseconds

and rounded up to the nearest whole millisecond;

e) QoS negotiation is outside the scope of these agreements. If QoS negotiation is not supported,

receipt of the parameters "throughput", "residual error rate", "priority", and "transit delay" in the CR

and CC TPDUs shall be ignored;

f) It is recommended that implementations not send user data in the CR TPDU or the CC TPDU.

The disposition of any user data received in a CR TPDU or CC TPDU is implementation dependent;

g) It is recommended that implementations not send user data in the DR TPDU. The disposition

of any user data received in a DR TPDU is implementation dependent;

h) An unknown parameter in any received CR TPDU shall be ignored;

i) A Transport entity shall accept a DR TPDU and a corresponding DC TPDU with or without a checksum in response to a CR or CC TPDU;

3
PART 4 - TRANSPORT December 1990 (Stable)

j) Transmitted DR TPDUs shall carry a disconnect reason code which pertains to the actual cause

of the disconnect. A DR TPDU may carry a reason code of "0" (unspecified) if an appropriate reason code is not defined;

k) Known parameters with valid lengths but with Invalid values in a CR TPDU shall be handled as

follows:

1) Parameter: 2) Action:

a) TSAP id a) Send DR TPDU

b) TPDU size b) ignore parameter, use default

c) Version c) ignore parameter, use default

d) Checksum d) discard CR TPDU

e) Alternate Protocol Classes e) Protocol Error

I) Unrecognized or not applicable bits of the Additional Options parameter shall be ignored.

m) It is recommended that the capability of request acknowledgments be supported and proposed

in CR TPDUs. If request acknowledgments are supported, then if the implementation delays

acknowledgments it shall:

1) request use of request acknowledgments in the CR TPDU;

2) accept the use of request acknowledgments in the CC TPDU if it was proposed In the

CR TPDU.

n) It is recommended that implementations send both the preferred and existing TPDU size

parameters in the CR TPDU.

o) It is recommended that inactivity timer values be exchanged during connection establishment.

This may be mandatory in the future. If the "exchange of inactivity timers" capability is supported,

the implementation shall send its minimum inactivity timer in the CR TPDU. If a CR TPDU is received

with this timer value and the capability is supported, the responding CC TPDU shall contain the

inactivity time.

If the Inactivity time is received and the capability is supported, the following shall be used as an upper

bound for w W:

(Ir-Eur)/N>W N>2

4
PART 4 - TRANSPORT December 1990 (Stable)

5.1.2.2 Transport Class 4 Service Access Points or Selectors

If present, the TSAP Id. field In the CR and CC TPDUs shall be encoded as a variable length field and

will be interpreted as an octet string. The length of the string cannot exceed 32 octets.

5.1.2.3 Retransmission Timer

It is recommended that the value used for the retransmission timer be based upon the round-trip delay

experienced on a transport connection. The implementation should maintain, and continually update, an

estimate of the round-trip delay for the TC. From this estimate, a value for the retransmission timer is calculated each time it is started. Example techniques for maintaining the estimate and calculating the

retransmission timer are described below. Example 1 represents a simple retransmission strategy and

example 2 is particularly suitable for networks subject to high traffic loads.

Example 1

The value of the retransmission timer may be calculated according to the following formula:

T1 <— kE + AR.

In this formula, E is the current estimate of the round-trip delay on the transport connection, AR is the

value of the acknowledgement time parameter received from the remote transport service provider

during connection establishment, and k is some locally administered factor.

A value for k should be chosen to keep the retransmission timer sufficiently small such that lost TPDUs

will be detected quickly, but not so small that false alarms are generated causing unnecessary

retransmission.

The value of E may be calculated using an exponentially weighted average based upon regular sampling

of the interval between transmitting a TPDU and receiving the corresponding acknowledgment. Samples

are taken by recording the time of day when a TPDU requiring acknowledgment is transmitted and

calculating the difference between this and the time of day when the corresponding acknowledgment is received. New samples are incorporated with the existing average according to the following formula:

E <_ E + (1 - a)(S - E).

In this formula, S is the new sample and a is a parameter which can be set to some value between 0

and 1 . The value chosen for a determines the relative weighting placed upon the current estimate and

the new sample. A large value of a weights the old estimate more heavily causing it to respond only

slowly to variations in the round-trip delay. A small value weights the new sample more heavily causing

I a quick response to variations. (Note that setting a to 1 will effectively disable the algorithm and result in

j a constant value for E, being that of the initial seed.)

' If a is set to 1-2 " for some value of n, the update can be reduced to a subtract and shift as shown

below:

5
PART 4 - TRANSPORT December 1990 (Stable)

E <— E + 2

" (S - E).

When sampling, if an AK TPDU is received wliich acl<nowledges multiple DT TPDUs, only a single

sample should be taken being the round-trip delay experienced by the most recently transmitted DT

TPDU. This attempts to minimize in the sample any delay caused by the remote transport service

provider withholding AK TPDUs.

Example 2

As network load increases, the variability of round-trip delay also increases. In environments where load

fluctuates widely, it is therefore useful to estimate the variability of round-trip delay measurements and

use this estimate in the calculation of retransmission timer values. An estimate of the variability of roundtrip delay measurements can be efficiently calculated as an exponentially weighted average of the

differences between round-trip delay measurements and the average round-trip delay. This represents

the mean deviation of the round-trip delays, which is a useful approximation of the standard deviation

and can be much more efficiently computed. The formula is

D <~D + (1 -a)(|S-E| -D)

where D is the estimate of variability in round-trip delays. S, E, and a are as defined for the preceding

formula. As before the value of a must be between 0 and 1 and the choice of a value of 1 - 2

^^ allows

for efficient update of the average. The value of a for the variability estimation, though, does not need to be the same as that used for the round-trip delay estimate. A smaller value for a is useful in the

variability estimation to cause a more rapid response to changes in round-trip delays. D can then be

used to calculate retransmission timer values according to the formula:

T1 <- E + AR + kD

where T1 is the retransmission timer value, E is the estimated average round-trip delay, AR is the value

of the acknowledgement timer parameter received from the remote transport service provider during

connection establishment, and k is a locally administered factor. Since D approximates the standard

deviation of the round-trip delays, but is greater than or equal to the standard deviation, round-trip

delays within k standard deviations of the mean would be accounted for by the retransmission timer

value (e.g., k = 2, if round-trip delays were normally distributed, would account for 95% of the

variability).

Round-trip time measurements based on acknowledgement of any retransmitted data should not be

used to update the round-trip delay estimate or the estimate of variability. Such measurements are not

reliable since it is ambiguous which transmission of the data is being acknowledged.

One strategy for handling a retransmission timeout is to retransmit the PDU and reset the timer with a

value that is twice the previous value. In this case, a new roundtrip delay estimate and estimate of

variability should be calculated only when an acknowledgement of data is received where none of the

acknowledged data has been retransmitted. This calculation uses the new round-trip delay

measurement and the last estimate before the retransmission timeout(s).

6
PART 4 - TRANSPORT December 1990 (Stable)

5.1.2.4 Keep-Alive Function

The Class 4 protocol detects a failed Transport connection by use of an 'Inactivity timer'. This timer is reset each time a TPDU is received on a connection. If the timer ever expires, the connection is terminated.

The Class 4 protocol maintains an idle connection by periodically transmitting an AK TPDU upon

expiration of the 'window timer'. Thus, in a simple implementation, the interval of one transport entity's

window timer must be less than that of its peer's inactivity timer, and vice versa. The following

agreements permit communicating transport entities to maintain an idle connection without shared

information about timer values:

a) In accordance with ISO 8073/X.224, Clause 12.2.3.9.a, all implementations must

respond to the receipt of a duplicate AK TPDU not containing FCC by transmitting an AK TPDU containing the 'flow control confirmation' parameter;

b) Implementations must always transmit duplicate AK TPDUs without FCC on

expiration of the local window timer (see ISO 8073/X.224, Clause 12.2.3.8.1).

Receipt of this TPDU by the remote Transport entity will cause it to respond with an AK TPDU containing the 'flow control confirmation' parameter. When this is received

by the local transport entity, it will reset its inactivity timer. See figure 1

c) It is a local matter for an implementation to set the intervals of its timers to appropriate relative values. Specifically:

1) The window timer must be greater than the round-trip delay. See 5.1.2.3;

2) The inactivity timer must be greater than two times the window timer; and

should normally be an even greater multiple if the Transport connection is to be resilient to the loss of an AK TPDU.

A duplicate AK TPDU (see figure 1) is one which contains the same values for YR-TU-NR, credit, and

subsequence number as the previous AK TPDU transmitted. A duplicate AK TPDU does not acknowledge any new data, nor does it change the credit window.

7
PART 4 - TRANSPORT

I w

December 1990 (Stable)

reset

reset

expire

expire

duplicate

AK

AK + FCC

duplicate

AK

AK + FCC

expire

Figure 1 - AK exchange on idle connection.

5.1.2.5 Congestion Avoidance Policies

This clause defines both mandatory and optional requirements relating to avoiding congestion in OSI

networl<s and recovering from it when it is experienced. The mandatory requirements specify a minimum approach to congestion avoidance/recovery which can be tuned based upon the specific

requirements of the network. The optional requirements specify a dynamic window sizing scheme

which, if implemented, will contribute further to the avoidance of congestion in the network.

Mandatory Requirements are as follows:

a) A maxinnum size for the "receive credit window", the value of which is locally

configurable, should be provided. A "receive credit window" reflects the number of

credits sent by a Transport entity for a Transport connection. The maximum size of

the "receive credit window" shall be referred to as WR,;

b) A maximum size for the "sending credit window", the value of which is locally

configurable, shall be provided. A "sending credit window" reflects the number of data

TPDUs that a Transport entity is willing to send on a Transport connection. The

maximum size of the "sending credit window" shall be referred to as WS,. As

specified in ISO 8073, the "sending credit window" shall also be less than or equal to the remote "receive credit window" as conveyed in the last CDT field;

B
PART 4 - TRANSPORT December 1990 (Stable)

c) It Is strongly recommended that an implementation use a retransmission timer per

Transport connection. If, upon expiration of the retransmission timer, an

implementation allows more than "1" TPDU to be transmitted a means to locally adjust

the maximum number shall be provided;

d) All implementations shall have the capability of operating without delaying ACKs of

data TDPUs received in-sequence (i.e., Al essentially equals zero). If an

Implementation optionally chooses to explicitly delay ACKs, a means to locally adjust

Al shall be provided.

Optional Requirements are as follows:

For systems implementing the dynamic window sizing scheme the following rules apply as described

below:

1. RECEIVING TRANSPORT ENTITY (RTE) RULES:

a) Rule 1 - Initialization of Window:

1) The initial value of WR (known as WRq) shall have a locally configurable

upper bound. This window is sent to the sending transport entity (STE) in the

next CDT field transmitted;

a) Rule 2 - Required Sampling Period:

1) All PTEs shall maintain a fixed value for WR until the next

2WR DT TPDU arrive since the last CDT field was transmitted by

the RTE;

b) Rule 3 - Required Counting of Received TPDUs in a Sampling

Period:

1) All RTEs shall maintain a count, N, equal to the total number

of TPDUs received and a count, NC, equal to the total number

of TPDUs received which had the CE Flag set. All types of

TPDUs are included in the counts for N and NC, not just DT

TPDUs;

c) Rule 4 - Required Action upon the end of a Sampling Period: All RTEs shall take the following actions at the end of each sampling

period:

1) If the count NC is less than 50 percent of the count N, the

RTE shall increase WR by adding 1 up to a maximum, WR,,

(that is based on the local buffer management policy);

9
PART 4 - TRANSPORT December 1990 (Stable)

otherwise, it shall decrease WR by multiplying by 0.875 (a

minimum of 1);

2) Reset N and NC to zero;

3) Transmit the new window WR in the next CDT field sent to

the sending transport entity;

2) SENDING TRANSPORT ENTITY (STE) RULES:

a) Rule 1 : Initialization of Window:

1) All STEs shall maintain a sending window size (WS). Initially

and also as long as there is no loss, WS is set equal to the

receiving window value WR received from the remote RTE in the

last CDT field;

b) Rule 2: Required Action on a Timeout;

1) All STEs shall reset WS to one when the retransmissions

timer expires and indicates a lost TPDU. WS now limits the

number of DT TPDUs that may be transmitted or retransmitted

without further acknowledgments;

c) Rule 3: Required Counting of Acknowledged TPDU:

1) All STEs shall maintain a count, ACKRCVD of the number of

DT TPDUs acknowledged, by the RTE, since WS was last adjusted. Therefore each time WS is adjusted, the count

ACKRCVD shall be reset to zero;

d) Rule 4: Increase Window Policy:

1) All STEs shall increase WS by one each time ACKRCVD is equal to or greater than the current value of WS, unless WS

exceeds the window permitted by the remote RTE.

5.1.2.6 Use Of Priority

(Refer to the Working Implementation Agreements).

10
PART 4 - TRANSPORT

5.2 Transport Class 0

December 1990 (Stable)

5.2.1 Transport Class 0 Overview

Transport Class 0 over X.25 is mandatory (see X.400) for use in communicating with public MHS

systems operating in accordance with the CCITT X.400 series recommendations. The purpose of the

agreements concerning Transport Class 0 is to allow connection to these public services. Transport

Class 0 over X.25 can also be used in communicating between PRMDs (this choice is prevalent outside

North America).

5.2.2 Protocol Agreements

5.2.2.1 General Rules

Transport Class 0 agreements are as follows:

a) The Error (ER) TPDU may be used at any time and upon receipt requires that the

recipient disconnect the network connection, and by extension the transport

connection;

b) The allowed values for the maximum TPDU size are 128, 256, 512, 1024, and

2048;

c) The Class 0 protocol does not support multiplexing. At any instant, one Transport

corresponds to one Network connection;

d) It is recommended that the optional timers TS1 and TS2, if implemented, be

settable by local system management. Values in the order of minutes should be

supported;

e) An unlimited TSDU length must be supported.

f) It is recommended that implementations send both the preferred and existing

TPDU size parameters in the OR TPDU.

5.2.2.2 Transport Class 0 Service Access Points

For communicating with public MHS systems, section 5 of X.410 specifies the use and format of TSAP

identifiers.

11
PART 4 - TRANSPORT

5.2.3 Rules for Negotiation

The rules for class negotiation sliall be used.

December 1990 (Stable)

5.3 Transport Class 2

5.3.1 Transport Class 2 Overview

Transport Class 2 is applicable in OSI end systems which provide the Connection-mode Networl<

Service.

5.3.2 Protoco! Agreements

Transport Class 2 agreements follow:

a) The values of the TS1 and TS2 timers shall be configurable. The recommended

timer values are:

1) TS1: 60 seconds;

2) TS2: 60 seconds;

b) If present, the TSAP-id field in the CR and CC TPDUs shall be encoded as a

variable length field and will be interpreted as an octet string. The length of the string

cannot exceed 32 octets;

c) The rules for class negotiation shall be used;

d) QoS negotiation is outside the scope of these agreements. If QoS negotiation is not supported, receipt of the parameters "throughput", "residual error rate", "priority",

and "transit delay" in the CR and CC TPDU shall be ignored.

NOTE - If Class 0 is indicated in the Alternative Protocol Class field and QoS parameters are conveyed

and the responding end system chooses Class 0, then the QoS parameters have been ignored by the responding system.

e) It is recommended that implementations send both the preferred and existing TPDU size

parameters in the CR TPDU.

12
PART 4 - TRANSPORT December 1 990 (Stable)

6 Provision of Connectionless Transport Service

ISO 8072/Add. 2 is the Transport Service Definition covering Connectionless-mode Transnnission. ISO

8602 is the Protocol for providing the Connectionless-Mode Transport Service.

6.1 Connectionless Transport Overview

When providing the connectionless Transport Service, the protocol shall be implemented as specified in ISO 8602.

6.2 Protocol Agreements

6.2.1 General Rules

The connectionless Transport protocol is a relatively simple protocol providing little opportunity for conflicting interpretations. A few relevant agreements follow:

a) The optional elements of procedure for use of CLTS over CONS (i.e., clause 6.3 of

ISO 8602) will not be supported;

b) A Unitdata TPDU that is received that contains a protocol error or an unknown

destination TSAP ID shall be discarded.

6.2.2 Connectionless Transport Service Access Points or Selectors

The TSAP selector field in the UD TPDU shall be encoded as a variable length field and will be

interpreted as an octet string. The length of the string cannot exceed 32 octets.

7 Transport Protocol Identification

The absence of Call User Data (CUD) in an X.25/ISO 8208 Call Request/Incoming Call packet indicates

the operation of ISO 8073/CCITT X.224.

Protocol Identification TPDU values applicable to these agreements are given in table 1 . These TPDUs,

when used, are conveyed as N-connect user data.

13
PART 4 - TRANSPORT December 1990 (Stable)

Table 1 - Protocol Identification TPDU Values

TPDU Value Protocol

03 01 01 00 * (see note 1)

03 01 02 00 ** (see note 2)

ISO 8073/Add. 1

ISO 8602

NOTES

1 Corresponds to an ISO 8073/Add. 1 UN-TPDU and a X.224 Annex B PI-TPDU.

2 Corresponds to an ISO 8073/Add. 1 UN-TPDU.

The following agreennents apply:

a) Any additional TPDU, which follows (by concatenation) a Protocol Identification TPDU shall be ignored If ISO 8073/Add. 1 is not supported;

b) When using ISO 8208, usage of a Protocol Identification TPDU not corresponding to those

listed in table 1 is outside the scope of these agreements.

14
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 5 - Upper Layers

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Mark Thomas, Unix

Scott Beale, ARINC Workshop Editor: Brenda Gray
Part 5 - Upper Layers September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Upper Layers Special Interest Group (ULSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors

of Open Systems Interconnection (01W). The charter for the 01W is located in the Procedures Manual.

The text in this part has been approved by the Plenary of the OIW. This part replaces the previously

existing part on the Upper Layers.

Annex A is for information purposes only. Annex B 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 stri keout. New and replacement text will be shown as

shaded.

ii
Part 5 - Upper Layers September 1991 (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 2

2.4 Application Layer - ASE/ACSE 2

3 Status 3

4 Errata 4

4.1 ISO Defect Solutions 4

4.2 Session Defect Solutions Correcting CCITT X.21 5 and X.225 4

4.3 Approved Errata 4

5 Association Control Service Element 5

5.1 Introduction 5

5.2 Services 5

5.3 Protocol Agreennents 6

5.3.1 Application Context 6

5.3.2 AE Title 6

5.3.3 Peer Entity Authentication 6

5.4 ASN.1 Encoding Rules 6

5.5 Connectionless 6

6 ROSE 7

7 RISE 7

8 Presentation 7

8.1 Introduction 7

8.2 Service 7

8.3 Protocol Agreements 8

8.3.1 Transfer Syntaxes 8

8.3.2 Presentation Context Identifier 8

8.3.3 Default Context 8

8.3.4 P-Selectors 8

8.3.5 Provider Abort Parameters 8

8.3.6 Provider Aborts and Session Version 8

8.3.7 CPC-Type 9

8.3.8 Presentation-context-definition-result-list 9

iii
Part 5 - Upper Layers September 1991 (Stable)

8.3.9 RS-PPDU 9

8.4 Presentation ASN.1 Encoding Rules 9

8.5 General 9

8.6 Connection Oriented 10

8.7 Connectionless 10

9 Session 10

9.1 Introduction 10

9.2 Services 10

9.3 Protocol Agreements 1 9.3.1 Concatenation 1 9.3.2 Segmenting 1 9.3.3 Reuse of Transport Connection 1 9.3.4 Use of Transport Expedited Data 1 9.3.5 Use of Session Version Number 1 9.3.6 Receipt of Invalid SPDUs 12

9.3.7 Invalid SPM Intersections 12

9.3.8 S-Selectors 12

9.4 Connectionless 13

10 UNIVERSAL ASN.1 ENCODING RULES 13

10.1 TAGS 13

10.2 Definite Length 13

10.3 External 13

10.4 Integer 13

10.5 String Types 14

10.6 Bit String 14

11 Character Sets 14

12 Conformance 14

13 Specific ASE Requirements 15

13.1 FTAM Phase 2 15

13.1.1 ACSE Requirements 15

13.1.2 Presentation Requirements 15

13.1.3 Session Requirements 16

13.1.4 Session Options 16

13.1.5 ASN.1 Encoding Requirements 17

13.2 MHS 17

13.2.1 Phase 1 (1984 X.400) Session Requirements 17

13.2.2 Phase 2, Protocol PI (1988 X.400) 17

13.2.2.1 ROSE Requirements 18

13.2.2.2 RTSE Requirements 18

13.2.2.3 ACSE Requirements 18

13.2.2.4 Presentation Requirements 19

13.2.2.5 Session Requirements 19

13.2.3 Phase 2, Protocol P7 (1988 X.400) 19

13.2.3.1 ROSE Requirements 19

iv
Part 5 - Upper Layers September 1991 (Stable)

13.2.3.2 RISE Requirements 19

13.2.3.3 ACSE Requirements 20

13.2.3.4 Presentation Requirements 20

13.2.3.5 Session Requirements 21

13.2.4 Phase 2. Protocol P3 (1988 X.400) 21

13.2.4.1 ROSE Requirements 22

13.2.4.2 RISE Requirements 22

13.2.4.3 ACSE Requirements 22

13.2.4.4 Presentation Requirements 22

13.2.4.5 Session Requirements 22

13.3 DS Phase 1 . 22

13.3.1 ACSE Requirements 22

13.3.2 Presentation Requirements 23

13.3.3 Session Requirements 23

13.4 Virtual Terminal 23

13.4.1 Phase la 23

13.4.1.1 ACSE Requirements 23

13.4.1.2 Presentation Requirements 24

13.4.1.3 Session Requirements 24

13.4.2 Phase lb 24

13.4.2.1 ACSE Requirements 24

13.4.2.2 Presentation Requirements 25

13.4.2.3 Session Requirements 25

13.5 MMS 26

13.5.1 ACSE Requirements 26

13.5.2 Presentation Requirements 26

13.5.3 Session Requirements 26

13.6 Transaction Processing 264

13.7 Network Management 26-1

13.7.1 ROSE Requirements 26"^1 13.7.2 ACSE Requirements

13.7.3 Presentation Requirements 264

13.7.4 Session Requirements 26-2

Annex A (informative)

Recommended Practices 27

Annex B (normative)

Object Identifier Register 31

B.I Register Index 31

B.2 Object Identifier Descriptions 31

V
Part 5- Upper Layers September 1991 (Stable)

List of Tables

Table 1 - Session States 28

Table 2 - Incoming Events 29-30

Vi
Part 5 - Upper Layers

0 Introduction

Editor's Note - The word "NIST" will be removed from places tt appears in tiife part as soon as possibfe

In this portion of the Innplementors' Agreements, the MST Upper Layers SIG is primarily concerned with

providing implementation agreements for ACSE, ROSE, RISE, 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. Each ASE SIG chooses

which protocols, functional units, application contexts, and parameters it requires. These must be listed

In the "Specific ASE Requirements" clause of this part.

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/I EC JTC1/SC21 N2494, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Sen/ice Definition-AD 2 to ISO 8326 to Incorporate

Unlimited User Data.

[4] ISO/IEC JTC1 /SC21 N2495, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Protocol Specification - AD 2 to ISO 8327 to Incorporate

Unlimited User Data.

[5] IS0/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-f^ode Session Service.

1
Part 5 - Upper Layers June 1991 (Stable)

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 JTCI /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 (ASM. 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] IS0/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 Sen/ice.

[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-f\/Jode Presentation Service.

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 Sen/ice 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

Sen/ice 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

2
Part 5 - Upper Layers June 1991 (Stable)

i$0 8649/Cor.1 : 1991 (tSO^fiC aTCl/$C21 N5630^, intome^fon Processing Systems - Open

^^ems friimiomectton^Tecimicaf Corngendtm iioACSE Service (ISO 8649; 1988) Covering

jaal iSO 86$a/Cor.1 ; 1981 (E) (tSO/iEC OTOl/SCai wnR^i^ mmstfon pfO00s$tfig SystBms - Open

Sy^ms fnmooftnectfon * Tecfmtcaf Corrigent :iSB Proiooof (ISO 86S0: 1 986}

Covwlnfil Defects 8650/DOI, 864^/904.

[20] ISO IS 10035: 1989-02-25 (ISO/IEC JTC1/SC21 N 3456), Information Processing Systems - Open Systems Interconnection - Connectionless ACSE Protocol to Provide the ConnectionlessMode ACSE Service.

3 Status

This text is stable, as of March, 1001.

NOTE - Changes due to errata are summarized in clause 4

3
Part 5 - Upper Layers

>

June 1991 (Stable)

4 Errata

4.1 ISO Defect Solutions

This clause lists the defect solutions from ISO which are currently recognized to be valid for the

purposes of NIST conformance.

ISO 8326 defect solutions:

023, 024

ISO 8327 defect solutions:

037, 038

4.2 Session Defect Solutions Correcting CCITT X.215 and X.225

The following approved defect solutions have been integrated into the current revisions of ISO 8326 and

ISO 8327, but are not part of CCITT X.215 and X.225 (1984). The defect solutions must be incorporated

into CCITT Session to insure conformance with ISO Session.

ISO 8326 defect solutions:

004, 006, 007, 009, Oil, 012, 013, 014, 015, 016, 017, 020.

ISO 8327 defect solutions:

001, 003, 004, 005, 006, 007, 008, 009. 010, 012, 017, 018, 019, 026, 027, 030, 034, 035.

4.3 Errata Approved by March, 1991 Appro\

Errata to this part are marked with change bars; deleted text is left but with strikeouts. The following

table indicates the clause and type for each erratum. NOTE - Shaded area indicates changes approved at the March 1991 meeting.

4
Part 5 - Upper Layers June 1991 (Stable)

Clause Type Comment

4.3 editorial added errata summary table

5.2 editorial grammar

8.3.7 editorial spelling

0,0,1.

8.5.1 editorial extraneous word

8.7 editorial update to document reference

Q A tSUX UVyL J. dX

J. J 6a X uQ/x X cix JUvJ VcfU aWiUC CIX^o L X Oi\^ C ajfllCCIA^o ov./ LlidU dXX dX/oUXdv^L

ojfilUdAvSo dXC? XXo L. XiSA UiiU6 X IT X tfo t.d C X \JIL X 6^j[U X X dUcil If o f UoX OVi/IUCr X d U I, X dils X X syii^dX eiiu X X es so ^nd^ unex e x s ozixy 0116

X O X CX %3ilwt3 CO AaoOv^ X d t OU U X diio X X OJ^ii U dJw ^^X ^ L \JLl^

of abstract syntaxes

/^hsnnp^ 4-D th*> PHf"o<1ir»fi r>f two KTAM ah^'hrar't'

syntaxes: "NBS abstract syntax ASl" and "NBS file

directorv entrv abstract svntax"

\^\JL XCftX B.2 editorial added explanatory note on nil application context

2.3 editorial delete references already provided in MHS

3. editorial add note that changes are summarized in clause 4 5.5 editorial delete 4 last line as not applicable

2.2 alignment delete references to ISO 8825/PDAD 1 and ISO 8824/

PDAD 1 and change references to 1990 version

9.3.4 alignment session use of transport expedited service is

optional

5.3.3 Working -> Stable

13.7.1 Working -> 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 NIST-conformant system.

5
Part 5 - Upper Layers June 1991 (Stable)

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

NIST ASE SIGS are listed in the clause entitled "Specific ASE Requirements".

5.3.2 AE Title

AE-titles shall be implemented as specified in Amondmont 1 to I SO 8660 (ISO 8650/AM4) Corr.t.

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 ABRT APDU is used during the connection establishment phase, Presentation layer negotiation

is considered to be complete, and the "direct-reference" component of EXTERNAL shall not be present.

5.5 Connectionless

The connectionless ACSE protocol shall be implemented as specified in ISO DIS 10035.

No further agreements beyond those specified elsewhere in this part have been made regarding this standard.

6
Part 5 - Upper Layers March 1991 (Stable)

6 ROSE

ROSE shall be implemented as specified In ISO DIS 9072-1.2 and ISO DIS 9072-2.2.

No further agreements beyond those specified elsewhere in this part have been made regarding this standard.

RISE shall be implemented as specified in ISO 9066-1 and ISO 9066-2.

No further agreements beyond those specified elsewhere in this part have been made regarding this standard.

8 Presentation

8.1 Introduction

This clause details the implementation requirements for the Presentation layer as defined in the

Presentation Service Definition, ISO 8822, and the Presentation Protocol Definition, ISO 8823.

The task of the Presentation layer is to carry out the negotiation of transfer syntaxes and to provide for the transformation to and from transfer syntaxes. The transformation to and from a particular transfer syntax is a local implementation issue and is not discussed within this clause. This clause is concerned

with the protocol agreements, and thus is entirely devoted to the issues involved with the negotiation of transfer syntaxes and the responsibilities of the Presentation protocol.

8.2 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.

7 RTSE

7
Part 5 - Upper Layers March 1991 (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 encode Presentation context identifiers in the range 0 to 32,767.

Implementations must be able to handle a minimum of two Presentation contexts per connection.

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.

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 an NIST-conformant system normally results in either a P-CONNECT indication or a P- CONNECT confirmation being issued.

8.3.5 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.

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.

8
Part 5 - Upper Layers March 1991 (Stable)

8.3.7 CPC-Type

Implementations shall not use any CPC-type values in the SS-user data parameter of the S-CONNECT

unless more than one transfer syntax is proposed for a single Presentation context of the Presentation

data values. Each CPC-type represents a unique transfer syntax, so if more than one transfer syntax is proposed, CPC-type values may appear in that SS-user-data parameter.

For a Presentation context for which the Basic Encoding Rules are a proposed transfer syntax, all PDVs

in the user data parameter of the CP PPDU must be encoded first using the Basic Encoding Rules and

must be examined by the receiving Presentation protocol machine. Following CPC-type values may be

examined or ignored at the receiver's option (see ISO 8823, clause 6.2.5.3).

8.3.8 Presentation-context-definition-result-Hst

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 CPRPPDU. If the Provider-reason is present, then the Presentation-context-definition-result-list is optional.

8.3.9 RS-PPDU

The Presentation-context-identifier-list shall not be present when only the kernel functional unit is in effect.

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 shall be

issued.

8.5 General

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-ASNI-type choice) or multiple PDVs

(using the octet-aligned choice). Note that receivers must accept any of the above encodings.

9
Part 5 - Upper Layers

8.6 Connection Oriented

March 1991 (Stable)

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.

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 NIST conformant system:

a) Kernel;

b) Duplex;

c) Expedited Data;

d) Resynchronize;

e) Exceptions;

f) Activity Management;

10
Part 5 - Upper Layers June 1991 (Stable)

g) Half-duplex;

h) Minor Synchronize;

i) Major Synchronize;

j) Typed Data.

9.3 Protocol Agreements

9.3.1 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.

9.3.2 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.3.3 Reuse of Transport Connection

Reuse of a Transport connection is not required and can be refused.

9.3.4 Use of Transport Expedited Data

The Session use of Transport expedited service is optional. Tho moani ng of "supported" i s spooi fi od i n cl auGO 3.1 of I SO DI SP AFTnn 1. NOTE - A referencing ASE may require that this feature shall be offered by an initiating implementation if

it is available, and that it shall be accepted by a responding implementation if it is available and was

offered.

9.3.5 Use of Session Version Number

Session Versions 1 and 2 are recognized. Each relevant NIST SIG chooses the version or versions of Session which it requires for a particular implementation phase, and these choices are documented in clause 12.

11
Part 5 - Upper Layers June 1991 (Stable)

Session Version 2 specifies tlie use of unlimited user data during connection establishment as dictated

by the AD 2 to ISO 8327 to Incorporate Unlimited User Data.

All Session Version 1 implementations must be able to negotiate Version 1 operation when responding

to a CONNECT (CN) SPDU proposing both Version 1 and Version 2.

In addition, all Session Version 1 implementations, upon receipt of a CONNECT (CN) SPDU proposing

only Version 2, should respond with a REFUSE (RF) SPDU containing a Reason Code indicating that the

proposed version is not supported. Until pending defect reports are adopted, implementations may

disconnect.

If Session Versions 1 and 2 are both proposed in the CONNECT (CN) SPDU, then the maximum length

of the User Data parameter value in the CONNECT (CN) SPDU shall be 512 octets and a PGI field of 193 shall be associated with this parameter. This implies that an implementation supporting both Session

Versions 1 and 2 can establish a connection with an implementation supporting only Version 1.

If only Session Version 2 is proposed in the CONNECT (CN) SPDU, then the maximum length of the

Session User Data parameter value of the S-CONNECT service request shall be 10,240 octets. This

restriction implies that the OVERFLOW ACCEPT (OA) SPDU and CONNECT DATA OVERFLOW (CDO)

SPDU are not used. If the length of the User Data parameter value is no greater than 512 octets, then an

associated PGI field of 193 shall be used, otherwise a PGI field of 194 shall be used.

When Session Version 2 is negotiated, then in all SPDUs the maximum length of the User Data

parameter value with an associated PGI field of 193 shall be 10,240 octets. NIST-conformant Session

Version 2 implementations need only support the maximum data lengths specified in the Specific ASE

Requirements section.

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.

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.

9.3.8 S-Selectors

S-selectors shall be a maximum of 1 6 octets.

12
Part 5-

9.4

Upper Layers

Connectionless

March 1991 (Stable)

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 an NIST-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.

10.2 Definite Length

The maximum value of an ASN.1 length octets component that need be handled by an NIST-conformant

implementation shall be 4,294,967,295. This is the maximum unsigned integer that can be represented in 32 bits, therefore, the maximum encoding of a length octets component will occupy 5 octets. Also, note

this restriction does not apply to indefinite length encoding.

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.I-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.

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 NIST agreement to the contrary is made for a specific INTEGER type.

13
Part 5 - Upper Layers March 1991 (Stable)

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.

10.6 Bit String

Unless othenA/ise specified in the abstract syntax definition, each bit named in a BIT STRING type used

in that abstract syntax definition shall be explicitly encoded in the associated BIT STRING value, even if it

Is part of a string of trailing zero bits.

Extra trailing bits beyond the exact number of bits which correspond to the complete list of the named

bits specified shall never be encoded. This rule applies to all BIT STRING types unless stated othenA^ise

in the standards.

1 1 Character Sets

See Part 21 of Working Implementation Agreements.

12 Conformance

In order for an implementation to be in conformance with the NIST 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) NIST-conformant implementations shall be ISO conformant. PICS may contain limitations on

length or value aspects of a protocol. PICS of NIST-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
Part 5 - Upper Layers March 1991 (Stable)

13 Specific ASE Requirements

The following list for each ASE the corresponding NIST SIG's requirements of and restrictions on ACSE,

ROSE, RISE, Presentation, and Session.

All listed requirements and restrictions shall be included in an NIST-conformant system and shall be

implemented in accordance with these NIST Implementor's agreements.

13.1 FTAMPhase2

13.1.1 ACSE Requirements

ACSE Functional Requirements: Kernel

Application Contexts: "ISO FTAM" { iso(1) standard (0) 8571 application-context iso-ftam(1) }

- implies

the use of the ACSE and the FTAM ASE.

A value is defined for the AE Title only to satisfy the FTAM requirement for exchanging fields of this type. This value does not identify an Application Entity and carries no semantics.

If the AE title is used, AE-title-form2 shall be supported. Support of AE-title-form2 includes support of APtitle-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.

13.1.2 Presentation Requirements

Presentation Functional Units: kernel

Presentation Contexts: At least 3 Presentation Contexts must be supported.

Abstract Syntaxes:

a) Abstract Syntaxes for conformant Implementations

1) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-control (2) abstract-syntax(1

)

apdus(O) version1(1) }

2) "FTAM-PCI" { iso(1) standard (0) 8571 abstract-syntax(2) ftam-pci(l) }

3) "FTAM unstructured binary abstract syntax" { iso(1) standard(O) 8571

15
Part 5 - Upper Layers March 1991 (Stable)

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(O) abstract-syntax(2) ftam-fadu(2) }

2) "FTAM unstructured text abstract syntax" { iso(1) standard(O) 8571 abstract-syntax(2)

unstructured-text(3) }

3) "NBS abstract syntax AS1" { iso identified-organization oiw(1 4) ftamsig(5)

abstract-syntax(2) nbs-asl(l) }

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(l)}

Editor's Note - The changes above involving "0IW(14)" were not explicitly mentioned at the March 1990

Plenary, but were implied from a correspondingly approved FTAM motion.

13.1.3 Session Requirements

Session Functional Units:

a) kernel

b) duplex

Version Number: 2

Maximum size of User Data parameter field: 10,240

13.1.4 Session Options

Session Functional Units:

a) resynchronize - only a Resynchronize Type value of "abandon"

b) minor synchronize

NOTES

16
Part 5 - Upper Layers March 1991 (Stable)

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 shall always be used, i.e., explicit confirmation is required.

13.1.5 ASN.1 Encoding Requirements

Some INTEGER types of the FTAM PCI may exceed the maximum size specified in the UNIVERSAL

ASN.1 ENCODING Rules. See the Range of values for INTEGER type Parameters of the FTAM part.

13.2 MHS

13.2.1 Phase 1 (1984 X.400) Session Requirements

Session Functional Units:

a) kernel

b) half-duplex

c) exceptions

d) activity management

e) minor synchronize

Version Number: 1

Maximum size of User Data parameter field: 512

NOTES

1 Restricted use is made by the RTS of the Session services implied by the functional units selected.

Specifically, 1) No use is made of S-TOKEN-GIVE, and 2) S-PLEASE-TOKENS only asks for the data token.

2 In the S-CONNECT SPDU, the Initial Serial Number should not be present.

3 The format of the Connection Identifier in the S-CONNECT SPDU is described in Version 5 of the X.400-

Series Implementors' Guide.

13.2.2 Phase 2, Protocol PI (1988 X.400)

17
Part 5 - Upper Layers

13.2.2.1 ROSE Requirements

ROSE is not used.

March 1991 (Stable)

13.2.2.2 RTSE Requirements

The RTSE requirements are:

a) Monologue

b) TWA - optional \ .: .

c) checkpointing:

1) minimum checkpointsize = 1

2) minimum windowsize = 1

d) no checkpointing

For the Monologue Association:

a) initiator keeps initial turn

b) APDUs are transferred from initiator to responder only

c) no turn passing

d) only the initiator effects the orderly release of an association

For the two way alternate Association

a) the initiator may keep or pass the initial turn, at binding

b) APDUs are transferred by the holder of the turn

c) only the initiator effects the orderly release of an association, when it possesses the turn

13.2.2.3 ACSE Requirements

As per Phase 2, Protocol P7.

Application Contexts:

a) "MTS-transfer-protocol-1 984" - mandatory

b) "MTS-transfer-protocol" - mandatory
Part 5 - Upper Layers

c) "MTS-transfer" - mandatory

March 1991 (Stable)

13.2.2.4 Presentation Requirements

Presentation Functional Units: l<ernel

Presentation Contexts: at least 3 must be supported

Abstract Syntaxes:

a) "ISO 8650-ACSE1" {joint-iso-ccitt(2) association-control (2) abstract-syntax(l ) apdus(O)

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(l) }

13.2.2.5 Session Requirements

As per Phase 2, Protocol P7.

13.2.3 Phase 2, Protocol P7 (1988 X.400)

13.2.3.1 ROSE Requirements

Operation and association classes are used as per the standard.

13.2.3.2 RISE Requirements

The RTSE requirements are:

a) TWA

b) normal-mode

c) checkpointing

d) minimum checkpointsize = 1

e) minimum windowsize = 1

19
Part 5 - Upper Layers March 1991 (Stable)

f) 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 two way alternate Association:

a) the initiator may keep or pass the initial turn, at binding

b) APDUs are transferred by the holder of the turn

c) only the initiator effects the orderly release of an association, when it possesses the turn

13.2.3.3 ACSE Requirements

ACSE Functional Requirements: Kernel

The use of AP-TITLE. AE-QUALIFIER. AP-INVOCATION-ID, and AE-INVOCATION-ID is not recommended; however, a receiving entity must be capable of ignoring them (if present) without refusing

the connection.

Application Contexts:

a) "MS-access" - mandatory; normal mode

b) "MS-reliable-access" - optional; normal mode

13.2.3.4 Presentation Requirements

Presentation Functional Units: kernel

Presentation Contexts: at least 5

Abstract Syntaxes:

a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control (2) abstract-syntax(l) apdus(0)

version! (1) }

b) MSBind/MSUnbind (with or without RISE)

20
Part 5 - Upper Layers September 1991 (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(l) }

13.2.3.5 Session Requirements

Session Functional Units:

a) kernel

1 b) half-duplex (tf RTSE is supportdci)

I c) excepti ons fult-dupt&x (If RT$£ 1$ not supported)

d) acti vi ty managomont 6x<:6ptlonE$

1 e) mi nor oynchroni zo activity maitageffl^nt

Q minor synchronize

Version Number: 2

i

i Maximum size of User Data parameter field: 10,240

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.

NOTES

13.2.4 Phase 2, Protocol P3 (1988 X.400)

21
Part 5 - Upper Layers September 1991 (Stable)

13.2.4.1 ROSE Requirements

As per Phase 2, P7.

13.2.4.2 RTSE Requirements

As per Phase 2, P7.

13.2.4.3 ACSE Requirements

As per Phase 2, P7.

Application Contexts:

a) "MTS-access" - mandatory

b) "MTS-reliable-access" - optional

c) "MTS-forced -access" - mandatory

d) "MTS-forced-reliable-access" - optional

13.2.4.4 Presentation Requirements

As per Phase 2, P7.

13.2.4.5 Session Requirements

As per Phase 2, P7.

13.3 DS Phase 1

13.3.1 ACSE Requirements

ACSE Functional Requirements: Kernel

Application Contexts:

a) "id-ac-directoryAccessAC" { joint-iso-ccitt(2) ds(5) 3 1 }

b) "id-ac-directorySystemAC" { joint-iso-ccitt(2) ds(5) 3 2}

22
Part 5 - Upper Layers March 1991 (Stable)

13.3.2 Presentation Requirements

Presentation Functional Units: kernel

Presentation Contexts: At least 2 Presentation Contexts must be supported.

Abstract Syntaxes:

a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control (2) abstract-syntax(1 ) apdus(O)

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(l) }

13.3.3 Session Requirements

Session Functional Units:

a) kernel

b) duplex

Version Number: 2

Maximum size of User Data parameter field: 10,240

13.4 Virtual Terminal

13.4.1 Phase la

13.4.1.1 ACSE Requirements

ACSE Functional Requirements: Kernel

Application Contexts: "ISO VT" { iso(1) standard(O) 9041 application-context(l) }- implies the use of the

ACSE and the VT ASE

23
Part 5 - Upper Layers March 1991 (Stable)

13.4.1.2 Presentation Requirements

Presentation Functional Units: kernel

Presentation Contexts: at least 2 must be supported

Abstract Syntaxes:

a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control (2) abstract-syntax(1 ) apclus(O)

version1(1) }

b) "VT Basic" { !So(1) standard(O) 9041 abstract-syntax(2) }

Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1)

basic-encoding(l) }

13.4.1.3 Session Requirements

Session Functional Units:

a) kernel

b) duplex

c) expedited data

d) major synchronize

e) resynchronize - only a Resynchronize Type value of "restart"

f) typed data

Version Number: 2

Maximum size of User Data parameter field: 10,240

Session Options: expedited data

13.4.2 Phase 1b

13.4.2.1 ACSE Requirements

ACSE Functional Requirements: Kernel

Application Contexts: "ISO VT" { iso(1) standard(O) 9041 application-context(l) }

- implies the use of the

ACSE and the VT ASE

24
Part 5 - Upper Layers September 1991 (Stable)

13.4.2.2 Presentation Requirements

Presentation Functional Units: kernel

Presentation Contexts: at least 2 must be supported

Abstract Syntaxes:

a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control (2) abstract-syntax(l) apdus(O)

version1(1) }

b) "VT Basic" { iso(1) standard(O) 9041 abstract-syntax(2) }

Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" { joint-iso-ccitt(2) asn1(1)

basic-encoding(l) }

13.4.2.3 Session Requirements

Session Functional Units:

a) kernel

b) duplex

c) half-duplex

d) expedited data

e) major synchronize

f) resynchronize - only a Resynchronize Type value of "restart"

g) typed data

Version Number: 2

Maximum size of User Data parameter field: 10,240

Session Options: expedited data

25
Part 5 - Upper Layers

13.5 MMS

Septemberig91 (Stable)

13.5»1 ACSH Requirements

ACSE Ftinc^nal Units: Kernel

Appfication Context: ISO MMS" { iso(l) standard(O) 9506 part(2) mms-application-context-versiOQt(3)> - Implies us$ of ACSE and MMS ASE

13.5.2 Presentation Requirements

Presentation Functional Units: Kernel

At lea^ 2 Presentation Contexts must be supported

Abstract Syntaxes;

a) "mms-abstract-syntax-major-verstonl" { 1so(l) standard(0) 9506 partC2} mms-abstradt^symtaix*

major-version 1 {1)>

b) "ISO 8650-AC$E1" {joint-iso-ccitt(2) association-control (2) abstract-syntax(l) apdu8(0)

versiont{t)>

Associated Transfer Syntax: "Basic Encoding of a single ASN.1 type" {joint-isO"CCitt(2) asnl(1) basicencoding(i ))

13*5,3 Session Requirements

Session Functional Units!

a) Kernd

b} Duplex

Version Number' 2

Maximum size of User DaTa parameter field: 10.240

26
Part 5 - Upper Layers

13.6 Transaction Processing

See Working Implementation Agreements Document.

September 1991 (Stable)

13.7 Network Management

13.7.1 ROSE Requirements

The Rose requirements are as specified in ISO 9596 section 5.2: Underlying Services, and section 6.2 Remote Operations.

Operations Classes: 1 , 2, and 5

Association Classes: 3

13.7.2 ACSE Requirements

ACSE Functional Units: kernel

Application Contexts: as defined by [SMO]

AE-Title: The association responder shall support both forms of the AE-Title. The association requestor

may use either form of the AE-Title.

13.7.3 Presentation Requirements

Presentation Functional Units: kernel

Presentation Contexts: At least 2 must be supported.

Abstract Syntaxes:

a) "ISO 8650-ACSE1" { joint-iso-ccitt(2) association-control (2) abstract-syntax(l) apdus(O)

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(l) }

26-1
Part 5 - Upper Layers

13.7.4 Session Requirements

Session Functional Units:

a) kernel

b) duplex

Version Number: 2

Maximum size of User Data parameter field: 10,240.

September 1991 (Stable)

26-2
Part 5 - Upper Layers March 1991 (Stable)

Annex A (informative)

Recommended Practices

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.

27
Part 5 - Upper Layers March 1991 (Stable)

Table 1 - Session States

State Rel Description

1 0 no transport connection

IB 1 VVCl X u for T-connect confirm

IC 2 Tfll XUXt?t>

f transport connected

2A 3 WCl X u for the ACCEPT SPDU

3 4 n ci X u 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

lA 9 Wait for the ABORT ACCEPT SPDU

4A 10 Wai t 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

lOA 16 Wai t for the S-SYNC-MAJOR response

lOB 17 Wait for the S-ACTIVITY-END response

llA 18 Wait for the S-RESYNCHRONIZE response

IIB 19 Wait for the S-ACTIVITY-INTERRUPT response

lie 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

ID 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

28
Part 5 - Upper Layers March 1991 (Stable)

Table 2 - Incoming Events

Event Rel Description

SCONreq 0 S-CONNECT request

SCONrsp 1 S-CONNECT accept response

SCONrsp 2 S-CONNECT reject response

SDTreq 3 S-DATA request

SRELreq 4 S-RELEASE request

SRELrsp 5 S-RELEASE accept response

SUABreq 6 S-U-ABORT request

TCONcnf 7 T-CONNECT confirmation

TCONind 8 T-CONNECT indication

TDISind 9 T-DISCONNECT indication

TIM 10 Time out

AA 11 ABORT ACCEPT

AB-nr 12 ABORT - no reuse AC 13 ACCEPT

CN 14 CONNECT

DN 15 DISCONNECT

DT 16 DATA TRANSFER

FN-nr 17 FINISH - no reuse RF-nr 18 REFUSE - no reuse SACTDreq 19 S-ACTIVITY-DISCARD request

SACTDrsp 20 S-ACTIVITY-DISCARD response

SACTEreq 21 S-ACTIVITY-END request

SACTErsp 22 S-ACTIVITY-END response

SACTIreq 23 S-ACTIVITY-INTERRUPT request

SACTIrsp 24 S -ACTIVITY-INTERRUPT response

SACTRreq 25 S-ACTIVITY-RESUME request

SACTSreq 26 S-ACTIVITY-START request

SCDreq 27 S-CAPABILITY-DATA request

SCDrsp 28 S-CAPABILITY-DATA response

SCGreq 29 S -CONTROL-GIVE request

SEXreq 30 S-EXPEDI TED-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

SR<?YNrpa < r \ 15

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

29
Part 5 - Upper Layers March 1991 (Stable)

Table 2 - Incoming Events (continued)

Event Rel Description

AB-r 44 ABORT - reuse SPDU

AD 45 ACTIVITY DISCARD SPDU

ADA 46 ACTIVITY DISCARD ACK SPDU

AE 47 ACTIVITY END SPDU

AEA 48 ACTIVITY END ACK SPDU

AI 49 ACTIVITY INTERRUPT SPDU

AIA 50 ACTIVITY INTERRUPT ACK SPDU

AR 51 ACTIVITY RESUME SPDU

AS 52 ACTIVITY START SPDU

CD 53 CAPABILITY DATA SPDU

CDA 54 CAPABILITY DATA ACK SPDU

ED 55 EXCEPTION DATA SPDU

ER 56 EXCEPTION REPORT SPDU

EX 57 EXPEDITED DATA SPDU

FN-r 58 FINISH - reuse SPDU

GT 59 GIVE TOKENS SPDU

GTA 60 GIVE TOKENS ACK SPDU

GTC 61 GIVE TOKENS CONFIRM SPDU

MAA 62 MAJOR SYNC ACK SPDU

MAP 63 MAJOR SYNC POINT SPDU

MIA 64 MAJOR SYNC ACK SPDU

MIP 65 MINOR SYNC POINT SPDU

NF 66 NOT FINISHED SPDU

PR-MAA 67 PREPARE (MAJOR SYNC ACK) SPDU

PR-RA 68 PREPARE (RESYNCHRONIZE ACK) SPDU

PR-RS 69 PREPARE (RESYNCHRONIZE) SPDU

PT 70 PLEASE TOKENS SPDU with Token Item Paramet r RA 71 RESYNCHRONIZE ACK SPDU

RF-r 72 REFUSE - reuse SPDU

RS-a 73 RESYNCHRONIZE - abandon SPDU

RS-r 74 RESYNCHRONIZE - restart SPDU

RS-S 75 RESYNCHRONIZE - set SPDU

TD 76 TYPED DATA SPDU

CDO 77 CONNECT DATA OVERFLOW SPDU

0A7 80 VERFLOW ACCEPT SPDU

PR-AB 79 PREPARE (ABORT) SPDU

30
Part 5 - Upper Layers March 1991 (Stable)

Annex B (normative)

Object Identifier Register

B.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(l) identified-organization(3) oiw(14) ulsig(8) application-context(l) nil(1) } is defined in 14.2;

b) { iso(1) identified-organi2ation(3) oiw(14) ulsig(8) abstract-syntax(2) octet-string(l) } is defined in 14.2.

B.2 Object Identifier Descriptions

{ iso(1) identified-organization(3) oiw(14) ulsig(8) application-context(l) 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(l) }

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.

31

Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 6 - Registrtation Authority

Output from the December 1990 NIST Workshop for

Implementors of OSl

SIG Chair: Einar Stefferud

PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

Table of Contents

Part 6 - Registration Authority Procedures for the OSI Implementors Worltshop (OIW) 1

0 Introduction 1

1 Scope 1

2 Normative References 2

3 Registered Information Objects 2

4 Registration Procedures for Object Identifiers 4

4.1 SIG Registration Authorization 4

4.2 SIG Registration Autliority Function and Duties 5

4.3 Requirements for Information Object Registration 5

4.3.1 Assignment of Object Identifier Component Values 5

4.3.2 Proposal of Object and Identifier to Plenary 5

4.3.3 Completion of IRegistration Procedure 5

4.3.4 Changes and Revisions to the information Object Registration 5

4.4 Register Index 6

Annex A (normative)

Assignments to Workshop Organizations 7

Annex B (normative)

Status of 1987 and 1988 Ad-hoc Object Identifiers 8

III
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Registration Special Interest Group

(RSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI).

This part replaces the previously existing chapter on this subject. There is no significant

technical change from this text as previously given.

iv
Part 6 - Registration Authority Procedures for the OSI Implementors

Workshop (OIW)

NOTE - Previous material in this section has been deleted and is no longer applicable.

This chapter establishes the policies and procedures for the registration of technical objects defined by the

OSI Implementors Worl<shop. Procedures for registering operational and administrative objects, such as the

MHS ADMD and PRMD names and addresses, are outside the scope of this chapter.

0 Introduction

In order to communicate, it is necessary to identify the objects involved in communication. These objects

have names and addresses. A name identifies an object within the domain of a registration authority. An

address is a name that is used to specify the physical or logical location of an object.

OSI names and addresses consist of attributes which are hierarchical in nature and which combine to

identify or locate an OSI object unambiguously. Since the relationship between the components of a name

or address is hierarchical, it follows that the registration authority for names and addresses should also be

hierarchical. A governing organization does not always have sufficient knowledge of organizations lower

in the hierarchy to assign values within those organizations. Thus, an approach frequently taken is to delegate registration authority to the lower organizations.

Hierarchy implies an inverted tree-like structure where the number of objects increases from the root of the

tree to the leaves of the tree. At the root of the tree, there is one designator that has the greatest scope

of authority (largest domain). This designator assigns identifier values to objects under its authority. Each

of these objects has a smaller scope of authority than the objects immediately above and may create zero, one, or many subauthorities at the next-lower level. The number of levels in such a tree-like structure is arbitrary.

1 Scope

This part defines registration procedures for OSI Implementors Workshop (OIW) information objects and

identifies additional registration requirements. These procedures shall be used by the Special Interest Groups (SIGs) of the Workshop to register information objects used in OSI communications according to the OIW Agreements Document.

In this part, the OIW and the SIGs themselves are assigned arcs in the object identifier tree. These arcs are

for OlW-specified objects. The SIGs should note that, as national and international registration authorities are established, objects of interest beyond the Workshop are more appropriately registered by a higher level

in the hierarchy. This will allow more widespread acceptance of the registered objects.

This part is structured as follows: 6.2 describes the information objects that need to be registered, and 6.3 describes a registration procedures for OIW object identifiers. Annex A lists the object identifier component

values assigned to the OIW and the SIGs. Annex B discusses object identifiers used in the 1987 and 1988

Stable Implementation Agreements. The appendices are integral parts of this specification.

1
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS * WORKSHOP (OIW) December 1990 (Stable)

2 Normative References

3 Registered Information Objects

If networks are to interoperate as envisioned in the OSI model, there must be a universal open and agreed

upon naming schema. There are many information objects that fall under this requirement.

Some of the foliov\/ing objects are registered in the standards, some are registered by OIW and others by

other registration authorities. An example list of objects to be registered is:

a) Application-process-titles;

b) Application-entity-titles;

c) Abstract syntaxes;

d) Transfer syntaxes;

e) Application-contexts;

MHS;

1) ADMD names;

2) PRMD names;

3) Organization names;

4) Encoded information types;

5) Extended body part types;

6) Extensions;

7) etc.;

g) Object Identifier values;

h) ASN.1 modules;

i) Directory;

1) Relative distinguished names;

2
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OS! IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

2) Attribute types;

3) Attribute syntaxes;

4) Object classes;

5) Encryption algorithms;

6) etc.;

j) VT;

1) Profiles;

2) Reference information objects;

3) etc.;

k) Network management objects;

I) Network layer addresses;

m) System titles;

n) FTAM;

1) Document types;

2) Constraint sets;

3) etc.;

o) etc.

The OIW Registration Authority shall only administer information objects created by the OIW Agreements

Document that are identified by the ASN.1 type OBJECT IDENTIFIER. Figure 1 illustrates the structure of the object identifier component value for OIW.

3
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSi IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

( iso identif ied-organization oiw (14) ) iso(l)

identif ied-organization( 3

)

oiw( 14

)

Figure 1 - Structure of Object Identifier for OIW.

As an example figure 2 shows the object identifier component value for an example object.

( iso identif ied-organization oiw(14) rasig(13) example ( 0 )

}

iso(l)

identif ied-organization( 3

)

rasig(13)

example (10)

Figure 2 - Structure of an Object Identifier for an Example Object for the Registration Authority BIG

of OIW.

The ISO 6523 Registration Authority has assigned an International Code Designator (ICD) value of 14 to OIW, and OIW has assigned a unique object identifier component value to each SIG. The assigned object

ID values for the OIW and for each SIG are in Annex A. The assignment of values below each SIG in the

object identifier tree is the responsibility of that SIG.

4 Registration Procedures for Object Identifiers

This clause specifies the responsibilities of each SIG and the procedures to be followed for the registration

of information objects, and submission to the OIW Plenary.

When an OIW SIG defines an information object the SIG shall register the object identifier. The registered

value shall be incorporated into the appropriate OIW Agreements Document as a result of a positive ballot response of the OIW Plenary.

4.1 SIG Registration Authorization

An OIW SIG is authorized by its charter and the scope of its work to submit a registration request to the

OIW Plenary.
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

4.2 SIG Registration Authority Function and Duties

The SIG Chair is responsible for the assignment, recording and maintenance of the SIG's registered objects.

The SIG Chair may appoint a specific person to carry out the SIG duties and responsibilities.

4.3 Requirements for Information Object Registration

4.3.1 Assignment of Object Identifier Component Values

Each SIG shall register an object identifier component value for each object's technical definition. The

NameAndNumberForm of the ObjIdComponent specified in ISO 8824/CCITT X.208 is used exclusively. This

form comprises an ASN.1 identifier and, significantly, a NumberForm.

It is suggested that the SIG assign a monotonically increasing integer to the NumberForm at any given level. To the significant root the SIG shall add a assigned object identifier component value that shall be unique.

An example of an object identifier created by the RASIG is shown as follows:

{iso(l)identified-organization(3) oiw(14) rasig(13) example(O)}

Here rasig is the SIG identifier and 13 is the NumberForm assigned by the OIW Registration Authority (see

Annex A); example is the identifier and 0 is the NumberForm assigned by the RASIG.

4.3.2 Proposal of Object and Identifier to Plenary

Registration of an object identifier and its definition is proposed by inclusion of the object identifier and its definition in the OIW "Working Implementation Agreements" document.

4.3.3 Completion of Registration Procedure

Registration of an object identifier and its definition is completed upon Plenary vote to move "Working

Implementation Agreements" text which contains the object identifier and its definition to the "Stable

Implementation Agreements" document.

4.3.4 Changes and Revisions to the Information Object Registration

Neither the technical definition nor the object identifier shall be changed or modified after registration i.e., after the definitions and their identifiers have been voted into the "Stable Implementation Agreements"

document.

5
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

4.4 Register Index

Each SIG shall maintain an index of object identifiers that point to the technical definitions of the respective

objects in the OIW Agreements Document. The index shall appear in the appropriate part annexes of the

OIW Agreements Document.

Index entry example:

Object Identifier Reference

iso identified-organization 4.3.1

oiw(14) rasig(13) example(O)

6
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

Annex A (normative)

Assignments to Workshop Organizations

Identifier Value

oiw 14 (Assigned to OIW by

ISO 6523 RA)

llsig 1 (Assigned to SIG by OIW)

nmsig 2

secsig 3

tpsig 4

f tamsig 5

mhsig 6

dssig 7

ulsig 8

rdasig 9

nunssig 10

odasig 11

vtsig 12

rasig 13

7
PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP (OIW) December 1990 (Stable)

Annex B (normative)

Status of 1987 and 1988 Ad-hoc Object Identifiers

In the 1987 and 1988 versions of the Stable Implementation Agreements, a number of OlW-specified

information objects are assigned object identifiers.

OSI requires names and addresses, e.g., object identifiers, be globally unambiguous. This chapter specifies

object identifier component values which are globally unambiguous. Other chapters in this document

specify the correct object identifiers to be used when referencing OlW-specified information objects.

The use of the 1987 and 1988 OlW-specified object identifiers is deprecated. Newly defined objects shall use the new OIW Identifier.

'

'

''°

8
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 7 - 1984 Message Handling

Systems

Output from the June 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Barbara Nelson (Retix)

Charles Combs (MCI) ftioh Ankney (Simpaot)
Part 7: 1984 Message Handling Systems June 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Message Handling Systems

Special Interest Group (X.400 SIG) of the National Institute of Standards and Technology (NIST)

Workshop for Implementors of Open Systems Interconnection (OSI).

Text in this part has been approved by the Plenary of the X.400 SIG. This part replaces the previously

existing chapter on this subject. There is no significant technical change from this text as previously

given.

Future changes and additions to this version of 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.
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table of Contents

Part 7 CCITT 1984 X.400 Based Message Handling System 1

0 Introduction 1

1 Scope 1

2 Normative References 3

3 Status 3

4 Errata 3

5 PRMD to PRMD 3

5.1 Introduction 3

5.2 Sen/ice Elements and Optional User Facilities 4

5.2.1 Classification of Support for Services 4

5.2.1.1 Support (S) 5

5.2.1.2 Non Support (N) 5

5.2.1.3 Not Used (N/U) 5

5.2.1.4 Not Applicable (N/A) 5

5.2.2 Summary of Supported Services 6

5.2.3 MT Service Elements and Optional User Facilities 6

5.2.4 IPM Service Elements and Optional User Facilities 7

5.3 X.400 Protocol Definitions 9

5.3.1 Protocol Classification 9

5.3.2 General Statements on Pragmatic Constraints 10

5.3.3 MPDUSize 11 5.3.4 PI Protocol Elements . 11 5.3.5 ORName Protocol Elements 16

5.3.6 P2 Protocol Profile (Based on [X.420]) 17

5.3.6.1 P2 Protocol - Heading 17

5.3.6.2 P2 Protocol - BodyParts 20

5.3.6.2.1 BodyPart Identifiers 20

5.3.6.2.2 Privately Defined BodyParts 20

5.3.6.3 P2 BodyPart Protocol Elements 21 5.4 Reliable Transfer Server (RTS) 24

5.4.1 Implementation Strategy 24

5.4.2 RTS Option Selection 24

5.4.3 RTS Protocol Options and Clarifications 25

5.4.4 RTS Protocol Limitations 27

5.5 Use of Session Services 29

5.6 Data Transfer Syntax 29

6 PRMD to ADMD and ADMD to ADMD 29

6.1 Introduction 29

ill
Part 7: 1984 Message Handling Systems December 1990 (Stable)

6.2 Additional ADMD Functionality 30

6.2.1 Relay Responsibilities of an ADMD 31

6.2.2 P1 Protocol Classification Changes 31

6.2.3 0/R Names 31

6.2.4 PI ADMD Name 32

6.3 Inten/vorking with Integrated UAs 32

6.4 Differences with Other Profiles 32

6.4.1 TTC Profile 33

6.4.2 CEPT Profile 33

6.5 Connection of PRMDs to Multiple ADMDs 33

6.6 Connection of an ADMD to a Routing PRMD 33

6.7 Management Domain Names 34

6.8 Envelope Validation Errors 34

6.9 Quality of Service . 35

6.9.1 Domain Availability 35

6.9.1.1 ADMD Availability 35

6.9.1.2 PRMD Availability 35

6.9.2 Delivery Times 35

6.10 Billing Information 36

6.11 Transparency 36

6.12 RTS Password Management 37

6.13 For Further Study 37

7 Inter and Intra PRMD Connections 37

7.1 Introduction 37

7.2 The Relaying PRMD 38

7.2.1 Relay Responsibilities of a PRMD 38

7.2.2 Interaction with an ADMD 38

7.3 Intra PRMD Connections 39

7.3.1 Relay Responsibilities of an MTA 39

7.3.2 Loop Suppression within a PRMD 40

7.3.3 Routing Within a PRMD 40

7.3.3.1 Class Designations 41

7.3.3.2 Specification of MTA Classes 42

7.3.3.3 Consequences of Using Certain Classes of MTAs 42

7.3.4 Uniqueness of MPDUidentifiers Within a PRMD 43

7.4 Service Elements and Optional User Facilities 43

7.5 X.400 Protocol Definitions . 43

7.5.1 Protocol Classification 43

7.5.2 PI Protocol Elements 44

7.5.3 Reliable Transfer Server (RTS) 46

8 Error Handling 46

8.1 MPDU Encoding 46

8.2 Contents 47

8.3 Envelope 47

8.3.1 Pragmatic Constraint Violations 47

8.3.2 Protocol Violations 47

8.3.3 0/R Names 47

iv
Part 7: 1984 Message Handling Systems December 1990 (Stable)

8.3.4 Tracelnformation 48

8.3.5 InternalTracelnfo 48

8.3.6 Unsupported X.400 Protocol Elements 48

8.3.6.1 deferredDelivery 49

8.3.6.2 PerDomalnBllaterallnfo 49

8.3.6.3 ExplicltConversion 49

8.3.6.4 alternateReclpientAllowed 49

8.3.6.5 contentReturnRequest 49

8.3.7 Unexpected Values for INTEGER Protocol Elements 49

8.3.7.1 Priority 49

8.3.7.2 ExplicitConversion 50

8.3.7.3 ContentType 50

8.3.8 Additional Elements 50

8.4 Reports 50

9 MHS Use of Directory Services 50

9.1 Directory Service Elements 50

9.2 Use of Names and Addresses 51

10 Conformance 52

10.1 Introduction 52

10.2 Definition of Conformance 52

10.3 Conformance Requirements 53

10.3.1 Introduction 53

10.3.2 Initial Conformance 54

10.3.2.1 Interworking 54

10.3.2.2 Sen/ice 54

Annex A (normative)

Interpretation of X.400 Service Elements 56

A.I Service Elements 56

A.2 Probe 56

A.3 Deferred Delivery 56

A.4 Content Type Indication 56

A.5 Original Encoded Information Types Indication 57

A.6 Registered Encoded Information Types 57

A.7 Delivery Notification 57

A.8 Disclosure of Other Recipients 57

A.9 Typed Body 57

A.10 Blind Copy Recipient Indication 58

A.11 Auto Forwarded Indication 58

A. 12 Primary and Copy Recipients Indication 58

A.I 3 Sensitivity Indication 58

A.14 Reply Request Indication 58

A. 15 Body Part Encryption 58

A. 16 Forwarded IP N/lessage Indication 59

A. 17 Multipart Body 59

V
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex B (informative)

Recommended X.400 Practices 60

B.1 Recommended Practices in P2 60

B.1.1 ORDescriptor 60

B.1.2 FonA/ardedlPMessage BodyParts 60

B.1.3 Deliverylnformation

.

60

B.2 Recommended Practices in RTS 60

B.2.1 S-U-ABORT 60

B.2.2 S-U-EXCEPTION-REPORT 61

B.2.2.1 receiving ability jeopardized (value 1) 61

B.2.2.2 local ss-User error (value 5) 61

B.2.2.3 irrecoverable procedure error (value 6) 61

B.2.2.4 non specific error (value 0) 61

B. 2.2.5 sequence error (value 3): 61

B.2.3 OSI Addressing Information 61

B.3 Recommended Practices for ORName 62

B.4 Postal Addressing 64

B.5 EDI use of X.400 . 65

B.5.1 Introduction and Scope 65

B.5.2 Model 65

B.5.3 Protocol Elements Supported for EDI 66

B.5.3.1 Content Type 66

B.5.3.2 Original Encoded Information Types 66

B.5.4 Addressing and Routing 66

B.6 USA Body Parts 67

B.7 Recommended Practices for Binary Data Transfer 67

B. 8 Recommended Practice for Office Document Architecture (ODA) Transfer 68

B.8.1 ODA In P2 68

B.8.2 ODA In PI 68

Annex C (normative)

Rendition of lASText and 161 String Characters 69

C. I Generating and Imaging IA5Text 69

C. 2 Generating and Imaging T61 String 69

Annex D (informative)

Differences in Interpretation Discovered Through Testing of the MHS for the CeBit 1987

Demonstration 70

D. I Encoding of RTS User Data 70

D.2 Extra Session Functional Units 70

D.3 Mixed Case in the MTA Name 71 D.4 X.410 Activity Identifier 71 D.5 Encoding of Per Recipient Flag and Per Message Flag 71 D.6 Encoding of Empty Bitstrings 71 D.7 Additional Octets for Bitstrings 72

D.8 Application Protocol Identifier 72

vi
Part 7: 1984 Message Handling Systems December 1990 (Stable)

D.9 Initial Serial Number in S-CONNECT 72

D.10 Connection Data on RTS Recovery 72

D.11 Activity Resume 72

D.12 Old Activity Identifier 72

D.13 Negotiation Down to Transport Class 0 73

Annex E (informative)

Worldwide X.400 Conformance Profile Matrix 74

Annex F (informative)

Interworking Warnings 84

vli
Part 7: 1984 Message Handling Systems December 1990 (Stable)

List of Figures

Figure 1 - The layered structure of this implementation agreement 1 Figure 2 - This agreement applies to the interface between: (A) PRMD and PRMD; (B) PRMD

and ADMD; (C) ADMD and ADMD; and (D) MTA and MTA 2

Figure 3 - Interconnection of private domains 4

Figure 4 - X.409 Definition of Privately Defined BodyParts 21 Figure 5 - An ADMD f^ay (b) or May Not (a) Serve as a Relay 30

Figure 6 - Relaying PRMD 38

Figure 7 - Intra PRMD connections 39

Figure 8 - MD C must know of A to route the message 39

Figure 9 - Definition of InternalTracelnfo 40

Figure 10 - Defined Actions in MTASuppliedlnfo 40

Figure 1 1 - Example of a Configuration to be Avoided 42

vlli
Part 7: 1984 Message Handling Systems December 1990 (Stable)

List of Tables

Table 1 - Basic MT Service Elements 6

Table 2 - MT Optional User Facilities Provided to the UA-Selectable on a Per-Message Basis 7

Table 3 - MT Optional User Facilities Provided to the UA Agreed for Any Contractual Period of

Time 7

Table 4 - Basic IPM service elements 8

Table 5 - IPM Optional Facilities Agreed for a Contractual Period of Time 8

Table 6 - IPM Optional User Facilities Selectable on a Per-Message Basis 9

Table 7 - Protocol Classifications 10

Table 8 - P1 Protocol Elements 12

Table 9 - ORName Protocol Elements 16

Table 1 0 - P2 Heading Protocol Elements 18

Table 1 1 - P2 BodyParts 22

Table 12 - Checkpoint Window Size of IP 27

Table 13 - RTS Protocol Elements 28

Table 14 - PI Protocol Classification Changes for a Delivering ADMD 31

Table 15 - Delivery Time Targets 36

Table 16 - Forced Nondelivery Times 36

Table 1 7 - Conformant MTA Classifications 41 Table 18 - PI Protocol Elements 44

Table B.I - Printable String to ASCII Mapping 63

Table E.I - Protocol Element Comparison of RTS 74

Table E.2 - Protocol Element Comparison of PI 76

Table E.3 - Protocol Element Comparison of P2 81

Ix
Part 7: 1984 Message Handling Systems December 1990 (Stable) '

Foreword

This part of the Stable Implementation Agreements was prepared by the Message Handling Systems

Special Interest Group (X.400 SIG) of the National Institute of Standards and Technology (NIST)

Workshop for Implementors of Open Systems Interconnection (OSI).

Text in this part has been approved by the Plenary of the X.400 SIG. This part replaces the previously

existing chapter on this subject. There is no significant technical change from this text as previously

given.

X
Part 7 CCITT 1984 X.400 Based Message Handling System

NOTE - The classification schema used in this chapter (see table 7) pre-dated TR 10 000 and was the

basis of extensive harmonization, as such: No attempt will be made to align this chapter with TR 10 000.

Editor's Note - Several errata items were approved at the March 1991 OlW Pleanry. dealing with (a) a

pjewsrequirement for the generation of domain-defined attributes, and (b) a relaxation of requirement iot-W. 10 Of the EIT to be set (recommendation for ODA transfer). Text j$ found in the aligned sectiort of the

VS/(»feing Document.

0 Introduction

This is an implementation agreement developed by the Implementor's Workshop sponsored by the U.S. National Institute of Standards and Technology to promote the useful exchange of data between

devices manufactured by different vendors. This agreement is based on, and employs protocols

developed in accord with, the OSI Reference Model. While this agreement introduces no new protocols,

it eliminates ambiguities in interpretations.

This is an implementation agreement for a Message Handling System (MHS) based on the X.400-series

of Recommendations (1984) and Version 5 of the X.400 Series Implementor's Guide from the CCITT. It is recommended that product vendors consult later versions of this guide. Figure 1 displays the layered

structure of this agreement.

This agreement can be used over any Transport protocol class. In particular, this MHS agreement can

be used over the Transport protocol class 0 used over CCITT X.25, described in clause 5.2 of this document. In addition, this MHS agreement can be used over the Transport profiles used in support of MAP (Manufacturing Automation Protocol) or TOP (Technical and Office Protocols). Note that the MAP

or TOP environment must support the reduced Basic Activity Subset (BAS) as defined in X.410.

The UAs and MTAs require access to directory and routing services. A Directory Service is to be

provided for each (vendor-specific) domain. Except insofar as they must be capable of providing

addressing and routing described hereunder, these services and associated protocols are not described

by this agreement.

User Agent Layer CCITT X.420

Message Transfer Agent Layer CCITT X.411

Reliable Transfer Service Layer CCITT X.410

Presentation Layer CCITT X.410 Sec. 4.2

Session Layer See clause 5.9

Figure 1 - The layered structure of this implementation agreement.

1
Part 7: 1984 Message Handling Systems March 1991 (Stable)

1 Scope

This agreement applies to Private Management Domains (PRMDs) and Administration Management

Domains (ADMDs). Four boundary interfaces are specified:

a) PRMDtoPRMD.

b) PRMDtoADMD,

c) ADMD to ADMD, and

d) MTA to MTA (witfiin a PRMD, e.g., for MTAs from different vendors).

In case A, tfie PRMDs do not make use of MHS services provided by an ADMD. In cases B and C, UAs

associated witii an ADMD can be tfie source or destination for messages. Furtliermore, in cases A and

B, a PRMD can serve as a relay between MDs, and in cases B and C an ADMD can serve as a relay

between MDs. Figure 2 illustrates the interfaces to which the agreement applies.

X.400 protocols other than the Message Transfer Protocol (P1) and the Interpersonal Messaging

Protocol (P2) are beyond the scope of this agreement. Issues arising from the use of other protocols or

relating to P1 components in support of other protocols are outside the scope of this document. This

agreement describes the minimum level of services provided at each interface shown in figure 2. Provision for the use of the remaining services defined in the X.400 Series of Recommendations is outside the scope of this document.

With the exception of intra domain connections, this agreement does not cover message exchange

between communicating entities within a domain even if these entities communicate via P1 or P2.

Bilateral agreements between domains may be implemented in addition to the requirements stated in this document. Conformance to this agreement requires the ability to exchange messages without use of bilateral agreements.

2
Part 7: 1984 Message Handling Systems March 1991 (Stable)

PRMD = Private Management Domain

ADMD = Administration Management Domain

PRMD

MTA A

D

MTA B

PRMD

I

I A

A

PRMD

I

I

I

I B

B

ADMD

C

ADMD

Figure 2 - This agreement applies to the interface between: (A) PRIVID and PRMD; (B) PRMD and

ADMD; (C) ADMD and ADMD; and (D) MTA and MTA.

2 Normative References

CCITT Recommendation X.121 (1988), Intemationai Numbering Plan.

CCiTT Recommendation X.400, (Red Book, 1984), Message Handling Systems: System Model-Service

Elements.

CCITT Recommendation X.401, (Red Book, 1984), Message Handling Systems: Basic Service Elements

and Optional User Facilities.

CCITT Recommendation X.408, (Red Book, 1984), Message Handling Systems: Encoded Information

Type Conversion Rules.

CCITT Recommendation X.409, (Red Book, 1984), Message Handling Systems: Presentation Transfer

Syntax and Notation.

CCITT Recommendation X.410, (Red Book, 1984), Message Handling Systems: Remote Operations and

Reliable Transfer Server.

CCITT Recommendation X.411, (Red Book, 1984), Message Handling Systems: Message Transfer Layer.

CCITT Recommendation X.420, (Red Book, 1984), MessageHandling Systems: Interpersonal Messaging

User Agent l_ayer.

CCITT Recommendation X.430, (Red Book, 1984), Message Handling Systems: Access Protocol for Teletex Terminals.

3
Part 7: 1984 Message Handling Systems March 1991 (Stable)

3 Status

This version of ttie X.400 based Message Handling System implementation agreements was completed on December 16, 1988. No further enhancements will be made to this version. See the next

clause-Errata.

4 Errata

5 PRMD to PRMD

5.1 Introduction

This clause is limited in scope to issues arising from the direct connection (interface A in figure 2) of two

PRMDs. "Direct" means that no ADMD or relaying PRMD provides MHS services to facilitate message

interchange. "Direct" does not exclude those instances for which Administrations happen to be ADMDs

but are not providing X.400 services, that is, they are used only to provide lower layer services such as

X.25. Figure 3 schematically represents the scope of this clause.

These issues relate to the use of the UAL (User Agent Layer) and MTL (Message Transfer Layer)

services, protocol elements, recommended practices and constraints. In particular, this clause addresses

the PI and P2 protocols and their related services in a direct connection environment. This clause

describes the minimum level of services provided by a PRMD. Provision for the use of the remaining

services defined in the X.400 Series of Recommendations is beyond the scope of this clause.

Private Domain X

UA

MTA

/ \

the

;remainder o£ : Domain X

NETWORK

P2

PI

Private Domain Y

UA

MTA

<—

I

the

remainder ofi: Domain Y

NETWORK

Figure 3 - Interconnection of private domains.

4
Part 7: 1984 Message Handling Systems March 1991 (Stable)

5.2 Service Elements and Optional User Facilities

This clause identifies tliose service elements and optional user facilities that nnust be provided in support

of P1 and P2.

The classification of UA and MT-Service elements is used to define characteristics of equipment.

Equipment can claim SUPPORT or NON-SUPPORT of a Service; in the case of UA-service elements, a

separate classification is given for Origination and Reception.

The service provider is defined as the entity providing the service, in this case, the MTL or the UAL. The

service user is either the MHS user or the UAL. The classification of provider and user relates to the

sublayer for which the service element is defined.

Support means:

a) The service provider makes the service element available to the service user, and

b) The service user gives adequate support to the MHS to invoke the service element or makes

information associated with the service element available.

Support for Origination means that:

a) The service provider makes the service element available to the service user for invocation,

and

b) The service user gives adequate support to the end user of the MHS to invoke the service

element.

Support for Reception means that:

a) The service provider makes information associated with the service element available to the

service user.

NOTE - A UA- or MT-service element can carry information from originator to recipient only if:

b) the service element is available to the originator,

c) the service element is available to the recipient, and

d) all intermediate steps carry the information.

5.2.1 Classification of Support for Services

5.2.1.1 Support (S)

5
Part 7: 1984 Message Handling Systems March 1991 (Stable)

5.2.1.2 Non Support (N)

This means that the service provider is not required to make the service element available to the service

user. However, the service provider should not regard the occurrence of the corresponding protocol

elements as an error and should be able to relay such elements. Implementations making a profile

available should indicate deviations (additions or deletions) with respect to the requirement in the profile.

5.2.1.3 Not Used (N/U)

This means that although the Recommendation allows this service element, this profile does not use it.

5.2.1.4 Not Applicable (N/A)

This means that this service element does not apply in this particular case (for originator or recipient).

5.2.2 Summary of Supported Services

Within a PRMD, a User Agent must support all P2 BASIC IPM Services (X.400) and all P2 ESSENTIAL

IPM Optional user facilities (X.401) subject to the qualifiers listed in annex A.

Within a PRMD, a MTA must support all BASIC MT Services (X.400) and all ESSENTIAL MT optional user facilities (X.401) subject to the qualifiers listed in annex A.

No support is required of the additional optional user facilities of X.401.

5.2.3 MT Service Elements and Optional User Facilities

Tables 1 through 3 show the Message Transfer (MT) service elements and optional user facilities.

Table 1 - Basic MT Service Elements

Support (S) or Service Elements Non-support (N)

Access Management N/U

Content Type Indication S

Converted Indication S

Delivery Time Stamp Indication S

Message Identification S

Non-delivery Notification S

Original Encoded Information Types Indication S

Registered Encoded Information Types N/U

Submission Time Stamp Indication S

Notes

1 Not applicable to co-resident UA and MTA.

6
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 2 - MT Optional User Facilities Provided to the UA-Selectable on a Per-Message Basis

Support (S) or MT Optional User Facilities Categorization Non-support (N)

Alternate Recipient Allowed E S

Conversion Prohibition E

Deferred Delivery E

Deferred Delivery Cancellation E kN^

Delivery Notification E

Disclosure of Other Recipients E ^3

Explicit Conversion A N

Grade of Delivery Selection E S

Multi-destination Delivery E S

Prevention of Non-delivery Notification A

Probe E N*

Return of Contents A N

Legend

E: Essential optional user facility.

A: Additional optional user facility.

Notes

2 A local facility subject to qualifiers in annex A.

3 Support not required for an originating MT user; support must be

provided for recipient MT users.

4 Subject to qualifiers in annex A.

Table 3 - MT Optional User Facilities Provided to the UA Agreed for Any Contractual Period of

Time

MT Optional User Facilities Categorization

Support (S) or Non-Support (N)

Alternate Recipient Assignment A

Hold for Delivery A

Implicit Conversion A

N

N/U

N

Legend

A: Additional optional user facility.

5.2.4 IPM Service Elements and Optional User Facilities

Tables 4 through 6 show the iPM service elements and optional user facilities.

7
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 4 - Basic IPM service elements

Or i ainat ion Reception

Service Elements by UAs by UAs

Access Management N/u5 N/U^

Content Type Indication S S

Converted Indication N/A S

Delivery Time Steunp Indication N/A s Message Identification S s Non-delivery Notification S N/A

Original Encoded Information s S

Types Indication

Registered Encoded Information Types N/A n/a5

Submission Time Stamp Indication s s IP-message Identification s s Typed Body s s Notes

5 Does not apply to co-resident UA and MTA.

Table 5 - IPM Optional Facilities Agreed for a Contractual Period of Time

Support (S) or Service Elements Categorization Non-Support (N)

Alternate Recipient Assignment A N

Hold for Delivery A N

Implicit Conversion A N

8
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 6 - IPM Optional User Facilities Selectable on a Per-Message Basis

Origination

IPM Optional User Facilities by UAs

Reception

by UAs

Alternate Recipient Allowed A (N) A (N)

Authorizing Users Indication A (N) E (S)

Auto-forwarded Indication A (N) E (S)

Blind Copy Recipient Indication A (N) E (S)

Body Part Encryption Indication A (N) E (S)

Conversion Prohibition E (S) E (S)

Cross-referencing Indication A E (S)

Deferred Delivery E (N)° N/A

Deferred Delivery Cancellation A (N/U)^ N/A

Delivery Notification E (S) N/A

Disclosure of Other Recipients A (N) E (S)

Expiry Date Indication A (N) E (S)

Explicit Conversion A (N) N/A

Forwarded IP—message Indication A (N) E (S)

Grade of Delivery Selection E (S) E (S)

Importance Indication A (N) E (S)

Mult i -destination Delivery E (S) N/A

Multi-part Body A (N) E (S)

Non-receipt Notification A (N) A (N)

Obsoleting Indication A (N) E (S)

Originator Indication E (S) E (S)

Prevention of Non-delivery Notification A (N) N/A

Primary and Copy Recipients Indication E (S) E (S)

Probe A (N) N/A

Receipt Notification A (N) A (N)

Reply Request Indication A (N) E (S)

Replying IP-message Indication E (S) E (S)

Return of Contents A (N) N/A

Sensitivity Indication A (N) E (S)

Subject Indication E (S) E (S)

Notes

6 A local facility subject to qualifiers in annex A,

5.3 X.400 Protocol Definitions

This clause reflects the agreements of the NIST/OSI Workshop regarding P1 and P2 protocol elements.

5.3.1 Protocol Classification

The protocol classifications are defined in table 7.

9
Part 7: 1984 Message Handling Systems

Table 7 - Protocol Classifications

December 1990 (Stable)

1) UNSUPPORTED = X

These elements may be generated, but no specific processing should

be expected in a relaying or delivering domain. A relaying domain

must at least relay the semantics of the element. The absence of

these elements should not be assumed, in a relaying or delivering

domain, to convey any significance.

2) SUPPORTED = H

These elements may be generated. However, implementations are not

required to be able to generate these elements. Appropriate

actions shall be taken in a relaying or delivering domain.

3) GENERATABLE = G

Implementations must be able to generate and handle these protocol

elements, although they are not necessarily present in all

messages generated by implementations of this profile.

Appropriate actions shall be taken in a relaying or delivering

domain.

4) REQUIRED = R

Implementations of this profile must always generate this protocol

element. However, its absence cannot be regarded as a protocol

violation as other MHS implementations may not require this

protocol element. Appropriate actions shall be taken in a relaying or delivering domain.

5) MANDATORY = M

This must occur in each message as per X.411 or X.420 as appropriate; absence is a protocol violation. Appropriate actions

shall be taken in a relaying or delivering domain.

5.3.2 General Statements on Pragmatic Constraints

Where a protocol element is defined as a choice of Numeric String and Printable String (i.e., Administration Domain Name and Private Domain Identifier), then a numeric value encoded as a

printable string is equivalent to the same value encoded as a numeric string. This does not apply to the

Country Name protocol element.

The maximum number of recipients in a single MPDU is 32K - 1 (that is, 32767). However, no individual

limits on the number of occurrences (recipients) are placed on the following protocol elements:

Authorizing Users, Primary Recipients, Copy Recipients, Blind Copy Recipients, Obsoletes and Cross

References. Additionally, there is no limit on the number of Reply to Users. This is a local matter for the

originating system.

Use of strings. A Printable String is defined in terms of the number of characters, which is the same

number of octets. For T.61 strings the number of octets is twice the number of characters specified.

The ability to generate maximum size elements is not required, with the exception of the component

fields in the Standard Attribute List, in which case it is required.

10
Part 7: 1984 Message Handling Systems December 1990 (Stable)

5.3.3 MPDU Size

The following agreements govern the size of MPDUs:

a) All MTAEs must support at least one MPDU of at least 2 megabyte, and

b) The size of the largest MPDU supported by a UAE is a local matter.

5.3.4 PI Protocol Elements

Table 8 contains Protocol Elements and their classes.

11
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 8 - Pi Protocol Elements

Class

MPDU

Ticd-VTDTMI G

ue J. 1 ve ryKepOr tfiirUU G

ProbeMPDU H

UserMDPU

UMPDUEnvelope M

UMPDUContent M

UMPDUEnve1 ope

MPDUIdentif ier M

originator ORname M

originalEncodedlnformationTypes G

±1. Liiis LiexQ IS aos&iix. f X.1IQH ^n6

jCiiicoaeu xnLorinaT,ion lype is

"unspecified.

ContentType M

UAContentID H Maximum length = 16 characters.

Priority G

PerMessageFlag G Maximum length = 2 octets.

deferredDelivery VA

PerDomainBilaterallnfo X pivj Oil iiumiJ€L QL occurr6nc6s.

Recipientlnfo M

ences . More severe limitations are by bilateral agreement.

Tracelnformation M

UMPDUContent M

MPDUIdentif ier

GlobalDomainldentif ier M

lASString M Maximum length = 32 characters,

graphical subset only. Refer to

T.50 for clarification of graphical PerMessageFlag subset

.

discloseRecipients H

conversionProhibited G

alternateRecipientAllowed H

contentReturnRequest X

12
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 8 - PI Protocol Elements (continued)

1 Element Class Restrictions and Conunents

PerDomainBilaterallnfo

Count r vName H Maximum lenath = 3 characters

Admi n i s t r a t i onDoma i nName M Maximum length = 16 characters.

Bilaterallnfo M Maximxun depth = 8; maximum

length = 1024 octets

(including encoding).

Recipient Info

recipient M

Extens i onl dent i f i e r M Maximum value = 32K - 1 (32767).

perRecipientFlag M Maximum length = 2 octets.

ExplicitConversion X

ResponsibilityFlag M

ReportRequest M

UserReportRequest M

Tracelnformation Reference should be made to

Version 5 of the X.400 Implementor's Guide for information

GlobalDomainldentifier M related to Trace sequencing.

Domai nSuppl i ed I nf

o

M

DomainSu'D'Dl i edinfo arrival M

deferred X

action M

0=relayed (value) G

l=rerouted (value) H Rerouting is not required.

converted H

previous H

ORName See clause 5.3.5

Encodedinformat ionTypes

bit string M Delivery can only occur if match

is made with Registered Encoded

Information Types. Individual

vendors may impose limits.

Maximum length = 4 octets.

G3NonBasicParameters X

TeletexNonBasicParameters X

Presentat ionCapabi 1 i t i es X

13
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 8 - PI Protocol Elements (continued)

Element Class Restrictions and Comments

De 1 i veryRepor tMPDU

DeliveryRepor tEnve1ope M

Deli veryReportContent M

DeliveryReportEnve1 ope

reoort M

originator M

Traceinformat ion M

Deli veryReportContent

original M

intermediate 6 See comment at end of table.

UAContentID G

ReportedRecipientlnfo M Maximum number = 32K - 1

occurrences

.

returned H Can only be issued if specifically

requested in the originating

message.

billinglnformation X Maximum depth = 8; maximum

length = 1024 octets (including

encoding)

.

ReportedRecipientlnfo

recipient M

Extensions Identifier M

PerRecipientFlag M

Las tTraceInformat ion M

intendedRecipient

Supplementaryinformat ion X Maximum length = 64 characters.

Value is pending verification by

the CCITT SG VIII or XI.

LastTraceInformat ion

arrival M

converted G

Report M

14
Part 7: 1984 Message Handling Systems June 1991 (Stable)

Table 8 - PI Protocol Elements (concluded)

Element Class Restrictions and Comments

Report

Deliveredlnfo

Nondeliveredlnfo

Deliveredlnfo

delivery

typeofUA

G

G

M

R

Generated if delivery is reported.

Generated if failure to deliver

is reported.

This element must be generated with

a PRIVATE value by PRMDs,

NonDeliveredlnfo

ReasonCode

Di agnos t i cCode

M

H Whenever possible, use a meaningful

1 agnos uxc coae. ProbeEnvelope

probe

originator

ContentType

UAContentID

original

M

M

M

H

G

Maximum length = 16 characters.

If this field is absent, then the

Encoded Information Type is

"unspecified.

Tracelnformation M

PerMessageFlag G

contentLength

PerDomainBi later allnfo

Recipientlnfo

GlobalDomai nident i £ i e

Count ryName

Admi ni s t r at i onDomai nName (4)

H

X

M

M

M

Maximum number = 32K - 1

occurrences.

Maximum length = 3 characters.

Maximum length = 16 characters or digits

PrivateDomainldentif ier R Maximum length = 16 characters or digits. This element must be

generated by PRMDs.

End of Definitions

Notes

Comment on intermediate Tracelnformation in the DeliveryReportContent in

table 8: Audit and confirmed reports should not be requested by other

than the originating domain for two reasons. First, the return path of

the report may be different from the path taken by the original message,

and it may exclude the domain that added the request for audit and

confirmed to the message. Second, if the return path is different from

the path of the original message, the originating domain would receive

intermediate trace information that it did not request.

15
Part 7: 1984 Message Handling Systems June 1991 (Stable)

5.3.5 ORName Protocol Elements

Only form 1 variant 1 0/R names are supported.

Table 9 contains ORName protocol elements.

These agreements interpret 1984 X.400 clause 3.4 to mean that the attributes in the ORName in the

MPDU must identify exactly one UA. and that all the values for the attributes specified in the ORName

must be identical to the values of the corresponding attributes associated with the recipient UA.

Underspecified names that are unique are deliverable.

Overspecified ORNames, ORNames with mismatching fields, and ambiguous names are to be nondelivered or sent to the alternate recipient as appropriate.

Table 9 - ORName Protocol Elements

Element Class Restrictions and Comments

ORName

StandardAttributeList M

DomainDef inedAttributeList

StandardAttributeList (1)

Count ryName R As defined in X.411, Maximum

length = 3 characters.

AdministrationDomainNeune (4) R Maximum length = 16 characters

or digits.

YA naximum xeng^n — aigirs.

TerminallD X Maximim length = 24 characters.

PrivateDomainName (2) 6 Maximum length = 16 characters.

OrganizationNeune (2) 6 Maximum length = 64 characters.

Uni queUAIdentifier X Maximum length = 32 digits.

PersonalName G Maximum length of values of subelements = 64 characters.

Note: The possibility that this

value may be reduced to 40

characters is for further

study by the CCITT.

OrganizationalUnit (3) G Maximum length =32 characters per occurrence. A maximum of four

occurrences are allowed.

DomainDef inedAttributeList (5) Maximum = 4 occurrences.

type M Maximum length = 8 characters.

value M Maximum length = 128 characters.

PersonalName

surName M Maximum length =40 characters.

givenName G Maximum length = 16 characters.

initials G Maximum length = 5 characters;

excluding surname initial and

generat ionQual i f ier

punctuation and spaces.

G Maximum length = 3 characters.

16
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 9 - ORName Protocol Elements (concluded)

Notes:

1 The following apply for comparison of the Standard Attributes of an 0/R Name:

a) Lower case is interpreted as upper case (for IA5).

b) Multiple spaces may be interpreted as a single space. Originating

domains shall only transmit single significant spaces. If multiple

spaces are transmitted, non-delivery may occur.

2 At least one of these must be supplied.

3 These should be sent in descending sequence, from the most significant

<Organizational Unit> (highest in organization hierarchy) to the least

significant. Only those specified should be sent. (That is, an unspecified <Organizational Unit> should not be sent along as a field

of [null] content, nor zero length, etc.)

4 This attribute shall contain one space in all ORNames of messages

originated in a PRMD that is not connected to an ADMD, and in ORNames

of recipients reachable only through a PRMD; otherwise, this attribute

shall contain an appropriate ADMD ncune.

5 Some existing systems which will be accessed via an X.400 service

(whether directly connected using X.400 protocols or otherwise) may

require the provision of addressing attributes which are not adequately

supported by Standard Attributes as defined in these Agreements. In

such cases. Domain Defined Attributes are an acceptable means of

carrying additional addressing information. Failure to support the

specification and relaying of DDAs may prevent successful interworking

with such existing systems until such time as all systems are capable

of relaying and delivery using only the Standard Attribute list.

Specific recommendations on the use of DDAs for particular applications

are in the Recommended Practices, annex B.

5.3.6 P2 Protocol Profile (Based on [X.420])

Tables 10 and 11 classify the support for the P2 protocol elements required by this profile. The tables

give restrictions and comments in addition to X.420.

Restriction on length is one of the types of restrictions. The reaction of implementations to a violation of

this restriction is not defined by this Profile.

5.3.6.1 P2 Protocol - Heading

Table 10 specifies the support for protocol elements in P2 Headings.

17
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 10 - P2 Heading Protocol Elements

Element Class Restrictions and Comments

UAPDU

TM—TIAPDII G

SR-UAPDU X

IM-UAPDU

Hp i na M

Body M

T PMoe e a no T M

originator R

author i z ingUser

s

H

primaryRecipients 6 At least one of primaryRecipients,

couvReciDients G copyRecipients , or blindCopyRecipients must be

b1 i ndCopyRec i pi ent s H present

,

inRenlvTo G

obsoletes H

crossReferences H

subject G Maximum length = 128 T.61

characters (256 octets) ;the ability

to generate the maximum size

subject is not required.

expiryDate H

replyBy H

replyToUsers H

importance H Appropriate action is for further

study.

sensitivity H Appropriate action is for further

study.

autoforwarded H

18
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 10 - P2 Heading Protocol Elements (continued)

Element Class Restrictions and Conmients

IPmessageld

ORNeune H

M

ORDescriptor

ORName H Specify the ORName whenever it is

possible. See annex B.

f reeformName H Maximum length = 64 characters,

oraDhical subsf^l" onlv fl28 octets \ t e 1 ephoneNumbe

H Maximum length = 32 characters.

This allows for punctuation. It

does not take into account possible

future use by ISDN.

Recipient

ORDescriptor M

reportRequest X

replyRequest H

Body No limit on number of BodyParts.

BodyPart G No limit on length of any BodyPart

or the depth of ForwardedlPMessage

BodyParts nested. Classification is

subject to pending CCITT resolution

SR-UAPDU

nonReceipt H

receipt H

reported M

actualRecipient R

i nt endedRec i p i en

t

H

converted X

NonReceipt Information

reason M

nonReceiptQualif ier H

comments H Maximum length = 256 characters.

returned H May only be issued if specifically

requested by originator.

19
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 10 - P2 Heading Protocol Elements (concluded)

Element Class Restrictions and Comments

Receipt Information

receipt M

typeOfReceipt H

Supplementaryinformat ion X Maximum length = 64 characters.

Note: This value is pending

verification by the CCITT SG

VIII or IX.

End of Definitions

5.3.6.2 P2 Protocol - BodyParts

5.3.6.2.1 BodyPart Identifiers

All BodyParts with identifiers in the range 0 up to and including 16K -1 are legal and should be relayed.

BodyPart identifiers corresponding to X. 121 Country Codes should be interpreted as described in Note 2

of figure 4.

a) Implementations are required to generate and image lASText.

b) Implementations should specify the other BodyPart types supported.

c) If an implementation supports a particular BodyPart type for reception, it should also be able

to support that BodyPart type for reception if it is part of a ForwardedlPMessage.

d) For the BodyPart types currently considered, support for the protocol elements is as

j indicated in table 11.

5.3.6.2.2 Privately Defined BodyParts

This clause describes an interim means for identifying privately defined BodyParts. This clause shall be

replaced in a future version taking into account CCITT recommendations with equivalent functionality.

20
Part 7: 1984 Message Handling Systems December 1990 (Stable)

BodyPart : : = CHOICE {

[0] IMPLICIT lASText,

[1] IMPLICIT TLX,

234] IMPLICIT UKBodyParts,

310] IMPLICIT USABodyParts,

} — Where UKBodyParts and USABodyParts are defined as:

SEQUENCE { BodyPartNumber, ANY ) BodyPartNumber ::= INTEGER

Notes

1 In the EncodedlnformationTypes of the PI Envelope, the

undefined bit must be set when a message contains a privately defined BodyPart. Each UA that expects such

BodyParts should include undefined in the set of

deliverable EncodedlnformationTypes it registers with the

MTA.

2 All BodyPartNumbers assigned must be interpreted relative

to the BodyPart in which they are used, which is that

tagged with the value [310] for those defined within the

United States. The NIST assigns unique message

BodyPartNumbers for privately defined formats within the

United States.

3 Refer to clause 12.6 for recommendations regarding the

implementaion of USABodyParts.

Figure 4 - X.409 Definition of Privately Defined BodyParts.

5.3.6.3 92 BodyPart Protocol Elements

21
Part 7: 1984 Message Handling Systems December 1990 (Stable) i

Table 1 1 - P2 BodyParts

Elements Class Restrictions and Conunents

BodyPart

lASText G

TLX X

Voice X

G3Fax X

TIFO X

TTX X

Videotex X

Nat i onal lyDef ined X

Encrvoted X

ForwardedlPMessage H

SFD X

TIFl X

unidentified , X

'

lASText

repertoi re H

lASString M For rendition of lASText see

1. annex C.

TLX For further study by CCITT.

Voice

Set For further study by CCITT.

BitString M

G3Fax

numberOfPages X

PI .G3NonBasicParameters X

SEQUENCE (OF BIT STRING) M

BIT STRING H See Note.

PI .GSNonBasicParameters Support for individual elements is

for further study.

TIFO

T.73Document M

T.73ProtocolElement H See Note.

22
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 1 1 - P2 BodyParts (continued)

Elements Class Restrictions and Comments

TTX

numberOfPages X

telexCompatible X

PI .TeletexNonBasicPareiins X

SEQUENCE M

T61String H See Note.

PI .TeletexNonBasicPareuns

graphicCharacterSets X

controlCharacterSets X

pageFormats X

miscTerminalCapabilities X

privateUse X

Videotex

SET For further study by CCITT.

VideotexString M

Nat i onal lyDef i ned

ANY M

Encrypted

SET For further study by CCITT.

BIT STRING M

ForwardedlPMessage

delivery H

Del i veryinformat ion H

IM-UAPDU M

Deliverylnformation

PI. ContentType M

originator M

original M

PI .Priority G

DeliveryFlags M

otherRecipients H

thisRecipient M

i ntendedRec ipi ent H

converted X

submission M

23
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 1 1 - P2 BodyParts (concluded)

Elements Class Restrictions and Comments

SFD

SFD . Document M

TIFl

T73 Document M

T73 .ProtocolElement H See note.

Note: This element is not an addition to the definition of the BodyPart.

It is described here to show that the SEQUENCE may contain zero

elements. A Problem Report has been submitted to the CCITT to

clarify whether this is permissible. The NIST/OSI Workshop

will adopt the CCITT decision.

5.4 Reliable Transfer Server (RTS)

5.4.1 Implementation Strategy

Based on X.410 Clause 3 and X.411 Clause 3.5.

5.4.2 RTS Option Selection

The maximum number of simultaneous associations is not limited in this profile; if the capacity of a system is exceeded, it should not initiate or accept additional associations.

Associations are established by the MTA which has messages to transfer.

Associations are released when they are not needed. Associations may also be ended prematurely due

to Internal problems of the RTS.

For both monologue and two way alternate associations, the initiator keeps the initial turn. When establishing an RTS association, the following rules apply to the use of parameters in addition to those in X.410 Clause 3.2.1:

a) Dialogue mode: Monologue must be supported for this profile; two-way alternate Is used only

if both partners agree.

b) Initial turn: Kept by the initiator of the association.

The 'priority-mechanism' and the 'transfer-time limit' are regarded as local matters.

24
Part 7: 1984 Message Handling Systems December 1990 (Stable)

5.4.3 RTS Protocol Options and Clarifications

Realization of tlie RTS protocol is subject to the following rules in addition to those specified in X.410

Clause 4:

a) One RTS association corresponds to one or more consecutive session connections (not

concurrent ones). The first is opened with ConnectionData of type OPEN, and subsequent ones

are opened with type RECOVER.

b) Recovery of a Session connection is only by RTS initiator.

c) Checkpoint size:

1 ) Checkpointing and No Checkpointing should be supported. Whenever possible,

checkpointing should be used.

2) The minimum checkpointSize is 1 (that is, 1024 octets).

d) Window size:

1) Minimal value of 1 (if checkpointing is supported).

2) WindowSize = 1 means: After an S-SYNCH-MINOR request is sent, wait until the

confirmation is received before issuing an S-DATA, S-SYNCH-MINOR, or S-ACTIVITY-END request.

e) APDUs should not be blocked into one activity.

f) Only one SSDU shall be transferred:

1) Between two adjacent minor synch points.

2) Between minor synch points and adjacent S-ACTIVITY-START and S-ACTIVITY-END

requests.

3) Between S-ACTIVITY-START and S-ACTIVITY-END without checkpoints.

g) A monologue association is defined as follows:

1 ) The RTS user responsible for establishing the association is called the initiator.

2) The initiator keeps the initial turn.

3) APDUs are transferred in the direction of the initiator to the recipient only.

4) There shall be no token passing.

5) Only the initiator can effect an orderly release of the association.

25
1

I

I

Part 7: 1984 Message Handling Systems December 1990 (Stable) \

b) A two-way alternate association is as described in X.410.

i) In the UserData parameter of the S-U-ABORT, the ReflectedParameter will not be used in the

Abort! nfornnation elenrient.

I

j) When the S-ACTIVITY-RESUME is used to resume an activity in the same session connection as the one in which it started, this must happen immediately after the activity has been

interrupted (i.e., no intervening activity can occur). Otherwise, X.410 Clause 4.3 paragraph 1 may

be violated.

k) When S-ACTIVITY-RESUME is used to resume an activity started in another session

connection, the following conditions must be met:

1) The current session connection is of type "recover."

2) The value of OldSessionConnectionldentifier in S-ACTIVITY-RESUME must match the

value of the SessionConnectionldentifier parameter used in the S-CONNECT of the prior

session connection. This value is also identical to the SessionConnectionldentifier in the

ConnectionData (in PConnect, in SS-UserData) for the current session connection.

3) This must occur as the first activity of the next session connection for the same

RTS-association. It must be the first, othenwise X.410 Clause 4.5.1 point 1 is violated.

NOTE - It Is In the same RTS-ASSOCIATION because the use of S-ACTIVITY-RESUME only makes sense

within the scope of one RTS association.

I) If the transfer of an APDU is interrupted before the confirmation of the first checkpoint, the

value of the SynchronizationPointSerialNumber in S-ACTIVITY-RESUME should be zero, and the

S-ACTIVITY-RESUME must be immediately followed by an S-ACT!VITY-DISCARD.

m) In S-TOKEN-PLEASE, the UserData parameter shall contain an integer conforming to X.409

which conveys the priority.

n) The receiving RTS can use the value of the Reason parameter in the

S-U-EXCEPTION-REPORT to suggest to the sending RTS that it should either interrupt or discard the current activity. S-U-Exception Reports are handled as stated in Version 5 of the

Implementors Guide pages 12-13, paragraph E-33.

o) In the case of S-P-ABORT, the current activity (if any) is regarded as interrupted, rather than

discarded.

p) Table 12 illustrates the legal negotiation possibilities allowed by X.410 Clause 4.2.1 regarding

checkpoint size and window size.

q) These agreements include the provisions of Version 6 of the Implementors Guide identical in

all respects to Version 5, except that the following points have been added to clause 3.5:

1) for section 4.4.1 of X.410; "If the receiving RTS receives an S-ACTIVITY-DISCARD

indication primitive and has already issued a TRANSFER indication primitive, it aborts
Part 7: 1984 Message Handling Systems December 1990 (Stable)

the connection (S-U-ABORT request) with the 'transfer completed' version code."

2) for section 4.6.2 of X.410 'The 'transfer completed (7)' abort reason is used to

indicate to the sending RTS that the receiving RTS could not discard the activity

because it has already completed the transfer (issued a TRANSFER indication primitive)."

Transfer completed (7) is also added to the table of abort reasons in this clause.

Table 12 - Checkpoint Window Size of IP acceptor answer

CS = 0

(or unspecified)

WS unspecified

CS = m

WS = j

(or unspecified)

CS = n

WS = j

(or unspecified)

initiator

proposal

CS = 0

(or unspecified)

WS = i (or unspecified)

legal legal legal

CS = k

WS = i (or unspecified)legal legal not allowed

Legend

CS: means CheckpointSize

WS: means WindowSize

i, j, k, m, and n: are integer values with the following relations:

0 i m i k < n (values assigned to CS)

0 < j 5 i (values assigned to WS)

For unspecified parameters, the default applies. In this case, the

numeric relations apply, that is, the default values substitutefor

the unspecified integer.

5.4.4 RTS Protocol Limitations

The RTS Protocol Limitations for this profile are listed in table 13.

27
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 13 - RTS Protocol Elements

Element Class Res t r i ct i on

PConnect M

Ua \^Cix L Cilia l.rsL OjrllLdA nM Value - 0.

pUserData M

checkpoints ize H

w1 nuowo 1 z e

ITII dialogueMode H

Connect ionData M

Value =1.

TT11 Value = 8883.

Var open

RTS user data G

recover

Dcoo JL (JIlV^OlXIl^w L 1 C/Il J. 06111, 1 L 1 e E RTS use-r data

mTAName G 1 IdA X luuiu J. cxxM L> 11 ^ *t v^iici 1. av^ O

graphic subset of IA5 only.

pas o Wvy-L U c Maximum length 64 octets

graphic subset of IA5 only.

r*VJ

SessionConnectionldentif ier

CallingSSUserReference M nax imuin xciigun d4 ocue^s incxuQing

encoding = 62 octets of T.61.

CommonRefe r enc

e

M

AdditionalReferencelnformation H Maximum length 4 octets including

encoding = 2 octets of T.61.

PAccept G

DataTransferSyntax M Value = 0.

pUserData M

checkpoints! ze H

windows ize H

Connect i onDat

a

M

28
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 13 - RTS Protocol Elements (concluded)

riiemeni X. I. X CX* 1 Oil

PRefuse G

Re£useReason M

SS User Data G See Note

(in S-TOKEN-PLEASE

)

Abortlnformation G

(in S-U-ABORT)

AbortReason H

ref lectedParameter X Restricted to 8 bits.

End of Definitions

Note - Generated if supplied by the RTS

priority in the TURN-PLEASE primitive,

SS-User-Data in S-TOKEN-PLEASE.

-user. The RTS use may specify a and if so, it is carried as the

5.5 Use of Session Services

The session requirements and use of session are covered in part 5 of this document.

5.6 Data Transfer Syntax

This clause defines Presentation Transfer Syntax and notation rules applicable to these agreements.

Implementations must conform EXACTLY as specified in X.409 with no further restrictions. Annex C

defines rendition of IA5 Text and T61 characters.

6 PRMD to ADMD and ADMD to ADMD

6.1 Introduction

This clause defines the implementation agreements that apply to the interface between two management

domains when at least one is an ADMD. A message arriving at an ADMD has either no recipient within

that domain or one or more recipients within that domain. In the former case, the ADMD serves as a

relay between two or more domains and the actions required of that ADMD are independent of the

nature (PRMD or ADMD) of the domains. In the latter case, the ADMD is responsible for delivering

messages to the proper recipient(s) within its jurisdiction, and may also be responsible for relaying the

message.

Given the two roles for an ADMD, this clause describes two distinct sets of functional requirements for an ADMD. The first is the relaying requirement that is needed to provide PRMD and other ADMD

29
Part 7: 1984 Message Handling Systems December 1990 (Stable)

interworking. The second is analogous to the PRMD's support to its customers through the integrated

UAs. These are distinct functional differences. The services provided to the UAs of an ADMD are independent of the requirement that an ADMD provide a function for interworking with any type of

Management Domain (MD). Figure 5 illustrates the two roles played by an ADMD.

This clause is presented in the form of deviations from the agreements applicable to PRMD-to-PRMD

(sec. 5). Unless explicitly noted in the remainder of this clause, all of the specifications for PRMD to PRMD apply to PRMD to ADMD and ADMD to ADMD.

PRMD or ADMD

IPM - UA

<

MTA

P2—

Pica)

ADMD —

—

IPM - UA

MTA

PRMD or ADMD PRMD or ADMD

IPM - UA P2 -> IPM - UA

MTA MTA

I

I

IPI

I

I

I

I

I

. > ADMD

MTA

<

I

I

I

I

IPI

I

I

I

I

(b)

Figure 5 - An ADMD May (b) or May Not (a) Serve as a Relay.

6.2 Additional ADMD Functionality

The following defines the additional ADMD specific functionality required over and above that specified in the PRMD clause.

30
Part 7: 1984 Message Handling Systems December 1990 (Stable)

6.2.1 Relay Responsibilities of an ADMD

ADMDs will relay all content types (not just P2) unchanged in the absence of a request for conversion.

6.2.2 PI Protocol Classification Changes

Table 14 describes the changes to the PRMD P1 Protocol classifications required for a delivering

Administration domain (with respect to the original message; this means the domain which originates the

delivery reports).

Table 14 - Pi Protocol Classification Changes for a Delivering ADMD

Protocol Elements Class

Deliveredlnfo

typeOfUA H

ReportedRecipientlnfo

Supplementarylnformation H See Note 1.

GlobalDomainldentifier

PrivateDomainldentif ier H

For relaying Administration domains, the classifications are all "X"

For originating Administration domains, these are all "NOT APPLICABLE."

Notes

1 Domains providing access to TELEX/TELETEX recipients, whether

directly or indirectly as a result of bilateral agreements

between domains, must ensure that this information, when

present, is accessible by the recipient of the delivery report.

6.2.3 0/R Names

0/R Names shall consist of:

a) CountryName,

b) AdministrationDomainName.

as well as one of the following:

a) PrivateDomainName,

b) Personal Name,

c) OrganizationName,

31
Part 7: 1984 Message Handling Systems December 1990 (Stable)

d) OrganizationalUnit,

e) UniqueUAIdentifier,

f) X1 21 Address.

and permits the optional inclusion of a

a) DomainDefinedAttributeList.

NOTE - The destination PrivateDomainName or OrganizationName must be present if destined for a PRMD. The ADMD relaying the message to that destination PRMD requires this element.

6.2.4 P1 ADMD Name

Management Domains (MDs) must specify in tfie ADMD name field of the 0/R Name

StandardAttributeList in P1 , the name of the Administration domain:

a) to which the message is being sent (in recipient names)

b) from which the message originated (in the originator name).

6.3 Interworking with Integrated UAs

If the message originates at a UA owned by an ADMD, or is delivered to such a UA, the 0/R Name

follows the same Form 1 Variant 1 constraints as the base specifications; except that the ADMD name is the name of the ADMD that owns the UA and instead of supplying a PRMD Name, one (or more) of the

following must be provided:

a) OrganizationName,

b) OrganizationalUnit,

c) PersonalName.

and may optionally include a

a) DomainDefinedAttributeList. .

6.4 Differences with Other Profiles

32
Part 7: 1984 Message Handling Systems December 1990 (Stable)

6.4.1 TTC Profile

There are no outstanding issues regarding intenA/orking between TTC-conformant systems and

N!ST-conformant systems with the exception of the number of recipients and the supported MPDU sizes. The Extensionidentifier field may contain a maximum value of 32K-1 ; however, according to the current TTC profile, if a message with more than 256 recipients is received, some TTC-conformant domain may

generate a nondelivery notification. This also applies to the ReportedRecipientlnfo in a delivery report.

Further, a TTC MTA is required to handle an MPDU size of at least 32KB. The NIST required MPDU size

is 2MB as covered in clause 5.3.3. Other differences are shown in annex E. TTC is currently based on

Version 4 of the Implementor's Guide.

6.4.2 CEPT Profile

See annex E.

6.5 Connection of PRMDs to Multiple ADMDs

Given that Management Domain names (both PRMD and ADMD) shall be unique within the United

States, then when an ADMD is presented a message for transfer from a PRMD, it will accept 0/R Names

(both originator and recipient) which have an AdministrationDomainName field value different than the

Administration's name. "Accept" implies the attempt to route/deliver the message shall be made, as

appropriate, based upon the knowledge that MD names are unique.

Whether this functionality is required by an Administration for conformance to this agreement is for

further study.

If a PRMD is connected to two or more ADMDs which are not effectively connected (either directly or via a third ADMD), full X.400 functionality shall not be available. Problems occur especially in the areas of:

a) Naming,

b) Routing,

c) Replying.

It should be noted that a single PRMD that is connected to more than one ADMD can be represented by more than one combination of country-name, ADMD-name, and PRMD name. For example, it may occur

that the PRMD-name for a particular PRMD may take different values, depending on the ADMD-name.

Implementors should be aware of the consequences of these possibilities on routing.

6.6 Connection of an ADMD to a Routing PRMD

It is possible for a collection of interconnected private domains to establish one domain as the "gateway"

to an ADMD, and hence to the world.

33
Part 7: 1984 Message Handling Systems December 1990 (Stable)

!f an ADMD is connected to such a gateway PRMD, the individual private domains shall be registered

with the Administration. Administrations need not support such connections.

Note also that upon receipt by the ADMD of a message originating somewhere within the PRMD

collection, that the Tracelnformation may contain more than one element.

The X.400 Recommendations specify that an ADMD should not attempt to relay a message destined for another ADMD through a PRMD, thus an ADMD should ensure that messages destined for another

ADMD are not relayed through a PRMD. It should be noted, however, that a relaying PRMD will relay any

such message it receives.

6.7 IVIanagament Domain Names

All Management Domain Names (both Private and Administration) shall be unique within the U.S.

A central naming authority shall be established to register domain names.

6.8 Envelope VaHdatiori Errors

For validation errors, a non-delivery notice shall be generated (if possible) with reason code of

'unableToTransfer' and diagnostic code of 'invalid Parameters' (unless specified othen/*/ise).

ADMDs will validate P1 Envelopes in the following areas:

a) The X.409 syntax of all elements should be checked.

b) The pragmatic constraint limits (lengths of fields and number of occurrences of fields) should

be checked.

c) Semantic validation of the following elements should be done:

1) originator 0/R Name,

2) recipient 0/R Name in the Recipientlnfo,

3) Priority.

d) Only recipient Names with the responsibility flag set should be validated. The validation of 0/R names is defined in 8.3.3; the validation of priority is defined in 8.3.7.1.

e) MPDU Identifier Validation

1) Validation of the GlobalDomainldentifier component of the MPDU Identifier is performed upon reception of a message (i.e., as a result of a TRANSFER.Indication).

2) The country name should be known to the validating domain, and depending on the

country name, validation of the ADMD name may also be possible.

34
Part 7: 1984 Message Handling Systems December 1990 (Stable)

3) Additional validation of tlie GiobalDomainldentifier is performed against the

corresponding first entry in the Tracelnfornriation. If inconsistencies are found during the

comparison, a non-delivery notice with the above defined reason and diagnostic codes

is generated.

4) A request will be generated to the CCITT for a more meaningful diagnostic code

(such as 'InconsistentMPDUIdentifier').

6.9 Quality of Service

6.9.1 Domain Availability

6.9.1.1 ADMD Availability

The goal is to provide 24 hour per day availability. Note that there will be periods of time when an ADMD

may be unavailable due lo maintenance windows in its supporting network or in an MTA within the

domain.

6.9.1.2 PRMD Availability

Although the goal of PRMD availability is also 24 hours per day, business reasons are likely to dictate some different level of availability. ADMDs shall require a profile from the PRMD that indicates its schedule of regular availability to the ADMD.

6.9.2 Delivery Times

In the absence of standardized quality of service parameters, the following are agreed to. When

standardized parameters from CCITT Study Group I become available, they shall be adopted.

a) In table 15 the delivery time targets are established.

b) The interval(s) between retries and the number of retry attempts that an ADMD uses in attempting delivery to a PRMD or integrated UA, will be locally determined domain parameters.

However, the total elapsed times after which delivery attempts will be stopped are shown in table

16. This implies that, after these times, a Non-Delivery Notice will be generated.

c) An Administration shall continue to attempt delivery until the forced nondelivery time, even if the recipient domain has scheduled an unavailability window.

35
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 15 - Delivery Time Targets

Delivery Class 95% Delivered Before

Urgent

Normal

Non-Urgent

3/4 hour

4 hours

24 hours

Table 16 - Forced Nondelivery Times

Delivery Class NonDelivery Forced After

Urgent

Normal

Non-Urgent

4 hours

24 hours

36 hours

NOTE - Both tables apply to the period between acceptance by the originating MTA in the originating

Administration domain to the time of delivery in the destination Administration domain. Transit time within PRMDs is NOT included in the above times.

6.10 Billing Information

All aspects relating to billing, charging, tariffs, settlement, and in particular to the use of the

billinglnformation field in the delivery report, is subject to bilateral agreement, and shall not be addressed

in these implementation agreements.

No ADMD shall require a PRMD to supply or process billing information.

6.11 Transparency

No P1 extensions, other than the MOTIS extensions are to be allowed (Reference A/3211). Should an ADMD receive a message containing PI extensions, it shall generate a non-delivery notice (if possible)

with reason code of unableToTransfer and diagnostic cede of invalid Parameters.

If MOTIS elements are present, a relaying MTA can optionally:

a) Relay the message. If the MTA does relay, it must not drop any of the protocol elements.

b) Non-Deliver the message.

A receiving MTA can optionally:

a) Deliver the message

b) Non-Deliver the message.

The CCITT has been requested to establish a more meaningful diagnostic code (such as protocol Error)

36
Part 7: 1984 Message Handling Systems December 1990 (Stable)

for this occurrence. Such a code has now been provided in the Implementors Guide.

P2 extensions shall be relayed transparently by ADMDs.

6.12 RTS Password Management

RTS password management shall be a local matter. This includes:

a) password length

b) frequency of changes

c) exchange of passwords with communicating partners

d) loading passwords (i.e., the timing of password changes with respect to active

associations).

6.13 For Further Study

Issues requiring further study are:

a) Intra-Domain Routing

b) Multi-Vendor Domains

7 Inter and Intra PRMD Connections

7.1 Introduction

This clause is limited in scope to issues arising from the indirect connection of a PRMD to another

PRMD or to an ADMD, and to the interconnection of MTAs to form inter-PRMD connections. Indirect means that the connection is made via a relaying PRMD. The X.400 Recommendations describe the way

that a PRMD connects to a ADMD and the way that an ADMD connects to another ADMD. The

Recommendations do not, however, describe the way that a PRMD connects indirectly to an ADMD or another PRMD, nor do they describe the way that MTAs are connected within a PRMD. These

configurations (shown in figures 6 and 7) are useful, for example, in connecting equipment from different vendors at a single customer site.

The P1 protocol and its related services for both inter and intra PRMD connections are addressed in this clause. In addition, a method for routing within a PRMD is given. It is recognized that uniform methods

for Administration, maintenance, and quality of service should be developed for such configurations, and

this work is for further study.

This clause describes the minimum that must be provided in order to implement a relaying PRMD and a

37
Part 7: 1984 Message Handling Systems December 1990 (Stable)

MTA within a PRMD.

This clause is presented in the form of deviations from agreements applicable to PRMD to PRMD

connection (sec. 5). That is, unless specifically noted in the remainder of this clause, the agreements in clause 5 apply to both relaying PRMDs and MTAs within a PRMD.

It should be noted that the comments regarding ORNames in clause 6.5 also apply to this clause.

7.2 The Relaying PRMD

A PRMD that has the capability of relaying messages to another PRMD is ceiled a relaying PRMD. A

PRMD implementation need not claim to be a relaying PRMD. A PRMD implementation which does claim

to be a relaying PRMD must follow the implementation agreements in this clause.

7.2.1 Relay ResponsibilitEes of a PRMD

The responsibilities of a relaying PRMD are the same as those of an ADMD (as specified in sees. 6.8 and

6.2.1). In addition, the PRMD will simply deliver messages routed to it from an ADMD, even if this results

in routing a message from the ADMD to the PRMD to another ADMD.

7.2.2 Interaction with an ADMD

In order for an ADMD to route a message to ADMD A via ADMD B, it must know that A is reachable

through B. Similarly, in order for any MD to route a message to PRMD A via a relaying PRMD B, it must

know that A is reachable through B (see figure 8).

ADMD

1 PRMD A PRMD B PRMD C

Relay

Figure 6 - Relaying PRMD.

38

.J
Part 7: 1984 Message Handling Systems December 1990 (Stable)

PRMD

MTA A MTA D

MTA B MTA C

ADMD

or PRMD

Figure 7 - Intra PRMD connections.

NOTES

1 Clause 6.6 specifies that ADMDs are not required to connect to a relaying PRMD, but they are not precluded from doing so.

2 Tracelnformation may have more than one sequence on submission of a message by a relaying PRMD

to an ADMD.

MD D

relay

MD C with

a message

for A

relay

MD B

MD A

Figure 8 - MD C must know of A to route the message.

7.3 Intra PRMD Connections

A PRMD is composed of MTAs which cooperate to perform the functions expected of a domain. An MTA

li implementation need not claim to follow the implementation agreements of this clause.

7.3.1 Relay Responsibilities of an MTA

The relaying responsibilities of an MTA are the same as those of an ADMD (as specified in 6.8 and 6.2.1)

with one exception: loop suppression within the domain is done using the MOTIS InternalTracelnfo

protocol element. The MTA must validate the InternalTracelnfo (see 8.3.5 for details on validation). In addition, the PRMD will simply deliver messages routed to it from an ADMD, even if this results in routing

39
Part 7: 1984 Message Handling Systems December 1990 (Stable)

a message from the ADMD to the PRMD to another ADMD (please see 6.6).

7.3.2 Loop Suppression within a PRMD

The only mechanism defined In the X.400 Recommendations for suppressing loops Is Tracelnformatlon,

which Is added on a per domain basis to detect and suppress loops among domains. Loops among

MTAs within a domain need to be detected and suppressed. This implies that each MTA must add trace information that is meaningful within the domain. The MOTIS solution of adding InternalTracelnfo to the PI Envelope of a message was adopted. The definition of InternalTracelnfo Is given in figure 9. The

InternalTracelnfo Is added by each MTA within a PRMD to handle a message, and It Is examined In the same way as Tracelnformatlon to detect and suppress loops.

InternalTracelnfo :;= [APPLICATION 30] IMPLICIT SEQUENCE OF SEQUENCE {

MTAName

,

MTASuppliedlnfo }

MTAName ::= PrintableString

Figure 9 - Definition of InternalTracelnfo.

If the MTAName and password of X.41 1 are used for validation, then it Is recommended that the

MTAName used for validation also be used In the InternalTracelnfo. However, there Is a complication: In X.41 1 , MTAName Is an lASStrlng, and the MTAname defined by MOTIS Is a PrintableString. Efforts will be

made to change the MOTIS definition from PrintableString to lASString.

Three actions are defined in MTASuppliedlnfo: relayed, rerouted, and reclplentReasslgnment as shown in figure 10. The reclplentReasslgnment action Is not supported In these agreements. The ability to generate It Is not required, and if It Is present on an Incoming message, the action field will be ignored.

MTASuppliedlnfo ;:= SET {

arrival [0] IMPLICIT Time,

deferred [1] IMPLICIT Time OPTIONAL,

action [2] IMPLICIT INTEGER {

relayed (0),

rerouted (1).

recipientReassignment (2) }

previous MTAName OPTIONAL }

Figure 10 - Defined Actions in MTASuppliedlnfo.

7.3.3 Routing Within a PRMD

Routing within a PRMD Is complicated by the lack of a directory standard. In particular, it constrains

intra-domain routing decisions to be based on some combination of the Intra-domain attributes of the

0/R Name, Organization Name Organizational Units, and Personal Name. In order to enhance

interworking and to reduce the difficulty of configuring intra-domain connections. It Is useful to restrict the ways in which these may be used In making routing decisions.

40
Part 7: 1984 Message Handling Systems December 1990 (Stable)

However, it is recognized that vendors may wish to provide MTAs with varying degrees of routing

cafDability within a PRMD as a temporary expedient until appropriate standards for automated

construction of directories and routing tables are available. This clause assigns class numbers to certain

levels of routing capability and discusses the consequences of using MTAs which fall into each class. The classification scheme will allow some diversity in allocating 0/R Name space and in configuring

intra-domain routes.

When other methods are recommerwJed by standards bodies, the classification scheme described here

will become obsolete. Large-scale, multi-vendor PRMDs may not be practical in the absence of standardized methods.

7.3.3.1 Class Designations

When it is clear that a message is to be delivered within a domain, the Country Name, ADMD Name, and

PRMD Name have already served their purpose in determining the next MTA in the route to the recipient.

The remaining fields that might be used on mai<ing routing decisions within the PRMD are the

Organization Name, Organizational Units, and Personal Name.

MTAs are classified by their ability to discriminate between 0/R names when making routing decisions

within a PRMD. Conformant MTAs will be classified as shown in table 17.

Tabie 17 •- Conformant MTA Classifications

Class 1 Class 2 Class 3

Organization Name H H H

SEQUENCE OF Organizational Unit X H H

Personal Name X X H

An 'H' means that the MTA must be able to base its intra-domain routing decisions on the given

component of the 0/R Name. In particular, both Class 2 and Class 3 MTAs must be able to discriminate on all the members in a supplied sequence of OrganizationalUnits. A Class 3 MTA must be able to discriminate on all of the elements in a PersonalName.

An 'X' means that the MTA need not have the ability to discriminate on the given component.

There is a hierarchy in support of components. The ability to discriminate on a given component does

not imply the requirement to do so: e.g., a Class 3 MTA is not required to have tables for every

PersonalName in the domain. Equally, an MTA which can discriminate on OrganizationalUnits to make

routing decisions need not always use the full sequence in an 0/R Name if a partial sequence provides

enough information.

The above classifications only apply to routing decisions in selecting a next hop within a domain. All MTAs are entitled to examine the full 0/R Name when identifying their own directly served UAs.

The routing table of a Class 1 MTA will be relatively small, because intra-domain routing decisions are based solely on OrganizationName. The routing table of a Class 2 MTA may be substantially larger and more complex because of its ability to discriminate on OrganizationalUnits as well as OrganizationName

41
Part 7: 1984 Message Handling Systems December 1990 (Stable)

to make routing decisions. The routing table of a Class 3 MTA may be larger still, because its use of the

components of PersonalName in addition to the other information.

7.3.3.2 Specification of MTA Classes

If an MTA implementation claims to follow the implementation agreements, it must be either a Class 1, Class 2, or a Class 3 MTA. The class of an MTA implementation should be specified so that PRMD

administrators can choose equipment properly.

7.3.3.3 Consequences of Using Certain Classes of MTAs

Definition: An MTA which accepts submission requests and furnishes delivery Indications to a UA is said to "directly serve" the UA.

The presence in a domain of an MTA acting as a Class 1 or Class 2 MTA imposes administrative

restrictions on the assignment of 0/R Names to UAs and in the configuration of routes within that domain.

A Class 1 MTA may directly serve UAs from several OrganizationNames. However, If a Class 1 MTA

directly serves a UA with a given OrganizationName, no other MTA in the domain may directly serve a

user with the same OrganizationName. This means that if all MTAs in a domain are Class 1 , then all UAs

with a given OrganizationName must be assigned to the same MTA.

A Class 2 MTA may directly serve UAs from any combination of OrganizationName and sequence of OrganizationalUnits. However, if a Class 2 MTA directly serves a UA with a given combination, no other

MTA in the domain may directly serve a user with the same combination. This means that if all MTAs in a domain are Class 2, then all UAs with a given OrganizationName and sequence of OrganizationalUnits

must be assigned to the same MTA.

A domain consisting entirely of Class 3 MTAs is free of all the above restrictions.

If Class 1 or Class 2 MTAs are used to perform relaying within a PRMD containing MTAs of other

classes, care must be exercised in determining the topology of the domain to avoid leaving certain UAs

inacessible from certain MTAs within the domain. The example below shows one of the configurations

that should be avoided. The example is intended to stimulate careful examination of the relationship

between network and organizational topologies.

MTA A

serving

Organization X

MTA B

(Class 1)

MTA C

serving

Organization X

Figure 11 - Example of a Configuration to be Avoided.

42
Part 7: 1984 Message Handling Systems December 1990 (Stable)

In figure 1 1

, B will route all messages for Organization X to either A or C because B is a Class 1 MTA.

The administrator who created this configuration probably wanted B to route some messages for Organization X to A, and some to C. However, B does not have the capability for this because it is only a Class 1 MTA. The configuration in figure 1 1 can be corrected by replacing B with a Class 2 or Class 3

MTA.

i

I 7.3.4 Uniqueness of MPDUIdentifiers Within a PRMD

j When generating an lASString in an MPDUIdentifier, each MTA in a domain must ensure that the string is

I unique within the domain. This shall be done by providing an MTA designator with a length of 1 2 octets

I which is unique within the domain, to be concatenated to a per message string with maximum length of

i 20 octets.

I Two pieces of information, the MTA name and MTA designator, need to be registered within a PRMD to guarantee uniqueness. This registration facility need not be automated. If the MTA name is less than or equal to 1 2 characters, it is recommended that it also be used as the MTA designator.

7.4 Service Elements and Optional User Facilities

A PRMD made up of MTAs which support varying sets of service elements in addition to those required

in these agreements may appear to provide inconsistent service for these elements. For example, if one MTA supports deferred delivery and another MTA does not, then deferred delivery can be used by some,

j but not all, users in the PRMD. Similarly, if one MTA supports return of contents and another does not, then a user outside of the PRMD will receive returned contents for messages sent to one user, but not

for messages sent to another user. Note that this same inconsistency occurs when sending to two

PRMDs which support different additional optional elements.

7.5 X.400 Protocol Definitions

This clause describes additions and modifications to clause 5.3 which are required for implementation of a relaying PRMD or an MTA within a PRMD.

7.5.1 Protocol Classification

The classification scheme given in clause 5.3.1 applies to elements passing from one PRMD to another. For both relaying PRMDs, and MTAs in a PRMD, the same classification scheme will be used, but within a PRMD the classification applies to elements passing from one MTA to another.

In addition to the classifications given in clause 5.3.1, a classification of Prohibited has been used.

PROHIBITED = P

This element shall not be used. Presence of this element is a protocol violation.

43
Part 7: 1984 Message Handling Systems December 1990 (Stable)

7.5.2 PI Protocol Elements

Table 18 contains protocol elements and their classes. An * signifies that the classification of the

protocol element has not changed from table 8.

Table 18 - Pi Protocol Elements

Element Class Restrictions and Comments

UMPDUEnvelope

MPDUIdentif ier M* This field needs to be unique

within a PRMD. See clause

7,3.4 for the method of

ensuring uniqueness.

originator M* It is recommended that all

components of the originator's

ORName be included to help ensure

that reports can be returned.

Tracelnformation M* The first MTA in the domain to

receive the message adds the

Tracelnformation. Subsequent

MTAs can update the

Tracelnformation in the event of

conversion or deferred delivery.

When a message is generated, the

originating MTA adds the

Tracelnformation.

InternalTracelnfo M/P This element is mandatory for

envelopes transferred between

MTAs within a PRMD, and

prohibited in messages

transferred outside the domain.

Elements are always added to the

end of the sequence. (See Note 1)

InternalTracelnfo

MTAName

M MTANames within a PRMD must be

unique. See clause 7.3.4 for

the method of assuring uniqueness

Maximum length = 32 characters.

MTASuppl i edinf

o

M
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table 18 - Pi Protocol Elements (continued)

Element Class Restrictions and Comments

MTASuppliedlnfo

arrival

deferred

M

X This field must be generated by

MTAs which perform deferred

delivery.

action M See clause 7.3.2 for

restrictions on values of this

field.

previous X This field must be generated by

MTAs which perform rerouting.

De 1 i veryRepor tEnve 1ope

TraceIn£orination M* The first MTA in the domain to

receive the report adds the

Tracelnformation. When a report

is generated, the originating MTA

adds the Tracelnformation.

InternalTracelnfo

DeliveryReportContent

intermediate InternalTracelnfo

M/P

P

This field is mandatory for

envelopes transferred between

MTAs within a PRMD, and

prohibited in messages

transferred outside the domain.

(See Note 1)

If it were possible to include

this field in the delivery report

content, an audit and confirmed

report could be provided to

detect problems within a PRMD.

Efforts are being made to add

this field to the MOTIS

definition.

Deliveredlnfo

typeOFUA R* It is the responsibility of the

MTA generating the report to

generate this element.

45
I

Part 7: 1984 Message Handling Systems December 1990 (Stable) ^

Table 18 - PI Protocol Elements (concluded)

Element Class Restrictions and Comments

ProbeEnvelope

Tracelnformation M* The first MTA in the domain to

receive the probe adds the

Tracelnformation. When a probe

is generated, the originating MTA

adds the Tracelnformation.

InternalTracelnfo M/P This field is mandatory for

envelopes transferred between

MTAs within a PRMD, and

prohibited in messages

transferred outside the domain.

(See Note 1)

Notes

1 The M classification

claiming conformance

is only applicable if an implementation is

according to clause 10.2.

7.5.3 Reliable Transfer Server (RTS)

In the pUserData of PConnect, the value of appllcationProtocol should be 1 . This value was chosen

because the agreements on intra-domain connections are not strictly P1 , nor are they MOTIS.

Philosophically, it would be good to choose a new application protocol identifier for these agreements,

but this introduces too many practical problems. Since these agreements are closer to P1 than to MOTIS, the value of 1 will be used. This will not cause intenA^orking problems between domains, because

the only deviation from P1 is the InternalTracelnfo, which will not be present in messages transferred

outside of a domain.

8 Error Handling

This clause describes appropriate actions to be taken upon receipt of protocol elements which are not supported in this profile, malformed MPDUs, unrecognized 0/R Name forms, content errors, errors in reports, and unexpected values for protocol elements.

8.1 MPDU Encoding

The MPDU should have a context-specific tag of 0, 1 , or 2. If it does not have one of these tags, it is not possible to figure out who originated the message. Therefore, the way this error is reported is a local matter.

46
Part 7: 1984 Message Handling Systems December 1990 (Stable)

8.2 Contents

Once delivery to the UA has occurred, it is not possible to report errors in P2 information to the

originator. In addition, it seems unreasonable to insist that the MTA that delivers a message ensure that the P2 content of the message is acceptable. As a result, the handling of content errors is a local matter.

8.3 Envelope

This clause describes the handling of errors in message envelopes. Some of the error conditions

described below may be detected in a recipient's 0/R Name. This may limit the reporting MTA's ability to generate a nondelivery notification that accurately reflects the erroneous 0/R Name in the

ReportedRecipientlnfo. This handling of this situation is a local matter.

8.3.1 Pragmatic Constraint Violations

In all cases of pragmatic constraint violation, a nondelivery report should be generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of pragmaticConstraintViolation.

8.3.2 Protocol Violations

If all required protocol elements are not present, a nondelivery report with a ReasonCode of unableToTransfer and a DiagnosticCode of protocolViolation should be generated.

If a protocol element is expected to be of one type, but is encoded as another, then a nondelivery report

with a ReasonCode of unableToTransfer and a DiagnosticCode of invalid Parameters should be

generated.

8.3.3 0/R Names

The domain that has responsibility for delivering a message should also have the responsibility to send

the nondelivery notification if the message cannot be delivered. Therefore, each MTA should only

validate the 0/R Names of recipients with responsibility flags set to TRUE. In addition, a nondelivery

notification can only be sent if the originator's 0/R Name is valid.

If any element in the 0/R Name is unrecognized or if the CountryName, AdministrationDomainName,

and one of PrivateDomainName and OrganizationName (and, for ADMDs, PersonalName and

OrganizationalUnit) are not all present, then a nondelivery report should be generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of unrecognizedORName. If the message can

be delivered even though the ORName is invalid, delivery is a local matter. Note, however, that if the

message is delivered, the invalid ORName might be propagated through the X.400 system (e.g., by

forwarding).

If the 0/R Name has all of the appropriate protocol elements and the message still cannot be delivered

to the recipient, the following DiagnosticCodes may appear in the nondelivery report;

47
Part 7: 1984 Message Handling Systems December 1990 (Stable)

unrecognizedORName.ambiguousORName.and uaUnavailable.

8.3.4 Tracelnformation

Since non-relaying domains need not do loop suppression, domains with responsibility for delivering the

message need not be concerned about the semantics of the Tracelnformation, that is, arrival time and

converted EncodedlnformationTypes can be provide to the UA without inspection by the MTAs of the

domain as long as the Tracelnformation is properly encoded according to X.409.

When a message is accepted for relay, the relaying domain must check that a Tracelnformation

SEQUENCE has been added by the domain that last handled the message. If the appropriate

Tracelnformation was not added, this should be treated as a protocolViolation (sec. 8.3.2).

In addition, the relaying domain must check that the information was added in the sequence defined by

the rules for adding Tracelnformation in the CCITT X.400 Implementor's Guide. If the sequence is invalid.then a nondelivery report should be generated with a ReasonCode of unableToTransfer and a

diagnosticCode of invalid Parameters.

NOTE - It would be desirable for the CCITT to add a diagnostic code of invalidTracelnformation to allow a more meaningful description of this problem. A request for this new diagnostic code will be submitted.

8.3.5 InternalTracelnfo

This clause applies only to MTAs which follow the agreements of clause 7.

When a message is accepted for relay from another MTA in the domain, the relaying MTA must check

that an InternalTracelnfo SEQUENCE has been added by the MTA that last handled the message. If the

appropriate InternalTracelnfo was not added, this should be treated as a protocolViolation (sec. 8.3.2).

In addition, the relaying MTA must check that the information was added in the sequence defined by the

rules for adding Tracelnformation in the CCITT X.400 Implementor's Guide. If the sequence is invalid,

then a nondelivery report should be generated with a ReasonCode of unableToTransfer and a

diagnosticCode of invalid Parameters.

NOTE - It would be desirable for the CCITT to add a diagnostic code of invalidTracelnformation to allow

for a more meaningful description of this problem. A request for this new diagnostic code will be submitted.

8.3.6 Unsupported X.400 Protocol Elements

The protocol elements defined in X.400 but unsupported by this profile are: the deferredDelivery and

PerDomainBilaterallnfo parameters of the UMPDUEnvelope, the ExplicitConversion parameter of Recipientlnfo, and the alternateRecipientAllowed and contentReturnRequest bits of the PerMessageFlag.

Appropriate actions are described below for domains that do not support the protocol elements.

48
Part 7: 1984 Message Handling Systems December 1990 (Stable)

8.3.6.1 deferredDellvery

The delivering domain shall do one of the following:

a) deliver at once,

b) hold for deferred delivery,

c) return a nondelivery notification with a ReasonCode of unableToTransfer and a

DiagnosticCode of noBilateralAgreement.

8.3.6.2 PerDomainBilaterallnfo

If a delivering domain receives this element, the element can be ignored.

8.3.6.3 ExplicltConverslon

If ExplicitConversion is requested the message should be delivered if possible. That is, if the UA is registered to accept the EncodedlnformationTypes of the message, then the message should be

delivered even though the requested conversion could not be performed along the route. If delivery is not possible, then a nondelivery report should be generated with a ReasonCode of conversionNotPerformed with no DiagnosticCode.

8.3.6.4 aiternateRecipientAllowed

If a delivering domain receives this element the element can be ignored.

8.3.6.5 contentReturnRequest

If a delivering domain receives this element, the element can be ignored.

8.3.7 Unexpected Values for INTEGER Protocol Elements

There are three INTEGERS in the P1 Envelope. Appropriate actions are described below for domains

receiving unexpected values for Priority, ExplicitConversion, and ContentType.

8.3.7.1 Priority

Additional values for Priority have been suggested by at least one group of implementors as upward

compatible changes to the X.400 Recommendations. Therefore, if a PRMD receives an unexpected value

for Priority, and this value is greater than one byte in length, a nondelivery report should be generated

with a ReasonCode of unableToTransfer and DiagnosticCode of invalidParameters. If the value is less than or equal to one byte, the PRMD can either generate a nondelivery report as previously specified or

49
I

Part 7: 1984 Message Handling Systems December 1990 (Stable) |

interpret the Priority as normal and deliver or relay the message.

8.3.7.2 ExpUcitConversion

When an unexpected value is received for ExplicitConversion, It should be handled as in clause 8.3.6.3.

If the ContentType is not supported by the delivering MTA, then a nondelivery report should be

generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of contentTypeNotSupported. |

I 8.3.8 Additional Elements !

in the absence of multilateral agreements to the contrary, receipt of privately tagged elements and

protocol elements in addition to those defined in X.400 will result in a nondelivery report with a ReasonCode of unableToTransfer and a DiagnosticCode of invalidParameters.

The exceptions to this are the MOTIS elements. The treatment of MPDU's containing these MOTIS

extensions is described in clause 6.11.

BA Reports

There is no mechanism for returning a delivery or status report due to errors in the report itself. Therefore the handling of errors in reports is a local matter.

9 MHS Use of Directory Services

9.1 Directory Service Elements

Recommendation X.400 recognizes the need of MHS users for a number of directory service elements.

Directory service elements are intended to assist users and their UAs in obtaining information to be used

in submitting messages for delivery by the MTS. The MTS may also use directory service elements to obtain information to be used in routing messages. Some functional requirements of directories have

been identified and are listed below:

a) Verify the existence of an 0/R name.

b) Return the 0/R address that corresponds to the 0/R name presented.

c) Determine whether the 0/R name presented denotes a user or a distribution list.

d) Return a list of the members of a distribution list.

8.3.7.3 ContentType

50
Part 7: 1984 Message Handling Systems December 1990 (Stable)

e) When given a partial name, return a list of 0/R name possibilities.

f) Allow users to scan directory entries.

g) Allow users to scan directory entries selectively.

h) Return the capabilities of the entity referred to by the 0/R name.

i) Provide maintenance functions to keep the directory up-to-date.

In addition to functionality, a number of operational aspects must be considered. These include

user-friendliness, flexibility, availability, expendability, and reliability.

Currently, these aspects of directory service elements and procedures are under study by both the

CCITT and the ISO. Both organizations are committed to the development of a single Directory Service

specification for use by MHS and all other OS! based applications.

Given the incomplete nature of the ongoing activities within the CCITT and the ISO, no impSementation

details will be provided now for MHS use of Directory Services. Implementation agreements for MHS

Use of Directory Services will be issued when current activities within the CCITT and the ISO are stable.

9.2 Use of Names and Addresses

It is recognized that these agreements enable a wide variety of naming and addressing attributes (see

sec. 5.3.5 ORName Protocol Elements) wherein each PRMD may adopt particular routing schemes

within its domain.

With the exception of the intra-domain connection agreements:

a) These agreements make no attempt to recommend a standard practice for electronic mail

addressing.

Inter-PRMD addressing may be secured according to practices outside the scope of these agreements,

such as:

a) manual directories

b) on-line directories

c) ORName address specifications

d) ORName address translation.

Further, each PRMD may adopt naming and addressing schemes wherein the user view may take a form

entirely different from the attributes reflected in table 9. And, each PRMD may have one user view for the

originator form and another for the recipient form, and perhaps other forms of user addressing. In some

cases (e.g., receipt notification) these user forms must be preserved within the constraints of these

implementation agreements. However, mapping between one PRMD user form to another PRMD user

51
Part 7: 1984 Message Handling Systems December 1990 (Stable)

form, via the X.400 ORName attributes of these agreements, is outside the scope of these agreements.

1 0 Conformance

10.1 Introduction

In order to ensure that products conform to these implementation agreements, it is necessary to define

the types and degrees of conformance testing that products must pass before they may be classified as conformant. This clause defines the conformance requirements and provides guidelines for the

interpretation of the results from this type of testing.

This clause is incomplete and will be enhanced in future versions of this Agreement. Later versions will reflect the problems of conformance testing and will outline specific practices and recommendations to

aid the development of conformance tests and procedures.

1 0.2 Definition of Conformance

For this clause, the term conformance is defined by the following:

a) The tests indicated for this clause are intended to establish a high degree of confidence in a statement that the implementation under test (lUT) conforms (or does not conform) to the

agreements of this clause.

b) Conformance to a service element means that the information associated with the service

element is made accessible to the user (person or process) whenever this agreement says that

this information should be available. Accessible means that information must be provided

describing how a user (person or process):

1) causes appropriate information to be displayed, or

2) causes appropriate information to be obtained.

c) Conformance to P1 , P2, and RTS as part of an X.400 OSI application requires that only the

external behavior of that OS! system adheres to the relevant protocol standards. In order to achieve conformance to this clause, it is not required that the inter-layer interfaces be available

for testing purposes.

d) Conformance to the protocols requires:

1) that MPDUs correspond to instances of syntactically correct data units,

2) MPDUs in which the data present in the fields and the presence (or absence) of those fields is valid in type and semantics as defined in X.400, as qualified by this profile,

3) correct sequences of protocol data units in responses (resulting from protocol

52
Part 7: 1984 Message Handling Systems

procedures).

December 1990 (Stable)

e) Statements regarding the conformance of any one implementation to this profile are not complete unless a Protocol Implementation Conformance Statement (PICS) is supplied.

f) The term "Implementation Under Test" (lUT) Is interchangeable with the term "system" in the

definition of conformance, and may refer to:

1) a domain, which may be one or more MTA's with co-located or remote UA's,

2) a single instance of an MTA and co-located UA with X.400 (P1, P2, RTS and session)

software,

3) a relaying product with PI, RTS and session software,

4) a gateway product.

g) Claiming Implementation Conformance

1) An implementation which claims to be conformant as an ADMD must adhere to the

agreements in clauses 5 and 6.

2) An implementation which claims to be conformant as a PRMD must adhere to the

agreements in clause 5.

3) An implementation which claims to be conformant as a relaying PRMD must adhere

to the agreements in clause 5 and the appropriate clauses of 7.

4) An implementation which claims to be conformant to the intra-domain connection

agreements must adhere to the agreements in clause 5 and the appropriate clauses of

7.

10.3 Conformance Requirements

10.3.1 Introduction

Conformance to this specification requires that all the services listed as supported in clauses 5, 6, and if appropriate, 7 of these agreements are supported in the manner defined, in either the CCITT X.400

Recommendations or these agreements. It is not necessary to implement the recommended practices of annex B, in order to conform to these agreements.

It is the intention to adopt, where and when appropriate the testing methodology and/or the abstract

test scenarios currently being defined by the CCITT X.400 Conformance Group. However, it is recognized that formal CCITT Recommendations relating to X.400 Conformance Testing will not be

available until 1 988. It is also recognized that aspects of these agreements are outside the scope of the

CCITT, and that other organizations will have to provide conformance tests in these cases.

53
Part 7: 1984 Message Handling Systems December 1990 (Stable) i

10.3.2 Initial Conformance

This clause is intended to provide guidelines to vendors who envisage having X.400 products available

prior to any formal mechanism, or "Conformance Test Center" being made accessible that would allow

for conformance to this product specification to be tested.

It is feasible that vendors and carriers will want to enter bilateral test agreements that will allow for initial trials to be carried out for the purposes of testing initial IntenA^orking capabilities. It is equally feasible that

for the purposes of testing interoperability, only a subset of this specification will initially be tested.

NOTE - By claiming conformance to this subset of information the vendor or carrier CANNOT claim

conformance to this entire specification.

There are two aspects to the requirements, interworking and service, as described in the following

clauses.

10.3.2.1 Interworking

The interworking requirements for conformance implies that tests be done to check for the syntax and

semantics of protocol data elements for a system as defined by the classification scheme of clauses

5.2.1.1 and 7.5.2. For a relay system, the correct protocol elements should be relayed as appropriate.

For a recipient system, a message with correct protocol elements must not be rejected where

appropriate.

10.3.2.2 Service

For information available to the recipients via the IPMessage Heading and Body, the following should be

made accessible:

a) IPMessage ID - only the PrintableString portion of the IPMessageld needs to be accessible.

b) subject.

c) primaryRecipients,

d) copyRecipients,

e) blindcopyRecipients,

f) authorizingUsers,

g) originator.

h) inReplyTo,

i) replyToUsers,

54
Part 7: 1984 Message Handling Systems December 1990 (Stable)

j) importance,

k) sensitivity,

I) lASText Bodypart.

55
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex A (normative)

Interpretation of X.400 Service Elements

The work on service element definitions is limited to those that are defined as 'supported' in clause 5 of

this specification. Furthermore it is not the intent of this clause to define how information should be

made available or presented to a MHS user, nor is it intended to define how individual vendors should

design their products. In addition, statements on conformance to a specific service element and the

allocation of error codes that are generated as a result of violations of the sen/ice should be defined in the clauses on conformance and errors as part of the main product specification. The main objective is to provide clarification, where required, on the functions of a service element, and in particular what the

original intent of the Recommendations were.

A.I Service Elements

The following Sen/ice Elements defined in X.400 have been examined and require further text to be

added to their definitions to represent the proposed implementation of these service elements by the

X.400 SIG.

The service element clarifications are to be taken in the context of this profile.

Service elements not referenced in this clause are as defined in X.400.

A.2 Probe

A PRMD need not generate probes.

If a probe is addressed to and received by a PRMD, the PRMD must respond with a Delivery Report as

appropriate at the time the probe was processed.

A.3 Deferred Delivery

In the absence of bilateral agreements to the contrary. Deferred Delivery and Deferred Delivery

Cancellation are local matters (i.e., confined to the originating domain) and need not be provided.

The extension of Deferred Delivery beyond the boundaries of the initiating domain is via bilateral agreement as specified in section 3.4.2.1 of X.41 1.

A.4 Content Type Indication

It is required that both an originating and recipient domain be able to support P2 content type. The

ability for domains to be able to exchange content types other than P2 will depend on the existence of

bilateral or multi-lateral agreements.

56
Part 7: 1984 Message Handling Systems December 1990 (Stable)

A.5 Original Encoded Information Types Indication

It is required that both an originating and recipient domain be able to support IA5 text. Support for other

encoded information types, for the purposes of message transfer between domains, will depend on the

existence of bilateral or multi-lateral agreements.

The use of the 'unspecified' form of encoded information type should only be used when the UMPDU

content represents an SR-UAPDU or contains an auto-forwarded IM-UAPDU.

The original encoded information type of a message is not meaningful unless a message is converted en

route to the recipient. These agreements support only IA5 text, which should not undergo conversion.

The original encoded information types should be made accessible to the recipient for upward

compatibility with the use of non-IA5 text message body parts.

A.6 Registered Encoded Information Types

A UMPDU with an 'unspecified' value for Original Encoded Information Type shall be delivered to the UA.

A.7 Delivery Notification

The UAContentID may be used by the recipient of the delivery notification for correlation purposes.

A.8 Disclosure of Other Recipients

This service is not made available by originating MTAE's to UAE's, but must be supported by relaying

and recipient MTAE's.

By supporting the disclosure of other recipients the message recipient can be informed of the 0/R

names of the other recipient(s) of the message, as defined in the P1 envelope, in addition to the 0/R

Descriptors within the P2 header.

These agreements do not support initiation of disclosure of other recipients, but the information

associated with it should be made accessible to the recipient for upward compatibility with support for the initiation of this service element.

A.9 Typed Body

As defined in X.400 with the addition of the Private Body Types that are to be supported. At present

there is no mechanism provided within X.420 that would allow you to respond to reception of an

unsupported body type.

Action taken in this situation is a local matter.

57
Part 7: 1984 Message Handling Systems December 1990 (Stable)

A.10 Blind Copy Recipient Indication

It should be considered that the recipient's UA acts on behalf of the recipient, and therefore may choose

to disclose all BCC recipients to each other. Therefore it is the responsibility of the originating domain to submit two or more messages, depending on whether or not each BCC should be disclosed to each

other BCC.

A.1 1 Auto Forwarded Indication

A UA may choose not to forward a message that was previously auto-forwarded. In addition there is no

requirement for an IPM UA that does not support non-receipt or receipt notification to respond with a

non-receipt notification when a message is auto-forwarded.

A.1 2 Primary and Copy Recipients Indication

It is required that at least one primary recipient be specified; however, for a fonwarded message this need not be present. The recipient UA should be prepared to accept no primary and copy recipients to enable future interworking with Teletex, Fax, etc.

A.1 3 Sensitivity Indication

A message originator should make no assumptions as to the semantic interpretation by the recipients

UA regarding classifications of sensitivity. For example, a persona! message may be printed on a shared

printer.

A.1 4 Reply Request Indication

In requesting this service an originator may additionally supply a date by which the reply should be sent and a list of the intended recipients of the reply. If no such list is provided then the initiator of the reply

sends the reply to the originator of the message and any recipients the reply initiator wishes to include.

The replytoUsers and the replyBy date may be specified without any explicit reply being requested. This

may be interpreted by the recipient as an implicit reply request. Note that for an auto-forwarded

message an explicit or implicit reply request may not be meaningful.

A.1 5 Body Part Encryption

The original encoded information type indication includes the encoded information type(s) of message

body parts prior to encryption by the originating domain. The ability for the recipient domain to decode

an encrypted body part is a local matter. Successful use of this facility can only be guaranteed if there

exists bilateral agreements to support the exchange of encrypted body parts.

58
Part 7: 1984 Message Handling Systems December 1990 (Stable)

A.16 Forwarded IP Message indication

The following use of the original encoded information type in the context of fonA^arded messages is clarified:

a) If forwarding a private message body part the originator of the forwarded message shall set the original encoded information types in the P1 envelope to undefined for that body part.

b) The encoded information types of the message being forwarded should be reflected in the new original encoded information types being generated.

c) See ammex B on recommended practices for the use of the delivery information as part of Forwarded IP-message.

A.17 Multipart Body

It is the intent of multipart bodies to allow for the useful and meaningful structuring of a message that is constructed using differing body part types. For example, it is not recommended that a message made

up of only IA5 text should be represented as a number of IA5 body parts, each one representing a

paragraph of text.

59
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex B (informative)

Recommended X.400 Practices

It is not necessary to follow the reconnnnended practices when claiming conformance to these

agreements.

B.I Recommended Practices in P2

B.1.1 ORDescriptor

Vendors following the NIST/OSI Workshop guidelines shall, whenever possible, generate the ORName

portion of an ORDescriptor in ALL IPM heading fields.

B.1.2 ForwardedlPMessage BodyParts

ForwardedlPMessage BodyParts should be nested no deeper than eight. There is no restriction on the

number of ForwardedlPMessage BodyParts at any given depth.

B.I.3 Dellverylnformation

It is strongly recommended that Dellverylnformation be supplied in both fonA^arded and autofonA/arded

message body parts. Dellverylnformation is useful when a message has multiple forwarded message

body parts because without it, the EncodedlnformationType(s) of the component fonA/arded messages

cannot be deduced easily. DeliveryInformation is useful for autoforwarded messages because the

EncodedlnformationType of an autoforwarded message is "unspecified" and the

EncodedlnformationType(s) of the message cannot be determined easily without it. Absence of the

EncodedlnformationType(s) makes it difficult for a UA to easily determine whether the message can be

rendered.

B.2 Recommended Practices in RTS

B.2.1 S-U-ABORT

In the case where S-U-ABORT indicates a temporaryProblem, reestablishment of the session should not be attempted for a "sensible" time period (typically not less than 5 minutes). In instances where this delay is not required or necessary, report a localSystemProblem.

60
Part 7: 1984 Message Handling Systems December 1990 (Stable)

B.2.2 S-U-EXCEPTION-REPORT

S-U-EXCEPTION-REPORT reason codes can be interpreted as follows:

B.2.2.1 receiving ability jeopardized (value 1)

Possible meaning: The receiving RTS knows of an impending system shutdown.

B.2.2.2 local ss-User error (value 5)

Possible meaning: The receiving RTS needs to resynchronize the session dialogue.

B.2.2.3 irrecoverable procedure error (value 6)

Possible meaning: The receiving RTS has had to delete a partially received APDU, even though some

minor synchronization points have been confirmed.

Possible meaning: The receiving RTS cannot handle the APDU (for example, because it was too large)

^ and wishes to inform the sending RTS not to try again.

Possible meaning: The S-ACTIVITY-RESUME request specified a minor synchronization point serial number which does not match the checkpoint data.

B.2.3 OSI Addressing Information

For purposes of identifying an MTA during an RTS Open, OSI addressing information should be used.

This addressing information is conveyed by lower layer protocols and is reflected by the calling and

called SSAP parameters of the S-CONNECT primitives.

MTA validation and identification are related, but separate, functions. The mTAName and password

protocol elements of the RTS user data should be used for validation, rather that identification, of an

MTA. The RTS initiator and responder may independently require each other to supply mTAName and

password.

The CallingSSUserReference parameter of the S-CONNECT primitives should only have meaning to the

entity that encoded it and should not be used to identify an MTA.

B.2.2.4 non specific error (value 0)

B.2.2.5 sequence error (value 3):

61
Part 7: 1984 Message Handling Systems December 1990 (Stable)

B.3 Recommended Practices for ORName

Table 9 stipulates that the StandardAttributeList must contain either PrivateDomainName or OrganizationName. It is recommended that, for both originator and recipients in a private domain, the

PrivateDomainName field be used.

It is recommended that there should be a DomainDefinedAttribute to be used in addressing UAs in existing mail systems, in order to curtail the proliferation of different types of DomainDefinedAttributes

used for the same purpose. The syntax of this DomainDefinedAttribute conforms to the CCITT Pragmatic

Constraints, and thus has a maximum value length of 128 octets and a type length of 8 octets, each of type Printable String. Only one occurrence is allowed.

This DomainDefinedAttribute has the type name "ID" (in uppercase). It contains the unique identifier of the UA used in addressing within the domain. This DomainDefinedAttribute is to be exclusively used for routing within the destination domain (i.e., once routed to that domain via the mandatory components of the StandardAttributeList); any other components of the StandardAttributeList may be provided. If they

conflict delivery is not made.

The contents of this parameter need not be validated in the originating domain or any relaying domain,

but simply transferred intact to the next MTA or domain.

Class 2 and class 3 MTAs in a PRMD should allow administrators to decide the number of

OrganizationalUnits that should appear in user names, instead of imposing a software controlled limit which is less than four. This is desirable because when two different vendors impose different limits on

the number of OrganizationalUnits in a name, it becomes difficult for the administrator to choose a

sensible naming scheme.

There are existing mail systems that include a small set of non-Printable String characters in their

identifiers. For these systems to communicate with X.400 messaging systems, either for pass-through

service or delivery to X.400 users, gateways will be employed to encode these special characters into a sequence of Printable String characters. This conversion should be performed by the gateway

according to a common scheme and before insertion in the ID DDA, which is intended to carry

electronic mail identifiers. X.400 User Agents may also wish to perform such conversions.

It is recommended that the following symmetrical encoding and decoding algorithm for non-Printable

String characters be employed by gateways. The encoding algorithm maps an ID from an ASCII

representation to a PrintableString representation. Any non-printable string characters not specified in the

table are covered by the category "other" in the table below.

The principal conversion table for the mapping is as follows:

62
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table B.I - Printable String to ASCII Mapping

ASCII Character Printable String Character

% (percent) (P)

e (at sign) (a)

! (excleunation) (b)

" (quote mark) (q) _ (underline) (u)

( (left paren.

)

(1)

) (right paren.

)

(r)

other (3DIGIT)

where 3DIGIT has the range 000 to 377 and is interpreted as the octal encoding of an ASCII character.

To encode an ASCII representation to a PrintableString, the table and the following algorithm should be

used:

IF current character is in the encoding set THEN

encode the character according to the table above

ELSE

write the current character;

continue reading;

To decode a PrintableString representation to an ASCII representation, the table and the following

algorithm should be used:

IF current character is not "(" THEN

write character

ELSE

{

look ahead appropriate characters;

IF composite characters are in the above table THEN

decode per above table

ELSE

^ write current character;

continue reading;

Class 2 and class 3 MTAs in a PRMD should allow administrators to decide the number of OrganizationalUnits that should appear in user names, instead of imposing a software controlled limit which is less than four. This is desirable because when two different vendors impose different limits on

the number of OrganizationalUnits in a name, it becomes difficult for the administrator to choose a

sensible naming scheme.

63
Part 7: 1984 Message Handling Systems December 1990 (Stable)

B.4 Postal Addressing

For domains wishing to support postal (or physical) delivery options, the following interim set of "nationally-defined" domain defined attributes are recommended. The CCITT will define Standard

Attributes in support of physical delivery in its 1988 Recommendations; this is only an interim solution.

CCITT will also be addressing the services associated with physical delivery. This interim solution does

not address the end-to-end service aspects of physical delivery; in particular, the following IPM service

elements do not currently extend outside of the X.400 environment:

a) alternate Recipient Assignment

b) PROBE

c) Receipt Notification / Non-Receipt Notifications

d) Grade of delivery

"Delivery" means passing a message from the MTS to the physical delivery system (PDS), and not to the user (or user agent).

The following three DDAs are recommended to be used to specify a postal (or physical) address:

CNTRPC encodes the country and postal code for postal delivery. The DDA value is of the form

"Country?Postalcode" (for example, "USA722096"). The country field is optional, the postal code is optional; the separator ("?") is not. If both country and postal code are missing, this DDA should not be

specified.

PDA1 The country and postal code fields are free-form text.

PDA2 These two DDA (signifying Postal Delivery Address strings 1 and 2) form a 256 character free- form postal address. Fields are separated by a question mark ("?"). There is no implied separator

between PDA1 and PDA2. The meaning of the fields are defined by each domain supporting the physical

delivery interface. PDA1 contains the first 128 characters, PDA2 the next 128 characters. If the PDA

string is less than 1 28 characters, PDA2 is not used.

For example, if the domain interprets the PDA fields as lines, the address

Mr . John Smi th

Conway Steel

123 Main Street

Reston VA 22096

would be encoded as follows:

type = "PDAl"

value = "Mr. John Smith?Conway Steel?123 Main Street?Reston VA"

CNTRPC = "722096"

64
Part 7: 1984 Message Handling Systems December 1990 (Stable)

B.5 EDI use of X.400

B.5.1 Introduction and Scope

This is a guideline for EDI data transfer in an X.400 environment conforming to the NIST agreements.

These recommended practices outline procedures for use in transferring EDI transactions between

trading partner applications in an attempt to facilitate actual X.400 implementation by EDI users.

The scope of this guideline is to describe specific recommendations for adopting X.400 as the data

transfer mechanism between EDI applications.

B.5.2 Model

The MHS recommendations can accommodate EDI through the approach illustrated below. Many

Message Transfer (MT) service elements defined in the X.400 recommendations are particularly useful to the EDI application.

x.400 Message (1 EDI interchange)

Envelope =_>

Content

MHS Message

PI Control

Information

—

One

EDI

Interchange

This diagram depicts an EDI content (1 EDI interchange) enveloped by the P1 MHS envelope. All the MT

Services defined in the X.400 Recommendations may be used for EDI. However, it is not required to support optional or non-essential services to exchange EDI data between EDI users. When an EDI user submits an EDI Trade Document to the EDI User Agent, the ED! UA will submit the ED! content plus P1

envelope to the Message Transfer System (MTS).

65
Part 7: 1984 Message Handling Systems December 1990 (Stable)

The EDI UA must support the essential MT Services as defined in these Agreements; for example, as a minimum, to provide default values for services not elected by the EDI user, such as Grade of Delivery.

NOTE - MT Services are not necessarily made available by the EDI UA to the EDI user.

B.5.3 Protocol Elements Supported for EDI

The following P1 protocol elements will be used to support EDI applications:

B.5.3.1 Content Type

For EDI applications, the content type will be 0 (undefined content).

B.5.3.2 Original Encoded information Types

Any EST defined in the X.400 Recommendations may be used to specify the encoding of EDI content. However, for ANSI X12 EDI applications in particular, it is expected that the "undefined" and "laSText"

EiT's will normally be used, with "undefined" used to signify the EBCDIC character set.

B.5.4 Addressing and Routing

It is anticipated that connection of some existing systems to an X.400 service for EDI purposes will be by

other than X.400 protocols, at least in the short term.

EDI messages entering the X.400 environment will therefore need to have X.400 0/R Names added to

identify the origination and recipient trading partners, typically by means of local directory services in the

origination domain which will map EDI identifiers/addresses into 0/R Names. Such 0/R Names will contain Standard Attributes as defined in table 9 and for recipient trading partners will at least identify

the destination domain.

In the case of trading partners outside the X.400 environment, it is expected, however, that there will be

cases where message delivery will require the provision of addressing information beyond that which can be carried in Standard Attributes. In such cases, Domain Defined Attributes are recommended to be

used.

The syntax of this DDA is as defined in table 9, with a single occurrence having the type name "EDI"

66
Part 7: 1984 Message Handling Systems June 1991 (Stable)

(uppercase) and a value containing the identifier/address of the trading partner. For ASC X12 purposes,

specifically, this value will comprise the 2 digit interchange ID qualifier followed by the interchange ID (max 15 characters). Routing on this DDA shall only occur, if at all, in the destination domain.

B.6 USA Body Parts

It is recommended that UAs can generate any USA Body Part, as defined in clause 5.3.6.2, and that they can receive such body parts as well, reception of USA Body Parts does not imply further processing by

the UA, but merely that the body part is made available, with a indication of its registered body part

identifier, to another process or deposition in a file. Generation implies the reverse of this process.

B.7 Recommended Practices for Binary Data Transfer

The capability to transfer binary data, such as those generated by word/document processing,

spreadsheets, or graphics applications among X.400 system is a useful and desirable feature. Many

messaging systems provide such capability today.

It is recommended that transfer of binary data through 1984-based systems be achieved using the

unidentified BodyPart in P2 with the ASN1 definition recaptured as follows:

BodyPart ::= CHOICE {

[0] IMPLICIT lASText

[14] IMPLICIT Unidentified

Unidentified ::= OCTET STRING

NOTE - the Unidentified BodyPart is included in 1984 X.400 Implementor's Guide, Version 6, and is renamed as BilaterallyDefinedBodyPart in 1988 X.400 Series with the same tag and definition.

Additionally the binary data can be identified by a text string in the subject heading or in an lASText body

part preceding the Unidentified BodyPart.

When the Unidentified BodyPart is present in a P2 message, the undefined(O) bit of the PI EncodedlnformationTypes will be set. If the IA5Text bodypart is also present, the IA5text(2) bit will also be

set.

The binary data is the raw data as generated by user applications. Besides encapsulating it for transfer purposes, X.400 systems do not encode or interprete the binary data in any way further. How the data is encoded or decoded is defined by the cooperating user applications. How the data is injected into X.400

systems or transferred out of X.400 systems to the user applications, or how the user applications are invoked to process the data is a local implementation issue and not defined.

67
Part 7: 1984 Message Handling Systems June 1991 (Stable)

B.S Recommended Practice for Office Document Architecture

(ODA) Transfer

It is recommended that the conveyance of ODA documents through 1984-based X.400 systems be

achieved using the following schemes:

B.8.1 ODA In P2

An ODA document will be transferred as a single body part with tag 12, recaptured as follows:

BodyPart ::= CHOICE {

[0] IMPLICIT lASText

oda [12] IMPLICIT OCTET STRING

... }

The content of the Octet String will contain a value of type OdaBodyPart as follows:

OdaBodyPart ::= SEQUENCE {

OdaBodyPartParameters

,

OdaData }

The Parameters and Data components are defined in Annex E of CCITT Recommendation T.411 (1988)

(ISO 8613-1).

B.8.2 ODA In PI

Both the undefined bit (bit 0) and tho ODA bit (bit 10) of the Encododlnformati onTypo will bo sot whon

an ODA document is prosont in P2.The undefined bit (bit 0) of the EncodedlnformationTypesismustibe

set and the ODA bit (bit 10) of the EncodedlnformationTypes should be set when an ODA document is present In P2. However, MTAs should be tolerant of messages containing ODA document^ being

received with just the undefined bit (bit 0) set, and should still deliver the message.

68
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex C (normative)

Rendition of lASText and T61 String Characters

C.I Generating and Imaging lASText

The characters that may be used in an lASString are the graphic characters (including Space), control

characters and Delete of the IA5 character repertoire ISO 646.

The graphic characters that nnay be used with a guaranteed rendition are those related with positions

2/0 to 2/2, 2/5 to 3/15, 4/1 to 5/10, 5/15 and 6/1 to 7/10 in the basic 7-bit code table.

The other graphic characters may be used but have no guaranteed rendition.

The control characters that may be used but have no guaranteed effect are a subset consisting of the

format effectors 0/10 (LF), 0/12 (FF) and 0/13 (CR) provided they are used in one of the following

combinations:

CR LF to Start a new line

CR FF to start a new page (and line)

LF .. LF to show empty lines (always after one of the

preceding combinations).

The other control characters or the above control characters in different combinations may be used but

have no guaranteed effect.

The character Delete may occur but has no guaranteed effect. The IA5String in a P2 lASText BodyPart

represents a series of lines which may be divided into pages. Each line should contain from 0 to 80

graphic characters for guaranteed rendition. Longer lines may be arbitrarily broken for rendition. Note

that X.408 states that for conversion from IA5Text to Teletex, the maximum line length is 77 characters.

C.2 Generating and Imaging T61 String

For further study.

69
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex D (informative)

Differences in Interpretation Discovered Through Testing of the MHS

for the CeBit 1 987 Demonstration

Several interworking problems were discovered through multi-vendor testing. These problems, and

recommendations for solutions to them are discussed In this annex.

D.I Encoding of RTS User Data

The password is defined as an ANY in the X.400 Recommendations, and implementor's groups have

decided to use an lASString for this field. There was some confusion about what the X.409 encoding for

this lASString would be, and the correct encoding is:

class

context specific

form: constructor

id code: 1

length: length of contents

contents: (primitive encoding)

lASString: 16

length: length of contents

contentsthe password string

class

context specific

form: constructor

id code: 1

length: length of contents

contents(constructor encoding) left as an exercise for the reader

Implementations should be prepared to receive any X.409 type for the password because of its definition as an ANY.

D.2 Extra Session Functional Units

One vendor proposed more than the required set of functional units on opening the session connection,

and the receiver rejected the connection. All debate aside about whether the initiator should have

proposed units outside of the required set, or whether the receiver should have rejected the connection,

the set of functional units can be negotiated in a straightfon^/ard way. The following is recommended.

If the initiator proposes using more than the required set of functional units, the responder should

specify the set of functional units that it would like to use (which should include the required set) in the

open response. The session implementations will automatically use the intersection of the units proposed

by both sides.

If the initiator proposes using less than the required set of functional units, the responder should reject

the connection. Unfortunately, there is not an appropriate RefuseReason for rejecting the connection, so

instead of refusing the connection in the response to the S-CONNECT, the receiver should issue an S-U70
Part 7: 1984 Message Handling Systems December 1990 (Stable)

ABORT with an Mr ...reason of protocol Error. Note that it is valid to issue an S-U-ABORT instead of responding to the S-CONNECT. A problem report has been submitted to the CCITT requesting the

addition of a RefuseReason for this situation.

If the responder proposes using less than the required set of functional units, the session connection is established before the initiator can check for this. If too few functional units have been proposed, the

initiator should abort the connection using S-U-ABORT, with an abort reason of protocolError.

D.3 Mixed Case in the MTA Name

The MTA name is frequently exchanged over the telephone when two systems are being configured to communicate with one another. In one such telephone exchange, the casing of the MTA name was not

specified, the MTA name consisted of both upper and lower case letters, and one of the implementations

compared MTA names for equality in a case sensitive manner. Consequently, connections failed until the

problem was detected and repaired. It is recommended that the MTA name be compared for equality in a case insensitive manner, and that the password be compared for equality in a case sensitive manner.

D.4 X.410 Activity Identifier

The X.400 Implementor's Guide recommends that the activity identifier be X.409 encoded, but this is only a recommendation and not a requirement. Consequently, receiving systems cannot assume that the

activity identifier will be X.409 encoded.

D.5 Encoding of Per Recipient Flag and Per Message Flag

In the definition of the PerRecipientFlag in X.41 1 , there is a statement that the last three bits are

reserved, and should be set to zero. It is unclear whether those bits are unused in the X.409 encoding.

Receivers should accept encodings with either zero or three unused bits. A problem report has been

submitted to the CCITT asking for clarification.

Though there is not any statement in X.41 1 about the last four bits of the PerMessageFlag, some

vendors have encoded this with zero unused bits, and some have encoded it with four unused bits. The

PerMessageFlag should be encoded with at least four unused bits.

D.6 Encoding of Empty Bitstrings

There are three valid encodings for an empty bitstring: a constructor of length zero, a constructor of

indefinite length followed by the end-of-contents terminator, and a primitive of length one with a zero

octet as the value.

71
Part 7: 1984 Message Handling Systems December 1990 (Stable)

D.7 Additional Octets for Bitstrings

Nothing in X.409 constrains an implementation from sending two, three, four, or even more octets for a

bitstring that fits into one octet, with the undefined bits set to zero. Note that the number of excess

octets is bounded by the pragmatic constraints guidelines of the CCITT X.400 Implementor's Guide for

all of the bitstrings in PI.

D.8 Application Protocol Identifier

If a value other that 1 is received in the applicationProtocol of the pUserData in the PConnect, NIST

implementations will reject the connection. If CEN/CENELEC implementations receive a value other than

8883 for this field, they will reject the connection. This is an unfortunate state of affairs, because if NIST

implementations accept the value of 8883 without supporting the MOTIS service elements, they would be

misrepresenting themselves. To mal<e matters worse, CEPT uses a value of 1 , but relays MOTIS

elements, which means that MOTIS elements will be relayed to implementations using a value of 1 to demonstrate that they do not support MOTIS. Work is continuing to try to find a solution that will allow

European implementations to interwork with U.S implementations.

D.9 Initial Serial Number in S-CONNECT

This should be implemented in accordance with section 3.5.1 E4 of the Implementor's Guide.

D.10 Connection Data on RTS Recovery

It is clarified that the ConnectionData is identical in both the S-CONNECT.request and the SCONNEOT.response. The value of the ConnectionData is the old Session Connection Identifier.

D.11 Activity Resume

If an activity is being resumed on a new session connection, it is not clear from X.410 and X.225 whether

all four of the called-ss-user reference, the calling-ss-user reference, the common reference, and the

additional reference information should be specified in the S-ACTIVITY-RESUME, or whether one of the

ss-user-references should be absent. It is also unclear whether the called-ss-user reference should be

identical to the calling-ss-user reference if both are present. Consequently, receivers should be tolerant

of this situation. Appropriate problem reports will be submitted to the CCITT asking for clarification.

D.I 2 Old Activity Identifier

The Old Activity Identifier in S-ACTIVITY-RESUME refers to the original activity identifier.

72
Part 7: 1984 Message Handling Systems December 1990 (Stable)

D.I 3 Negotiation Down to Transport Class 0

For European implementations, X.410 specifies that class 0 transport must be supported. However, it is permissible for an initiator to propose a higher class as the preferred class, provided that class 0

appears as the alternate class in the T-Connect PDU. A responding implementation can choose to use

either the preferred or alternate class, but again, must be able to use class 0. In other words, for private

to private connections in Europe, class 0 transport is required.

This conflicts with the NIST agreements, since class 0 is only required if one of the partners in a

connection is an ADMD.

73
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex E (informative)

Worldwide X.400 Conformance Profile Matrix

Y CONFORMANCE (E) implies a conformance problem for European products in the United States.

Y CONFORMANCE (US) implies a conformance problem for U.S. products in Europe.

Tlie A/31 1 profile is specified in Env 41 202, the A/321 1 profile in Env 41 201

No TTC protocol classification for RTS exists.

The notation X/Y indicates "X" for PRMDs and T" for ADMDs, i.e., "M/G" would be Mandatory for PRMDs and Generatable for ADMDs.

Table E.I - Protocol Element Comparison of RTS

RTS element NIST A/311 A/3211 PROBLEM Y/N

PConnect M M M N

DataTransferSyntax M 0 M 0 M 0 N

n M PI

VTN

checkpoints ize H H H N

windowSize H H H N

dialogueMode H H H N

connectdata M M M N

appl i cat ionProtocol G 1 H 1 R 8883 N

H 8883

Connect ionDat

a

Open G G G N

Recover G H G N

Open

RTSUserData G G G N

Recover

SessionConnectionID G G G N

RTSUserData

MTANaiae G G G N

Password G G G N

null G G G N

SessionConnectionID

CallingUserReference M M M N

ConunonRe f e r ence M M M N

AdditionalRef Info H H H N

PAccept G G G N

DataTransferSyntax M 0 M 0 M 0 N

74
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.I - Protocol Element Comparison of RTS (concluded)

RTS element NIST A/311 A/3211 PROBLEM ( Y/N

)

PUserData M M M N

CheckpointSize H H H N

Windows ize H H H N

Connect i onDat a M M M N

irKeruse r' c RefuseReason M M M N

SSUserData G G G N

(in S-TOKEN-PLEASE

)

AbortInformation 6 G G N

(in S-U-ABORT)

AbortReason H H H N

ref lectedPareimeter X X X N

75
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.2 - Protocol Element Comparison of PI

PI Protocol NIST A/ Jli A /on T A/ J 1

1

PRUBLEM ( Y/N

)

ORname

otanudruAttriDUCeLilSt n wn wn n N see Note 4

Doms. i nDe£At t r i but eLi s t X X X Y See Note 5

stanaardAtt riDuteList

Count ryName R R R M N

SO R R N

TOT

. 121 TTn Y Conformance (E)

ther X Y Prot Vio

Adm1 n 1 s t r at 1 onDoma 1 nName R R G M N

... if PrintableString R G N

... if numericString H H Y Conformance (E)

X.121 Address X X/R X Conf(US)See Note 1 Terminal ID X X/G X Conf(US)See Note 1 Pr i vat eDoma i nName G G G G N

Organizat ionName G G G G N

UnigueUAident i f ier X X/G X Conf(US)See Note 1 Per sonalName G G G G N

Organizat ionalUnit G G G G N

Doma i nDef i nedAt t r i but

e

X X X G N

Type M M M M N

Value M M M M N

Per sonalName

Surname M M M M N

GivenName G G G G N

Initials G G G G N

fi YA YA YA X w^oncormdiice K^)

GlobalDomainldentif ier

Count ryName M M M M N

Admi n i s t r at i onDoma i nName M M G M Y Proto Vio

PrivateDomainldentif ier R/H H R M/X N

MPDU

UserMPDU G G G G Y TTC required

MPDU size is

DeliveryReportMPDU

32K

G G G G N

ProbeMPDU H H H H N

76
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.2 - Protocol Element Comparison of PI (continued)

PI Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

UserMPDU

UMPDUenve 1ope M M M M N

UMPDUcontent M M M M N

UMPDUenve1ope

MPDUidentif ier M M M M N

or i g i natorORname M M M M N

or i g i nalEncodedTypes G H H G Y Conformance (E)

ContentType M M M M N

UAcontentID H H H H N

Priority G G G G N

G G G N

Defer redDeli very X X X X N

PerDomainBilatlnfo X X X X N

Recipientlnfo M M M M Y TTC MPDU 32K

Traceinformat ion M M M M N

MOTIS-> LatestDelivery X N

MOTIS-> InternalTracelnfo M/P P N

UMPDUcontent M M M M N

mrUKJ ± Uoii L X i. X ^ L GlobalDomainldent M M M M N

lASstring M M M M N

PerMessageFlag

DiscloseRecipients H a MT H H Y Conformance (US)

at U Y Conformance (US)

ConversionProhibited G G G G N

AlternatRecipAl lowed H @ MT H X Y Conformance (US)

at U ? Y Conformance (US)

ContentReturnReques t X X X X

MOTIS-> redirectionProhibited X N

PerDomainBilaterallnfo

Count ryName M M M M N

Admi nDomai nName M M G M Y Prot Vio

MOTIS-> Pr i vat eDomai nName G N

Bilaterallnfo M M M M N

77
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.2 - Protocol Element Comparison of PI (continued)

PI Protocol NIST A/311 A/3211 TTC PROBLEM ( Y/N

)

Del i ver vRetsortContent

oriainal MPDUidpni" M M M M N

intA rmAdi atA Trace X/G X X X Y Conformance (E)

UAcontentlD G G G G N

ReportedRecipientlnfo M M M M Y TTC 256 max

returned H H X X Y Conformance (E)

billina information X X X X N

ReportedRecipientlnfo

recipient ORncune M M M M N

ext^ns i ons Td^nt i f i pr M M M M N

PerReciDientPlaa X^ X Ax^V^ X k/ X ^?AJl W X XdU M M M M N

LastTraceInformat ion M M M M N

intendedRecipient H H H H N

Supplementarylnfo X/H X X X Y Conformance (E)

MOTIS-> Reass i gmnent Info X N

MOTIS-> Reassignment Info

MOTIS-> i nt endedRec i pi ent M N

MOTIS-> reasonForReassigmnent H N

LastTraceInformat ion

arrival M M M M N

convertedEncInfoTypes G G H G Y Conformance (E)

Reoor

t

M M M M N

Reoort

Deliveredlnfo G G G —

1

_r

N See Note 6

NonDp 1 i VP r p d T n f

o

G G G N

Deliveredlnfo

delivery M M M M N

TypeofUA R/H H R M/G N

NonDeliveredlnfo

ReasonCode M M M M N

Di agnos t i cCode H H H H N

MOTIS-> UAprof ileldentif ier X N

MOTIS-> UAprof ileldentif ier

MOTIS-> ContentType M N

MOTIS-> EncodedI nfoTypes M N

78
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.2 - Protocol Element Comparison of Pi (continued)

PI Protocol NIST A/311 A/3211 TTC PROBLEM ( Y/N

)

ProbeEnve1ope

probe M M n M N

originator M M M M N

ContentType M M M M N

ITn n n

urn KI or igineilEncInfoTypes \3 un n Y Conformance (E)

Tracelnformat ion M M M n

XTN

^^^^ FernssSayer ^\ ^ ^ ^ ^\ k<* 1 9 laC| V7 \3 <j KI con u ent LienQ u n 11 n

rja n

PerDomainBi lat Inf

o

V"A X X X N

Recipient Info M M M M Y TTC 256 max

MOTIS-> InternalTracelnfo M/P P N

KecipienuxnEo

Rec i pi entORname n n M

Extensionldentifier M M M M N

PerRecipientFlag M M M M N

Expl i c i tConver s i on X X X X N

MOTIS-> OriginReqAlternatRecip X N

nuTio—> KeassigmnenLinro A MN

PerRecipientFlag

Respons ibilityFlag M M M M N

Repor tReques t M M M M N

UserReportRequest M M M M N

Tracelnformation

GlobalDomai nl dent M M M M N

DomainSuppliedlnfo M M M M N

79
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.2 - Protocol Element Comparison of PI (concluded)

PI Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

DomainSuppl led Info

arrival M M M M N

deferred X X X X N

action M M M M N

( 0=relayed) G 6 G N Note:

Re-routing not

required.

(l=rerouted) H H H N

MOTIS-> (2=recipientReassigned) H N

converted H G H H Y Conformance (US

)

previous H G G X Y Conformanr'p ( UJ? ^ fNote! G is

inconsistent with

action (relayed)

being "H.")

ORname

Encodedlnformati onTypes BitString M M M M N See Note 3

G3NonBasicParcuneters X X X X N

TelstGxNonBas icParams X R Y Y X v^v^ii J. v^i. luaiiot; ^ uo ^ Presentat ionAbi lit ies X X Y Y N

uei. 1 veryKepor tMFDU G G M G N

DeliveryReportEnvelop M M M M N

DeliveryReportContent M M M M N

DeliveryReportEnvelope

report M M M M N

originator ORname M M M M N

Tracelnformation M M M M N

InternalTracelnfo M/P P N

80
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.3 - Protocol Element Comparison of P2

FZ rTOuOCOX MTCT n/ .3J.X n/ J Z X X 1 rKKJDLtcjn ( X./ iS }

UAPDU

IM UAPDU G G G G N

SR_UAPDU X X X X N

IM_UAPDU

Heading M M M M N

Body M M M M N

Heading

IPmessagelD M M M M N

Originator ORname R R R M/G N

Author izingUsers H H H H Y TTC 16 max

PrimaryRecipients G G G G Y TTC 256 max

CopyRecipients G G G G Y TTC 256 max

Bl i ndCopyRec i pi ent H H H H Y TTC 256 max

InReplyTo G G G G N

Obsoletes H H H H Y TTC 8 max

(.^rossKecerences IIn n

ITnIT

11 X xic o max

Subject G G G G N

ExpiryDate H H H H N

ReplyBy H H H H N

Kepxyiousers ITn n n n X xxv^ max

Importance H H H H N

Sensitivity H H H H N

Autoforwarded H H H H N

MOTIS-> CirculationList X N

MOTIS-> ObsoletingTime X N

IPmessagelD

ORname H H H H N

Printablest ring M M M M N

ORdescr intor

ORname H H H >N See Note 6

FreeFormName H H H N

Te1 ephoneNumbe

H H H G N

Recipient

ORdescriptor M M M M N

ReportRequest X X X X N

ReplyRequest H H H H N

81
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.3 - Protocol Element Comparison of P2 (continued)

P2 Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

MOTIS—> Ci rciilai- ionList

MOTIS-> CirculationMember X N

MOTIS-> checkmark M N

M NI MOTIS-> OBsoletingTime

o

n

JZKyUy£r oL Jl U \s Jn c> X ^onrormance ( Uo

}

SR_UAPDU

Nr>rsP**r'c*i Til" XX u ~Um

Mv%

£1 If n

PATV^ ?" 1" A M M M

A<^^*n5*l Pa*^"i t^t finrt'h p DK Pi l^kkx, ^llLiCSU£\.t5V^ 1 L/ i. ^11 L u£1 TIn n

XTn KTiN Vi^WJllV^l. YA A YA c\s KI MOTIS—> Ci rculat ionSf^i'l-^ies YA ra KonReceipt Information

CVOC19 wXX Mi * M M IM TJriTlPor'O "i T>*E' rSn a 1 \ Fiat* n n n

ITnVTW

nu nu u

KI =obsoleted (value) 1 1 1 1 N

ssubscriptionTerminated 2 2 2 2 N

MOTIS-> =timeobsoleted (value) X N

Comments H H H X N

returned H X X X Y Conformance (E)

Receipt Information

Receipt M M M M N

TypeOfReceipt H H H G N

Supplementarylnfo X X X X N

82
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Table E.3 - Protocol Element Comparison of P2 (concluded)

D9 Pf/^l'^rT^l NIST A/311 A/3211 PROBLEM f Y/N ^

BODYPART SUPPORT

O IA5 Text G G G N See Note 7 O TLX X X X N

o Voice X X X N

o G3FAX X X X N

O TIFO X X X N

O TTX X X/H X Y Conf(US)See Note 2 o VideoTex X X X N

o NationallyDef ined X X X N

o Encrypted X X X N

o ForwardedlPmessage H H H N

o SFD X X X N

O TIFI X X X N

MOTIS-> O ODA X N

MOTIS-> o IS06937 Text H N

NOTES

1 It should be noted that the A/31 1 profile states: For routing all ADMDs should support all Form 1 Variants of 0/R Name. All PRMDs should support at least Form 1, Variant 1 form of OR Name.

2 It should also be noted that the A/31 1 profile requires that all ADMDs should support the reception of Teletex body parts for delivery to their own UAEs.

3 An A/3211 implementation may generate fwfOTIS encoded information types. See 6.11.

4 Only Form 1 Variant 1 of 0/Rname shown for TTC, but TTC defines other forms and variants. Form 1 Variant 1 recommended for PRMDs and ADMDs, Form 1 Variant 2 also recommended for ADMDs.

5 DDA's can be used to specify recipients in any Japanese domains other than TTC. Assignment of DDAs

for UAs within TTC domains is not recommended.

6 One of [Deliveredlnfo/NonDeliveredlnfo] must be present. TTC encodes this as shown. Other profiles

represent this by classifying both protocol elements as generatable. A similar situation exists with the P2

ORdescriptor.

7 TTC is expected to support IA5 for some international MHS communications.

83
Part 7: 1984 Message Handling Systems December 1990 (Stable)

Annex F (informative)

^

Interworking Warnings

ADMD name is to be encoded as a single space when configurations with no ADMD's are present. It should be noted that this may change in January 1988 so that the ADMD name is encoded as a zero

length element in such cases.

The NIST agreements allow implementation to generate MPDUs with no body parts. Such MPDUs will be

rejected by European-conformant systems. (Note this situation may change in January 1988)

In order to optimize the number of recipients you can read and reply to, it is advisable to be able to generate all standard 0/R name attributes.

84
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 8 - 1988 Message Handling

Systems

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Neil Koorland (OSIWare)

Rich Ankney (Simpact)
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Message Handling Systems Special

Interest Group (X.400 SIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection (OIW).

Text in this part has been approved by the Plenaries of the X.400 SIG and of the OIW. This part replaces

the previously existing chapter on this subject. Additional material has been included recently. Annexes C,

D, E, and F are for information only.

Future changes and additions to this version of 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
jPart 8: 1988 Message Handling Systems September 1991 (Stable)

Pm 9 1988 Message Handling Systems _ ''.^'^'/W^M0 inlroauclion . tffi

iiii

Wm

21

.

: ,

. .; .

, . ,

,

. , , „

. , . . . .

; . , , , : , , ,

,

.

,

lative References . . , CCITT

. ... ,.|

......... . . p:isomw^;rv^. :. ... .... .i.. ...... „ . .

4-4^-»k*A««4-*+>#AA44-*frr*A«4 iS

. _ , , $

, - A < 4 6

MT Kernet .... * S,1 Introduction

^.t Elements of Service

5-3 MT$ transfer Protocol (P1) , ^ 5.4 MT8*AP0USIze

$.5 1888/84 U^tet^A«^fl<lng Conskteratton^ .

IPM Kernel .... %A Introduction

tSL Elements Service

9

9

, . .:. , , , , . lO

6.3 imerpersonat Messaglntg Protoc^ (P2)

5.4 Body Part Support

r. , , . „ , . , „ : ,

7,t intfoducilQo

7.3 Elements of $0rvrce

. d

. . .li

V.\ . . . ..'.v. . .. 14

. „ . . . .:- , ........ mmmmmm-M - - ^ ^ - ^ ^ ^ - ^ ^|

7*4 Attribute Types ,

7.7 Access Protocol (P7)

7>8 MTS Access Protocol (P3) . . . . ,

Remote User Agent Support

8.1 Introduction >

::+:::;*:-:->>:->:vx-;-;<-:-:<-:->:-:*:-;->:; ^ . . .i ; ''6 WW^mWrn^'.

,

16-1

........ . . ,

,

, ... ..... : . ,i|

'm

18

8.2 Scope

8 3 Elernents Service _ 8.4 MTS Access Protocol (P3)

liiiiSiiBiiliiiiiiiiW ^''t-''^^ ^ -

*^ ^19

: 20

9,1 y§e of 0/R Addresses for Routing

ill
Part 8: 1988 Message Handling Systems September 1991 (Stable)

9.2 <>RA<i<lres$ Attfltx^ List Iqglv^ce M0$ . ^ , . 20

9.3 DIslfibiifloR yst« > X > , 20

8.4 MHS U$0 of Olfactory ... ........ ......... 20

FuHo8on^ Cottftguf^eion 21

9^.4,3 FunctionalSy .. x , x < 21

p^.-! ftoling «nd Attributes 22

t Elements of Seivlce x x < . 23

Directcrty Services 23

OiW X*40d Base Directory IropJementatioo Agreemer«s .. x x < 24

Oti\^P«M&$$upp(M0d , _ 24

tandard Applicatior* Spedflo Attributes and Attribute Sets . > x < . . > 24

L Star^dard Appltcatloft $pef^ Obj^cl Cl3t§s$$ i . , 24

OtVV Application Specific AttrilMes and Attribute Sets x < 25

f OfW Application Specific Object Ctasses , 25

9>4.7<6 Structure Rules * . . x < . . , x , - .>> x x . 25

9A7.6.t MHS Distribution List , 25

9A7.6.2 lyJHS User _ 25

10 MHS Management ...... 25

11 MHSSecuHty 2S

lt.1 Oven^Jew _ 25

11.2 Common Requirements .... ........ . . 27

11-2.1 Intenworking Between Security Classes , w . 28

11.21.2 Comparison of Security Labels ..... 28

11.2. Application Context 29

11>3 Oesc of Security Qasses ,

. 29

11.4 Sect iisOCSO) , 29

11.4 Security Functlonailty . . 29

11.-^ Security Services for $0 , . 30

1 1.5 Sec .ss OA (SOa) , 31

1 1 f Security Functionality . 31

1l.t Security Services for SOa . 31

11.6 Set, , ^ssl (Si) . 32

t1.6.t Security Functionality ... , . 32

11-S.2 Security Services for St .. 32

11*7 Securfty Qass 1A (Sia) , , . 33

11.?.t Security Functionality ... 33

11,7.2 Security Services for Sia 33

11.a Security Class 2 (S2) . , . 34

11.8.1 Security Functionality , _ . 34

11.8.2 Security Service for S2 34

11.9 Security Class 2A (S2a) _ 3S

11.9.1 Security Functionality . 35

11.9.2 Security Services for S2a ..... . 35

12 Specialized Access ............. 35

iv
Part 8: 1988 Message Handling Systems September 1991 (Stable)

13

14

Conversion . ^^^^^^^^^^^^^^^^^

is

16

EDI (Utcrssaglng Service > >

.

Use of Uimerlylf^ Layers *,,x<<***,>x<,***,>x<<**^. 36

it

16.1 MTS Ttanifef Protocol 0*1)

16,i! Mrs Access Protocol (P3) and MS Access Protocot |P7) . , ,

.

.... .,, ..........

36

36

36

36

36

ilii

17.4 Reports

17.5 Pragmatic Cor»strajnls ^ . ,

.

Oortformanoe

1S.1 h/fX Ketnei Conformance Levels

ld«2 MS Oorrfoimance Levels *>'-'tt***>>-''ft**>r-'<ttt^tr •

Management Domain Agreements <

37

37

37

37

3d

39

Id 39

Annex A (normative)

A.1 MTS Transfer Protocol (Pi)

A:2 Interpersonal Messaging Protocdl (P2)

A,3 MTS Access Proloe?^ (P3)

KA MS Access Protocol CP7> , A.5 Classification of the PI Protocol Elements for Security Classes

46 ... 41

. . 61

> ... .54

. . .66

.... 7a

A6

AJ

A.8

A.9

A.10

A.t1

Classification dtlie P3 Protocol Bements for Secuiity Qasses

Classification of the P7 Protocol Dements for Security Classes

Message Store G^eral Attribute Support

Classification of the tPM MS General Attrlbtjtes for Sec

Message Store IPM Attribute Support

EDI Messaging Service Protocol (Pedi)

Message Store EDIMS AttrllKite Supp^

76

83

85

87

. , , 86

9o:

Annex B (normative)

list of ASN.1 Object IdentlfSers - , 9|

B<1 Content T^s ,<....>>>.<. ..,..>.< 9|;

B:2 Body Part Types - 9^

B.3 Security Classes , 92

Annex (3 (informatwe)

Interpretation of Elements of Service 93

V
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Ann0x D (informstivei)

Reoommended fructices .... - ^ * * * » . 94

D.1 Pfiotabl© String ;

V

. ...94

l%eilct»tloti.<^JA5TeJct , 95

EDIUseofMHS ... 96

0,3.1 IptroduoiQirt ^md ^oop^ , ... , , 96

protocol Elements Scqi^xaled for £1^ . , . 97

Addressing and Routing 97

D.4 textuBtf Ri^esentation oi 0/R Names . , ...... 98

D.5 ODATransfffl^ . . 98

0.6 Use of Externally Defined Body Part . - 9$

fymm E (informative)

Se(^e Messaging Guidelines ..,,...> ...,..,......,< 101

E.1 introduction . . . . . . 101

E>2 Message Handling Viinerabilities 101

E3 General Princi|^6$ 102

E3.1 Security Policy X . . , , , 102

E.3.2 Security aas$0$ 102

Dynamic Behavior Requirements . , 103

E.3,4 Encryption Techniques ...... . . . . . 103

£3.5 Implementation Considerattons ......... ... 104

E.3.5J Peer Entity Authentication ..104

E3*S>a Confidentiality ..... ......... 104

E.3,5.3 Integrity ............. . _ . . 104

E.3x5i||||iii||es^ AulhenticatioR ............-,.,.,.....,;...,.„..- tO|

E3a5.$ Non-Repudiation ......... 105

E.3.5.6 Secure Access Management . . 105

E.3.5.7 Implications for the Use of Distribution Lists .105

E.3.5.8 implications on Redirection .... . .... 106

E.3.5.9 Implications for 1984 Interworking . . . 106

E<3.5.10 Implications for Use of Directory .... , 106

E.3.5.t1 Implications for COftverslor* . 106

E.3.5.12 Accountability , . , > 106

E.3.5.13-:-o::; : Doutjls EnveloplnQ , ,107

E4 Security Class SO . 107

E.4,1 Rationale ........ . ..... 107

EA2 Technical Impiications . , , . t08

E.5 Security Oass Si 108

E,5*1 Rationale , . .108

E.S.2 Technical Implications .................. 108

E<6 Secu^ Class Sa ....... .... , , . . i09

E.6..1 Fiatlonale 109

E6*2 Technical Implications . , . . ,, . . 109

E.7 Confiderttlal Security Qass Variants (SOa, Si a, and S2a| .... no

E7.1 Rationale 1 10

vl
Part 8: 1988 Message Handling Systems September 1991 (Stable)

vll
Part 8: 1988 Message Handling Systems September 1991 (Stable)

list of Figures

Figure 1-

Figure

Figure

A"

Figure

Rgure iii

Figure

Figure

aFigure 10

Figure

Figure

111$

Figure

Figure

Figure

Figure

16

17

18

Figure

, , 14

<444- + -f>>X<

95

96

m

vlii
Part 8: 1988 Message Handling Systems September 1991 (Stable)

List of Tabte3

1 Table 1

- Tai3le 2-

Table 3-

Ta{:^fii4-

V

8-

ID

11

i\ Table 14

t Tat^e 15

Talsle 16

1 TabTe 17

1 Table 18

TabT^ 19

I Table 20

1 Tdbl$ 21

' JaUe 22

Table 23

Ts^e 24

i Table 25

Table 32

1 Table 33

Table 34

Table 35

Table 36

Table 37

Table 3d

Table 33

Table 40

Tat^e 41

Ta^e 42

Table 43

MT Kerfwi: Basic Ber)i»»its of Service i r

MT Kern^: MT $e)rvlce Optional f

Applicadon Oont^s Oassiflica^ x . IPl^ Kernel: Ba$lc il^M Etetnenu <tf Sendee

IPW Kemet: ^PM Service C^>tloiial User Facw»t.c IPM Kernet: Body Part Type$

Message SttK^e;: Etemmts <3f ^rvice x x x ApplloaHor* Contexts Support tor P7 . * , Appllcs^km Contexts Support for P3 x x <

- Remote U$i^ Agent Support: MT Elemeitte<^ Service .........

^ Remote User Agent Support: tPM Elemer^ts of Service x <,..., > - Application Ooniextfi Support for P3

» Use of DtPB^Qry; MT Elemer^ts of Service .

' Use of Directory: IPM Etement$ of Service .

- Directory Service Support fKequiremems

- Standard Attributes; and Attribute Sets .

Standard Object Classes * , >

- Overview of Security Iteqiilretnents for EaoK Security Oass.

* Security Class 0 {s6) x <,....> x , - Security Ctas$ <JA (SOa>. ........ . - » Security Class 1 (Si) . . x < . . . .

- Security Olase 1 A (Sla) ..........

* Security Oass 2 {S2) x x <

- Security Oa$$ 2A ($2a) ,

- Conformance Requirements

-Classlfic^lbn Ci^n9e$

* Classification ctf the PI Protocd Elements > - Cias^ificdtl<^ of the P2 Protoo£^ Elemertt^ .

>- Classificatic»i of the P3 Protocdl Etements . . , . - Classiflcatt<»i of the P7 Protoo<^ £iement$ .

* Conformance Classification of the PI Protocol Elements for Securtty Class S i > Conforrtianoe Classification of tfie Pi Protocol Elements for Security Class $2

- Conformance Oassificatlon of

^P3 Protocol Bements for Security Class SO

- Conformance Classification of die P^ Protocol Elemente for Security C^ss Si

- Conformance Classification of the P3 Protocol Bements fa* Security Class S2

- Conformance Classification of the Protocol Elements for Security Classes SOa, Si a, or S2a > x <

,

> > X < 4 Table 44 - Conformance Classification of the P7 Protocol Elamente for Security Class Si

Table 4S » Classification of the Message Store Gleneral Attributes . Table 46 > IPM MS Security Attribute Support — . . . . . . - -

- Table 47 - Classification of the Message Store IPM Attribute? ,

, Table 50 ' Printable String to ASCII Mapping ......

Table 61 - Interpretation format Effector Combinations ^

m

17

Id

19

19

23

23

23

24

24

27

30

31

33

34

34

35

38

40

42

§1

54

72

74

76

79

81

83

84

8S

87

88

94

95

IX
1
Part 8 1988 Message Handling Systems

0 Introduction

This is an Implementation Agreement developed by the Implementor's Workshop sponsored by the U. S. National Institute of Standards and Technology to promote the useful exchange of data between devices

manufactured by different vendors. This Agreement is based on, and employs protocols developed in accord with, the OSI Reference Model. It provides detailed guidance for the implementor and eliminates

ambiguities in interpretations.

This is an Implementation Agreement for Message Handling Systems (MHS) based on both the CCITT X.400

(1988) series of Recommendations and the similar (but not identical) ISO MOTIS standard (see References).

These Recommendations and Standards are referred to as the base standards. The term 'MHS' is used to

refer to both sources where a distinction is unnecessary. Similarly, '1984' and '1988' are often used to distinguish between the CCITT X.400 (1984) series of Recommendations and the later sources.

This Implementation Agreement seeks to establish a common specification which is conformant with both

CCITT and ISO with a view to:

a) Preventing a proliferation of Incompatible communities of MHS systems which are isolated for protocol reasons;

b) Achieving interworking with implementations conforming to the OIW Stable Implementation

Agreements for CCITT 1984 X.400-based Message Handling Systems;

c) Facilitating integration of other OSI-based services (e.g.. Directory) within a single real system.

This initial Implementation Agreement is designed to encourage early upgrade of existing 1984-based

systems as follows:

a) To add 1988 functionality (Message Store, Remote User Agent, etc);

b) To provide additional functionality above the minimal conformant 1988 MHS defined in the

December 1989 version of the OIW Implementation Agreements. Subsequent versions of this Agreement will define such additional 1988 aspects as incremental enhancements.

However, it is considered that the OIW Stable Implementation Agreements for CCITT 1984 X.400-based

Message Handling Systems (Part 7) should not be withdrawn at this stage. It is anticipated that X.400 (1 984)

implementations will continue to provide a viable alternative for applications that do not require the additional

1988 functionality for some time.

1 Scope

This Agreement specifies the requirements for MHS implementations based on the 1988 MHS standards.

This Agreement applies equally to Private Management Domains (PRMDs) and Administration Management

Domains (ADMDs). Four boundary interfaces are specified, as illustrated in figure 1:

1
Part 8: 1988 Message Handling Systems December 1990 (Stable)

a) Management Domain (MD) to MD;

b) Message Transfer Agent (MTA) to MTA within a donriain;

c) MTA to remote Message Store (MS) or User Agent (UA);

d) MS to Remote UA.

MHS protocols other than the Message Transfer Protocol (P1), the Message Transfer System Access

Protocol (P3), the Interpersonal Messaging Protocol (P2), and the Message Store Access Protocol (P7) are beyond the scope of tfiis Agreement. Issues arising from the use of other protocols are outside the scope

of this document. This Agreement describes the services provided at each Interface shown in figure 1

.

MHS implementations may be configured as any single or multiple occurrence or combination of MTA, MS

and UA, as illustrated in figure 1 . It is not intended to restrict the types of system that may be configured

for conformance to this Agreement (although it is equally recognized that not all configuration types may

be commercially viable).

MD

UA

MTA

UA

MS

MTA

PI

PI

MTA

PI

MS

P3

MTA

MS

P7

UA

P3

MS UA

P3

P7

UA

UA

Figure 1 - Scenario Definition.

The 1988 MHS standards cover a wide and diverse range of functional areas, not all of which would be

relevant to every implementation. In order to achieve a more precise definition of conformance requirements

according to the functionality supported by an implementation, and additionally to facilitate future enhancement of this initial specification, the concept of Functional Groups has been introduced.

Conformance requirements for support of Functional Groups by particular configurations are specified in clause 16.

In the context of these agreements, the term "Support" means that the service provider makes the element

2
Part 8: 1988 Message Handling Systems December 1990 (Stable)

of service (and related elements of protocol) available to the service user. The service user provides

adequate access to invoke the elements of service and/or makes information associated with the service

element available. Additionally, for "Not Defined" or "Not Applicable" elements, the service provider is not

required to make the element available to the service user. However, the service provider should not regard

the occurrence of the corresponding protocol elements as an error and should relay those elements.

Naturally, protocol elements marked critical for submission, transfer, or delivery must be processed

according to the base standards.

The following functional groups are covered by this Implementors Agreement:

a) The MT Kernel in clause 5;

b) The IPM Kernel in clause 6;

c) The Message Store in clause 7;

d) Remote User Agent support in clause 8;

e) Distribution Lists in 9.2 (which are for further study);

f) Use of Directory in 9.3;

g) MHS Management in clause 10 (which is for further study);

h) Security in clause 11;

i) The Physical Delivery Access Unit in 12.1 (which is for further study);

j) Other Access Units in 12.2 (which are for further study);

k) Conversion in clause 13 (which is for further study);

I) Redirection in clause 14 (which is for further study);

m) The EDI Messaging Service in clause 15 (which is for further study).

2 Normative References

2.1 CCITT

Application Layer - MIHS

CCITT Recommendation X.400 (1988), l\/lessage IHandling, System and Sen/ice Overview.

CCITT Recommendation X.402 (1988), Message IHandling Systems, Overall Architecture.

CCITT Recommendation X.407 (1 988) , Message tiandling Systems, Abstract Service Definition Conventions.

3
Part 8: 1988 Message Handling Systems December 1990 (Stable)

CCITT Recommendation X.411 (1988), Message Handling Systems, Message Transfer System: Abstract

Sen/ice Definition and Procedures.

CCITT Recommendation X.413 (1988), Message Handling Systems, Message Store: Abstract Sen/ice

Definition.

CCITT Recommendation X.419 (1988), Message Handling Systems, Protocol Specifications.

CCITT Recommendation X.420 (1988), Message Handling Systems, Interpersonal Messaging System.

CCITT Recommendation X.I 21 (1988), International Numbering Plan.

CCITT draft Recommendation X.435 (June 1990), Message Handling Systems, EDI Messaging System,

Protocol Specifications.

CCITT draft Recommendation F.435 (June 1990), Message Handling Systems, EDI Messaging System,

Abstract Service Definition.

Application Layer - MHS

ISO 10021-1 Information Processing Systems - Text Communication - MOTIS - System and Service

Oven/lev/.

ISO 10021-2 Information Processing Systems - Text Communication - MOTIS - Overall Arcfiitecture.

ISO 10021-3 Information Processing Systems - Text Communication - MOTIS - Abstract Service Definition

Conventions.

ISO 10021-4 Information Processing Systems - Text Communication - MOTIS - Message Transfer System:

Abstract Service Definition and Procedures.

ISO 10021-5 Information Processing Systems - Text Communication - MOTIS - Message Store: Abstract

Service Definition.

ISO 10021-6 Information Processing Systems - Text Communication - MOTIS - Protocol Specifications.

ISO 10021-7 Information Processing Systems - Text Communication - MOTIS - Interpersonal Messaging

System.

This version oHhe Implementation Agreements for Message Handling Systems (MHS) is underdevelopment.

It is based on the CCITT X.400 (1988) Recommendations and ISO MOTIS (10021, parts 1-7) standards, as amended by the MHS Implementors Guide, version 3.

2.2 ISO

3 Status

4
Part 8: 1988 Message Handling Systems December 1990 (Stable)

It is intended that the Stable Implementation Agreements will initially include an Agreement which specifies a minimal 1988-based MHS implementation and support for Message Stores and Remote User Agents, and

which addresses interworking with 1 984-l)ased implementations. The remaining features specified in the

1988 standards will be covered in subsequent versions of this Agreement.

This initial version has not yet been aligned with other MHS profiles, so changes may be necessary in the

future for international harmonization, (e.g., support for international character repertoires and conversion).

4 Errata

No Errata to Stable material at this time.

5 MT Kernel

5.1 Introduction

This clause specifies the requirements for a minimal 1988-based MTS implementation (i.e., MTA) which is capable of interworking with 1984-based MTAs. The 'base' MT Service specified in this clause does not

include:

a) Message Store (see clause 7);

b) Remote UA (see clause 8);

c) Use of Directory Services (see 9.3);

d) Distribution Lists (see 9.2);

e) Security (see clause 11);

f) Interworking with Physical Delivery systems or Specialized Access (see clause 12);

g) Conversion (see clause 13).

Such a minima! 1988-based MTA will have the following capabilities in order to achieve intenA^orking with

1984-t)ased MTAs and to facilitate migration to full 1988 operation:

a) It will be protocol-conformant to 1988 PI;

b) It will downgrade 1988 PI to 1984 PI when relaying to 1984-based MTAs, as specified in Annex

5
Part 8: 1988 Message Handling Systems December 1990 (Stable)

B of X.419 (see clause 5.5);

c) It will support both 'normal' mode and 'X.410-1984' ('passthrough') mode protocol stacks (I.e., as required by ISO and CCITT respectively);

d) A conforming implementation shall obey the criticality mechanism defined in the base standards.

The following abstract operations are made critical for delivery for these Implementation

Agreements: message token, content integrity check, and content confidentiality algorithm Id.

5.2 Elements of Service

This clause specifies the requirements for support of MT Elements of Service by an MTA conforming to the

MT Kernel Functional Group of this Agreement.

The classification scheme for support of Elements of Service is as follows:

Mandatory (M): the Element of Service must be supported and made available to the sen/ice user;

Optional (0): the Element of Service may be supported, but is not required for conformance to this Agreement;

Out of Scope (I): the Element of Service is outside the scope of these Implementation Agreements;

Not Applicable (-) : the Element of Service is not applicable in the particular context according to the t>ase standard;

To Be Determined (*): the support classification for the Element of Sen/ice has yet to be

determined.

The requirements for support of MT Elements of Service for origination and reception and (where relevant)

relaying are distinguished. Elements of Service which are new in the 1988 MHS standards are indicated as

(1988).

An MTA must support those Basic MT Elements of Service and MT Optional User Facilities defined in section

19 of X.400 (1988) as listed and qualified in tables 1 and 2.

Specification of dynamic behavior in these agreements will only be included in those cases where there is an identified functional objective which is not satisfied by the specification of dynamic behavior in the corresponding base standard (s) and where the resulting behavior does not breach base standard

conformance requirements.

In these exceptional cases, there may be situations where these agreements must specify the dynamic

behavior of an implementation as distinguished in annex 0 of ISO TR-10 000. Where this occurs, a table of dynamic conformance requirements will be presented using the classification scheme below:

Mandatory (M): The element must be implemented although use is not required for conformance

to the base standard. The element shall always be used for conformance to these agreements.

6
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Excluded (X): This element must either not be implemented, or it must be possible to prevent use

of the element.

NOTE - As stated in 6.7 of ISO TR-1 0 000-1, restrictions by a profile on the dynamic conformance

requirements of a base standard are exceptions, and should only apply to transmission. Restrictions should

not apply to reception. In the case of Excluded options, it must be possible to ensure that such options are not initiated or transmitted. However, it is still possible that an implementation may receive an Excluded element

from an implementation which does not conform to the same profile.

Table 1 - MT Kernel: Basic MT Elements of Service

Element of Service Origination Reception Relaying

Access Management m1 Ml

Content Type Indication M M

Converted Indication M M M

Delivery Time Stamp Indication M

Message Identification M M

Non-delivery Notification M M M

Original Encoded Information

Types Indication M M

Submission Time Stamp Indication M M

User/UA Capabilities

Registration (1988) m1

Notes

1 A local matter in the case of collocated UA/MTA and/or

MS/MTA configurations.
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 2 - MT Kernel: MT Service Optional User Facilities

Element of Service Origination Reception Relaying

M m2

02

Ponvprc; "i on Proh i bi i" ion M M M

Ponvp r ci i on Proh i b i i" i on in CasG

of TiOc; Q of Tn fortnA I" i on ( 1 98 8 \ 0 0 0

T^^^ 1^^ c^TJL, yX Fitful l-'C XX"i \7<^T*\7 V C X ^ m3 0 0

Doijx^ fX £i\? T"r X X DpLJs^ livprv xxv^xy P^^nppllat'i x^aiiVrfT^xx a v x onwxx m6

DpXJX^ 1XXVv^Xy "i \7P TV T\IO"t" i^V^L.XXX^Mi'ClL'X "1 f "i A "h "i onV^IX M M

M M M

ULt ILXjpall^ 1 Oil nioLvJLy XIxU 1 Oct L X vJXl m4

T\T Ui-I. T*'v"r\a"nc;'i £j JL^Clllo X /^n vjll PirXV.'llXUX T"^h "i b "i t*Lc^U oH M^

"PvT^l L^X \X r*\ \<r X

\'

l.r 0on\70 V^V.'ll V O TX

c*A 1X onWll 0 0 0

CtiT of Dp! 1 \7PT\7 QpI pot" i on M M M

TTol iiw X C\u "fX OTv,^ X Dpi i^c XX1 \7PT*\7 V o X y

1 M

Tmril X XII X iX o Xi i"U Convp \^\w/XX V ^ rX s^ iX onv^xx 0 0 0

T.a+'PC't" Dp! t\7Pt"\7 DpQirmj^'l"'! on ^ 1 Q ft P o 0 0

Multi Destination Delivery M M M

Originator Requested Alternate

Recipient (1988) 0 0

Prevention of Non-delivery

Notification M

Probe M M M

Redirection Disallowed by

Originator (1988) M M

Redirection of Incoming

Messages (1988) 0

Requested Delivery Method (1988) M M

Restricted Delivery (1988) 0

Return of Content 0 0 0

Notes

1 A local matter in the case of collocated UA/MTA and/or

MS/MTA configurations.

2 If Alternate Recipient Assignment is supported on

reception, then support of Alternate Recipient Allowed is

Mandatory on reception; otherwise, support of Alternate

Recipient Allowed is not applicable on reception.

3 Support of this MT Element of Service is Mandatory for

conformance reasons, but may be performed as a local

matter to the originating MTA.

4 Support of this MT Element of Service refers only to the

delivery of DL expansion history and not to the performing

of DL expansion (see clause 9.2).

5 Support of this MT Element of Service does not imply the

capability to perform DL expansion (see clause 9.2).

6 Messages should be held in the originating MTA to provide

support for this element of service.

5.3 MTS Transfer Protocol (P1)

The requirements for support of MTS Transfer Protocol (PI) elements are detailed in clause 1 of annex A.

8
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Support of MTS Transfer Protocol application contexts by an MTA is classified as in table 3.

Table 3 - Application Contexts Classification

Application Context Support

mts-transfer-protocol-1984

mts-transfer-protocol

mts-transfer

Mandatory

Mandatory

Mandatory

Use of the underlying services to support these application contexts is specified in clause 14.

5.4 MTS - APDU Size

See Working Document.

5.5 1988/84 Interworking Considerations

See Working Document.

6 IPM Kernel

6.1 Introduction

This clause specifies the requirements for a minimal 1988-based IPMS implementation (i.e., UA) which is capable of interworking with 1984-based UAs. The 'base' IPM Service specified in this clause does not

include:

a) Message Store (see clause 7);

b) Remote UA (see clause 8);

c) Use of Directory Services (see 9.3);

d) Distribution Lists (see 9.2);

e) Security (see clause 11);

f) Interworking with Physical Delivery systems or Specialized Access (see clause 12).

Such a minimal 1988-based UA will have the following capabilities in order to achieve intenworking with 1984-

based UAs and to facilitate migration to full 1988 operation:

a) It will continue to support content type P2 (encoded as integer 2) on origination and reception;
Part 8: 1988 Message Handling Systems December 1990 (Stable) i

b) It will support receipt of P2 (encoded as integer 22);

c) It may originate P2 encoded as integer 22, but the guidelines specified in section 8.18.2 of X.420

(1988) are to be followed, i.e. the content type shall be encoded as integer 2 unless 1988 P2

protocol elements are present. All IPM UAs must support either MTS Submission and Delivery

based on the protocol classifications in clause 3 of annex A, or MS Submission and Retrieval based on the protocol classifications in clause 4 of annex A. However, how such information is conveyed

to/from the MTS or MS in the case of a collocated UA is a local matter, and will not necessarily be

subject to conformance verification.

6.2 Elennents of Service

This clause specifies the requirements for support of IPM Elements of Service by a UA conforming to the IPM Kernel Functional Group of this Agreement.

The classification scheme for support of Elements of Sen/ice is as defined in 5.2.

The requirements for support of IPM Elements of Service for origination and reception are distinguished.

Elements of Service which are new in the 1988 MHS standards are indicated as (1988).

A UA must support those Basic IPM Elements of Service and IPM Optional User Facilities defined in section

19 of X.400 (1988) as listed and qualified in tables 4 and 5.

Table 4 - IPM Kernel: Basic IPM Elements of Service

Element of Service Orig Recep

Access Management Ml Ml

Content Type Indication M M

Converted Indication M

Delivery Time Stamp Indication M

IP-message Identification M M

Message Identification M

Non-delivery Notification M

Original Encoded Information

Types Indication M M

Submission Time Stamp Indication M M

Typed Body M ^1 User/UA Capabilities Registration (1988)

Notes

1 In the case of a collocated UA/MTA or collocated

UA/MS, the method and extent to which this Element of

Service is provided is a local matter; it is not

necessarily testable in the absence of support for the

P3 or P7 protocol.

I

1

10
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 5 - IPM Kernel: IPM Service Optional User Facilities (concluded)

Element of Service Orig Recep

Restricted Delivery (1988) 0

Return of Content 0

Sensitivity Indication 0 M

Subject Indication M M

Use of Distribution List (1988) 0

Notes

I Other m Blem^aits 6t service are listed In Table 4|| - guppi)r ili; of Non-lece i pt iSot; i f i cat ion Request on reception does not require the capability to generate

a non-receipt notification in the case of an implementation in which a non-receipt condition cannot

occur

.

6.3 Interpersonal Messaging Protocol (P2)

The requirements for support of Interpersonal Messaging Protocol (P2) elements are detailed in clause 2

of annex A.

6.4 Body Part Support

This clause specifies the requirements for support of IPM body part types by a UA conforming to this Agreement.

The classification scheme for support of IPM body part types is as defined in 5.2.

The requirements for support of IPM body part types for origination and reception are distinguished. Body

part types which are new in the 1988 MHS standards are indicated as (1988).

A UA must support those IPM body part types defined in Annex E of X.420 (1988) as listed and qualified in table 6. If an implementation supports a particular body part type for reception, it should also be able to support that body part type for reception if it is part of a forwarded message.

Any basic body part type that is supported on reception must be supported as integer encoding (ASN.1

context-specific identifier) and as object identifier (externally-defined) encoding.

All body parts with integer-encoded identifiers in the range 0 up to and including 16K-1 are legal. Body part

integer-encoded identifiers corresponding to X.121 country codes should be interpreted as described in

figure 4. These privately-defined body part types are specified as an interim measure to provide backward

compatibility with 1984 MHS implementations. For intenworking between UAs based on the 1988 (or later) MHS standards, It is strongly recommended that the externally-defined body part be used instead.

12
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 5 - IPM Kernel: IPM Service Optional User Facilities

Orig Recep

ai4-orn^'l"p Rpr'iriipni" Al lowGd 0 _

Ali-prna*l"p PppiDipnt AssioninGn'k 0

All t hnr i 7 i na Users Indica'tion 0 M

Aiito— forwarded Indication 0 M

Blind Copy Recipient Indication 0 M

Body Part Encryption Indication 0 M

Conversion Prohibition M M

Convcrs i on Proh ibi t i on in CdS6 of Loss of

Tnf X 11 rvrTn;^ f i nn M QfiR ^ 1- WX lUd %^ X V./11 \ X ^ u u / 0 0

C*mc* c Pp f p r pnp "i nn Tnd i cat i on 0 M

npf 1^/^ X prrpd ^ X X ^u Dpi i^/^ XXVi vprv ^ X y M

DpFprrpd L o X X DpIivptv x/^ XX V ^ X jr Cancpllat Vi^aii^ar G x. ^ n v ion x waa 0

T^o lyC 1XX"1 V %S TX \7y Not" L^V./ L'XXX^CkCX 1 f "1 r'^^ t" 1 onWli. M

riiQolo^iirp oF Dthpr Rppi'oi pnt

s

0 M

DTjJaJ Exnansion A-l«^ ^/ W X Xi/AA Historv AA X w \r _T Indication AAX^ X Vft V> X ^^A A fl988) ^ ^ ^ W w ^ M

nr. FYri;^nc=i on Proh ihitpd MQRfi^ M

JUiX^lxy JJClUtj J. iiu 1 L X 0 M

Exnl i c i t Convprs i on 0

Forwarded X \^ X TV W4 X \^ \^ IP— X X messaae AKI taJ W4 \^ Indication X A A VaS X \^ Vft w X X^AA 0 M

firade of Del i verv Selection M M

Hold for Deli verv 0

ImDlicit X All X X X ^ Conversion ^« Vi/A A V X w X AA 0

Importance Indication 0 M

Incomplete Copy Indication (1988) 0 0

Lanauaae XJ^AA AS^ xA W4 X^ Indication X A AxA X \^ W% W X \.^A A fl988) ^ X^ ^ \J f 0 M

Latest Delivery Designation (1988) 0

Multi—Destination Delivery M _ Multi—part Body 0 M

Non—receipt Notification Request 0 m2

Obsoleting Indication 0 M

Originator Indication M M

Originator Requested Alternate

Recipient (1988) 0

Prevention of Non-delivery Notification 0

Primary and Copy Recipients Indication M M

Probe 0

Receipt Notification Request Indication 0 0

Redirection Disallowed by Originator (1988) 0

Redirection of Incoming Messages (1988) 0

Reply Request Indication 0 M

Replying IP-message Indication M M

Requested Delivery Method (1988) M

Editor's Note: This table was renumbered from table 25 in the X.400 Working copy (not table 24 as the

September, 1991, Plenary motion stated).

11
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 6 - IPM Kernel: Body Part Types

Body Part Type Or i g Recen

1 exT, M M

Voice 0 0

G3Facsimile 0 0

\ 1 i. t: V I 0 0

0 0

Videotex 0 0

Encrypted 0 0

Message ( ForwardedlPMessage

)

0 M

MixedMode (TIFl) 0 0

Bi later allyDe fined (Unidentified) 0 0

NationallyDef ined 0

ExternallyDef ined (1988) 0 0/M-^

PrivatelyDef ined (see figure 4) 0 0

GeneralText (1988 - extended) * *

Notes

1 Any basic body part type that is supported on reception as integer encoding must also be supported

as object identifier encoding. Support for all other

externally defined body parts is optional.

13
Part 8: 1988 Message Handling Systems December 1990 (Stable)

BodyPart ::= CHOICE {

ia5-text [0] lASTextBodyPart

,

externally-defined [15] External lyDef inedBodyPart

,

[234] UKBodyParts,

[310] USABodyParts

,

Where UKBodyParts and USABodyParts (privately defined) are defined as:

SEQUENCE {BodyPartNtimber, ANY}

BodyPartNvunber ::= INTEGER

These privately-defined body part types are specified as an interim measure to provide backward compatibility with 1984

MHS implementations. For interworking between UAs based on

the 1988 (or later) MHS standards, it is strongly

recommended that the externally-defined body part be used

instead.

The undefined bit in PI EncodedinformationTypes must be set

when a message contains a privately defined body part. Each

UA that expects such body parts should include undefined in

the set of deliverable EncodedlnformationTypes it registers

with the MTA.

Body part numbers are interpreted relative to the body part

type in which they are used. OIW registers body part

numbers for privately-defined formats within the United

States

.

Figure 4 - Privately-Defined Body Parts.

7 Message Store

7.1 Introduction

This clause specifies Agreements for implementation of the Message Store (MS) Functional Group. The MS

is responsible for accepting delivery of messages on behalf of a single end-user, and retaining the messages

until the end-user's UA is able to retrieve them. Message submission and some administration services are provided via "pass-through" to the MTS. Figure 5 illustrates the logical relationship of the MS to the UA and

MTS.

14
Part 8: 1988 Message Handling Systems September 1991 (Stable)

RETRIEVAL DELIVERY

UA "< MS MTS

INDIRECT

SUBMISSION

-<

SUBMISSION

>-

ADMINISTRATION

>-

ADMINISTRATION

-< >- -< >-

Figure 5 - Message Store Model.

The Agreements in this clause specify the Message Store's use of the retrieval, delivery, and administration

services. Agreements on submission services are specified in clause 8, which describes support for the

Remote UA.

The goal of the Agreements in this clause is to define the minimal set of features which are necessary to provide useful Message Store services, independent of the MTA implementation version (i.e., 1984 or 1988).

7.2 Scope

The scope of the Agreements in this clause is depicted in figure 6, and is confined to the services and

protocols between the boundaries shown (marked with asterisks). Requirements for the UA and MTA are addressed only to the extent that they affect the Message Store and Remote User Agent services and

protocols. This reflects the additional services required at the UA to support MS access and at the MTA to support a remote MS.

*

1

1 P7 P3

*

1

1 UA MS MTA

I I

I I

Figure 6 - Scope of Message Store Agreements.

The UA, MS and MTA configuration is not restricted; any of these components may be collocated, although

they are depicted as logically separate. In the case of a collocated UA and MS, a proprietary interface may

be used instead of P7. In the case of a collocated MS and MTA, a proprietary interface may be used instead

of P3.

15
Part 8: 1988 Message Handling Systems September 1991 (Stable)

7.3 Elements of Service

This clause specifies the requirements for support of Elements of Service to provide a Message Store conforming to the Message Store Functional Group of this Agreement.

The classification scheme for support of Elements of Service is as defined in clause 5.2.

Support for Elements of Service is specified in table 7 both for the Message Store itself and for the User

Agent.

Table 7 - Message Store: Elements of Service

Element of Service UA MS

''•MS Regi^ti^r'' M

Stored Message Deletion M

Stored Message Fetching M M

Stored Message Listing M M

Stored Message Summary M M

Stored Message Alert 0 0

Stored Message Auto Forward 0 0

7.4 Attribute Types j

Requirements for support of the attributes used in the Message Store are detailed in clauses 8 and 10 of I annex A. Clause 8 of annex A specifies support for the General Attributes of the Message Store, while clause

10 of annex A specifies support for the IPM Message Store Attributes.

j

There are three classes of support for General Attributes in the Message Store: Basic, IPM, and EDIMG.

The Basic MS is intended to support the use of the MS as a continuously available, reliable device (such as a spooling entity) for receiving, storing, and forwarding messages and reports. The Basic MS is not required to support any IPM or EDIMG attributes.

The IPM MS provides more flexible access to the General Attributes as well as supporting IPM Attributes.

IPM User Agents can make use of either the Basic or IPM MS. j

Clause A.10 of annex A is to be read in accordance with annex C of X.420 (1988).

| EDI UA can make use of either Basic or EDI MS. Clause A. 12 of annex A is to be read in accordance with annex C of X.435.

16
Part 8: 1988 Message Handling Systems September 1991 (Stable)

7.5 Pragmatic Constraints for Attribute Types

There are no additional pragmatic constraints for attribute types beyond tliose of the base standards.

7.6 Implementation of the MS with 1984 Systems

While the Message Store is part of the 1988 MHS standards, implementation of MS services with a 1984 MTA

is possible. In order to interoperate with other 1984 MHS systems, implementations with this configuration

should adhere to the following guidelines:

16-1

Part 8: 1988 Message Handling Systems December 1990 (Stable)

a) The UA must generate 1984 P2 PDUs;

b) The UA must identify the content protocol as integer 2 to the MS;

c) The MS must be collocated with the MTA unless 1988 P3 support is provided on the 1984 MTA

as well.

To meet these guidelines, the UA may be implemented as follows:

a) The UA could conform to X.420 (1984), with 1988 UA extensions for utilizing the MS services;

b) The UA could be a 1988 UA with restrictions on protocol elements generated and by identifying

the content type as integer 2 rather than 22. No 1988-specific elements should be generated.

Details of the interface between the 1988 MS and the 1984 MTA when collocated are beyond the scope of these Agreements.

7.7 MS Access Protocol (P7)

The requirements for support of MS Access Protocol (P7) elements by an MS and a remote MS-user are

detailed in clause 4 of annex A.

The requirements for support of MS Access Protocol (P7) application contexts by an MS and an MS-user

areas specified in clauses 6.1 and 10.1 of X.419 (1988) (ISO 10021-6) with the additional requirement that an MS-user must at least support the ms-access application context, as defined in table 8.

Table 8 - Application Contexts Support for P7

Application Context MS MS-user

ms-access

ms-reli able-access

Mandatory

Optional

Mandatory

Optional

Use of the underlying services to support these application contexts is specified in clause 14.

7.8 MTS Access Protocol (P3)

The requirements for support of MTS Access Protocol (P3) elements by an MTA and an MS where the MS

is not collocated with the MTA are detailed in clause A.3 of annex A.

The requirements for support of MTS Access Protocol (P3) application contexts by an MTA and an MS in such a scenario are as specified in sections 6.1 and 10.1 of X.419 (1988) (ISO 10021-6) with the additional

requirement that a remote MS must at least support the mts-access and mts-forced-access application

contexts, as defined in table 9.

17
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 9 - Application Contexts Support for P3

Application Context MTA MS

mts-access

mts-forced-access

mts-rel i able-access

mts-forced-reli able-access

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Optional

Optional

Use of the underlying services to support these application contexts is specified in clause 14.

8 Remote User Agent Support

8.1 Introduction

This clause specifies Agreements for implementation of the Remote User Agent Functional Group, i.e. for support of an IPM UA that is not collocated with its MTA.

- NOTE - Support of other classes of UA is for further study.

The goal of the Agreements in this clause is to define the minimal set of features which are necessary to provide useful Remote User Agent services, independent of the MTA implementation version (i.e., 1984 or

1988).

8.2 Scope

The scope of the Agreements in this clause is depicted in figure 7, and is confined to the sen/ices and

protocols between the boundaries shown (marked with asterisks). Requirements for the UA and MTA are addressed only to the extent that they affect the Remote User Agent services and protocols. Access to a Message Store by a Remote User Agent is covered in clause 7.

* *

I I

I I P3

UA MTA

Figure 7 - Scope of Remote User Agent Agreements

18
Part 8: 1988 Message Handling Systems

8.3 Elements of Service

December 1990 (Stable)

This clause specifies the requirements for support of Elements of Service for conformance to the Remote

User Agent Functional Group of this Agreement.

The classification scheme for support of Elements of Service is as defined in 5.2.

Support for Elements of Service is specified both for the MT Service (table 10) and for the IPM Service (table

11), and is in addition to the support requirements specified in clauses 5 and 6 if this Functional Group is supported.

Table 10 - Remote User Agent Support: MT Elements of Service

Element of Service Origination Reception

Access Management M M

Hold for Delivery M

User/UA Capabilities Registration M

Table 11 - Remote User Agent Support: IPM Elements of Service

Element of Service Origination Reception

Access Management M M

Hold for Delivery M

User/UA Capabilities Registration M

8.4 MTS Access Protocol (P3)

The requirements for support of MTS Access Protocol (P3) elements by an MTA and an MTS-user (whether

UA or UA/MS) where the MTS-user is not collocated with the MTA are detailed in clause A.3 of annex A.

The requirements for support of MTS Access Protocol (P3) application contexts by an MTA and an MTS-user

In such a scenario are as specified in sections 6.1 and 10.1 of X.419 (1988) (ISO 10021-6) with the

additional requirement that a remote MTS-user must at least support the mts-access and mts-forced-access

application contexts, as defined in table 12.

Table 12 - Application Contexts Support for P3

Application Context MTA MTS-user

mts-access

mts-forced-access

mts-reli able-access

mts-for ced-r el i able-access

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Optional

Optional

Use of the underlying services to support these application contexts is specified in clause 14.

19
Part 8: 1988 Message Handling Systems December 1990 (Stable)

9 Naming, Addressing & Routing II

9.1 Use of O/R Addresses for Routing

Procurers are responsible for understanding the implications of routing requirements and capabilities.

9.2 ORAddress Attribute List Equivalence Rules

Two ORAddresses are equivalent if each contains the same set of attributes and each attribute compares

in type and value.

The following equivalence rules apply when comparing a provided ORAddress with a collection of known

ORAddresses. For example, in order to perform delivery of a message to a recipient, the MTA must

unambiguously match the ORAddress contained in the message with the known ORAddresses. See X.402

(1988), section 18.4, for the base standard attribute equivalence rules. The following additional rules must

also be applied by the delivering (or non-delivering) MTA:

a) If the provided ORAddress is an unambiguous underspecification of a known ORAddress, the

ORAddresses are equivalent. For example, if the initials were omitted, the ORAddress would still be

equivalent. Under-specification means that some attributes that are not present in the provided

ORAddress are present in the known ORAddresses. Under-specification does not mean partial value

(e.g., substring) equivalence when the same set of attributes are present in the ORAddresses.

b) Over-specified ORAddresses are not equivalent. Over-specification means that more attributes are present in the provided ORAddress than are present in the known ORAddresses.

c) An ADMD or PRMD name that is all numeric but encoded as Printable String is considered to be equivalent to the same ADMD or PRMD name, respectively, with the same numeric values

. encoded as Numeric String.

NOTES

1 An X.500 Directory service may or may not support these matching rules for equivalence.

2 Operational equivalence between T.61 and Printable String is for further study.

9.3 Distribution Lists

See Working Document.

9.4 MHS Use of Directory

20
Part 8: 1988 Message Handling Systems December 1990 (Stable)

9.4.1 Introduction

The MHS standards recognize the need of MHS users for a number of directory service elements. Directory

service elements are intended to assist users, their UAs, and MTAs in obtaining information for use in submission, delivery, and the transfer of messages.

NOTE - The MTS may also use the directory service elements to obtain information, for example, to be used

in the routing of messages. This application of the directory service is not defined by the base standards and

is therefore not addressed by this Agreement.

9.4.2 Functional Configuration

Two MHS functional entities, the IPM UA and MTA, may access the Directory service using the Directory

User Agent (DUA). The interface between the UA and DUA, or MTA and DUA is local and not defined. The

interaction between the DUA and Directory System Agent (DSA) is specified in Part 1 1 . A collocated DUA

and DSA is also permitted.

9.4.3 Functionality

Examples of functional usages of directories have been identified for UAs and the MTAs in conjunction with

their DUAs. These are:

a) UA Specific Functionality:

1) Verify the existence of a Directory Name;

2) Given a partial name, return a list of possibilities;

3) Search the Directory for entries containing a specified attribute type and value and

return the Distinguished Names of the matching entries;

4) Return the 0/R Address(es) that correspond to a Directory Name;

5) Determine whether a Directory Name presented denotes a user or a Distribution List;

6) Return the members of a Distribution List;

7) Return the capabilities of the entity referred to by a Directory Name;

8) Maintenance functions to keep the directory up-to-date, e.g., register and change

credentials;

b) MTA Specific Functionality:

1) Authentication;

2) Return the 0/R Address(es) that correspond to a Directory Name;

21
Part 8: 1988 Message Handling Systems December 1990 (Stable)

3) Determine whether a Directory Name presented denotes a user or a Distribution List;

4) Return the members of a Distribution List;

5) Return the capabilities of the entity referred to by a Directory Name;

6) Maintenance functions to keep the directory up-to-date.

In addition to functionality, a number of operational aspects must be considered. These include

user-friendliness, flexibility, availability, expandability and reliability.

9.4.4 Naming and Attributes

Since user-friendliness is of primary importance in a messaging system, the naming conventions used in building the Directory Information Tree (DIT) will impact the ability of a user to make intelligent guesses

for Directory Names.

It is recommended that the naming guidelines and DIT structures defined in Annex B of Recommendation X.521 /ISO 9594-7 be used as the basis for MHS Directory Names. Annex C of Recommendation X.402/ISO 10021-2 specifies further the MHS specific object classes. The naming for MHS specific object classes are recommended as follows:

a) The naming for mhs-message-store, mhs-message-transfer-agent, and mhs-user-agent is that of Application Entity in the DIT.

b) The naming attribute for mhs-distribution-list is commonName. The organization,

organizationalUnit, organizationalRole, organizationalPerson, locality, or groupOfNames can be

immediate superior to entries of object class mhs-distribution-list.

i c) The naming for mhs-user is that of organizationalPerson, residentialPerson,

organizationalRole, organizationalUnit, organization, or locality.

NOTE - The mhs-user object class is a generic object class which may be used in conjunction with another standard object class for the purpose of adding MHS information attributes, such as ORAddresses,

to a Directory entry. The means to associate attributes of a generic object class to an entry (or to different entries) named by a standard object class(es) is by defining a new (un-)registered object class, whose

superclass(es) is that of the naming object class(es), and of the generic object class. E.g., to associate

mhs-user attributes in the organizationalPerson entry, a new unregistered object class can be defined as shown in figure 8.

real-user-entry : •= OBJECT CLASS

SUBCLASS OF organizationalPerson,

mhs-user

Figure 8 - Example of Unregistered Object Class Definition.

The MHS object classes, attributes, and attribute syntaxes that need to be supported by the Directory

22
Part 8: 1988 Message Handling Systems December 1990 (Stable)

In addition, tfie object classes organization, organizationalUnit, organizationalRole, organizationalPerson,

locality, groupOfNames, residentialPerson, and country and tlieir attributes and associated syntaxes as

defined in X.520 (ISO 9594, Part 6) and X.521 (ISO 9594, Part 7) are required to support the MHS.

I 9.4.5 Elements of Service

I This clause specifies the requirements for support of Elennents of Service for conformance to the Use of

j Directory Functional Group of this Agreement.

The classification scheme for support of Elements of Setvice is as defined in clause 5.2;

Support for Elements of Service is specified both for the MT Service (table 14) and for the IPM Service (table

15).

Table 14 - Use of Directory: MT Elements of Service

Element of Service Origination Reception Relay

Designation of Recipient by

Directory Name M M

Table 15 - Use of Directory: IPM Elements of Service

Element of Service Origination Reception

Designation of Recipient by

Directory Name M

9.4.6 Directory Services

These Implementation Agreements require the Directory services as defined in table 16. Indicated are the

Directory services required to support the needs of the MHS UA/MTA and MHS Administrator.

Table 16 - Directory Service Support Requirements

Directory Service

MHS

UA/MTA

MHS

Admin

Bind and Unbind M M

Read M M

Compare M M,

Abandon M M

List M M

Search M M

Add Entry 0 M

Remove Entry 0 M

Modify Entry M 0

Modify RDN 0 0

23
Part 8: 1988 Message Handling Systems December 1990 (Stable)

9.4.7 OIW X.400 Base Directory Implementation Agreements

This clause defines the X.400 base Directory Implementation Agreements. Its structure and content are based on the Implementation Agreements template suggested in Part 11.

9.4.7.1 Other Profiles Supported

The OIW X.400 Base Directory Implementation Agreements requires the support of OIW Directory Common

Application Directory Implementation Agreements as defined in Part 11.

9.4.7.2 Standard Application Specific Attributes and Attribute Sets

The standard application specific attributes and attributes sets supported by these Implementation

Agreements are listed in table 17. For each attribute and attribute set, a reference is provided to the standard

where it is defined.

Table 17 - Standard Attributes and Attribute Sets

Attribute / Attribute Set References

mhs-deliver able-content-length

mhs-deliverable-content-types

mhs-deliverable-eits

mhs-dl-members

mhs-dl-submit-permissions

mhs-mes sage-store

mhs-or-addresses mhs-prefer red-deli very-methods

mhs-supported-automatic-act ions

mhs-supported-content-types

mhs-supported-optional-at tributes

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

9.4.7.3 Standard Application Specific Object Classes

The standard application specific object classes supported by these Implementation Agreements are listed

in table 18. For each object class, a reference is provided to the standard where it is defined.

Table 18 - Standard Object Classes

Object Class References

mhs-distribut ion-list

mhs-mes sage-store

mhs-mes sage- transfer-agent

mhs-user

mhs-user-agent

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

X.402/IS 10021-2

24
I Part 8: 1988 Message Handling Systems December 1990 (Stable)

I 9.4.7.4 OIW Application Specific Attributes and Attribute Sets

There are no application specific attributes or attribute sets defined by tliese Implementation Agreements.

9.4.7.5 OIW Application Specific Object Classes

; There are no application specific object classes defined by these Implementation Agreements.

9.4.7.6 Structure Rules

i This clause defines the naming and structure rules for the MHS object classes which are subclasses of top.

j 9.4.7.6.1 MHS Distribution List

Attribute commonName is used for naming.

[ Themhs-distribution-list, organization, organizationalUnit, organizationalRole, organizationalPerson, locality,

! or groupOfNames can be immediately superior to entries of object class mhs-distribution-list.

: 9.4.7.6.2 MHS User

li The naming for mhs-user is that of organizationalPerson, residentialPerson, organizationalRole,

j organizationalUnit, organization, or locality.

jl The organizationalPerson, residentialPerson, organizationalRole, organizationalUnit, organization, or locality

I object classes can be combined with the mhs-user object class to form a new composite object class.

10 MHS Management

j See Working Document.

11 MHS Security

1 1 1 .1 Overview

f The Security functional group is specified as three security classes which are incremental subsets of the

I security features available in the base standard. They are denoted as SO, S1, and S2. An implementation

j that conforms to the Security functional group map support one or more of the security classes defined in these Implementation Agreements.

SO: This security class gathers together security functions applicable only between MTS-Users.

25
Part 8: 1988 Message Handling Systems December 1990 (Stabl^)|

Consequently, security mechanisms are implemented witliin the MTS-User. An MTA is required to support the syntax of the security sen/ices on submission, as the "Kernel" supports the syntax on relay i and delivery. The MTA is not expected to understand the semantics of the security services. |

Si : This security class requires secure functionality with the MTS-User and MTS. The MTS secure , functionality is only required to achieve secure access management. As with SO, most of the security f mechanisms are implemented within an MTS-User. It primarily provides integrity and authentication i between MTS-Users. However, MTAs are expected to support digital signatures for peer to peer \ authentication, security labeling and security contexts.

S2: This security class is a superset of S1 , adding security functions within MTAs and the MTS. The main ' security function added within this group is authentication within the MTS, and, as a consequence, due i to the non-repudiable nature of the keys used for authentication, non-repudiation is also added. !

In addition, each of the three security classes has a variant, denoted as SOa, Sla, and S2a, which

mandates support of end-to-end confidentiality.

Symmetric or asymmetric techniques (or a combination thereof) may be used within each security class ' and are identified by the registered algorithm identifier.

Various levels of assurance in trusted COMPUSEC functionality may be used within each security class. ! This is outside the scope of this Implementors Agreement.

A full rationale for each of the security classes and a broader discussion of security considerations are

; provided in annex E.

Table 19 provides an overview of the requirements made by the security classes on the MTS-User and \ MTA. The table entries are descriptive, and are not intended to refer to security service elements.

26
i Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 19 - Overview of Security Requirements for Each Security Class.

Class

Requirements

MTS-User MTA

Kernel Submission, delivery, and

relay of EoS

SO Content Integrity, Proof of

Delivery, Message Origin

Aucnent: ica t ion to ua)

Kernel

SOa SO plus Content

Conf i dent i al i ty

Kernel

SI SO plus Message security

label. Message security

Services

Peer entity authentication.

Security context. Security

Message Security Label

Sla SI plus Content

confidentiality

SI

S2 SI plus Message Origin

Authentication Check, Probe

Origin Authentication Check,

Report Origin Authentication

Check, Proof of Submission,

and, Non-repudiation

SI plus Message Origin

Authentication Check, Prove

Origin Authentication Check,

Report Origin Authentication

Check, Proof of Submission,

and. Non-repudiation

S2a Sla plus S2 Sla plus S2

The incremental functionality of the security classes can be represented diagrammatically as shown in figure 9.

SO

1

1

1

1 \

SOa

SI

1

1

1 \

Sla

S2

\

S2a

Figure 9 - Incremental Functionality of the Security Classes.

11.2 Common Requirements

27
Part 8: 1988 Message Handling Systems December 1990 (Stable)

11.2.1 Interworking Between Security Ciasses

A security class can be viewed as a tool which can be used to implement a security policy, and is not a

security policy in its own right but a component of a security policy.

lnterworl<ing between implementations supporting different security classes can be achieved in terms of any common class(es) supported. As specified in the base standard, the label of the message, probe or

report must be checked against the security context by any implementation claiming conformance to classes S1, Sla, S2, and S2a.

NOTE Interworking can be iimited to messages of only one security class by defining a security context

consisting of labels with security policy identifiers of only that security class.

This profile defines security policy identifiers (annex B, figure 15) that corresponds to the security

classes defined in this section. Such generic security policy identifiers only imply support of the X.400

security services as specified for these security classes in this clause. No other COMSEC or COMPUSEC functionality can be assumed by use of such policy identifiers. More specific security

policies may be based on one or more of the security classes in this section but will require use of registered policy identifiers.

1 1 .2.2 Comparison of Security Labels

The Security Content service ensures that the message security label matches at least one of the set of labels specified in the security content established between the communicating MHS entities.

An MTA which supports the Security Content service shall as a minimum support matching for equality on the security-policy-identifier, security-classification, and security-categories elements of the label. NOTE - The basic support requirement is that absence of an element shall not be treated as "any value',

i.e., all permissible combinations of occurrence and value for the elements of the message security label must be elaborated in the security context.

Any other matching rules (e.g., covering the privacy-mark element or based on alternative methods of comparison) may be used in particular application scenarios, but such specification and usage will be

subject to bilateral agreement and will depend on the security policy in force.

The message security label can be placed in the per-message extensions or in the signed or encrypted

data of the per-recipient message token. It is recommended that the integrity of the security label is protected by including it in the token signed data, or (if the label Is in the per-message extensions) by

computing the message origin authentication check on the message. (Support of MOAC is optional in security classes SO and S1 .) Which of these labels is/are checked by the security context service is dictated by the security policy in force. The security policy should also define any requirements on

allowable (per-recipient) label values in the case where the message is addressed to multiple recipients

(and thus has multiple tokens).

A label may also be included in the token encrypted data with (confidential) end-to-end semantics.

28
Part 8: 1988 Message Handling Systems December 1990 (Stable)

11.2.3 Application Context

When providing the peer entity authentication service, it is recommended that MTAs should not use the

"association-recovery" procedure of RISE (section 7.8.3 of X.228). MTAs in the role of sender should not

invoke this procedure and MTAs in the role of receiver should not accept RT-OPEN requests asking for recovery.NOTE - It is permissible for the sending MTA to perform the "activity resumption" (section 7.8.1 of X.228) on an existing, authenticated RISE association owned by this MTA.

1 1 .3 Description of Security Classes

The sections to follow describe the security classes within the Security functional group. For each

security class, there is a description of the security functionalities provided, followed by a table which

gives the classification for each of the security services required by that class. Where the classification of a security service does not change for a higher security class, then that security service is not repeated

in the table for the higher security class.

Figure 10 explains the column headings used in the security class tables. The classifications are defined

in clause 5.2.

I—1-

UA MS MTA MTA MS UA

1: UA/UA

2: UA/MS

3: MS/MTA

Legend

4: UA/MTA

5: MTA/MS

6: MTA/MTA

7: MTA/UA

8: MS/Originating UA

9: MS/Recipient UA

Figure 10 - Security Interfaces.

1 1 .4 Security Class 0 (SO)

11.4.1 Security Functionality

Security measures shall be provided by the MHS implementation in order to provide the following:

29
Part 8: 1988 Message Handling Systems December 1990 (Stable)

a) Integrity of message content;

b) Authentication of the MTS-User who originated the message;

c) Authentication of the MTS-User to whom the message was delivered.

This security class mandates the above services are provided by an MTS-User.

There are no requirements placed on the MTA.

1 1 .4.2 Security Services for SO

Security class 0 (SO) mandates the security services listed in table 20.

Table 20 - Security Class 0 (SO)

Security Interface 1

Uri/

UA

2

KJn/

MS

3 no/

MTA

4

TTA /

MTA

5

MS

6

1*1 Xrl/ MTA

7 MT2V FIX /

UA

8

MQ /

UA

9 no/

Security Service UA

Origin Authentication

Message Origin Authentication-"-

Probe Origin Authentication

Report Origin Authentication

Proof of Submission

Proof of Delivery

M

M

^6 l6

I

I

I I I

I

-

m4

-

Secure Access Management

Peer Entity Authentication^''

Security Context

0

0

0

0

0

0

0

0

0

0

0

0

0

0

Data Confidentiality

Connection Confidentiality"

Content Confidentiality

Message Flow Confidentiality

I

I

I I I I I I I

Data Integrity Services

Connection Integrity°

Content Integrity

Message Sequence Integrity-'--'-

M

0

I I I I I I I

Non-Repudiation

Non-Repudiation of Origin^

Non-Repudiation of Submission

Non-Repudiation of Delivery^ ' -^^

0

0

I I 0

Message Security Labelling^ 0 0 0 0 0 0 0 0 0

Security Management Services

Change Credentials

Register

MS-Register

0

0

0

0

0

0 l9 0

30
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 20 - Security Class 0 (SO) (concluded)

I Notes

I 1 Only provided to the message recipient.

I 2 Using either symmetric or asymmetric algorithms as identified

I by the algorithm identifier in the applicable protocol element.

I 3 When security labelling is used, the security policy identifier shall

be included.

4 If Proof of Delivery and Content Confidentiality are both used, and

delivery is to an MS, then proof of delivery can only be computed on the

encrypted content. It should be noted that this will not provide

non-repudiation of delivery.

5 Using either a trusted notary (symmetric) or using certificates

tokens which are not repudiable (asymmetric).

6 Corrects table 7 of X.402 in the base standard.

7 Authentication between collocated objects is a local issue.

8 Refer to section 10 of X.402 and ISO/IEC 10 021-2 and IS 7498-2.

9 These services are expected to be provided by non-standard

management services and are therefore outside the scope of this

Implementors Agreement.

10 Non-Repudiation of Delivery can only be provided when the

proof-of-deli very service is used.

11 Allocation and management of sequence numbers is outside the

of this Implementors Agreement (as it is subject to bilateral

agreements )

.

11 .5 Security Class OA (SOa)

11.5.1 Security Functionality

Security measures shall be provided by the MHS Implementation in order to provide the following:

a) Security Functionality defined in security class SO;

b) Content Confidentiality.

11.5.2 Security Services for SOa

Security class OA (SOa) mandates the security services of class SO plus those listed in table 21.

Table 21 - Security Class OA (SOa)

Security Interface 1

UA/

UA

2 UA/

MS

3

MS/

MTA

4 UA/

MTA

5

MTA/

MS

6

MTA/

MTA

7 MTA/

UA

8

MS/

UA

9 MS/

Security Service UA

Data Confidentiality

Content Confidentiality M

31
Part 8: 1988 Message Handling Systems

11.6 Security Class 1 (SI)

11.6.1 Security Functionality

| Security measures shall be provided by tlie MHS implementation in order to provide the following:

a) Authentication of MTA, MS, and UA;

b) Confidentiality of connections between MTA, MS, and UA;

c) Integrity of message content;

d) Authentication of message originator;

e) Authentication of message delivery (Proof of delivery);

f) MLS-features of MTA, MS, and UA;

g) MLS-separation of messages, probes, and reports;

h) MLS-mediation by secure access measures. NOTES

1 The level of assurance of the MLS trusted components is subject to bilateral agreement.

2 The level of accountability provided is subject to bilateral agreement.

11.6.2 Security Services for SI

Security class 1 (S1) mandates the security services of class SO plus those listed in table 22.

32
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 22 - Security Class 1 (SI)

Security Interface 1 UA/

UA

2 UA/

MS

3 MS/

MTA

4 UA/

MTA

5

MTA/

MS

6 MTA/

MTA

7 MTA/

UA

8 MS/

UA

9 MS/

Security Service UA

Origin Authentication

Message Origin Authentication2 Ml I I Secure Access Management

Peer Entity Authentication-''*

Security Context Ml Ml Ml

Ml

Ml Ml

Ml

Ml Ml"i

Data Integrity Services

Content Integrity Ml

Message Security Labelling^ Ml Ml Ml Ml Ml Ml Ml Ml Ml

Security Management Services

Change Credentials

Register

MS-Register

M

M

M

M

M

M l5 M

Notes

1 Shall always be used.

2 Only provided to the message recipient.

3 Using either symmetric or asymmetric algorithms as identified by

the algorithm identifier in the applicable protocol element.

4 Authentication between collocated objects is a local issue,

5 These services are expected to be provided by non-standard

management services and are therefore outside the scope of this

Implementors Agreement

.

1 1 .7 Security Class 1 A (S1 a)

11.7.1 Security Functionality

Security measures shall be provided by the MHS implementation in order to provide the following:

a) Security functionality defined for security class S1

b) Content Confidentiality.

11.7.2 Security Services for SI a

Security class 2A (Si a) mandates the security sen/ices of class S1 plus those listed in table 23.

33
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 23 - Security Class 1A (Sla)

Security Interface 1

UA/

UA

2 UA/

MS

3 MS/

MTA

4 UA/

MTA

5 MTA/

MS

6

MTA/

MTA

7 MTA/

UA

8

MS/

UA

9

MS/

Security Service UA

Data Confidentiality

Content Confidentiality M

11.8 Security Class 2 (S2)

11.8.1 Security Functionality

Security measures shall be provided by the MHS implementation in order to provide the following:

a) Security functionality defined for security class S1;

b) Authentication and non-repudiation of messages, probes, and reports.

1 1 .8.2 Security Service for S2

Security class 2 (S2) mandates the security services of class S1 plus those listed in table 24.

Table 24 - Security Class 2 (S2)

Security Interface 1

UA/

UA

2 UA/

MS

3 MS/

MTA

4 UA/

MTA

5 MTA/

MS

6

MTA/

MTA

7 MTA/

UA

8 MS/

UA

9 MS/

Security Service UA

Origin Authentication

Message Origin Authentication^

Probe Origin Authentication

Report Origin Authentication

Proof of Submission

Ml

M^ "JM-"- Ml Ml Ml

M

Non-Repud i at i on Non-Repudiation of Origin

Non-Repudiation of Submission

Non-Repud i at ion of Delivery

m5

m5

m2

m2

m2

Notes

1 Shall always be used.

2 Using an asymmetric mechanism (i.e., certificates and tokens which

are not repudiable for authentication within MTAs and the MTS.

3 Using the Message Origin Authentication Check as detailed in the

base standard.

4 Shall always be used, and corrects table 7 in X.402.

5 Using either a trusted notary (symmetric) or using certificates

tokens which are not repudiable (asymmetric).

34
Part 8: 1988 Message Handling Systems December 1990 (Stable)

1 1 .9 Security Class 2A (S2a)

11.9.1 Security Functionality

Security measures shall be provided by the MHS implementation in order to provide the following:

a) Security functionality defined for security class S2;

b) Content Confidentiality.

11.9.2 Security Services for S2a

Security class 2A (S2a) mandates the services of class S2 plus those listed in table 25.

Table 25 - Security Class 2A (S2a)

Security Interface 1

UA/

UA

2 UA/

MS

3 MS/

MTA

4 UA/

MTA

5 MTA/

MS

6

MTA/

MTA

7 MTA/

UA

8

MS/

UA

9 MS/

Security Service UA

Data Confidentiality

Content Confidentiality M

I 12 Specialized Access

' See Working Document.

I 13 Conversion

I

See Working Document.

i

! 14 Redirection

II

' See Working Document.

1

1 15 EDI Messaging Service

I See Working Document.

35
Part 8: 1988 Message Handling Systems December 1990 (Stable)

16 Use of Underlying Layers

16.1 MTS Transfer Protocol (PI)

The P1 protocol is mapped onto the Reliable Transfer Service Element (RTSE) either in X.410-1984 mode

or in norma! mode, as specified in clause 5.3. In X.410-1984 mode, the RTSE makes direct use of the

sen/ices provided by the Session Layer, as specified in Part 5 (Upper Layers) of the Stable Implementation

Agreements. In normal mode, the RTSE makes use of the services provided by the Association Control

Service Element (ACSE) and Presentation Layer, as defined in Part 5 (Upper Layers) of these Agreements.

16.2 MTS Access Protocol (P3) and MS Access Protocol (P7)

The P3 and P7 protocols make use of the services provided by the Remote Operations Service Element

(ROSE), Association Control Service Element (ACSE), Presentation Layer, and, optionally, the Reliable

j Transfer Service Element (RTSE), as defined in Part 5 (Upper Layers) of these Agreements. It is recommended that RTSE be used for recovery purposes when the implementation does not use Transport

Class 4 or there is a high probability of an association failure.

17 Error Handling

This clause describes appropriate actions to be taken upon receipt of protocol elements which are not supported in these Implementation Agreements: malformed PDUs, unrecognized 0/R Name forms, content

errors, errors in reports, and unexpected values for protocol elements.

An implementation must be able to report all error conditions which may occur with the appropriate error information as defined in the referenced base standards. An implementation must be able to handle receipt of all error indications which are defined in the referenced base standards. An implementation must also

be tolerant of any additional error indications which are not currently defined, but is not required to be able

to interpret such error information.

17.1 PDU Encoding

See Working Document.

17.2 Contents

See Working Document.

36
Part 8: 1988 Message Handling Systems December 1990 (Stable)

17.3 Envelope

See Working Document.

17.4 Reports

See Working Document.

17.5 Pragmatic Constraints

See Working Document.

1 8 Conformance

For this clause, the term conformance is as defined in ISO 9646.

Bilateral agreements between domains may be implemented in addition to the requirements stated in this document. Conformance to this Agreement requires the ability to exchange messages without use of bilateral agreements.

In order to achieve a more precise definition of conformance requirements according to the functionality

supported by an implementation, the concept of Functional Groups has been introduced. A Functional

Group is a set of related Elements of Sen/ice and associated protocol elements which provide a discrete area of functionality.

Conformance to this Agreement requires as a minimum that all Mandatory Elements of Service listed in this Part are supported in the manner defined in the MHS standards, as qualified in this Agreement, for each of the Functional Groups claimed. Any Optional Elements of Service for which support is claimed

must also be supported as defined in the MHS standards and as qualified in this Agreement. Pragmatic

constraints shall be observed as specified in the CCITT X.400 (1988) Series of Recommendations. It is not necessary to implement the recommended practices of annex D in order to claim conformance to

this Agreement.

Conformance requirements for support of Functional Groups by particular configuration types (see

clause 2) are listed in table 32. An implementation may claim conformance to multiple configuration

types (e.g., "MTA+UA" and "Class B MTA only").

37
Part 8: 1988 Message Handling Systems December 1990 (Stable)*

Table 32 - Conformance Requirements

Functional Group

MT Kernel

IPM Kernel

Message Store*

Remote UA

Distribution List

Directory

MHS Management

Security

Physical Delivery

Other Access Units

Conversion

Redirection

EDI Messaging

Configuration-^

MTA

+

2

M

O

O

0

*0

*

*

*

MTA

+MS

M

M

0

0

0

*o

*

*

*

MTA Only-^

M

O

0

*0

*

**

B

M

M

O

0

*o

*

*

*

*

M

O

O

*o

*

**

**

MS

+UA

M

M

*O

*0

*

*

MS

Only

M

0

*0

*

*

**

UA Only

P7 P3

M

M

O

*O

*

*

*

*

*

M

M

*O

*O

*

*

*

*

*

Notes

1 There are three conformance levels defined for the

MT Kernel in clause 18.1.

2 Optional elements of the IPM Kernel need not be

supported in the MT Kernel in this configuration, for

example Probe and Deferred Delivery Cancellation.

3 The designation of a in a configuration (e.g.,

'MTA+MS') implies that there is no exposed protocol in

the interface between the two components.

4 There are two conformance levels defined in clause

18.2 for MS support.

18.1 MT Kernel Conformance Levels

The MT Kerne! conformance levels are:

a) A class 'A' MT Kernel implementation conveys a message, probe, or report to another MT

Kernel using standard means. A class 'A' MT Kernel is specifically implemented in order to

transfer messages, probes, and reports which have previously been transferred and need not support submission and delivery. A class 'A' MT Kernel may perform other activities such as

originate reports, expand distribution lists, and perform conversions.

b) A class 'B' MT Kernel implementation supports submission, delivery, and transfer using

standard means, i.e. P3 and P1. A class 'B' MT Kerne! need not support the transfer of previously transferred messages, probes, or reports.

c) A class 'C MT Kerne! implementation requires support for transfer of messages, probes, and

reports to another MT Kerne! using standard means. A class 'C MT Kernel does not require

support for the transfer of previously transferred messages, probes, and reports, and message

submission and delivery is achieved by non-standard means.

38
Part 8: 1988 Message Handling Systems December 1990 (Stable)

An MTA may conform to one or more of the MT Kernel classes. For example, a class 'B' or 'C MT

Kernel which supports the transfer of previously transferred messages, probes, and reports is also

conformant to a class 'A' MT Kernel. Figure 1 1 illustrates several combinations of MT Kernel

conformance classes. Additional combinations are possible.

UA

MS

MTA

Class B

MTA

Class A

MTA

Class AB

Standard

Non-standard

UA

MS

MTA

Class C

UA

MS

Figure 1 1 - MT Kernel Conformance Classes

18.2 MS Conformance Levels

The MS conformance levels are:

a) A Basic MS only requires support for the General Attributes as specified in clause 8 of annex

A;

b) An IPM MS requires support from both the General Attributes and IPM Attributes as specified

in clauses 8 and 10, respectively, of annex A.

19 Management Domain Agreements

See Working Document.

39
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Annex A (normative)

MHS Protocol Specifications

Tables 34 through 49 specify the requirements for support of MHS protocol elements for conformance to

this Agreement. It should be noted that the tables specify minimum support for conformance to the

relevant Kernel functional groups and where appropriate also specify enhanced support requirements

where one or more further functional groups are claimed. All element support Is subject to further

review and may be upgraded In later versions of this Agreement

Within the classification tables (34-49), the column "S" indicates the classification from the base

standards. This is provided for reference purposes only and is intended to be in agreement with the base

standards.

The protocol support classification scheme used in this version of this Agreement is described below.

However, it should be noted that the scheme is currently under review both within the OIW X.400

S!G and in the EWOS/ETSI MHS groups and is likely to be revised for later versions of this

Agreement.

The classification of support for a protocol element specifies the requirements for implementations

conforming to this Agreement to be able to generate, receive and process that protocol element, as

appropriate (the 'receiving' role includes relaying where appropriate). The classification of support for each protocol element is relative to that for its containing element. Where sub-elements within a

containing element are not listed, then their support classification shall be assumed to be that of the

containing element. Where the range of values to be supported for an element is not specified, then all values defined in the base standard shall be supported.

The classifications have been revised. The new classifications relate to the classifications in the Part 7 of the Stable Agreements as shown in table 33.

Table 33 - Classification Changes

Former

Category

New

Originator

Category

Recipient

Category

Generatable (G)

Supported (H)

Mandatory (M)

Required (R)

Unsupported (X)

Mandatory (M)

Optional (0)

Mandatory (M)

Mandatory (M)

Optional (0)

Mandatory (M)

Mandatory (M)

Mandatory (M)

Mandatory (M)

Optional (0)

The support classifications are stated for both Origination and Reception (0/R) in the following tables

(34-49). The defined support for each is stated within each classification.

Implementations conforming to this Agreement must be capable of accepting the syntax of every

protocol element of a protocol for which support is claimed. When an MS or MTA receives a protocol

element that according to the base standard should be conveyed to another MHS entity (MTA, MS, or

40
Part 8: 1988 Message Handling Systems December 1990 (Stable)

UA), the MS or MTA is required to preserve tlie semantics of tliat protocol element in the PDU

conveyed. Notwithstanding the above, criticality must be observed according to the base standard.

Mandatory (M) on Origination: Implementations conforming to this Agreement shall generate this element in all information objects in which, according to the base standards, it shall occur.

Mandatory (M) on Reception: Implementations conforming to this Agreement shall process this element appropriately according to its semantics.

Optional (O) on Origination: Where this element Is not conveyed from one MHS entity to another, implementations conforming to this Agreement may optionally be capable of generating

this protocol element, but are not required to do so.

Optional (O) on Reception: Implementations conforming to this Agreement may, but are not

required to be capable of processing this protocol element.

NOTE - Some protocol elements may not be conveyed, if dow/ngrading rules are applied.

To Be Determined (*): the support classification for this protocol element has yet to be

determined.

Not Applicable (-): The protocol element is not applicable in the particular context according to the base standard.

Where the dynamic behavior of protocol elements need to be specified, the following classification scheme is used:

Mandatory (m): The protocol element shall always be implemented and generated. On reception, correct action shall be taken as specified in the base standard, or as qualified or specified in these Agreements. Absence of the corresponding protocol element shall cause the appropriate

abstract error to be generated.

Excluded (x): The protocol element shall not be present or it must be possible to prevent its use.

Its presence shall cause the appropriate abstract error to be generated.

Dynamic conformance classifications are indicated in a single column of each of the Protocol Element

tables. The classification applies to the usage only of the protocol elements which have a static

classification.

A.1 MTS Transfer Protocol (PI)

41
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the PI Protocol Elements

MTS Transfer Protocol (PI) Part 1 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

MTABind M M/M M/M MTABind

MTAUnbind M M/M M/M

MTSE See protocol elements

MessageTransfer M M/M M/M

ProbeTransfer M M/M M/M

Reoort Transfer M M/M M/M

Arguments/Results

MTABind

ARGUMENT

<NULL> 0 0/M 0/M See Note 2 <SET> 0 M/M M/M

1 ni "h 1 a "1" or—n;^TIP M M/M M/M

initiator-credentials M M/M M/M

simple 0 M/M M/M

strong 0 0/0 0/0

secur i ty-cont ext 0 0/0 0/0

RESULT

<NULL> 0 0/M 0/M See Note 2 <SET> 0 M/M M/M

responder-name M M/M M/M

responder-credentials M M/M M/M

simple 0 M/M M/M

strong 0 0/0 0/0

Notes

1 The MT Kernel implementation classes are defined in

clause 16.

2 The action to be taken on receipt of null MTABind

authentication is that an implementation must understand the

semantics, but the form of authentication that is acceptable

is a local matter.

42
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the PI Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 2 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

MTS-APDU

message M M/M 0/M

envelope M M/M M/M MessageTransferEnvelope

content M M/M M/M See P2 - else undefined

probe M M/M 0/M ProbeTransferEnvelope

report M M/M M/M

envelope M M/M M/M ReportTransferEnvelope

content M M/M M/M ReportTransferContent

MessageTransferEnvelope

message-identifier M M/M M/M MTSIdentif ier

originator-name M M/M M/M ORName

or iginal-encoded-informat iontypes 0 M/M 0/0 EncodedlnformationTypes

content-type M M/M M/M

built-in 0 M/M 0/0

external 0 0/M 0/0

content-identifier 0 0/M 0/0

priority 0 M/M 0/M All values

per-message- indicators 0 M/M 0/M

disclosure-of-recipients 0 0/M 0/M

implicit-conversion-prohibited 0 M/M 0/M

alternate-recipient-allowed 0 M/M 0/0

content-return-request 0 0/0 0/0

defer red-deli very-time 0 0/0 0/0

per-domain-bi lateralinformation 0 0/0 0/0 PerDomainBi lateralinf

o

trace-information M M/M M/M Traceinformat ion

extensions 0 M/M M/M ExtensionField

recipient-reassignmentprohibited 0 M/M M/M

dl-expans ion-prohibited 0 M/M 0/M

conver s ion-wi th-lossprohibited 0 0/M 0/M

XCILVo Ur^U^XX VcLy^U X lllo n\j See X.411 , 14.1.1 note 2 originator-return-address 0 0/0 0/0

originator-certificate 0 0/0 0/0

content-confidentialityalgorithm-identifier 0 M/M M/M See Note 6 message-originauthentication-check 0 0/0 0/0

message-secur i ty-label 0 0/0 0/0 See Note 5 security-policy-identifier 0 M/M M/M

security-classification 0 M/M M/M

privacy-mark 0 0/0 0/0

secur i ty-cat egor i es 0 M/M M/M

content-correlator 0 0/0 0/0

43
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Ciasssfication of the Pi Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 3 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

dl-expans ion-history 0 0/M 0/M DLExpansionHi story

internal-t race-information 0 M/M M/M InternalTraceInf

o

per-recipient-f ields M M/M M/M

recipient-name M M/M M/M ORName

originally-specif iedrecipient-number M M/M M/M

per-recipient-indicators M M/M M/M

expl i c i t -conve r s i on 0 0/0 0/0

extensions 0 0/M 0/M ExtensionField

originator-requestedalternate-recipient 0 0/0 0/0

requested-del i very-method 0 M/M 0/M

physical-forwardingprohibited 0 0/0 0/0

physical-forwarding-addressrequest 0 0/0 0/0

physical-delivery-modes 0 0/0 0/0

registered-mail-type 0 0/0 0/0

recipient-number-for-advice 0 0/0 0/0

physical-rendition-attributes 0 0/0 0/0

physical-delivery-reportrequest 0 0/0 0/0

message-token 0 0/0 0/0

asymmetric-token 0 M/M M/M See Note 5

signature-algorithmidentifier M M/M M/M

name M M/M M/M

time M M/M M/M

sign-data 0 M/M M/M

content-confidentialityalgorithm-identifier 0 M/M M/M

content-integrity-check 0 M/M M/M

message-security-label 0 0/0 0/0

proof-of-deli very-request 0 M/M M/M

message-sequence-number 0 0/0 0/0

encrypt ion-algor i thmidentif ier 0 M/M M/M

encrypted-data 0 M/M M/M

content-confidentiality-key 0 M/M M/M

content-integrity-check 0 M/M M/M

message-security-label 0 0/0 0/0

content-integrity-key 0 0/0 0/0

message-sequence-number 0 0/0 0/0

content-integrity-check 0 M/M M/M See Note 6 proof-of-deli very-request 0 M/M M/M See Note 6 redirection-history 0 0/M 0/M

44
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the PI Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 4 of 9 MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

ProbeTransferEnvelope

probe-ident i f ier M M/M M/M MTSIdentif ier

originator-name M M/M M/M ORName

or iginal-encoded-informat iontypes 0 M/M 0/0 EncodedlnformationTypes

content-type M M/M M/M

built-in 0 M/M 0/0

external 0 0/M 0/0

content-ident i f ier 0 0/M 0/0

content-length 0 M/M 0/0

per-message-indicators 0 M/M 0/M

disclosure-of-recipients 0 0/0 0/0

implicit-conversion-prohibited 0 M/M 0/M

alternate-recipient-allowed 0 M/M 0/0

content-return-request 0 0/0 0/0

per-domain-bi lateralinformation 0 0/0 0/0 PerDomainBi lateral Info

trace-information M M/M M/M Tracelnformation

extensions 0 M/M M/M ExtensionField

recipient-reassignmentprohibited 0 0/0 0/0

dl-expans ion-prohibited 0 M/M 0/M

conversion-with-lossprohibited 0 0/0 0/0

or iginator-certi f icate 0 0/0 0/0

message—security—label o o/o o/o

content-correlator 0 0/0 0/0

probe-origin-authenticationcheck 0 0/0 0/0

d 1 -expans i on-h i s t or

y

0 0/M 0/M DLExpans ionHi story

internal-trace- information 0 M/M M/M InternalTracelnfo

per-recipient-f ields M M/M M/M

recipient-name M M/M M/M ORName

originally-specif iedrecipient-number M M/M M/M

per-recipient-indicators M M/M M/M

explicit-conversion 0 0/0 0/0

extensions 0 0/M 0/M ExtensionField

originator-requestedalternate-recipient 0 0/0 0/0

requested-deli very-method 0 M/M 0/M

physical-rendition-attributes 0 0/0 0/0

redirection-history 0 0/M 0/M

45
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the PI Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 5 of 9 MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

ReportTransferEnvelope

report-identifier M M/M M/M MTSIdentif ier

report-destination-name M M/M M/M ORName

trace-information M M/M M/M Tracelnformation

extensions 0 M/M M/M ExtensionField

message-security-label 0 0/0 0/0

or i g i nat or -and-DL-expans i on- OriginatorAndDL

history 0 M/M 0/0 ExpansionHi story

r epor t i ng-DL-name 0 0/0 0/0

report ing-MTA-certificate 0 0/0 0/0

report-origin-authenticationcheck 0 0/0 0/0

internal-trace-information 0 M/M M/M InternalTracelnfo

ReportTransferContent

subject-identifier M M/M M/M MTSIdentif ier

sub ject- intermediate-traceinformation 0 M/M M/M Tracelnformation

or iginal-encoded-informat iontypes 0 M/M M/M EncodedlnformationTypes

content— type U iTl/rl TW /tut built-in 0 M/M M/M

external 0 M/M M/M

content-identi f ier 0 M/M M/M

returned-content 0 0/M 0/0

additional-information 0 0/0 0/0

extensions 0 0/M 0/M ExtensionField

content-correlator 0 0/M 0/M

per-recipient-f ields M M/M M/M

actual-recipient -name M M/M M/M ORName

originally-specif iedrecipient-number M M/M M/M

46
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the Pi Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 6 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

per-recipient-indicators M M/M M/M

last-trace-information M M/M M/M

arrival-time M M/M M/M

converted-encodedinformat ion-types 0 M/M M/M Encodedinformat ionTypes

report M M/M M/M

delivery 0 M/M 0/0

message-delivery-time 0 M/M M/M

t VDP—of —MTS—11 s p r 0 M/M 0/0 All values =0/M

non-delivery 0 M/M M/M

non-delivery-reason-code 0 M/M M/M

non-delivery-diagnosticcode 0 0/M 0/M

originally-intended-recipientname 0 M/M M/M ORName

supplementary-information 0 0/0 0/0

i^n^ "i one o M/M M/M ExtensionField

redirection-history 0 M/M M/M RedirectionHi story

physical-forwarding-address 0 0/0 0/0

recipient-certificate 0 0/0 0/0

o o/o o/o

Common Data Types

Encodedinformat ionTypes

built-in-encoded-informat iontypes M M/M M/M See Note 3 non-basic-parameters 0 0/0 0/0

external-encoded-informat iontvDes 0 0/M 0/M

MTSIdentif ier

global-domain-identifier M M/M M/M GlobalDomainldentif ier

local-identifier M M/M M/M

PerDomainBi lateral Info

country-name M M/M M/M

administrati on-doma i n-name 0 M/M M/M DomainName

private-domain-identifier 0 M/M M/M DomainName

(only encoded as SEQ if

both present)

bilateral-information M M/M M/M

47
Part 8: 1988 Message Handling Systems December 1990 (Stable) ^

Table 34 - Classification of the PI Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 7 of 9 MT Kernel Support by MTS Class Comments/References

B/C

c n/R See Note 1

Trar'pTn format" ^ on

X X uV^^ X XXI. v./ X Xlld X vXI I 1 X ^lU^XX c M M/M M/M

global-domain- identifier M M/M M/M GlobalDomainldentif ier

doma i n-suppl i ed-i nformat i on M M/M M/M

Cki. I. XVCIX~CX iUV M M/M 11/ 11 M/M 11/ 11 rout inci—act ion M M/M M/M

X c X Q y M/M 11/ 11 M/M 11/ 11 fX OVXWU fOll 1 n/M n/M w/ r'l 54 1 1 omnt ^^1—rlomj* i n n n/M11 n/M w/ 11 GlobalDomainldent i f i er

Hpf^^rrp^l— U^ X ^X X ^U tif "iX mplUC n M/M 1 1/ 11 M/M 11/ 1

1

converted-encodedinformat ion-types 0 0/M 0/M EncodedlnformationTypes

other—act ions 0 0/M 0/M

redi rected 0 0/M 0/M

dl—otierat ion 0 0/M 0/M

ExtensionField

type M M/M M/M

<^T1 "t"! *^J4l 1 +"\7 V.rX X ^X^CIXX Ujr nW//M11 n/M

fj_ oT" —~sQ1UWIUX 1 Htn 1 c*S3 ciO

!X onv/11 n n/n n/n

for XVh/X — tI^XuXXOX^X ran^fpr o M/M M/M

for—dpi i vpr

V

0 M/M M/M

value M M/M M/M

DLExpansionHi story

DLExpans i on M M/M M/M

ORAddressAndOpt ionalDi rectory

Name M M/M M/M ORName

dl—expansion—t ime M M/M M/M

Int p rna 1 Trar'pTn f orina i" i on

XXX^^X.XXC&X.X XCXVi^^XXXX. \J L, Xllu Kf X \_/XXXJ X CSXllCXX u MX i M/M 1 1/ 11 M1 1//M1

1

alobal X\.yia^CX X —dotna UWXllCi in— X XX idpirfi X U^XX ^ X fX. iX e^r C X M M/M 1 1/ 1

1

M/M 1 1/ 1 1 GlobalDomainldentif ier

mta-name M M/M M/M

mta-supplied- information M M/M M/M

arWX XXAVmX r i va 1 —tifX"i mpxu^ M M/M 1 1/ 1

1

1M/M 1/ 1 1 Ton X tL> "iXlXt^~Cl^ nn r^tL> iX onwll M M /MFx M/M 11/ n

relayed 0 M/M M/M

rerouted 0 0/M 0/M

attempted 0

mta 0 0/M 0/M

domain 0 0/M 0/M GlobalDomainldentif ier

deferred-time 0 0/M 0/M

other-actions 0 0/M 0/M

redirected 0 0/M 0/M

dl-operation 0 0/M 0/M

Or iginatorAndDLExpansionHi story

originator-or-dl-name M M/M M/M

or igination-or-expans ion-time M M/M M/M

48
ijPart 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the PI Protocol Elements (continued)

MTS Transfer Protocol (PI) Part 8 of 9 MT Kernel Support by MTS Class Comments/Ref e r ences B/C A

Protocol Element S 0/R 0/R See Note 1

RedirectionHistory

Redirection M M/M M/M

intended-recipient-name M M/M M/M

ORAddressAndOpt ionalDi rectory

Name M M/M M/M ORName

redi rect ion-t ime M M/M M/M

redirection-reason M M/M M/M

ORName

address M M/M M/M

standard-attributes M M/M M/M

country-name 0 M/M 0/M Count ryName

administration-domain-name 0 M/M 0/M DomainName

network-address 0 M/M 0/M

terminal-identifier 0 M/M 0/M

pr i vat e-doma i n-name 0 M/M 0/M DomainName

organi zat ion-name 0 M/M 0/M

numeric-user-identifier 0 M/M 0/M

personal-name 0 M/M 0/M

surname M M/M M/M

given-name 0 M/M 0/M

initials 0 M/M 0/M See Note 4

generation-qualifier 0 M/M 0/M

or gani zat ional-uni t-names 0 M/M 0/M

Organi zat ionUni tName M M/M 0/M

domain-defined-at tributes 0 M/M 0/M

DomainDefinedAt tribute M M/M 0/M

type M M/M M/M

value M M/M M/M

extension-attributes 0 0/M 0/M Ext ens ionAt tribute

common-name 0 0/M 0/M

n/M n/M

teletex-organi zat ion-name 0 M/M 0/M

t e1 et ex-per s ona1 -name 0 M/M 0/M

teletex-organi zat ional-uni t- names 0 M/M 0/M

teletex-domain-def inedattributes 0 M/M 0/M

pds-name 0 0/M 0/M

physical-delivery-countryname 0 0/M 0/M

postal-code 0 0/M 0/M

phys i cal -de live r y-of f i ce-name 0 0/M 0/M

49
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 34 - Classification of the PI Protocol Elements (concluded)

MTS Transfer Protocol (PI) Part 9 of 9

MT Kernel Support by MTS Class

Protocol Element

B/C

0/R

A

0/R

Comments/References

See Note 1

physical-delivery-officenumber

extension-OR-addresscomponents

physical-delivery-personalname

physical-deliveryorganizati on-name

extens ion-phys i cal-del i veryaddress-components

unformatted-postal-address

street-address

post-office-box-address

poste-rest ante-address

uni que-pos t a 1 -name

local-postal-attributes

extended-network-address

terminal-type

directory-name

Extens ionAt tribute

extension-attribute-type

extension-attribute-value

GlobalDomainldentif ier

country-name

administrati on-domai n-name

private-domain-identifier

Count ryName

xl21-dcc-code

iso-3166-alpha2-code

DomainName

numeric

printable

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/0

M/M

M/M

M/M

M/M

M/M

0/M

M/M

0/M

M/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/M

0/0

M/M

M/M

M/M

M/M

0/M

0/M

0/M

0/M

0/M

Count ryName

DomainName

DomainName

Notes ( cont i nued

)

3 An implementation is only required to generate EITs that

correspond to the body parts it is capable of generating.

4 If the initials component of personal-name attribute is used,

it should comprise all of the person's initials (including the

given name) except the person's surname, as specified in

X.402/IS 10021-2.

5 All SO services may be provided without using the message token,

e.g., using per-message extensions.

50
I Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.2 Interpersonal Messaging Protocol (P2)

Table 35 - Classification of the P2 Protocol Elements

Interpersonal Messaging Protocol (P2) Part 1 of 3 Support by

UA

Protocol Element s 0/R Comments/References

InformationOb ject

ipm 0 M/M IPM

ipn 0 M/M IPN - see Note 4 IPM

heading M M/M

this-IPM M M/M IPMIdentif ier

originator 0 M/M ORDescriptor

author i zing-users 0 0/M Rec i pi ent Spec i f i e r primary-recipients 0

TUT M/M/TUT RecipientSpecif ier

copy-recipients 0 M/M Rec i pi ent Spec i f i er blind-copy-recipients 0 0/M RecipientSpecif ier

replied-to-IPM 0 M/M IPMIdentif ier

obsoleted-IPMs 0 0/M IPMIdentif ier

related-IPMs 0 O/M IPMIdentif ier

subject 0

Tuf /xjr See Note 1, 8

expiry-time 0

r\U/M/\M reply-time 0 U/M

reply-recipients 0 U/M ORDescriptor

importance 0 O/M

sensitivity 0 O/M

auto-forwarded 0 O/M

extensions 0 O/M HeadingExtension

incomplete-copy 0 o/o

languages 0 U/M

bodv M M/M BodyPart

IPN

common-f i e1 d

s

M M/M

sub ject-ipm M M/M

ipn-originator 0 M/M ORDescriptor

ipm-prefer red-recipient 0 M/M ORDescriptor

conve r s i on-e its 0 0/M EncodedInformationTypes

non-receipt-fields 0 M/M See Note 5

non-receipt-reason M M/M

discard-reason 0 M/M

auto-forward-comment 0 0/M

returned-ipm 0 0/0 See Note 2 receipt-fields 0 0/M

receipt-time M M/M

51
Part S: 1988 Message Handling Systems December 1990 (Stabie)

Table 35 - Classification of the P2 Protocol Elements (continued)

Interpersonal Messaging Protocol (P2) Part 2 of 3

Support by

UA

Protocol Element S 0/R Comments/References

acknowledgment -mode 0 0/M

suppl-receipt-inf

o

0 0/0

Head i ngExt ens i on

type M M/M

value M M/M

IPMIdentif ier

user 0 0/M

user-relative-identifier M M/M

ORDescriptor

formal-name 0 0/M ORName - see Note 3

free-form-name 0 0/M See Note 8

t e1 ephone-number 0 0/M

RecipientSpecif ier

recipient M M/M ORDescriptor

notification-requests 0 0/M

reply-requested 0 0/M

BodyPart

ia5-text 0 M/M

parameters M M/M

repertoire 0 0/M See Note 6

data M M/M

voice 0 * See Note 7 g3-facsimile 0 0/0

parameters M M/M

number-of-pages 0 0/M

non-basic-parameters 0 0/M

data M M/M

g4-classl 0 0/0

teletex 0 0/0

parameters M n./ f*i number-of-pages 0 0/0

telex-compatible 0 0/0

non-bas i c-par amet e r s 0 0/0

data M M/M

videotex 0 0/0

parameters M M/M

syntax 0 0/M

data M M/M

encrypted 0 * See Note 7

52
Part 8: 1988 Message HandMng Systems December 1990 (Stable)

Table 35 - Classification of the P2 Protocol Elements (coricluded)

Interpersonal Messaging Protocol (P2) Part 3 of 3

Protocol Element

Support by

UA

0/R Conraients/Ref erences

message

pareuneters

delivery-time

delivery-envelope

data

mixed-mode

bilaterally-defined

nationally-defined

externally-defined

parameters

data

GeneralTextBodyPart

0/M

M/M

0/M

0/M

M/M

0/0

0/0

0/0

0/M

M/M

M/M

See P3 OtherMessage

Del iveryFi elds

Notes

1 The ability to generate the maximum size subject is not

required.

2 May only be included if specifically requested by the

originator

.

3 The ORName should be specified wherever possible.

4 The ability to generate an IPN is optional in the case of an implementation in which a non-receipt condition cannot occur and receipt notification is not supported (see

table 5).

5 The ability to generate non-receipt-fields is optional in

the case of an implementation in which a non-receipt

condition cannot occur (see note 4).

6 Only the IA5 repertoire has to be supported for an ia5-text body part on reception.

7 The definition of these body parts is for further study in

CCITT and ISO.

8 Only the IA5 subset of the T.61 character repertoire need

be generated. All T.61 characters should be supported on

reception.

53
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.3 MTS Access Protocol (P3)

NOTE - The support classifications for the IPM UA, MS and MTA below indicate the minimum level of support

required by implementations conforming to these Agreements, and should not be misconstrued as a

redefinition of any of the MHS application contexts.

Table 36 - Classification of the P3 Protocol Elements

MTS Access Protocol (P3) Part 1 of 12

Support by: IPM

UA

0/R

MS

0/R

MTA

Protocol Element S 0/R Comments/References

Operations

MTSBind

MTSUnbind

M

M

M/M

M/M

M/M

M/M

M/M

M/M

MTSBind

MSSE

message-submission

probe-submission

cancel-deferred-delivery

submi s s i on-cont rol

M

M

M

M

M/-

0/-

0/-

-/M

M/M

M/M

M/M

M/M

-/M

-/M

-/M

0/-

MessageSubmission

ProbeSubmission

CancelDeferredDelivery

Submi s s ionCont rol

MDSE

message-delivery

report-delivery

delivery-control

M

M

M

-/M

-/M

0/-

M/M

M/M

0/-

M/-

M/-

-/M

MessageDelivery

ReportDelivery

DeliveryControl

MASE

register

change-credentials

(MTS to MTSuser)

(MTSuser to MTS)

M

M

M

0/-

-/M

0/-

M/M

M/M

M/M

-/M

0/-

-/M

Register

ChangeCredent i als

ChangeCredentials

Note - A Message Store must

operations unaltered.

pass through all MSSE and MASE

54
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 2 of 12

Support by: T TiUt Urn.

urc* UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

Arguments/Results

MTSBind MTS to MTS User

ARGUMENT

ini t i ator-neune M -/M -/M M/-

MTS-user /- -/ /

MTA 0 /M M/M/-

isMessageStore / / / mes sages -wa i t i ng 0 -/O -/O 0/-

initiator-credentials M -/M -/M/TUT M/-

simple 0 -/M -/M M/-

strong 0 -/o -/o 0/-

secur i ty-context 0 -/o ~/o 0/- 1-256

RESULT

responder-name M M/- M/- -/M

MTS-user 0 M/- M/- -/M

MTA / /-

ismessagestore 0 n/ — M/_ ra/- - /M

messages-waiting / / /

responder-credentials M M/- M/- -/M

simple 0 M/- -/M

strong 0 u/- -/u

MTSBind MTS User to MTS

ARGUMENT

initiator-name M M/- M/- -/M

mTS-user 0 M/- M / /M

mTA -/- /

isMessageStore 0 n/-

messages-waiting /

initiator-credentials M M/_ n/ — M/_ n/- -/M

s impxs r\U M/- M/- -/M

strong 0 0/- 0/- -/o

security-context 0 0/- 0/- -/o 1-256

RESULT

responder-name M -/M -/M M/-

mTS-user -/- -/- -/-

mTA 0 -/M -/M M/-

isMessageStore -/- -/- -/- messages-waiting 0 -/o -/o 0/-

responder-credentials M -/M -/M M/-

simple 0 -/M -/M M/-

strong 0 -/o -/o 0/-

55
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 3 of 12

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

Mes s ageSubmi s s i on

ARGUMENT

envelope M M/- M/- -/M MessageSubmi ssion

Envelope

content M M/- M/- -/M

RESULT

mess age-submi s s i on- i dent i £ i er M -/M -/M M/- See PI MTSIdentif ier

message-submi ss ion-t ime M -/M -/M M/-

content-identifier 0 -/M -/M M/-

extensions 0 -/o -/o 0/-

or iginat ing-MTA-cert if icate 0 -/O -/O nO/-/ proof-of -submi ssion 0 -/o -/o 0/-

P r obeSubmi s s i on

ARGUMENT

envelope M M/- M/- -/M ProbeSubmi ssion

Envelope

prooe—suuini ss ion— i aenr i r i sr Tur n -/M -/M M/- See PI MTSIdentif ier

probe-submiss ion-time M -/M -/M M/-

content— 1 aent

i

e i er U -/M -/M M/-

CancelDeferredDeli very

ARGUMENT

message—submission—identi f ier M M/- M/- -/M See PI MTSIdentif ier

Submi s s 1 onCont rol

IV D r TurcKTm AKGUMTiNT

controls M -/M -/M M/- See Note 1

restrict 0 -/M -/M 0/-

permissible-operations 0 -/M -/M 0/-

permissible-maximum-contentlength 0 -/M -/M 0/-

permissible-lowest-priority 0 -/M —/II -/M 0/-

permi ss ible-secur i ty-context 0 -/o -/o 0/-

RESULT

waiting M M/- M/- -/M See Note 2 wai t i ng-oper at i ons 0 0/- 0/- -/M 0-16

waiting-messages 0 0/- 0/- -/M

waiting-content-types 0 0/- 0/- -/M 0-1024

waiting-encoded-informat ion- See PI Encoded

types 0 0/- 0/- -/M InformationTypes

56
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 4 of 12

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

MessageDel i very

ARGUMENT

M -/M -/M M/- MessageDeliveryEnve 1ope

content M -/M -/M M/-

RESULT

reciTDient—cert i f icate 0 0/- 0/- -/o

proof—of—deli very 0 0/- 0/- -/o

ReportDelivery

ARGUMENT

envelope M -/M -/M M/- ReportDeliveryEnvelope

returned—content 0 -/M -/M 0/-

Deli veryCont rol

ARGUMENT

controls M M/- M/- -/M See Note 3

restrict 0 0/- 0/- -/M

Dermi ss ible—onerat i ons 0 0/- 0/- -/M

permissible-maximum-contentlength 0 0/- 0/- -/M

permiss ible—lowest—prior ity 0 0/- 0/- -/M

permiss ible—content—types 0 0/- 0/- -/M

permiss ible—encoded— See PI Encoded

informat ion—types 0 0/- 0/- -/M InformationTypes

permi ss ible—secur i ty—context 0 0/- 0/- -/O

RESULT

wa i t i ng M -/M -/M M/- See Note 4 wa i t i ng—operati ons 0 -/M -/M 0/-

wai ting—messages 0 -/M -/M 0/-

wai t ing-content-types 0 -/M -/M 0/-

waiting-encoded-informat ion- See PI Encoded

types 0 -/M -/M 0/- Informati onTypes Register See Note 5 ARGUMENT

user-name 0 0/- 0/- -/o See X.411 , 8.4.1.1.1.1

user-address 0 0/- 0/- -/o

deliverable-encoded- See PI Encoded

informat ion-types 0 0/- M/- -/M Informat ionTypes

deliverable-maximum-contentlength 0 0/- M/- -/M

default-delivery-controls 0 0/- 0/- -/M

restrict 0 0/- 0/- -/M

57
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 5 of 12

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

permissible-operations 0 0/- 0/- -/M

permissible-maximiim-contentlength 0 0/- 0/- -/M

permissible-lowest-priority 0 0/- 0/- -/M

permi ss i ble—content—types 0 0/- 0/- -/M 1-1024

permi ss ible—encoded— See PI Encoded

information-types 0 0/- 0/- -/M InformationTypes

deli verable—content—types o 0/- M/- -/M 1-1024

labels-and-redi rect ions 0 0/- 0/- -/o 1-256

user-security-label 0 0/- 0/- -/o

recipient-assigned-alternaterecipient 0 0/- 0/- -/o

ChangeCredent lals MTS to MTSuser

ARGUMENT

old-credentials M -/M -/M M/- Note 8

simple 0 -/M -/M 0/-

strong 0 -/o -/o 0/-

new-credentials M -/M -/M M/- Note 8

simple 0 -/M -/M 0/-

strong 0 -/o -/o 0/-

ChangeCredent ials MTSuser to MTS

A T3 T TTurc^xim AKCjUMJiNT

old—credentials M M/- M/- -/M Note 8

s imple U 0/- 0/- -/M

strong u 0/- 0/- -/o

new-credentials M M/- M/- -/M Note 8

simple O 0/- 0/- -/M

strong 0 0/- 0/- -/o

Mes s ageSubmi s s i onEnve1 ope See Note 6

originator-name M M/- M/- -/M See ORName

or iginal-encoded-informat ion- See PI Encoded

types 0 M/- M/- -/M Informat ionTypes

content-type M M/- M/- -/M

built-in 0 0/- M/- -/M

external 0 0/- M/- -/M

content-identifier 0 0/- M/- -/M 1-16

priority 0 M/- M/- -/M All values

per-message-indicators 0 M/- M/- -/M

disclosure-of-recipients 0 0/- M/- -/M

58
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 6 of 12

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/Ref e r ences

i mpl i c i t -conver s i on-proh i b i t ed 0 M/- M/- -/M

alternate-recipient-allowed 0 M/- M/- -/M

content-return-request 0 0/- M/- -/H

deferred-delivery-time 0 M/- M/- -/M

extensions 0 M/- M/- -/M

recipient-reassignmentprohibited 0 0/- M/- -/M

d1 -expans i on-proh i b i t ed 0 M/- M/- -/M

conversion-wi th-lossprohibited 0 0/- M/- -/M

latest-deli very-time 0 0/- M/- -/M

originator-return-address 0 0/- M/- -/M

originator-certificate 0 0/- 0/- -/o

content-conf i dent i al i tyalgor i thm- i dent i f i er 0 0/- 0/- -/o

message-originauthent i cat i on-check 0 0/- 0/- -/o

message-secur i ty-label 0 0/- 0/- -/o

proof-of-submiss ion-request 0 0/- 0/- -/o

content-correlator 0 0/- M/- -/M

forwarding-request 0 0/- 0/- -/M MS Abstract Service only

PerRecipientMessageSubmission

Fields M M/- M/- -/M 1-32767

recipient-name M M/- M/- -/M See ORNeune

originator-report-request M M/- M/- -/M

expl i c i t -conver s i on 0 0/- M/- -/M

extensions 0 M/- M/- -/M

originator-requestedalternate-recipient 0 0/- 0/- -/O

£6(^Ut?D^t?Cl— X VTSLy-ilt€UliV^Q M/- M/- -/M Note 9

phys ical-forwardingprohibited 0 O/- M/- /yi phys ical-forwarding-addressrequest 0 0/- 0/- -/o

physical-delivery-modes 0 0/- 0/- -/o

registered-mail-type 0 0/- 0/- -/o

recipient-number-for-advice 0 0/- 0/- -/o

physical-rendition-attributes 0 0/- 0/- -/o

physical-delivery-reportrequest 0 0/- 0/- -/o

message-token 0 0/- 0/- -/o

content-integr i ty-check 0 0/- 0/- -/o

proof-of-deli very-request 0 0/- 0/- -/o

59
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 7 of 12

Support by: TDM J. trn

TTa MTA FIX r\ Protocol Element S U/ K Comments/References

ProbeSubnti ss ionEnvelope See Note 6

originator-name M M/n/- Pl/- -/PI See ORName

or iginal-encoded-informat ion- See PI Encoded

types 0 M/- n/ — M/- -/M InformationTypes

content-type M M/- -/M/M

built-in 0 O/- M/- -/M —/n 0-32767

external 0 n/_ u/

n/ — _/M -/n

content-identifier 0 O/- u/ — n/- M/- -/M —/PI 1-16

content-length 0 M/- n/- M/- pi/ — -/M —/PI 1-'7FFFFFFF'H

per-message-indicators 0 n/- -/PI /M

implicit-conversion-prohibited 0 M/- n/ — M/- -/M —/ Pi alternate-recipient-allowed 0 u/- n/- -/PI /M

extensions 0 M/- M/- -/M —/PI

recipient-reassignmentprohibited 0 O/- M/- -/M —/PI

dl-expans ion-prohibi ted 0 n/- n/- -/n/M

conversion-with-lossprohibited 0 u/- M/n/- -/M/M

originator-certificate 0 u/- nu/-/ -/u/n

message-security-label 0 u/- -/u/n

content-correlator 0 0/- M/- -/M

probe-origin-authenticationcheck 0 VJ/- -/u

PerRecipientProbeSubmission

Fields M n/- n/- _-/n/M 1-32767

recipient-name M pi/- n/ - _-/PI /M See ORName

originator-report-request M M/- M/- pi/ — -/M —/PI

exp1 i c i t -conver s i on 0 n/- M/- -/M —/PI 0-256

extensions 0 M/- M/- -/M —/II

alternate-recipient 0 0/- 0/- -/o

requested-deli very-method 0 M/- M/- -/M 0-256, Note 9

physical-rendition-attributes 0 0/- M/- -/M

MessageDeliveryEnvelope See Note 7 message-delivery-identifier M -/M -/M M/- See PI MTSIdentif ier

message-delivery-time M -/M -/M M/-

other-fields M -/M -/M M/-

content-type M -/M -/M M/-

built-in 0 -/M -/M M/- 0-32767

external 0 -/M -/M M/-

originator-name M -/M -/M M/- See ORName

60
Part 8: 1988 Message Handling Systems June 1991 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 8 of 12

Support by: IPM

UA MS MTA

Protocol Element S O/R O/R O/R Comment s/References —

original-encoded-informat ion- See PI Encoded

types 0 -/M -/M M/- InformationTypes

priority o -/M -/M M/- All values

delivery- flags 0 -/M -/M M/-

implicit—conversionprohibited O -/M -/M M/-

other-recipient-names 0 -/M -/M M/- See ORName

this—recipient—name M -/M -/M M/- See ORName

originally— intended—recipient

name O -/M -/M M/- See ORName

converted-encoded- in format ion- See PI Encoded

types 0 -/M -/M M/- InformationTypes

message—submission—time J, / M -/M -/M M/-

content-ident if ier 0 -/M -/M M/- 1-16

extensions o -/M -/M M/-

convers ion-with- lossprohibited 0 -/M -/M M/-

requested-de livery-method o -/M -/M M/- Note 9

physical— forwarding—

pron j.^6Q r\\J -/I M/-

pnysxcax lorwarci j.ny aciciress

request U -/i -/- M/-

physical—del ivery—modes r\U -/i -/- M/- 0-16

registered—mail—type U -/i -/- M/- 0-256

recipient—number— for— advice f-\ o -/i M/- 1-32

physical-rendition-attributes 0 -/:| -/- M/-

physical-delivery-reportrequest o -/i M/- 0-256

originator-return-address o -/i -/- M/-

originator-certificate o -/O 0/-

message-token 0 -/o -/o o/-

content-confidentialityalgorithm- identifier 0 -/o -/o 0/-

content- integrity-check 0 -/o -/o 0/-

message-originauthentication-check 0 -/o -/o 0/-

message-security- label o -/o -/o o/-

proof-of-de livery-request 0 -/o -/o 0/-

redirection-history o -/M -/M M/- 1-512

dl-expans ion-history 0 -/M -/M M/- 1-512

61
Part 8: 1988 Message Handling Systems June 1991 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 9 of 12

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

ReportDeliveryEnvelope See Note 7 subject-submiss ion-identifier M -/M -/M M/- See PI MTSIdentif ier

content-identifier 0 -/M -/M M/-

content-type 0 -/M -/M M/-

built-in 0 -/M -/M M/- 0-32767

external 0 -/M -/M M/-

or i g i nal -encoded- i nformat i on- See PI Encoded

types 0 -/M -/M M/- Informati onTypes extensions 0 -/M -/M M/-

message-secur i ty-label 0 -/o -/O 0/-

content-correlator 0 -/M -/M M/-

or iginator-and-DL-expans ion- See PI OriginatorAndDL

history 0 -/M -/M M/- Expans i onHi s t or

y

reporting-DL-name 0 -/M -/M M/-

report ing-MTA-cert if icate 0 -/O -/O 0/-

r epor t -or i g i n-authent i cat i on- check 0 -/o -/O 0/-

PerReci pi entReportDeli veryFields M -/M -/M M/- 1-32767

actual-recipient-neune M -/M -/M M/- See ORName

report M -/M -/M M/-

delivery 0 -/M -/M M/-

message-delivery-time M -/M -/M M/-

type-of-MTS-user 0 -/M -/M M/-

non-delivery 0 -/M -/M M/-

non-delivery-reason-code M -/M -/M M/-

non-delivery-diagnostic-code 0

/xs -/M -/M M/-

converted-encoded-informat ion- See PI Encoded

types 0 -/M -/M M/- Informati onTypes

originally-intended-recipientname 0 -/M -/M M/- See ORName

supplementary-information 0 -/M -/M M/- 1-256

extensions 0 -/M -/M M/-

redirection-history 0 —/n —/M M/- See PI Redirection

History, 1-512

physical-forwarding-address 0 -/M -/M M/-

recipient-certificate 0 -/o -/o 0/-

proof-of-deli very 0 -/o -/o 0/-

ORName MTS User to MTS

standard-attributes

country-name 0 M/- M/- -/ Count ryName

administration-domain-name 0 M/- M/- -/M DomainName

network-address 0 0/- 0/- -/M

terminal-identifier 0 0/- 0/- -/M

62
I Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 36 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 10 of 12

Support by: TDM

FTA \it\ MCno Protocol Element S Ki/ K <J/ K

private-domain-name 0 M/- M/_ n/ — _ /M

organization-name 0 n/ — n/- -/ri /M

nvuneric-user-identif ier 0 u/- U/- -/M

per sona1 -name 0 n/- -/n

surname M M/n/- n/- -/w/M

given-name 0 M/_ n/ — n/ — _-/n/M

initials 0 M/- n/ — M/_ n/ — _/M ~/n

generat ion-qual i f ier 0 n/- M/- -/n

organi zat ional-uni t-names 0 n/- Mn/-/_ _ /M

OrganizationUnitName M M/- M/- -/M

domain-defined-at tributes 0 M/ -/n

Domai nDef i nedAt t r i but e M M/- M/- -/M

type M n/- n/ — -/n/M

value M n/ — M/- -/M

extension-attributes 0 M/- M/- -/M

common-name 0 M/n/- n/- -/n/M

t e 1 et ex-common-name 0 0/- 0/- -/M

teletex-organi zat ion-name 0 M/- O/- -/M

telet ex-personal-name 0 M/- 0/- -/M

teletex-organi zat ional-uni t- names 0 M/- 0/- -/M

teletex-domain-def inedattributes 0 M/- 0/- -/M

pds-name 0 0/- 0/- -/M

physical-delivery-country-name 0 0/- 0/- -/M

postal-code 0 0/- 0/- -/M

physical-delivery-office-name 0 O/- O/- u/ — -/M

phys i cal-del i very-of f i ce- number 0 0/- 0/- -/M

extension-OR-addresscomponents 0 O/- O/- -/M

pnys icax—uex i very—personai—

name 0 0/- 0/- -/M

physical-deli veryorganizati on-name 0 n/_ u/- n/_ u/ - _/M —/n

extension—physical—deli very—

address-components 0 0/- 0/- -/M

unformatted-postal-address 0 0/- 0/- -/M

street-address 0 0/- 0/- -/M

post-office-box-address 0 0/- 0/- -/M

poste-restante-address 0 0/- 0/- -/M

uni que-pos t a1 -name 0 0/- 0/- -/M

local-postal-attributes 0 0/- 0/- -/M

extended-network-address 0 0/- 0/- -/M

terminal-type 0 0/- 0/- -/M

ORName MTS to MTS User

standard-attributes

country-name 0 -/M -/M M/- Count ryName

63
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 35 - Classification of the P3 Protocol Elements (continued)

MTS Access Protocol (P3) Part 11 of 12

Support by: IPM

UA MS MTA

e 0/R 0/R 0/R Comments/References

auiuim s u To u ion—aoiuain*-iiciin6 u -/M -/M M/- Doma i nName

116 cWOlK—aQQres s

r\

KJ -/M -/M M/-

L 1111 llaX~ 1 Clcll U 1 1. 1 x?l. r\\J -/M -/M M/-

pt 1 vate—aoiiia 1 11—nanie KJ -/M -/M M/- DomainName

Or yall 1 Z a 1 on—Ilaine KJ -/M -/M M/-

lllXlUt?! —Uotsl — 1 Ut;llU 1 L 1 6l -/M -/M M/-

p61 sonaX —ilain^ KJ -/M -/M M/-

s>Ui lloiu^ Mn -/M -/M M/-

-/M -/M M/-

J.11X 1^ XdXa KJ -/M -/M M/-

yt;llt?L d lOll—^UctX 1 1. 1 ^X. KJ -/M -/M M/-

oryaiii Zat^ loncix—uni r—najnes KJ -/M -/M M/-

Ul^alll ZaC IL/llUlll X^INalut? 1*1 -/M -/M M/-

Uv^iUOL X ii—Ux?X XXiC^U— cx XUU n -/M -/M M/-

UkJUIcL X llX/tf X X ll^Un L UX XUUI^C M -/M -/M M/-

type M -/M -/M M/-

Val U6 Mri -/M -/M M/-

ex^^ns 1 on—ax. u x i dux^6S KJ -/M -/M M/- ExtensionAttribute

^\^llllu\_/l 1 —1IdiU o -/M -/M M/-

u €1 61 6x—coiuiuon—najne U -/M -/M M/-

(.rCSXC UC7A—V^X l^aXl X ^ Cl U X V./11—IICUUV -/M -/M M/-

"hoi O ^ O r^O T" C/^Tl J* 1 r% arni^ Ll?Xt; L.t;X—]^T5X sl^liCIX—XXdlUt? KJ -/M -/M M/-

i-tsxts utsx—OX y diix xoxidx—uiix u —

XXdXl&%?o n -/M -/M M/-

V^X^IU^A U\_/XUC4 JL XX U^JLXXX^U

J*dwi" "f" UXT" TXUIXU^o Vill '1' AC n -/M -/M M/-

L^Uk> —XXClllly? -/O -/M M/-

^ixjf o Xwdx—ucfx X vtix jr —w<->u.xx c x _y —xxdxiiti -/o -/M M/-

n -/o -/M M/-

^IXjr o Xv^dX—vX^X X Vv7X jr —wX X X XXdXll^ n -/O -/M M/-

piijr a X Odx—U6X X vex y—Ox X 1 oe—

iiuiuijex n -/o -/M M/-

exueiis loii—Oxx—dQux ess — coniponen t s

r\

KJ -/o -/M M/-

physical-delivery-personalname 0 -/o -/M M/-

phys i cal-del i veryorgani zat ion-name 0 -/o -/M M/-

ext ens ion-phys i cal-del i veryaddress-components 0 -/o -/M M/-

unformatted-postal-address 0 -/o -/M M/-

street-address 0 -/o -/M M/-

post-office-box-address 0 -/o -/M M/-

poste-restante-address 0 -/o -/M M/-

unique-postal-name 0 -/o -/M M/-

local-postal-attributes 0 -/o -/M M/-

extended-network-address 0 -/o -/M M/-

terminal-type 0 -/o -/M M/-

64
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 36 - Classification of the P3 Protocol Elements (concluded)

MTS Access Protocol (P3) Part 12 of 12

Notes

1 The MTS-user may interpret any restriction as simply withhold

*all' submissions.

2 No explicit action needs to be taken by the MTA.

3 The MTA may interpret any restriction as simply withhold »all'

deliveries

.

4 No explicit action needs to be taken by the MTS-user.

5 The Register operation may be performed locally (see X.411).

Although not required for the UA for conformance, it is

considered to be a useful service and support is recommended.

6 The action to be taken by a submitting MTA is as defined in

X.411 (ISO 10021-4). In the absence of any specific processing

requirements for a particular element in a submission envelope,

the action to be taken is simply the faithful mapping of such

element to the corresp>onding element of the appropriate transfer

envelope.

7 The action to be taken by a delivering MTA is as defined in X.41

(ISO 10021-4). In the absence of any specific processing

requirements for a particular element in a delivery envelope, the

action to be taken is simply the creation of such element from

the corresponding element of the appropriate transfer envelope.

8 At least one of simple and/or strong must be specified.

9 Applies to ORNames containing Directory Names and/or ORAddresses

See Recommendation X.411, section 8.2.1.1.1.14.

65
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.4 MS Access Protocol (P7)

Table 37 - Classification of the P7 Protocol Elements

MS Access Protocol (P7) Part 1 of 6

Support by: IPM

UA

0/R

MS

Protocol Element S 0/R Comments/References

Operations

MSBind

MSUnbind

M

M

M/-

M/-

-/M

-/M

MSBind

MSSE

message-submission

probe—submi s s i on cancel-deferred-delivery

submission-control

M

M

M

M

M/-

n/-

0/-

-/M

-/M

—/PI

-/M

M/-

See P3 MessageSubmission

See P3 ProbeSubmission

See P3 CancelDeferred

Delivery

See P3 Submi ssionControl

MASE

register

change-credentials (MS to UA)

change-credentials (UA to MS)

M

M

M

0/-

-/M

0/-

-/M

M/-

-/M

See P3 Register

See P3 ChangeCredentials

See P3 ChangeCredentials

MRSE

summarize

list

fetch

delete

register-ms

alert

M

M

M

M

M

M

M/-

M/-

M/-

M/-

0/-

-/O

-/M

-/M

-/M

-/M

-/M

0/-

Summarize

List

Fetch

Delete

Register-MS

Alert

Arguments/Results

MSBind

ARGUMENT

MSBindArgument

initiator-name

initiator-credentials

simple

strong

security-context

fetch-restrictions

allowed-content-types

allowed-EITs

maximum-content-length

MS-configurat ion-request

M

M

M

0

0

0

0

0

0

0

0

M/-

M/-

M/-

M/-

0/-

0/-

0/-

0/-

0/-

0/-

0/-

-/M

-/M

-/M

-/M

-/o

-/o

-/M

-/M

-/M

-/M

-/M

66
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 37 - Classification of the P7 Protocol Elements (continued)

MS Access Protocol (P7) Part 2 of 6 Support by: IPM

UA MS

0c 0/R 0/R Comments/References

OFQFTT.T

M -/M M/-

rpfiriondpT*—prpdAni" i sis M -/M M/-

sxuipxc w -/M M/-

a u X \jn^ n -/O 0/-

CI V 61 X XAl-'X t?~CIU I* w CI V<» if X V/IAS ow -/M M/- 1-16

AVAX X AJJXc;"a L CX XL/UL'CS* i^jf^f^o -/M M/- 1-1024

Q -/M 0/-

-/M M/-

O ullUllu X X

5?iiTnTndri 7pArniiTnpni" M M/- -/M

X XXX. vyx xuA If X vyxx Jk^do ^ y o 0/- -/M Informat ionBase

OCXC^ L.V^X M M/- -/M Selector

summary-requests 0 0/- -/M 1-16

RESULT

O UxiUUAX X £ttH\X£o U X U M11 -/M M/-

n -/M M/-

M -/M M/- 1-«7FFFFFFF'H

0^Ail n -/M M/-

1 OVPQ fr M11 -/M M/-

Vi 1 nhPQ "f" 11 X ^11^9 M11 -/M M/-

a UxlilllA X X Co -/M M/- 1-16

absPTii" %i Jill/0 ^xx \^ 0 -/M M/- 1-'7FFFFFFF'H

0 -/M M/- 1-32767

t VD6 M -/M M/-

value M -/M M/-

count M -/M M/-

List

ARGUMENT

ListArgument M M/- -/M

informat ion-base-type 0 0/- -/M Informat ionBase

selector M M/- -/M Selector

requested-at tributes 0 M/- -/M AttributeSelection

RESULT

ListResult M -/M M/-

next 0 -/M M/-

requested 0 -/M M/- EntryInformat ion.

0_»7FFFFFFF'H

67
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 37 - Classification of the P7 Protocol Elements (continued)

MS Access Protocol (P7) Part 3 of 6 Support by? IPM

UA MS

Protocol Element S 0/R 0/R Comments/References

Fetch

ARGUMENT

FetchArgument M M/- -/M

information-base-type 0 0/- -/M Informat ionBase

item M W~ -/M

search 0 M/- -/M Selector

precise 0 M/- -/M

requested-at tributes 0 M/- -/M AttributeSelection

RESULT

M -/M M/-

entry-information 0 -/M M/- Entryinformat ion

list 0 -/M M/- 0-'7FFFFFFF'H

next 0 -/M M/-

Delete

ARGUMENT

DeleteArgument M M/- -/M

information-base- type 0 0/- -/O Informat ionBase

items M M/- -/M

selector 0 M/- -/M Selector

sequence-numbers 0 M/- -/M 1-'7FFFFFFF'H

RESULT

DeleteResult M -/M M/-

Register-MS

ARGUMENT

Regi s t e r -MSArgumen

t

M M/- _/M

auto-action-registrations 0 0/- -/O 1-1024

type M M/- -/M

registration- identifier 0 M/- -/M

registration-parameter M M/- -/M See auto action

registration parameters

auto—act ion—deregi st rat ions 0 0/- -/o 1-1024

type M M/~ -/M

registration-identifier 0 M/- -/M

list-attribute-defaults 0 M/- -/M 1-1024

fetch-attribute-defaults 0 M/- -/M 1-1024

change-credentials 0 M/- -/M Note 1

old-credentials M M/- -/M

new-credentials M M/- -/M

user-security-labels 0 0/- -/O 1-256

RESULT

Register-MSResult M -/M M/-

68
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 37 - Classification of the P7 Protocol Elements (continued)

MS Access Protocol (P7) Part 5 of 6 Support by: IPM

UA

0/R

MS

Protocol Element S 0/R Comments/References

Common Data Types

AttributeSelection

type

from

count

M

0

0

M/-

0/-

0/-

-/M

-/M

-/M

1-32767

1-32767

AttributeValueAssertion

type

value

M

M

M/-

M/-

-/M

-/M

Ent ryInformat i on

s equence-number attributes

type

values

M

0

M

M

-/M

-/M

-/M

-/M

M/-

M/-

M/-

M/-

1-1024

Filter

item

and

ornot

0

0

0

0

M/-

0/-

0/-

0/-

-/M

-/o

-/o

-/o

Filterltem

1-32

1-32

Filterltem

equality

substrings

type

strings

initial

any

final

greater-or-equal

less-or-equal

present

approximate-match

0

0

M

0

0

0

0

0

0

0

M/-

0/-

M/-

M/-

U/-

0/-

0/-

0/-

0/-

0/-

0/-

-/M

-/o

-/M

-/M

-/n

-/M

-/M

-/M

-/M

-/M

-/o

AttributeValueAssertion

(Support is 0 if Orname)

AttributeValueAssertion

AttributeValueAssertion

Informat ionBase

stored-messages

inlog

out log

0

0

0

M/-

0/-

0/-

-/M

-/o

-/o

70
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 37 - Classification of the P7 Protocol Elements (continued)

MS Access Protocol (P7) Part 4 of 6

Support by: IPM

UA MS

Protocol Element S 0/R 0/R Comments/References

Alert

ARGUMENT

AlertArgvunent M -/M M/-

alert-registration-identifier M -/M M/-

new-entry 0 -/M M/- Ent r vinformat ion

RESULT

AlertResult 0 M/- -/M

Auto Action Registration

Parameters

AutoForwardRegistrationParameter

filter 0 0/- -/M Filter

auto-forward-arguments M M/- -/M

originator-name M M/- -/M

content-identifier 0 0/- -/M

pr ior i ty 0 0/- -/M

per-message-indicators 0 0/- -/M See P3

deferred-delivery-time 0 0/- -/M

extensions 0 0/- -/M See P3

per-recipient-f ields M M/- -/M

recipient-name M M/- -/M

originator-report-request M M/- -/M

expl ici t-convers ion 0 0/- -/M

extensions 0 0/- -/M See P3

delete-after-auto-forwarding 0 0/- -/M

other-parameters 0 0/- -/M See Note 2 auto-forwarding-comment 0 0/- -/M

cover-note 0 0/- -/M

this-ipm-pref ix 0 0/- -/M

AutoAlertRegistrationPareuneter

filter 0 0/- -/M Filter

alert-addresses 0 0/- -/o

address M M/- -/M

alert-qualifier 0 0/- -/o

requested-at tributes 0 M/- -/M AttributeSelection

69
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 37 - Classification of the P7 Protocol Elements (concluded)

MS Access Protocol (P7) Part 6 of 6 Support by: IPM

UA

0/R

MS

Protocol Element S 0/R Comments/References

Range

sequence-number-range

from

to

0

0

0

0/-

0/-

0/-

-/M

-/M

-/M

creation-time-range

from

to

0

0

0

0/-

0/-

0/-

-/M

-/M

-/M

Selector

child-entries

range

filter

limit

override

ooooo 0

O

OO

o

1

1

t

1

1 -/M

-/M

-/M

-/M

-/M

Range

Filter

Notes

1 At least one of simple and/or

2 The specified syntax of otheronly - see X.413 section 12.1

strong must be specified,

-parameters is for IPMS use

and X.420 section 19.4.

71
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.5 Classification of the P1 Protocol Elements for Security Classes

The protocol element classifications used in tables 38 and 39 should be viewed as a delta to the lower' security class or, if there is no lower security class, to the kernel as classified in table 34. Thus, table 38

shows the additional support required in P1 to conform to security class S1 . Table 39 indicates the additional

support required to support security class S2 (above and beyond that for security class S1).

NOTES

1 There are no additional classifications for security class SO.

2 The addition of mandatory content confidentiality does not affect the P1 protocol.

Table 38 - Conformance Classification of the PI Protocol Elements for Security Class SI

MTS Transfer Protocol (PI) for Security Class SI Part 1 of 2 MT Kernel Static Support by MTS Class

Protocol Element

B/C

0/R

A

0/R Dyn Conunent s /Refe r ences MTABind

ARGUMENT

<SET>

initiator-credentials

simple

strong

bind-token

certificate

security-context

RESULT

<SET>

responder-credentials

simple

strong

bind-token

certificate

MessageTransferEnvelope

extensions

message-security-label

0/0

M/M

M/M

0/0

M/M

0/0

M/M

M/M

0/0

M/M

0/0

M/M

M/M

0/0

M/M

0/0

M/M

M/M

0/0

M/M

M

X

M

M

M

M

X

M

M

M

72
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 38 - Conformance Classification of the Pi Protocol Elements for Security Class Si

(concluded)

MTS Transfer Protocol (PI) for Security Class SI Part 2 of

MT Kernel Static Support by MTS Class

Protocol Element

B/C

0/R

A

0/R Dyn Comments/References

ReportTransferEnvelope

extensions

message-secur i ty-label

per-recipient-f ields

extensions

message-token

asynunet r i c-token

signed-data

message-security-label

encrypted-dat

a

message-security-label

bind-token

asymmetric-token

signature-algorithm-identifier

neune time

signed-data

encrypt ion-algor i thmidentif ier

encrypted-data

message-security-label

content-integr i ty-key

message-security-label

secur i ty-pol i cy- i dent i f i er

M/M

0/0

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

0/0

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

See Note 2

M

M See Note 2 See Note 2

See Note 1

M

M

M

M

M

M

See Note 2

Notes

1 In line with the CCITT MHS Implementors ' Guide, the asymmetric

token can be used by symmetric and asymmetric techniques as identified by the algorithm identifier.

2 The message security label may appear in any or all of the

indicated locations in the envelope. However the Security context

service applies only to the label in the "extensions" and/or token

signed-data as defined by the security policy in force. Labels in th

token encrypted data have only end-to-end (UA-to-UA) significance.

73
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 39 - Conformance Classification of the PI Protocol Elements for Security Class S2

MTS Transfer Protocol (PI) for Security Class S2 Part 1 of 2 MT Kernel Static Support by MTS Class

Protocol Element

B/C

0/R

A

0/R Dyn Comment s /Refe r ence

s

MessageTransferEnvelope

extension

originator-certificate

certificate

certification-path

message-origin-authenticationcheck

algorithm-identifier

content

content-identifier

message-security-label

ProbeTrans f erEnvelope

extensions

originator-certificate

certificate

certification-path

probe-origin-authenticationcheck

algor i thm-i dent i f i er content-identifier

message-security-label

ReportTransferEnvelope

extensions

report ing-MTA-certificate

certificate

certification-path

report-origin-authenticationcheck

algorithm-identifier

content-identifier

message-secur i ty-label

per-recipient

actual-recipient-name

originally-intended-recipientname

delivery

message-delivery-time

type-of-MTS-user

recipient-certificate

proof-of-deli very

non-delivery

non-delivery-reason-code

non-delivery-diagnostic-code

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

0/0

0/0

M/M

M/M

M/M

M/M

0/0

M/M

0/0

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

0/0

0/0

M/M

M/M

M/M

M/M

0/0

M/M

0/0

M

M

M

74
'art 8: 1988 Message Handling Systems December 1990 (Stable)

Table 39 - Conformance Classification of the Pi Protocol Elements for Security Class S2

(concluded)

MTS Transfer Protocol (PI) for Security Class S2 Part 2 of 2 MT Kernel Static Support by MTS CleISS

A

Protocol Element 0/R 0/R Dyn Comments/References

Certificate

version

serialNiimber

signature

algorithm

parameters

issuer

validity

notBefore

notAfter

subject

subjectPublicKeylnfo

algorithm

subjectPublicKey

M/M

M/M

M/M

M/M

0/0

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

0/0

M/M

M/M

M/M

M/M

M/M

M/M

M/M

M/M

75
Part 8: 1988 Message Haodling Systems

A.6 Classification of the P3 Protocol Elements for Security Classes

;

The protocol element classifications in tables 40, 41 , and 42 should be viewed as a delta to the lower)

security class or, if there is no lower security class, to the kerne! as classified in table 36. Thus, table 40' shows the additional support required in P3 to conform to security class SO. Table 41 indicates the additionali support required to support security class S1 (above and beyond that for security class SO). Table 42

indicates the additional support required to support security class S2 (above and beyond that for security

class SI).

NOTE - There are no dynamic conformance classifications required by security class SO (table 40). |

Table 40 - Conformance Classsfication of the P3 Protocol Elements for Security Class SO

MTS Access Protocol (P3) for Security Class SO Part 1 of 2 Static Support byj IPM

UA

0/R

MS

0/R

MTA

Protocol Element 0/R Dyn Comment s /Ref er ences MessageDelivery

RESULT

proof-of-deli very M/- M/- -/o

Mes s ageSubmi s s i onEnve 1 ope

PprRpsf C O JL Xi r>i L/ J, pntMpejcianpfiiiliTiii ^IJL ^1 ICO O ClU dip LI Jh/AU X O O iX on\JLjL Fields

extensions

message-token M/- M/- -/O

asymmetric-token M/- M/- -/o

signature-algorithmidentifier M/- M/- -/o

name M/- M/- „/0

time M/- M/- „/0

signed-data M/- M/- „/0

content-confidentialityalgorithm-identifier 0/- 0/- -/o

content-integrity-check M/~ M/- -/o See Note 1

message-security-label 0/- 0/- -/o

procf-of-deli very-request M/- M/- -/o See Note 1

message-sequence-number 0/- 0/- -/o

encryption-algorithmidentifier 0/- 0/- -/o

encrypted-data M/- M/- -/o

content-confidentialitykey 0/~ 0/- -/o

content-integrity-check M/- M/- -/o See Note 1

message-security-label 0/- 0/- -/o

content-integrity-key 0/- 0/- -/o

message-sequence-number 0/- 0/- -/o

content-integr i ty-check M/- M/- -/o See Note 1

proof-of-deli very-request M/- M/- -/o See Note 1

I

December 1990 (Stable^i

76
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 40 - Conformance Classification of the P3 Protocol Elements for Security Class SO

(concluded)

MTS Access Protocol (P3) for Security Class SO Part 2 of 2 Static Support by: IPM

UA MS MTA

Protocol Element 0/R 0/R 0/R Dyn Comments/References

MessageDeliveryEnvelope

other-fields

extensions

message-token -/M -/M 0/-

asymmetric-token -/M _/M 0/-

s ignature-algor i thmidenti f ier -/M -/M 0/-

name -/M -/M 0/-

time -/M -/M 0/-

signed-data -/M _/M 0/-

content -conf i dent i al i tyalgorithm-identif ier -/O -/o 0/-

content-integrity-check -/M -/M 0/- See Note 1

message-security-label -/O -/o 0/-

proof-of-deli very-request -/M -/M 0/- See Note l

message-sequence-number -/O -/O 0/-

encryption-algorithmidentifier -/o -/O 0/-

encrypted-data _/M -/M 0/-

cont ent-conf i dent i al i tykey -/O -/O 0/-

content-integrity-check -/M -/M 0/- See Note 1

message-security-label -/O -/O 0/-

content-integrity-key -/o -/O 0/-

mes s age-sequence-numbe r -/O -/o 0/-

content-integrity-check -/M -/M 0/- See Note 1

proof-of-deli very-request -/M -/M 0/- See Note 1

ReportDeliveryEnvelope

PerRecipientReportDeli veryFields

extensions

proof-of-deli very -/M -/O 0/-

Notes

1 Implementations shall generate no more that one instance of these

identically-named protocol elements in a single message.

77
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 41 - Conformance Classification of the P3 Protocol Elements for Security Class Si

MTS Access Protocol (P3) for Security Class SI Part 1 of 3 Static Support by: IPM

UA

0/R

MS

0/R

MTA

Protocol Element 0/R Dyn Comments/References

MTSBind MTS to MTS User

ARGUMENT

initiator-credentials M

simple -/o -/o 0/- X

strong -/M -/M M/- M

bind-token -/M -/M M/- M

certificate -/O -/O 0/-

secur i ty-context -/M -/M M/- M

RESULT

responder-credentials M

simple 0/- 0/~ -/O X

strong M/- M/- -/M M

bind-token M/- M/- -/M M

certificate 0/- 0/- -/o

MTSBind MTS User to MTS

ARGUMENT

initiator-credentials M

simple 0/- 0/- -/o X

strong M/- M/- -/M M

bind-token M/- M/- -/M M

certificate 0/- 0/- -/o

security-context M/- M/- -/M M

RESULT

responder-credentials M

simple -/o -/o 0/- X

strong -/M -/M M/- M

bind-token -/M -/M M/- M

certificate -/o -/O 0/-

Submi s s i onCont rol -/M M/M M/-

ARGUMENT

controls

permissible-security-context -/M -/M M/-

DeliveryControl M/- M/- -/M

ARGUMENT

controls

permissible-security-context M/- M/- -/M

Register ^ ARGUMENT

user-name M/- M/- -/M

labels-and-redirections

user-security-label M/- M/- -/M

78
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 41 - Conformance Classification of the P3 Protocol Elements for Security Class SI

(continued)

MTS Access Protocol (P3) for Security Class SI Part 2 of 3 Static Support by: IPM

UA

0/R

MS

0/R

MTA

Protocol Element 0/R Dyn Comments /References

ChangeCredentials MTS to MTSuser

ARGUMENT

old-credentials M

simple -/o -/o 0/- X

strong -/M -/M M/- M

bind-token -/M -/M M/- M

certificate -/o -/o 0/-

new-credentials M

simple -/o -/o 0/- X

strong -/M -/M M/- M

bind-token -/M -/M M/- M

certificate -/o -/o 0/-

ChangeCredentials MTSuser to MTS

ARGUMENT

old-credentials M

simple 0/- 0/- -/o X

strong M/- M/- -/M M

bind-token M/- M/- -/M M

certificate 0/- 0/- -/o

new-credentials M

simple 0/- 0/- -/o X

strong M/- M/- -/M M

bind-token M/- M/- -/M M

O/- n/- -/O

MessageSubmissionEnvelope

extensions

message-token M/- M/- -/M

signed-data

message-security-label M/- M/- -/M See Note 1 secur i ty-pol i cy- i dent i f i er M/- M/- -/M M

encrypt ed-data

message-security-label 0/- 0/- -/o

content— integr i ty—check M/- M/- -/M M

message-security-label M/- M/- -/M See Note 1 secur i ty-pol i cy- i dent i f i e r M/- M/- -/M M

MessageDeliveryEnvelope

extensions

message-security-label -/M -/M M/- See Note L security-policy-identifier -/M -/M M/- M

message-token -/M -/M M/-

signed-data

message-security-label -/o -/o 0/- See Note 1 encrypted-data

message-security-label -/o -/O 0/- See Note 1

79
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 41 - Conformance Classification of the P3 Protocol Elements for Security Class Si

(concluded)

MTS Access Protocol (P3) for Security Class SI Part 3 of 3

Static Support by: IPM

UA

0/R

MS

0/R

MTA

Protocol Element 0/R Dyn Comment s /Ref e r ence

s

ReportDeli veryEnvelope

extensions

message-secur i ty-label -/M -/M M/- M See Note 1

bind-token

asymmetric-token

signature-algorithm-identifier

name

time

signed-data

encrypt ion-aIgor i thmidentif ier

encrypt ed-dat

a

message-secur i ty-label

content-integr i ty-key

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

-/M

M/-

M/-

M/-

M/-

M/-

M/-

M/-

M/-

M

M

M

M

Notes

1 The message-security-label may appear in any or all of the indicated

locations in the envelope. However, the security labelling context

services apply only to the label in the "extensions" field. Labels in th

message token have only end-to-end (UA-to-UA) significance.

80
I Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 42 - Conformance Classification of the P3 Protocol Elements for Security Class S2

MTS Access Protocol (P3) for Security Class S2 Part 1 of 2 Static Support by: IPM

UA

0/R

MS

0/R

MTA

Protocol Element 0/R Dyn Comments/References

... MessageSubmission

RESULT

extensions

or i ginating—MTA—cert i f icate -/M -/O M/-

certificate -/- -/o -/-

certification-path -/- -/o -/-

proof-of-submission -/M -/o M/-

MessageDeli very

RESULT

recipient-certificate TUT / M/- M/- -/o

certificate M/— TUT / M/- -/M

certification-path M/- M/- -/M

MessageSubmi ss ionEnvelope

extensions

or iginator-certi f icate M/- 0/- -/M

certificate -/- -/o -/-

certification-path -/- -/o -/-

message-originauthent i cat ion-check M/- 0/- -/M M

algorithin-identi f ier M/- M/- -/M

content M/- M/— /TUT -/M

content — i dent i f i e r M/— M/— -/M

message-secur i ty-label M/- M/- -/M

proof-of-submission-request M/- 0/- -/M

ProbeSubmiss ionEnvelope

extensions

originator-certificate M/- 0/- -/M

certificate -/- -/o -/-

certification-path -/- -/o -/-

probe-origin-authenticationcheck M/- 0/- -/M M

algor i thm-i dent i f i er M/- M/- -/M

content -identifier M/- M/- -/M

message-security-label M/- M/- -/M

81
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 42 - Conformance Classification of the P3 Protocol Elements for Security Class 82

(concluded)

MTS Access Protocol (P3) for Security Class S2 Part 2 of 2 Static Support by: IPM

UA

0/R

MS

0/R

MTA

Protocol Element 0/R Dyn Comments/References

MessageDeliveryEnvelope

extensions

originator-certificate -/M -/M M/-

certificate -/M -/M M/-

certification-path -/M -/M M/-

message-originauthent i cat ion-check -/M -/M M/- M

algorithm-identifier -/M -/M M/-

content -/M -/M M/-

content-identifier -/M -/M M/-

message-security-label -/M -/M M/-

ReportDeliveryEnvelope

extens ions

report ing-MTA-certificate -/M -/O M/-

certificate -/- -/o -/-

certification-path -/- -/o -/-

report-origin-authenticationcheck -/M -/o M/- M

PerRecipientReportDeli veryFields

extensions

recipient-certificate -/M -/M 0/-

certificate -/M -/M M/-

certification-path -/M -/M M/-

Certificate

version -/M -/M M/-

senax IN uniD6 r -/M /TUT TUT n/-/ signature -/M -/M M/-

algorithm -/M -/M M/-

parameters -/o -/o 0/-

issuer -/M -/M M/-

validity -/M -/M M/-

notBefore -/M -/M M/-

notAfter -/M -/M M/-

subject ^ -/M -/M M/-

sub jectPublicKeyInfo -/M -/M M/-

algorithm -/M -/M M/-

sub jectPublicKey -/M -/M M/-

82
Part 8: 1988 Message Handling Systems December 1990 (Stable)

I Table 43 presents the classification delta to classification tables 40, 41, and 42, for the addition of

'j mandatory content confidentiality in the static conformance classification.

NOTE - There are no dynamic conformance classification required by the addition of content

confidentiality.

Table 43 - Conformance Classification of the P3 Protocol Elements for Security Classes SOa, SI a, or S2a

MTS Access Protocol (P3) for Security Classes SOa, Sla, S2a Part 1 of 1

TDM

no ni A

U/ I\ L/yii Comments/References

nes s ay 6buDID 1 5 s 1 onj!inve Xops

algorithm-identifier M/- 0/- -/o

message-token

asymmetric-token

signed-data M/- -/- -/-

conten t-conf i dent i al i tyalgorithm-identif ier M/- -/- -/-

encrypted-data

content-confidentialitykey M/- -/- -/-

MessageDeliveryEnve1ope

extensions

message-token -/M -/M 0/-

asymmetric-token

signed-data -/M -/M -/-

content-conf i dent i al i tyalgorithm-identif ier -/M -/M -/-

encrypted-data

content-confidentialitykey -/M -/M -/-

content-confidentialityalgorithm-identifier -/M -/M 0/-

Notes

1 Implementors shall generate no more than one instance of

identically named protocol elements in a single message.

these

A.7 Classification of the P7 Protocol Elements for Security Classes

j The protocol element classifications in table 44 should be viewed as a delta to the lower security class

or, if there is no lower security class, to the kernel as classified in table 37. Thus, table 44 shows the

I additional support required in P7 to conform to security class 31

NOTES

83
Part 8: 1988 Message Handling Systems December 1990 (Stable)

1 There are no additional classifications for security classes SO and S2.

2 The addition of nnandatory content confidentiality does not affect the P7 protocol.

Table 44 - Conformance Classification of the P7 Protocol Elements for Security Class 81

MS Access Protocol (P7) for Security Class SI Part 1 of 1 Static Support by: IPM

UA

0/R

MS

Protocol Element 0/R Dyn Comments/References

MSBind

ARGUMENT

initiator-credentials M

simple 0/- -/O X

strong M/- -/M M

bind-token M/- -/M M

certificate 0/- -/O

security-context M/- -/M M

RESULT

responder-credentials M

simple -/O 0/- X

strong -/M M/- M

bind-token , -/M M/- M

certificate -/o 0/-

Register-MS

ARGUMENT

Register-MSAr gumen

t

changeCredent ials M

old-credentials M/- -/M M

simple 0/- -/o M

strong M/- -/M X

bind-token M/- -/M M

certificate 0/- -/O

new-credentials M/- -/M M

simple 0/- -/o X

strong M/- -/M M

bind-token M/- -/M M

certificate 0/- -/o

user-security-labels M/- -/M M

message-security-label

secur ity-pol icy- i dent i fier M/- -/M M

security-classification M/- -/M

privacy 0/- -/o

security-categories M/- -/M

84
Part 8: 1988 Message Handling Systems September 1991 (Stable)

A.8 Message Store General Attribute Support

Table 45 - Classification of the Message Store General Attributes

Message Store General Attribute Support Part 1 of 2 Support by; IPM

UA

Rec

Bas

MS

Org

IPM

MS

Attribute s Org Comments/References

chi Id—sequence—numbers M M M M

content M M M M

content—conf i dent i al i t v—

al aciT i t"hin— i dAnt i f i at 0 0 0 0

content—cor relator 0 0 0 M

cr>n t" pnt — i dpnt i f i p r 0 o o M

content-intear i tv—check 0 0 0 0

content—lenath 0 o ow M

content—returned 0 0 0 M

content—t vise M M M M

convers ion—wi th—loss—prohibi ted 0 0 0 M

converted-eits 0 0 0 M

creat ion-time M M M M

del i vered—ei t

s

0 0 H M

delivery—flags 0 0 6 M

dl—expansion—history 0 0 0 M

entry—status M M M M

entry-type M M M M

int ended-reci pi ent-neune 0 0 0 M

message-delivery-envelope M M M M

message—deli very— i dent i fier r\U 0 0 M

message-del i very-1 i me 0 0 0 M

message-origin-authenticationcheck 0 0 0 0

message-secur i ty-label 0 0 0 0

message-submi ss ion-t ime 0 0 0 M

message-token 0 0 0 0

original-eits 0 0 0 M

originator-certificate 0 0 0 0

originator-name 0 0 0 M

other-recipient-names 0 0 0 M

parent-sequence-number M M M M

per-recipient-report-deli veryfields M M M M

priority 0 0 H M

proof-of-del i very-request 0 0 0 0

redirection-history 0 0 0 M

report-delivery-envelope M M M M

report ing-dl -name 0 0 0 H

report ing-mta-certificate 0 0 0 6

85
Part 8: 1988 Message Handling Systems September 1991 (Stable)

Table 45 - Classification of the Message Store General Attributes (concluded)

Message Store General Attribute Support Part 2 of 2 Support by: IPM

UA

Rec

Bas

MS

Org

IPM

MS

Attribute S Org Comments/References

report-origin-authenticationcheck

security-classification

sequence-number

subject-submission-identifier

this-recipient-name

0

0

M

M

0

0

0

M

M

0

0

0

M

M

0

0

0

M

M

M

Note - Enhanced MS support for optional Functional Groups is for

further study. Attributes which are relevant to these areas are currently specified as Unsupported.

f

86
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.9 Classification of the IPM MS General Attributes for Security

Classes

The classification of tfie attributes in table 46 is a delta to the MS General Attributes classified in table 38. Table 46 indicates the additional attributes that must be supported in the IPM MS for each of the security

classes. There is no support required for security attributes in the basic MS.

Table 46 - IPM MS Security Attribute Support

Security Class

Attribute SO SOa SI Sla S2 S2a

content-conf i dent i al i ty-algor i thmidentif ier 0 M 0 M 0 M

content- integrity-check M M M M M M

message-secur i ty-label 0 0 M M M M

message-orig in-authentication-check M M M M M M

message-token M M M M M M

origination-certificate 0 0 0 0 M M

proof-of-delivery M M M M M M

report ing-mta-certificate 0 0 0 0 M M

report-origin-authentication-check 0 0 0 0 M M

security-classification 0 0 M M M M

87
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.10 Message Store IPM Attribute Support

This clause is to be read in accordance with Annex C of X.420 (1988).

Table 47 - Classification of the Message Store IPM Attributes

Message Store IPM Attribute Support Part 1 of 2 Support by: IPM

UA

Rec

IPM

MS

Attribute S Org Comments/References

Summary Attributes:

ipm-entry-type 0 0 M

ipm-synopsis 0 0 M

Heading Attributes:

author i zing-users 0 0 M

auto-forwarded 0 0 M

bl ind—copy—r ec i pi ent s 0 0 M

copy-recipients 0 0 M

expiry-time 0 0 M

heading M M M

importance 0 0 M

incomplete-copy 0 0 0

languages 0 0 M

nrn-requestors 0 0 M

obsoleted-ipms 0 0 M

originator 0 0 M

primary-recipients 0 0 M

related-ipms 0 0 M

replied-to- ipm 0 0 M

reply-recipients 0 0 M

reply-requestors 0 0 M

reply-time 0 0 M

rn-requestors 0 0 M

sensitivity 0 0 M

subject 0 0 M

this-ipm M M M

Body Attributes:

bilaterally-def ined-bodyparts 0 0 0

body M M M

encrypted-body-parts 0 0 0

encrypt ed-dat

a

0 0 0

encrypt ed-parameters 0 0 0

extended-body-part-types 0 0 0

88
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Table 47 - Classification of the Message Store IPM Attributes (concluded)

Message Store IPM Attribute Support Part 2 of 2 Support by: IPM

UA

Rec

IPM

MS

Attribute S Org Comments/References

g3-facsimile-body-parts 0 0 0

g3-facsimile-data 0 0 0

g3-facsimile-parameters 0 0 0

g4-classl-body-parts 0 0 0

ia5-text-body-parts 0 0 M

ia5-text-data 0 0 0

ia5- text-parameters 0 0 0

message-body-parts 0 0 M

message—Qat

a

u 0 0

message-parameters 0 0 0

mixed-mode-body-parts 0 u U

nationally-def ined-body-parts 0 0 0

telet ex-body-parts 0 0 0

teletex-data 0 0 0

telet ex-parameters 0 0 0

videotex-body-parts 0 0 0

videotex-data 0 0 0

videotex-parameters 0 0 0

voice-body-parts 0 0 0

voice-data 0 0 0

voice-parameters 0 0 0

Notification Attributes:

acknowledgment -mode 0 0 M

auto-forward-comment 0 0 M

conve r s i on-e its 0 0 M

discard-reason 0 0 M

ipm-prefer red-recipient 0 0 M

ipn-originator 0 0 M

non-receipt-reason 0 0 M

receipt-time 0 0 M

returned-ipm 0 0 0

sub ject-ipm M M M

suppl-receipt-inf

o

0 0 0

89
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.11 EDI Messaging Service Protocol (Pedi)

See Working Document.

90
Part 8: 1988 Message Handling Systems December 1990 (Stable)

A.I 2 Message Store EDIMS Attribute Support

See Working Document.

91
Part 8: 1988 Message Handling Systems December 1990 (Stable)

Annex B (normative)

List of ASN.1 Object Identifiers

B.I Content Types

See Working Document.

B.2 Body Part Types

See Working Document.

B.3 Security Classes

Tlie ASN.1 expressed in figure 15 defines the security Object Identifiers specified by these Implementation

Agreements. These are the same as defined in the EWOS/ETSI A/3311 profile.

id-mhs-security OBJECT IDENTIFIER ::= { iso (1)

identif ied-organization (3) ewos (16) eg (2) mhs (4) security (4) }

id-policy- id

id-category- id

OBJECT IDENTIFIER

OBJECT IDENTIFIER — Security Policy Object Identifiers —

secur ity-class-0

security-class-Oa

secur ity-class-1

security-class-la

secur ity-class-2

secur ity-class-2a

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER — Security Category Object Identifiers —

private-id

confidence-id

coittmercial-in-conf idence-id

management -in-confidence-id

per sonal-in-conf idence-id

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER

OBJECT IDENTIFIER

;= f id-mhs-security 1 ) ;= { id-mhs-security 2 }

= { id-policy-id 0 } = { id-policy-id 0 1}

= { id-policy-id 1 ) = f id-policy-id 11}

= { id-policy-id 2 } = { id-policy-id 2 1}

= { = {

:[

= {

id-category-id 0

id-category-id 1 id-category-id 2 id-category-id 3 id-category-id 4

Figure 15 - Security Object Identifiers

92
Part 8: 1988 Message Handling Systems June 1991 (Stable)

Annex C (informative)

Interpretation of Elements of Service

The ob)0CtiV0 <rf thl$ 0iaU$Q ^ to ptct^lxi^ clarlflc nctlonaltty of Elements cA Service where the MHS standards are unclesK- c ..^^nt of this clause to define

how iftformaSott should 1)0 msd^ av^M^e or pi ->.^. .w- , .or is it Intended to define how

iindfvlduai vendoi^ should design th^ productSx

The ft^ov^g MHS Bemerrts of Ser^fee require ftjrther text to be added to their deBnitlons to represent

the prcp:i$ed imj^erri^^tion of iti6$e vio$: for <Jo»fOfm$tio$ to this Agreemer^t

Q€»nent$ of Service wNc^ are fiOt referet^ced m tliis clause are as defined m the IVIHS base standards*

Ref^ Request Indlcatictfi: The re^^'feclpFerts and the reply-^lme may tje ^ctSed wlthotrt any explicit

reply being requested. This n^ay b^ inti^preted by the feolptent as an Implicit rei^y reciuest.

NO" " ' an arfo^arwarded massage, an 'explicit or Jmplldt r^ly request may nor be meaningful.

Forwarded tP-meseage indloatlcmt The Ibliovt^ng use of the orlQlnat encoded Information t/pe In the

context of forwarded messages Is dteirifled;

a) Ttie encoded Infonmtlon types of 8he message b^ng forwarded shcHJid be rejected in the

new otiglnal encoded Infc^ntatlon types b^lng generated^

b) forwarding a ptlvatety defined body part (see figure 4), the originator of the forwarding

rnessage €^all set ibe c^iglnal encoded Information t^s in the PI envelope to Underfined for

93
Part 8: 1988 Message Handling Systems June 1991 (Stable)

Annex D (informative)

Recommended Practices

This clause provides guidelines on areas not addressed by the base standards. These guidelines have

been produced in order to promote awareness of interim solution to problems as agree by members of the OIW X.400 SIG. However implementors of these recommended practices should note that it is not necessary to follow the recommended practices when claiming conformance to these agreements.

Implementors should also note that future standardization by CCITT and ISO/IEC on area covered by

this clause may result in different solutions to those proposed in this clause.

D.I Printable String

There are existing mail systems that include a small set of non-Printable String characters in their

identifiers. For these systems to communicate with MHS systems, either for pass-through service or

delivery to MHS users, gateways will be employed to encode these special characters into a sequence

of Printable String characters. This conversion should be performed by the gateway according to a common scheme and before insertion in Domain Defined Attributes, which are intended to carry

electronic mail identifiers. MHS UAs may also perform such conversions.

It is recommended that the following symmetrical encoding and decoding algorithm for non-Printable

String characters be employed. The encoding algorithm maps an ASCII representation to a

PrintableString representation. Any non-printable string characters not specified in table 50 are covered

by the category "other".

Table 50 - Printable String to ASCII Mapping

ASCII Character Printable String Character

% (percent) (P)

@ (at sign) (a)

! (exclamation) (b)

" (quote mark) (q) _ (underline) (u)

( (left paren.) (1)

) (right paren.

)

(r)

other (3DIGIT)

where 3DIGIT has the range 000 to 377 and is interpreted as the octal encoding of an ASCII character.

To encode an ASCII representation to a PrintableString, table 50 and the algorithm in figure 16 should be

used.

94
Part 8: 1988 Message Handling Systems December 1990 (Stable)

IF current character is in the encoding set THEN

encode the character according to table 50

ELSE

write the current character;

continue reading;

Figure 16 - ASCII to PrintableStrIng Algorithm.

To decode a PrintableString representation to an ASCII representation, table 50 and the algorithm in figure 17 should be used.

IF current character is not THEN

write character

ELSE

{

look ahead appropriate characters;

IF composite characters are in table 50 THEN

decode per table 50

ELSE

write current character;

}

continue reading;

Figure 17 - PrintableString to ASCII Algorithm.

D.2 Rendition of lASText

The characters that may be used in an lASString are the graphic characters (including Space), control

ll characters and Delete of the IA5 character repertoire ISO 646.

The graphic characters that may be used with a guaranteed rendition are those related with positions

2/0 to 2/2, 2/5 to 3/15, 4/1 to 5/10, 5/15 and 6/1 to 7/10 in the basic 7-bit code table.

I' The other graphic characters may be used but have no guaranteed rendition.

The control characters that may be used but have no guaranteed effect are a subset consisting of the

j format effectors 0/10 (LF), 0/12 (FF) and 0/13 (CR) provided they are used in one of the following

combinations as defined in table 51.

Table 51 - Interpretation of Format Effector Combinations.

Combination Interpretation

CR LF

CR FF

LF . . LF

to start a new line

to start a new page (and line)

to show empty lines (always after one of the

preceding combinations).

The other control characters or the above control characters in different combinations may be used but

95
Part 8: 1988 Message Handling Systems

have no guaranteed effect.

December 1990 (Stable)

The character Delete nnay occur but has no guaranteed effect. The lASString in a P2 lASText BodyPart

represents a series of lines which may be divided into pages. Each line should contain from 0 to 80

graphic characters for guaranteed rendition. Longer lines may be arbitrarily broken for rendition. NOTE - X.408 states that for conversion from lASText to Teletex, the maximum line length is 77

characters.

D.3 EDI Use of MHS

D.3.1 Introduction and Scope

This clause presents a carry-forv\^ard of the Recommended Practices in Part 7 of the OIW Stable

Implementation Agreements for support of EDI data transfer in an MHS (1988) environment. These

recommended practices outline an interim procedure for use in transferring EDI transactions between

trading partner applications in order to facilitate further MHS implementation by EDI users. It is the

stated objective of the OIW X.400 SIG to migrate towards the CCITT target solution of P^di once it is defined (currently expected to be completed by late 1990). The approach for carrying EDI interchanges over MHS systems as recommended in this clause provides a mechanism for a smooth migration to the

target CCITT P^d, solution.

The scope of this guideline is to describe specific recommended practices for extending MHS as a data

transfer mechanism between EDI applications. This interim solution, as in the existing X.400 (1984)

Agreements, is referred to as the PO approach and differs slightly from the European solution which uses a P2 mechanism to package the EDI data stream. However, if adhered to, PO messages may be

delivered to P2 recipients and vice-versa, by the MTA making a minor envelope conversion as recommended in this clause.

li

D.3.2 Model

The model used is consistent with that defined in clause 7.12.5 of the Agreements for X.400 (1984)

systems, with several minor exceptions. As before, the model provides for a peer-to-peer EDI Messaging (EDIM) UA service.

EDI User

Application

EDIM

UA

MTS EDIM

UA

EDI User

Application

Figure 18 - EDI Messaging Functional Model.

In figure 18, the EDIM UA may support delivery of EDI messages formatted according to the OIW PO

96
Part 8: 1988 Message Handling Systems December 1990 (Stable)

(1988), PO (1984), P2 (1984) or P22 (1988) Agreements. It is recommended that implementations

supporting EDI over MHS generate PO formatted messages as described below, but be prepared to

deliver any of tlie four recognized formats for which Agreements have been achieved. Whether the EDI

transaction is carried using the PO or P2 (1988 or 1984) approaches, the EDI content is restricted to be

only one EDI interchange per MHS message. The OIW approach carries forward the 1984 X.400

recommended practices as a interim intenvorking solution. The use of object identifiers in either the EIT

or Content Type fields is not recommended due to the current definition of the 1984 interworking rules specified in CCITT Recommendation X.419 (see clause 3.3 of annex C).

The EDIM UA must support the essential MT and MS Elements of Service as defined in this Agreement.

It is recognized that a Message Store may not convey much information to a remote EDIM UA with the

PO approach. It is further recognized that MS Elements of Service are not necessarily made available by

the EDIM UA to the EDI user application.

D.3.3 Protocol Elements Supported for EDI

The following PI protocol elements will be used as a minimum to support EDI applications:

Content Type: For EDIM applications, the content type will continue to be as specified in clause 7.12.5.3

of the OIW Stable Agreements for X.400 (1984), i.e.. Undefined (0). The interchange contained in the PI envelope and identified by this Content Type is carried as an octet string.

NOTE - For intenworking with 1984 X.400 systems, the use of an externally registered object identifier is not recommended. Such use would create interworking problems as well as loss of information when the X.419 downgrading rules are applied. In the current definition of the latter, an object identifier would be

mapped to the Content Type value of 1 (External), instead of 0 (Undefined). Additionally, the downgrading

rules require the object identifier value to be inserted into the Content, which would cause further intenworking problems since 1984 EDIM UAs will expect only the EDI interchange in the Content.

Original Encoded Information Types (EITs): EDIM applications will continue to use the EITs as specified

in clause 7.12.5.3 of the OIW Stable Agreements for X.400 (1984), i.e., IA5Text and Undefined (for EBCDIC encoding). However, it is recognized that any EIT defined in the 1988 MHS standards may be

used to specify the encodings of the EDI content. NOTE - For interworking with 1984 X.400 systems, the use of an externally registered object identifier signify the EDI encoding is not recommended. According to the current definition of the downgrading

rules in CCITT Recommendation X.419, a 1988 MTA must downgrade an object identifier to Undefined and

then discard the object identifier. Such loss of EDI encoding information conflicts with the existing

Agreements for X.400 (1984) systems that the semantics of the Undefined EIT is always EBCDIC.

D.3.4 Addressing and Routing

As in the Stable Implementation Agreements for X.400 (1984), EDI messages entering a 1988 MHS

environment will need to have MHS 0/R Names and/or 0/R Addresses in the PI envelope to identify

the originator and recipient trading partners. The mapping of the EDI originator and recipient

interchange addresses to an 0/R Name or 0/R Address may be achieved either by local means or through services provided by the OSI Directory (see part 9, clause 1).

97
Part 8: 1988 Message Handling Systems December 1990 (Stable)

If the EDI message Is originated and delivered without transitting a X.400 (1984) MTA, then any of the

0/R Address forms specified in this Agreement may be used. However, since it cannot be assumed

that EDI messages will never transit an X.400 (1984) MTA, it will often be useful to include additional

Domain Defined Attributes as specified in clause 7.12.5.4 of the Stable Agreements. This DDA is needed

to ensure that a message is deliverable to an EDIM UA associated with a X.400 (1984) MTA and that delivery and receipt reports can be flagged as a new report type.

D.4 Textual Representation of 0/R Names

See Working Document.

D.5 ODA Transfer

See Working Document.

D.6 Use of Externally Defined Body Part

The Externally Defined Body Part allows the identification of various types of information exchanged

between UAs. This capability allows a UA on reception to recognize the appropriate application to process the information, e.g., to automatically invoke the application. It also allows the MTS to possibly convert from one type to another (e.g., to convert a word-processing document to ODA). For example, a

spreadsheet application on a personal computer from vendor A by operating system X can send via

X.400 to the UA on workstation from vendor B using operating system Y, and the latter will be able to recognize and possible invoke the appropriate spreadsheet application to process the data.

The Externally Defined Body Part definition is reproduced in figure 19.

98
Part 8: 1988 Message Handling Systems December 1990 (Stable)

External lyDefinedBodyPart

parameters

data

ExternallyDef inedParameters

External lyDefinedData

EXTERNAL

direct-reference

indirect-reference

data-value-descriptor

encoding

single-ASNl-type

octet-aligned

arbitrary

SEQUENCE {

[0] ExternallyDef inedParameters OPTIONAL,

ExternallyDef inedData }

EXTERNAL

EXTERNAL

[UNIVERSAL 8] IMPLICIT SEQUENCE {

OBJECT IDENTIFIER OPTIONAL,

INTEGER OPTIONAL,

ObjectDescriptor OPTIONAL,

CHOICE {

[0] ANY,

[1] IMPLICIT OCTET STRING.

[2] IMPLICIT BIT STRING } }

Note - In the case of transfer of EXTERNAL in P2 BodyPart, the

direct-reference component is mandatory and the indirect-reference and

data-value-descriptor components must be absent.

Figure 19 - Externally Defined Body Part Definition.

The following recommends how to use the components of this BodyPart:

a) Use of Parameters component: In simple cases, to ease the integration of applications to X.400 systems, the Parameters component need not be used;

b) Use of Data component: For each different format of data, different Object Identifiers for the

Data component are recommended. If an application chooses to use ASN.1 to format the data

to achieve a single representation across platforms, the single-ASN1-type encoding choice

should be used. OtheoA/ise:

1) The octet- (i.e., byte) aligned choice is used if the data format is octet-aligned;

2) The arbitrary choice is used if the data is bit-aligned;

c) Assignment of Object Identifiers: Object Identifiers need to be assigned for the EXTERNALS,

and these identifiers for the Parameters and Data components should be different. The Object

Identifier for an EXTERNAL also indicates the syntax of the data encoding, i.e., whether singleASNl-type or octet-aligned or bit-aligned is being used.

NOTE - Whether the Object Identifier needs to be present in this case is for further study.

There are many ways to obtain object identifiers. One such way is described as follows:

a) The application provider obtains a unique Numeric Name form for their organization from

ANSI, as described in ANSI ISSB 840 and ISSB 843, and appends this number form to {iso (1) member-body (2) US (840)} to form an object identifier denoting their organization.

b) The application provider (organization) allocates a series of numbers to identify the

application data format; these numbers are appended to the object identifier constructed in step

99
Part 3: 1933 Message Handling Systems December 1990 (Stable)

(i) to form an object identifier that is globally unique. It Is recommended that the application

provider (organization) use a hierarchical structure for identifying their data types to ease the

administration of the identifiers.

For example, company PCSoftware Inc. obtains the organization number "999" from ANSI. The

PCSoftware Spreadsheet file for MS-DOS might be assigned the following object identifier.

NOTE - ASN.1 notation is used. The numbers in parentheses form the identifier, the associated words

describe the number.

{ iso (1) member-body (2) US (840) PCSoftware Inc. (999) J^S-DOS-Application (1) Spreadsheet

(3) Data (1) }

Since the Spreadsheet data format for MS-DOS does not follow ASN.1 encoding rules and is octet- aligned, the encoding choice for the Data EXTERNAL is octet-aligned.

It is also recognized that not ail objects will be registered as indicated above. In order to transfer unregistered data, It is recommended that they be transferred in the BilaterallyDefinedBodyPart.

It is recommended that a 1988 system be able to support the Undefined Body Part (14), if it also

supports Extended Body Parts. This is in order to facilitate inter-working with 1984 systems.

100
iPart 8: 1988 Message Handling Systems December 1990 (Stable)

'Annex E (informative)

Secure Messaging Guidelines

E.I Introduction

The purpose of the security functional group Is to define an approach to the provision of secure messaging

with Message Handling systems within the general framework of these Implementation Agreements.

E.2 Message Handling Vulnerabilities

The message handling vulnerabilities (threats) which can be protected using security measures are defined

In Annex D (Security Threats) to Recommendation X.402 (1988):

b) Message sequencing;

c) Modification of information;

d) Denial of service;

e) Repudiation;

«

f) Leakage of information.

I Other specific threats exist if there is a failure to maintain information separation, which includes:

a) Manipulation;

b) Misrouting.

Some of these threats are defined in ISO standard IS 7498, OSi Reference Model, Part 2: Security

Architecture. The ISO standard also specifies other threats, not all of which are relevant to message handling

Annex D to CCITT Recommendation X.402 (1988) also indicates which MHS security services may provide

protection against such threats.

Some threats to message handling systems cannot be easily prevented, merely detected, others are not appropriated for standardization.

a) Masquerading;

systems.

101
Part 8: 1988 Message Handling Systems

E.3 General Principles

December 1990 (Stable)

E.3.1 Security Policy

A general security policy can be defined as tlie set of laws, rules, and practices that regulate how an

.

organization manages, protects, and distributes sensitive information. Thus a security policy defines an

organization's overall approach to security and must cover all security aspects.

Security within an organization is not only the concern of message handling service and must be viewed

in a more global and general sense. The wider aspects of a security policy would therefore include

personnel security (such as the vesting and confidence placed in stafO, end-user access control, physical,

procedural and documentation security. These Implementation Agreements however is only concerned with

Electronic Information Security (EIS), specifically in the areas of communications (COMSEC) and computer

(COMPUSEC) as applicable to standardization of a secure message handling system operating in a store and forward environment.

E.3.2 Security Classes

In the X.400 (1988) Recommendations, some threats are countered by EIS measures, these measures are

realized by providing security services and implemented using security elements.

These Implementation Agreements groups together security features of a message handling system defined

by the base standards into separate classes. A security class can be viewed as a tool which can be used

to implement a security policy, and is not a security policy in its own right but a component of a security

policy.

These Implementation Agreements includes a set of security classes; each class stipulates a set of mandatory and optional security services. The security classes are incremental subsets of the security

features in the MHS Base Specifications:

Security Class SO only requires support of end-to-end security services between UAs (content

integrity, message origin authentication, proof of delivery), and hence can be used to provide some

protection even in the case of transit through an intermediary MTS which may not be trusted.

Security Class S1 additionally requires support and use of secure access management within the

MTS so as to allow the enforcement of a label-based security policy and enable trusted interworking

between security domains.

Security Class S2 additionally requires support and use of origin authentication checks within the

MTS to verify the origin of messages, probes, and reports, thereby making it possible to provide

non-repudiation within the MTS.

Mandatory security services within a security class can be selected by the subscriber or user, either on a per-message basis, or for an agreed contractual period of time. It is a local issue to determine when a mandatory security service is offered for user selection or when it is permanently invoked. Facilities and

mechanisms to support the mandatory security services must always be provided within the security class,

which specifies the services as "mandatory".

102
Part 8: 1988 Message Handling Systems December 1990 (Stable)

E.3.3 Dynamic Behavior Requirements

The use of some security services is always required for certain security classes. This is specified in these

Implementation Agreements by imposing additional dynamic requirements, to those specified in the base

standards, ensuring that the corresponding protocol elements are always present.

Similarly, use of some security services are prohibited for certain security classes. This is specified In these

Implementation Agreements by imposing additional dynamic requirements to those specified in the base

standards, ensuring that the protocol elements are never present.

E.3.4 Encryption Techniques

The secure messaging facilities defined in the base standards are provided using three basic security

techniques, namely:

a) Symmetric encryption;

b) Asymmetric encryption;

c) Trusted functionality (i.e., COMPUSEC measures).

The base standards permit the use of the techniques on an Individual basis to provided security services

or they can be combined in support of a security policy. These Implementation Agreements combine the

techniques in order to provide a comprehensive set of security facilities, which are intended to counter

various combinations of the vulnerabilities of a messaging service. In some cases the security services

defined in the base standards can only be implemented using one of the techniques above, namely

asymmetric encryption. However, the actual technique employed shall be dependent on the algorithms,

which shall be registered by a security authority for the domain.

It is the intention of these Implementation Agreements that implementations will not be restricted to asymmetric techniques. All the mandatory security services can be implemented using trusted functionality

in combination with symmetric, asymmetric, or both encryption techniques.

Although the base standards defines the syntax of an asymmetric token, these Implementation Agreements

takes into account the ISO/CCITT MHS Implementors' Guide, which permits the use of both asymmetric

and symmetric techniques for both the signed and encrypted data.

The actual technique employed depends on the algorithm used. Algorithms are assumed to be bilaterally

agreed or registered by a registration authority. However, the algorithm-identifier must be unique and

unambiguously define the algorithm.

It is recommended that a conforming ASN.1 BIT STRING is normally used to contain the encrypted data (as

generated by use for the ENCRYPTED macro), thereby ensuring insertion of padding zero bits which may

be necessary for correct operation of certain algorithms. Alternatively, the implementation should take such

action explicitly.

It is recommended that, in the absence of any requirement for support of other specific algorithms,

103
Part 8: 1988 Message Handling Systems December 1990 (Stable)

implementations shall as a default support algorithms identified in CCITT X.509 (ISO/IEC 9594-8). It is also

strongly recommended that implementations are capable of using any encryption-based technique on a

"plug-in" or modular basis.

In the case of verification of SIGNATURES (e.g., proof of delivery, MOAC, POAC, or ROAC), implementations

should assume that all relevant data present in the subject message, probe, or report has been included in the signature.

E.3.5 Implementation Considerations

E.3.5.1 Peer Entity Authentication

i Peer entity authentication is provided using the strong authentication mechanisms on the various Bind

operations, using either asymmetric or symmetric techniques. The key management information necessary « for symmetric peer entity authentication is outside the scope of these Implementation Agreements.

E.3.5.2 Confidentiality

Connection confidentiality is provided using the underlying OSI layers and is outside the scope of these

Implementation Agreements. Mechanisms to support connection confidentiality are subject to bilateral agreement between peers (i.e., connection confidentiality may even be achieved by trusting the connection

to the peer OSI entity).

Content Confidentiality may be achieved by either symmetric or asymmetric encryption techniques. It should

be noted that use of asymmetric techniques precludes submission of messages to multiple recipients.

E.3.5.3 Integrity

Connection Integrity is provided using the underlying OSI layers and is outside the scope of these

Implementation Agreements. Mechanisms to support Connection Integrity are subject to bilateral agreement

between peers. It should be noted that the integrity of a connection can be increased by use of RTSE.

Content Integrity is achieved by computing a content integrity check as a function of the entire message

content. When symmetric techniques are used to compute the content integrity check a secret key is

^ required. This content integrity key may be confidentially sent to the message recipient using the message

' argument confidentiality security element in the message token (i.e., there may be other keys or parts of the

key not sent by the originator with the message, but the key management of such external keys is outside

the scope of these Implementation Agreements). It should be noted that placing the content integrity check

in the encrypted data of the message token will provide additional protection against masquerade threats. NOTE - Content Integrity can also provide integrity of receipt and non-receipt notifications (IPNs) and can

assist in the provision of "non-repudiation of receipt" since non-repudiation of delivery may be insufficient where

delivery is to a Message Store.

I

I

104
Part 8: 1988 Message Handling Systems December 1990 (Stable)

E.3.5.4 Message Origin Authentication

End-to-end (i.e., UA to UA) Message Origin Autlientication is automaticaily provided by content integrity.

Security classes S2 and S2a provide additional protection (i.e., of the integrity of the label) by requiring

support of origin authentication checks within the MTS.

If asymmetric techniques are used for content integrity it can also provide non-repudiation of origin (UA

to UA) depending on the level of trust placed In the certificate. If symmetric techniques are used, content

integrity can also provide non-repudiation of origin, but only by using a trusted notary to validate the

content integrity and provide trusted key management facilities. A degree of non-repudiation can be

provided by the use of trusted accountability services.

NOTE - It is assumed that an originating UA will ensure that delivery notification is requested when proof

of delivery is requested.

E.3.5.6 Secure Access Management

Secure Access Management can be implemented by a combination of Multi-Level Security (MLS)

functionality by assurance of the various MHS components to support such functionality. MLS

functionality is supported in the base standards by the use of security labels, security context and the

security token and can be applied in a hierarchical and/or role manner depending on the policy

requirements of a domain.

MLS assurance will generally also require other (COMPUSEC) measures and is outside the scope of the

base standards and these Implementation Agreements. Reference should be made to the appropriate

security authority and any applicable security evaluation criteria (e.g., U. S. DoD Orange Book, UK - Netherlands - Germany - France draft Evaluation Criteria).

E.3.5.7 Implications for the Use of Distribution Lists

An MTA performing distribution list expansion must create all the per-recipients fields for the members of the distribution list. It may either generate a new token for each DL member (i.e., using the recipient name of that DL member) or alternatively it may copy the same token (i.e., containing the recipient name

of the DL itself) into the per-recipient fields for each DL member. In the former case, the contentintegrity-check should not be changed if it is to be used to provide message origin authentication. Also

in such case, the DL expansion point must have at least the same security class as the originator and

must have trusted functionality. The choice of which approach to use will therefore need to be

determined in accordance with the security policy which may prohibit the use of distribution lists altogether.

E.3.5.5 Non-Repudiation

105
Part 8: 1988 Message Handling Systems December 1990 (Stable)

E.3.5.8 Implications on Redirection

The Security Functional Group has the effect of either requiring trust in any redirection facilities or

| prohibiting the use of redirection. If the Redirection facility is to be trusted, it must be subject to the

security policy and obey the security labels as defined in the base standards. It is recommended that the I token is not altered on redirection (i.e., it will contain the originally-specified recipient name).

Interworking between implementations conforming to Security Functional Groups and 1984 systems is not supported. The Double Enveloping technique can be used to traverse an 1984 system.

E.3.5.10 Implications for Use of Directory

The X.400 security services use of the directory service does not require a trusted directory because the

information that is retrieved is certified and can be validated independently of the directory.

Other threats (e.g., malicious corruption of directory information) may arise from the broader use of the

directory, however these are outside of the scope of the X.400 base standard and this Implementors

Agreement.

Work continues within CCITT and ISO to improve the security inherent in the Directory standards.

E.3.5.1 1 Implications for Conversion

Implementation of the Security functional group may additionally either require that any conversion

facilities are highly trusted to regenerate the appropriate security elements (notably the content integrity

check) or prohibit the use of conversion within the MTS altogether. In particular, it should be noted that use of conversion facilities will invalidate any origin authentication based on the original content.

E.3.5.1 2 Accountability

Accountability depends on the identification and authentication of users, then subsequent records being

kept on the actions taken by users. Therefore, accountability depends on all the relevant information

being properly stored or recorded.

Accountability features provided by domains (or MTAs) are subject to bilateral agreement between

domains (or MTAs) and may optionally provide non-repudiation services. Accountability features include

pervasive mechanisms such as security logs, audit trails and archives, or they may be mechanisms

supported by protocol. Protocols to support accountability will be subject to bilateral agreement.

E.3.5.9 Implications for 1984 Interworking

106
Part 8: 1988 Message Handling Systems December 1990 (Stable)

E.3.5.13 Double Enveloping

Double enveloping can be used with each secure messaging security class. For each security class it is an optional extension to the security features which can be used to counter specific vulnerabilities. When

double enveloping is used, it shall be applied at the boundary of a domain, and obey the rules of an MTA at management domain boundaries. Figure 20 Illustrates the technique.

Outer Envelope 2 Content 2 Inner Envelope 1

Content 1

Figure 20 - Double Enveloping Technique.

Address information in envelope 1 and 2 are not necessarily the same.

Trace information in envelope 1 and 2 are not necessarily the same.

The double envelope technique can be used in 1984 and 1988 MTS environments. When used in an

1988 environment, any security class can be applied to the outer envelope. It is recommended that the

inner envelope is encrypted. When the double envelope technique is used as a secure relay path via an

1984 domain, any encryption of the content 2 is subject to bilateral agreement.

Trace information is not passed between inner and outer envelopes. It is recommended that trace

information on the outer envelope is always archived when the double envelope technique is used.

E.4 Security Class SO

E.4.1 Rationale

Security class SO is confined to security functionality operating between MTS-Users on an end-to-end

basis. It is designed to minimiz:; the required functionality in the MTS to support submission of elements

associated with these services. Security services which must be supported (i.e., must be made available) are those which are considered in any secure messaging environment, i.e.:

a) Content Integrity;

107
Part 8: 1988 Message Handling Systems December 1990 (Stable)

b) Message Origin Authentication (end-to-end);

c) Proof of Delivery.

Other security services, such as Content Confidentiality, rnay optionally be supported.

E.4.2 Technical Implications

The technical Implications for security class SO are:

a) It is necessary to provide mechanisms in a UA which can generate the signed, signature and

encrypted macros on message submission;

b) It Is necessary to provide mechanisms in a UA which can handle the signed, signature and

encrypted macros on message delivery.

E.5 Security Class SI

E.5.1 Rationale

The S1 security class is a superset of security class SO and introduces the basic requirement for security

functionality not only within the MTS-User but also within the MTS. This security functionality within the

IVITS is designed to support the enforcement of a security policy within a security domain. As a consequence, S1 enables trusted routing to be implemented.

NOTE - The level of trust in the route will depend on the level of trust in the security label and security context.

E.5.2 Technical Implications

The technical implications of security class S1 are:

a) It is necessary to provide mechanisms in a UA which can generate the signed, signature and

encrypted macros on message submission.

b) It is necessary to provide mechanisms in a UA which can handle the signed, signature and

encrypted macros on message delivery.

c) It is necessary to provide mechanisms In the MTA for registration, change-credentials and

bind abstract operations (i.e., signed macro for bind).

d) It is necessary to provide mechanisms In the MS for MS-registration and MS-bind operation

(i.e., signed macro for MS-Bind).

108
^art 8: 1988 Message Handling Systems December 1990 (Stable)

e) It is necessary to support message security labelling (the level of assurance is subject to

Individual security domain requirements).

f) It is necessary that reliable access is always supported.

g) It is necessary for the MTAs to check the existence of the security elements which are

classified as "dynamic mandatory".

h) It is necessary to provide a trusted connection between peers to provide adequate

confidentiality, integrity and peer entity authentication.

iE.6 Security Class 82

E.6.1 Rationale

Security Class S2 is a superset of Security Class Si. It enhances the facilities of the MTAs in order to check the origination of messages, probes, and reports within the MTS and to provide enhanced

integrity checks on the security label while in the MTS. The extra security services provided by this security class can help to provide trusted routing within an MTS.

Additionally, It is possible to provide non-repudiation within an MTS.

E.6.2 Technical Implications

The extra security services specified by Security Class S2 use asymmetric techniques exclusively.

The technical implications are as in Security Class S1 , plus:

a) It Is necessary to provide mechanisms in an MTA and UA that can process the signed macro

of certificates;

b) The constraint that the option of supporting Content Confidentiality cannot be allowed when

the message origin authentication check (MOAC) is used to provide non-repudiation services.

Under this condition Content Confidentiality is not supported. If the MOAC is not used for this purpose, Content Confidentiality can be supported as an optional security service;

c) It is necessary to provide mechanisms in a MTA which can generate and process the

signature macro of a message, probe, and report authentication check (MOAC, POAC and

ROAC);

d) It is necessary to provide mechanisms in a UA and MTA that can interface with an X.500

directory supporting the Authentication Framework as defined in X.509/ISO 9594-8 or can

distrubute public keys by other trusted means which is compliant with X.509;

e) It is necessary to provide a trusted means of generating certificates;

109
Part 8: 1988 Message Handling Systems December 1990 (Stable);

f) It is necessary to provide mechanisms in tlie MTA wfiich can process a proof of submission

request and generate tlie proof of submission signature;

g) It is necessary to provide a mechanism in an MTA which will generate ROAC signatures with

reports;

h) Connection confidentiality is only provided by this security class when the message-originauthentication-check is computed using clear content to provide non-repudiation of origin

security service (i.e., non-repudiation is provided only on the clear content of the message);

i) The irrevocable proof required to provide non-repudiation within the MTS is achieved by the

management of asymmetric keys. The explicit definition of asymmetric key management is outside the scope of these Implementors Agreements.

E.7 Confidential Security Class Variants (SOa, S1a, and S2a)

E.7.1 Rationale

These security class variants are supersets of SO, S1 , and S2, adding the requirement for support of end-to-end content confidentiality. The rationale for these variants is to avoid the implementation cost and processing overhead involved in encrypting the entire message content unless there is a definite requirement. It is also possible to protect the encryption techniques and mechanisms (i.e., algorithms,

key lengths, key versions, etc.) by Secure Access Management.

E.7.2 Technical Implications

The technical implications of the confidential security class variants are the same as those for the

corresponding primary security class, plus:

a) It is necessary to provide mechanisms in a UA which can use the encrypted macros to encrypt and decrypt the message content.

110
Part 8: 1988 Message Handling Systems December 1990 (Stable)

[ Annex F (informative)

I ~" iBibliography

F.1 ANSI

! Procedures for Registering Organization Names in ttie United States of America, ISSB 843, December 5,

, 1989.

Procedures for Registering Names in tiie United States of America, ISSB 840, December 5, 1989. The

United States Register is included.

Ill
I

I
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 9 - FTAM Phase 2

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Darryl Roberts, Unisys ONG

Larry Friedman, Digital Equipment Corporation
Part 9 - FTAM Phase 2 September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the File Transfer, Access and

Management Special Interest Group (FTAM SIG) of the National Institute of Standards and Technology

(NIST) Workshop for Implementors of Open Systems Interconnection (OSI). 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. There is no significant technical change from this text as

previously given.

Future changes and additions to this version of these Implementor Agreements will be published as change

pages. Deleted and replaced text will be shown as stri keout. New and replacement text will be shown as shaded.

I

f

ii
lilPart 9 - FTAM Phase 2 September 1991 (Stable)

Pm 9 - ISO Fife Transfer^ Acc&$$ and Management Pha«e 2 . ,

,

9 Inifoductioa l^-^^fj

^ Hormattv0 Helerene^ , z

I

^ ' " < "

' ^

i > . .--^ ij

, , ;i;. x; ^ , ^ V . > > ' i' ' - + ^

" " ' " ' * '^^^

I $ Assumptions . . S

6 Presentation agreements . . .7

! 7 S^lce tJlass agreements . . , 8

, a Funettonal iinll agreements , , , . B

\ 9 File attribute agreements ....... 9

9.T Wandatory group . 9

9.2 Optior»al groups

>

tO

10 0ooumenttypeagreemertis> . - 10

10.1 Character set . . * il

10.1,1 ISO ^0 Character set i|

10.12 Format effectors . . * , i|

8859-1 Character set . . . . . , 15

10.2 Documi^it type Negotiatlort rules 15

10.2-1 Connection establishment . . 15

10.2.5 l=le creation 16

10.2.3 ^ opening . ^ 1^

10.3 Relationship between DUs. DEs and document types 16

11 :^ANCEL action . .... .17

12 implementation Information agreements , 17

13 Diagnostic agreements . . . 18

114 Conourrenoy . i|

IS i^equested access ...,...,>.<<,.. ......<<....,.<,......<<,..,..<.... 19

Hi
Part 9 - FTAM Phase 2 September 1991 (Stable)

16 S^cifilty 20

16J inliiator Idemlty and fitestore pa 20

16.2 Ao£50$$ pa$$wofd$ ......... - 20

18.3 Impiementa^dcm responsibilftles > , . . , , . , 20

_ I

jf.j,,,,_j}»i'i-' . : _ -'vWiMi

17.2 Reir 22

17,^ l^eq 22

17.4 Jni« . , 22-1 1 iff V ^ -

.

, , , , , . . . , _ msimy^^^^^

||g||y:Sef8dei-e .................. . . , -TMX-'. ..... . :.:|5

11.6, J Jnitiator Senders 25

17,6,2 Responder Senderi, 25

17.7 ??i5Ceiverg .26

17-7,{3 Responder Receivers , ^ ^ , 26

17JS ftjJIniinum ranges . 27

17.9 fJangeiol values for INTEGER type pararneters . . , 30 1710 tls& of lower layer services , , ..30

18 Implementation Profiles ... ... > . . . , . . . , . . . 30

18.1 Oenerai requirements for the defined Impfementation Profiles - . .32

18.2 (doleled) 32

18»5 OoOUmenl type irequirements for the defined Impli^enJ^ation Prc^iles . . 32

18*4 Parameters for the defined Impfementatlot^ Prc^es 32

ia6 Pammet^ ranges for the defined Implem^tatlon Profiles 33

18.6 File attribute support for Implenaentations * 33

IS PROVtSrOM OF $PECIFIC FUhTCTtON 37

'

19>1 Implementadon Profile T1: Simple File Transfer . 3/

19:2 Implemerrtatlon Profile T2: Positional File Transl-^^r . . . 37

19^ impierrtentatfon Profile T3: Full File Transfer > . , , , , , 38

19.4 impl0mentalton Profile A1: Simple F8e Access . . , 39

19>6- ^mplemerrtation Profile A2: Full File Access 39

19.6 ' Implementation Profile Mi: Managenient . . , , , 40

20 Harmonf2:atlon . ......... .... . 40

Anrtex A (normaJive)

rrAMDooumemtypea 4i A.t MBS-^ SequenttM file document . . . . . 41 A.2 Random access file ...... 41 A,3 'ndexed sequential file ..... . , . . . 42

Ai4 directory file

,

.

^ 42

Ai5 idal tile document type , ........... . , 42

- Number: NB$-6 ..... 42

imtion object .42

iv
Part 9 - FTAM Phase 2 September 1991 (Stable)

$oop0 dfici field of appitoatiott : . / : r: '""U

A>6x4 References . . .... ... 44

k^J^ D^lnitions , . . 44

A*5*$ Abbreviations * 44

A^,7 Doounpient S0mantlo$ . . , , 44

A.6.B Abstract syntactic structure < , « . > x < < * * . 4S

D^lnltiofl of tfiarjsfer , , . , 45

AS*1&*1 Datatype definitJons x > 45

A^,9.2 Pr$$etitatlon ^lata valu0$ , 45

A>6.9<3 Sequence of presentation data ^ , < . . 46

Transfer s^ax 46

Pd&A I ASE specific specifications for F ... 46

AJ5,11.1 Simplification and rdaxation $trt 46

A>6.11>2 Access context selectlor 46

A 1 Tfie INSERT operation 46

A.6 , .WH^ 4 flarKiom access file . ... 47

A,ai Entry number: NBS-7 . 47

infonnation object .47

A.^.3 Scope and field of application . 49

A*6.4 References ....... < . 49

A,6,5 Definitions ..... . . 49

A>6.5 Abbreviations >..,,. . ... .49

A.^.7 Docunrient semantics . 49

A*6*8 Abstract syntactic structure , , , , . , . . 50

Aj6,9 £fetlnltl<«i of transfer . . 50

A>6.9,t Datatype definitions 50

A.i&A2 Presfitfitatiott date values , _ 50

A*6*0.3 Sequence of presentation data values . .51

A,€kio Transfer sv^tax , . 51

A>e,11 ASE specife specifications for FTAM x < .81

K^AXA Slmp(lfioat)on and rdoitatton Structural Amplification . ^^ Ai6*1t2 Access context selectioni . .51

Aiait.3 The INSERT operation ,.51

A. NBS-8 Indexed sequential file . 53

A,7.1 Entry Number: N8$-S . . ^ .53

Ai7*2 Infomrration Objects . . 53

A.7,3 Sct^ and field of application 54

A>7.4 References - . .55

A.7.5 Definitions . . . , 55

A.7.6 Abbreviations ....... . . . . . .55

A.7,7 Doctin^nt semantics . , . 55

A>78 Abstract syntactic structure . ... 56

A.7.9 Definition of transfer . . . . .57

A*7A1 Datatype definitions ... . . ... . ... 57

A.7,9.2 Presentation data values . - 57

A>7v9.3 Sequence of presentation data values 57

A.7.10 Transfer s^ax ... 58

A*7*1 1 ASE specific specifications for FTAM . . , , . . 58

A.7,1t,1 Structural simplification 58

V
Part 9 - FTAM Phase 2 September 1991 (Stable)

A,7,1 1.2 Acce^ <5<»tt0Xt $$letCti{^ . , , . » . , _ S8

PkfA i>Z The INSERT opersHon > x x ^ x < 68

A,7.11.4 Th^ EXTEND opefiaJlon m

A»8 NBS^ Fie dtrecliory f x x x ^ x<<*» + 59

E«^K 69

$00|>e $1

A<0<.4 : :

: ::->x.:-:v:-:-:.:.:.JI^Bri6r >x<<**-t-tt.x<<***t>x<<***»>x<t*** 6i ^ Dafioitk , , . , ai

^' lIvXvlyXylvlAlljbPBVl' >>X<<«*'»»KX<44'*'»>>X<<«''f'»>>X< 61 ^ Docttm. _ ^1

P Mnltl * . . » _ , 62

A Presen _ , f;2 ^ Sequer lues x x > 62

Transfc 62

/ w ASE Sp , , V ^^ + +>X<<<-+>>\<<«4+^>X< 62

Anfiex sB (flofmatlvej^

Constrafnk Sets * . ^ . * * * 6;3i MBS w .^,^,.,»»+,,v,,»*^,,,.,»»+63

B.2 NBS OJ^ 64

0 ^ +::+;:>::•r:•x::•::^v;*::::+;^^::.v^x:•:<-::^^^^^

loeniity constraims .... , . 66

Anneit 0 (ftoitna^e)

0^1 Abstract Syfttax NBS-ASi . . _ 67

C.a Abslra(a; Syrtax NBS-ASl x 67

a3 Abstract Syittax N8$-AS1 delfnlltort . . _ , . . 67

C.4 Abstrat^ Syntax N8$*AS2 defihitioii . k x < 69

C,5 Abstract Syrttax *FTAM unstmctufad text ab$traot syntax" , 69

Q<B Abstrad: $yrrtax*FTAM unstructured binary abstrad syntax* ...>> x <.....> x . 69

Vi
! Part 9 - FTAM Phase 2 September 1991 (Stable)

ilsl if fab^

ifitabte TaWe

Tatte

1-

2 * 3-

Tatte 11

Tatjfe

Tahiti 5-

ft * Table 7-

Tafcrfe Taljfe 9-

Table 10

Table 11 Tabfe

Tafote Table

12

13

14

t Tabte 15

Par^m^m Ibr FTA^*-1, -a, -3 fmW^A

Pafametars1orNBS^.«B8-7.NBS*e ... id

FTAlwl j>r6ifi8ivi&<*diat il

IRVQrapfifc (Praetor ABocations. 12

Irjt^Qpwat^ <3C5P6gi««iSor»i, ^ ^ , » * ^ , ^ , . 20

Beqt^Bd minlmatpaosHTieter support . . 2:6 Ipiplerwntditon profile support requirements —, 34

Implsmeraatton Profites <NIST> artet lilies {SPAQ/CS^KILC) . 38

lfjformal«mob]fiici&lnNBS-6. . , 4i

* liiJomiatlDfl d^ects NBS«7 45

' Nomidtlon olJieots NSS^ 49

* Datat^sBS for keys 51

- Information d3|eots »i N8$-9 . . . .

. 55

» Basic eontstfislnls lor NBS ordered fiat 59

- Itfetjtity <x»isttaijTt5 lr» ordered flat 60

vii
Part 9 - FTAM Phase 2 September 1991 (Stable)

U$t of Figures

t

- Model + 1

Vili
Part 9 - FTAM Phase 2 December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the File Transfer, Access and

Management Special Interest Group (FTAM SIG) of the National Institute of Standards and Technology

(NIST) Workshop for Implementors of Open Systems Interconnection (OSI). 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. There is no significant technical change

from this text as previously given.

ix
I
Part 9 - ISO File Transfer, Access and Management Phase 2

NOTE - In document type names, constraint set names, and abstract syntax definitions, the "NBS" designation

will be preserved.

0 Introduction

This part defines Implementors' Agreements based on ISO File Transfer, Access and Management (FTAM),

as defined in ISO 8571 . This International Standard has four parts. Part 1 of the IS gives general concepts,

part 2 defines the Virtual Filestore (VFS), part 3 defines the File Service, and part 4 defines the File Protocol.

FTAM, as described in the IS, is based on the following ISO documents: ACSE Service and Protocol (ISO

8649, ISO 8650), Presentation Service and Protocol (ISO 8822, ISO 8823), ASN.1 Abstract Syntax Notation

and Basic Encoding Rules (ISO 8824, ISO 8825), and Session Service and Protocol (ISO 8326, ISO 8327).

These services and protocols are defined architecturally in the OSI Reference Model (ISO 7498). These

Agreements provide detailed guidance for the implementor, and eliminate ambiguities in interpretations.

The general agreements reached with respect to the ISO File Transfer, Access and Management Protocol

(FTAM) are that the Phase 2 FTAM specification (this part) is based on the International Standard (IS).

1 Scope

These FTAM Phase 2 Agreements cover transfer of and access to files between the Filestores of two end

systems, including the management of a Virtual Filestore. One end system acts in the Initiator role and

initiates the file transfer/access, while the other end system acts in the Responder role and provides access

to the file in the Virtual Filestore. This part describes Agreements for the actions and attributes of the Virtual

Filestore, and the service provided by the file service provider to file service users, together with the

necessary communications between the Initiator and Responder.

virtual

Fi lestore

2

Real

Fi lestore

1

Etxl System 1 - Initiator -End

System 2

- Responder -

Real

Fi lestore

2

Figure 1 - Model of file transfer/access.

NOTE - Agreements apply on the double lines of figure 1 . The mapping between the Virtual Filestore and

the Real Filestore together with the local data management system is not part of these Agreements.

These Agreements define general Agreements in clauses 5 through 16, minimum functionality (Conformant

Implementations) in clause 17, and functionality for several Implementation Profiles which are tailored to

different classes of user requirements in clauses 18 and 19.

1
Part 9 - FTAM Phase 2 December 1990 (Stable)

2 Normative References

ISO 8571-1: 1988(E), Information Processing Systenns - Open Systems Interconnection - File Transfer, Access and f^anagement Part 1: General Introduction

8571-2: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer,

Access and Management Part 2: Virtual Filestore Definition ISO

ISO 8571-3: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management Part 3: The File Service Definition

ISO 8571-4: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management Part 4: The File Protocol Specification

Version 3 of the FTAM Phase 2 Implementation Agreements was completed December 15, 1989, and

published in version 3 of the Stable Implementation Agreements (NIST Special Publication 500-177,

December 1989). Some editorial clarifications and technical changes (due to international harmonization

of Profiles) were added to Version 3 Agreements in the course of 1990. All these changes are now fully

incorporated in this version 4 of the FTAM Phase 2 Stable Agreements.

No further enhancements will be made to this version 4 of FTAM Phase 2 (see the clause 4 ERRATA).

This version 4 of the FTAM Phase 2 Agreements fully replaces the version 3 as published in NIST SP 500-

1 77. Therefore, the old version 3 of FTAM Phase 2 will no longer be maintained.

The following list summarizes the technical errata changes to FTAM Phase 2, Version 1 which were

incorporated in Version 2. It also states the degree of possible interworking and t)ackward compatibility to RAM Phase 2, Version 1

.

3 Status

2
Part 9 - FTAM Phase 2 December 1990 (Stable)

Technical Changes In FTAM Phase 2,

Version 2 (Dec. '88)

Backward Compatibility to FTAM

Phase 2, Version 1 (Dec. '87)

1 . Check of already established

presentation contexts for a document type not at CREATE

time but at OPEN time

Interworking problems could occur when creating a document type

which is not opened

2. Receivers shall not require

sending of AETtitles

Interworking problems could occur

if AETitles are not sent

3. Minimum requirement for FADU

identities for document types

which use the sequential flat constraint set

Interworking problems could occur

if FADU identities beyond the

minimum requirement are used

3
Part 9 - FTAM Phase 2 December 1990 (Stable)

The following list summarizes the technical errata and alignment changes which were incorporated in FTAM

Phase 2, Version 3. It also states the degree of possible interworking and backward compatibility to FTAM

Phase 2, Version 2.

Technical Changes in FTAM Phase 2, Backward Compatibility to FTAM

1 . Unconstrained Service Class outside

the scope of the Implementation

Profiles

Full compatibility, since change only

from "optional" "to "outside scope"

2. < contents-type-list > parameter:

Both types of values optional

for Initiators

Full compatibility, since this

clarification is only for Initiators

3. Specification of supported values for < override > oarameter in F-CREATEInterworking problems may occur, if different values suooorted

4. Parameters <filesize>, < future

filesize>, <fadu-number> may be

encoded with up to 8 contents

octets

Interworking problems may occur,

since no minimum requirement was

defined for Version 2.

5. For NBS-7 and NBS-8 in conjunction with T or TIVI Service Class, the FADU

identities "current", "next",

"previous" are not required

Full compatibility, since these

identities were never useful in conjunction with T or TM Service

Class

6. For NBS-8 files the minimum range

for keys of string-type is (1-16)

instead of (0-16)

Interworking problems may occur

for key-length parameter 0

7. Restriction "NBS-9 files may not be

Created or Deleted" removed from

the document type definition. But

both actions are outside the scope of

the Agreements.

Full compatibility, since Creation,

Deletion was never in the scope of

the Agreements

8. Constraint set NBS-ordered-flat:

The location after an Insert Is "end"

Full compatibility, since this

specification was already implicitly

clear

4
'art 9 - FTAM Phase 2

i

September 1991 (Stable)

,4 Errata

NU. Ur

ERRATA

TVDC 1 Yrt ncrcricNUcLl

DOCUMENT

Ol Al ICC

CP 3/91-1 EDITORIAL NIST-SP 500-183 All Update to ISO style.

General formatting and

error corrections.

Alignment with the

wording of the ISP. Consistent naming

conventions.

liiilllll liliilil Table 9 Datatypel ASN.1

Tabl$ tg comment to use the

miiiii Table 11 object descriptor

miiiiiii

Clause 17

Annex A

include Corrigenda

Editors rK)te to point at iiiiii

ISP for regfetered

objectsi

A.6>11J Change header to

Structural Simplification.

CP 9/91-6

A.7.9.1 AJ.a2

Added deflnltfofis f<» Datatypes

I 5 Assumptions

I RAM protocol machines must be able to parse and process at a minimum 7K octets of FTAM PCI, FTAM

( structuring (FTAM-FADU) and FTAM user data (including grouped FPDUs) as they would be encoded with

the ASN.1 Basic Encoding Rules. It is recommended, however, that Presentation user data not be restricted

in size.

j In order to maximize interoperability, it is important that the implementations of FTAM service providers do

not unnecessarily restrict the service user's ability to generate arbitrary file service requests. Otherwise, they

may not be able to work with FTAM Responders whose operation is constrained by their mapping of the

FTAM Virtual Filestore to their local filestore. For example, error procedures should only be invoked when

an error actually occurs, not at the point of the specification of options which might result in an error.

^ Implementations must be able to parse all valid optional parameters if they are present in the PDU. Only

those optional parameters specified as supported in these Agreements are required to be implemented. If

5
Part 9 - FTAM Phase 2

•I September 1991 (Stable) |

these parameters are not present, a default value is assigned locally. A Responder sliould not refuse a request solely because a parameter that is optional in the FTAM standard, but is supported in these

Agreements, is not present.

Consideration of any standardized service interface is not covered by these Agreements.

These Agreements define no restrictions for the values used for the < communication quality of service>

parameter in <F-INITIALIZE>.

FTAM is defined in phases. The Phase 1 FTAM implementation specification is based on the second ISO H Draft Proposal, dated April 1985, and the ISO Draft Proposal 8824 and 8825.

The Phase 2 FTAM specification (this part) is based on the International Standard (IS). THERE IS NO

BACKWARD COMPATIBILITY WITH NIST FTAM PHASE 1. Backward compatibility is impossible, since

Phase 1 uses Session services directly, while Phase 2 uses ACSE and Presentation services. Furthermore,

there are differences in Filestore, PDU Abstract Syntax, FADU Abstract Syntax, and Transfer Syntax. There

also are differences in the transparency mechanisms and service class negotiations.

The < implementation information > parameter of <F-INITIALIZE> FPDU as defined in ISO 8571-4, 20.3 is used to pass 'user version' information with respect to different FTAM phases of the NIST Implementors

Agreements or with respect to FTAM profiles of other bodies (see clause 12). It is the goal of these

Agreements to use the 'user version' mechanism to provide at least one level of backward compatibility for

all future NIST FTAM Phases, facilitating backward compatibility for future FTAM products, assuming

different new versions of the respective IS's also enable backward compatibility.

The FTAM specific ASE requirements for ACSE in the Upper Layers part of this document define a value

(that carries no semantics) for the AETitle that can be used by FTAM ASEs for communication. Other values

for the AETitle are outside the scope of these Agreements.

The association shall not be rejected/aborted if any of the following parameters either contains the defined

value or is not sent:

Called - AETitle

6
Part 9 - FTAM Phase 2 March 1991 (Stable)

Calling - AETItle

Responding - AETitle

The association may be rejected/aborted if any of these parameters contain other values.

Use of values outside the scope of these Agreements is discouraged until agreed upon semantics have been

associated with AETitles.

Use of < shared ASE information > parameter and < charging > parameter is not defined v*/ithin the scope

of the Agreements.

Use of < application context name> parameter is not defined within the scope of these Agreements. This

parameter does not prohibit the establishment of an FTAM association.

These Agreement use the term 'supported' for a parameter to mean that the syntax and semantics of that parameter shall be implemented. However, it is not a requirement that the parameter be used in all instances of communication, unless stated otherwise.

Also these Agreements use the term 'optionally supported' for a parameter to mean that it is left to the

implementation whether the semantics of that parameter are implemented or not.

6 Presentation agreements

The following Abstract Syntaxes are recognized in these Agreements:

"FTAM FADU"

"FTAM PCI"

"FTAM unstructured text abstract syntax"

"FTAM unstructured binary abstract syntax"

"NBS abstract syntax ASl"

"NBS file directory entry abstract syntax"

The following Transfer Syntax is supported:

"Basic Encoding of a single ASN.1 type"

See also annex C.

7
Part 9 - FTAM Phase 2 March 1991 (Stable)

7 Service class agreements

Implementation Agreements have been reached for the following service classes:

File Transfer

File Access

File Management

File Transfer and Management

Unconstrained

8 Functional unit agreements

Implementation Agreements have been reached for the following functional units:

Kernel

Read

Write

File Access

Limited File Management

Enhanced File Management

Grouping

Implementation of the Recovery, Restart Data Transfer, and FADU Locking functional units is not specified.

8
Part 9 - FTAM Phase 2 March 1991 (Stable)

9 File attribute agreements

! Implementation of the Kernel Group of file attributes is defined. If the optional Storage Group and Security

Group are implemented, aspects of their implementation are defined. Implementation of the Private Group

is not specified.

Responses to an attribute value request shall always include one of the following (as specified in ISO 8571 -2,

i clause 4):

An actual file attribute value.

A value indicating that no value is available, optionally with a diagnostic.

No value and an error code, optionally with a diagnostic indicating that the attribute is not supported.

9.1 Mandatory group

Only the Kernel Group of attributes is required. A value for <filename>, < permitted actions>, and

< contents type> will always be available.

A minimum range is required for <filename> values as specified in ISO 8571-2. No maximum length or format restrictions apply. A system that does not support < filename > values with a sequence of more than one Graphic String or extended <filename> characteristics may reject a request involving such a

<filename>. All systems must be able to interpret a < filename > value with a sequence of one Graphic

String.

A Responder shall not require an Initiator to use multiple component Graphic String filenames. Requests

using a single component < filename > value with a sequence of one Graphic String shall be responded to using a single component <filename> value. Responses to requests involving < filename > values having

two or more Graphic Strings are not defined here but may be interpreted via bilateral or other external agreements. Use of < filename > values with a sequence of more than one Graphic String is discouraged.

Apart from the minimum conformance requirements specified in ISO 8571-2, file names have to be specified

in the naming convention of the responding FTAM implementation. It is a local implementation matter of the FTAM Responder, whether or not an additional name mapping onto the real Filestore's file name

convention is supported.

In order to enable interworking with all FTAM Responders' virtual Filestores, it is recommended that FTAM

Initiators impose no restrictions on the attribute range supported for file names beyond those specified in ISO 8571-2.

For the purpose of intenworking according to these Agreements the < contents type> attribute is limited to the <documenttype name> format. The < constraint set name, abstract syntax name> form is outside the

scope of these Agreements. It should always be parsed correctly when received, but may result in an error.

9
Part 9 - FTAM Phase 2

9.2 Optional groups

If the optional Security Group of file attributes is implemented, an actual value must be available for the < access control > attribute.

The < access control > attribute is a SET OF < access control element >. The minimum requirement in these > Agreements is the support of one <access control element>, according to the base standard. The terms

< concurrency access >, < identity >, and < passwords > are each optionally supported. Details of their use i shall be specified in the PICS. Use of the < location > term is not specified in these Agreements.

Implementation of the Private Group is not specified.

10 Document type agreements

These document types are defined:

FTAM-1 "ISO FTAM unstructured text"

FTAM-2 "ISO FTAM sequential text"

FTAM-3 "ISO FTAM unstructured binary'

NBS-6 "NBS-6 FTAM sequential file"

NBS-7 "NBS-7 FTAM random access file"

NBS-8 "NBS-8 FTAM indexed file"

NBS-9 "NBS-9 FTAM file directory file"

Detailed document type definitions are given in annex A and in ISO 8571-2, annex B. NOTE - Document types NBS-1 to NBS-5 are not defined in these Agreements. The numbering starts with NBS-6 because of the original DiS version of these Agreements.

An implementation claiming conformance to these Agreements which also supports any or all of the

document types FTAM-1, FTAM-2, and FTAM-3 as defined in ISO 8571-2, annex B, must minimally support

the combinations of parameter values as specified in table 1

March 1991 (Stable)

10
Part 9 - FTAM Phase 2 December 1990 (Stable)

jtable 1 - Parameters for FTAM-1, -2, -3

r~

Class Number

Maximum

String Length**'

Strina wLI II IM Significance

FTAM-1 General String '(27)

lASString '(22)

134 or less 'not-significant'®

FTAM-2 Graphic String ''(25) 134 or less^ 'not-significant'®

FTAM-3 <not applicable > 512 or less 'not-significant"'

NOTES

1 The minimum level of support for General String is the ISO 646, IRV GO character set and the 8859-1 GO

and G1 character sets, and ISO 646, IRV CO set.

2 The support for IA5 String is the ISO 646, IRV GO character set and the ISO 646, IRV CO set.

3 The minimum level of support for Graphic String is the ISO 646, IRV GO character set and the 8859-1 GO

and G1 sets.

4 This is the default when the parameter is not specified.

5 The implementation need not support Data Units whose total character count exceeds 134.

6 As per table 3.

7 The length refers to the number of characters from the applicable character set. It does not include any

escape sequences or overhead from the encoding.

8 If escape sequences are used in the encoding of the data and string boundaries are not maintained when

the file is stored, it may be necessary for the escape sequences to occur at different locations when the file

is re-sent.

For document types which use the sequential flat constraint set, conformant implementations must

minimally support FADU identities as follows:

- for Transfer service class: 'begin', 'end'

- for Transfer and Management service class: 'begin', 'end'

- for Access service class: 'begin', 'end', 'first', 'next'

For the document types NBS-7 and NBS-8 used in conjunction with the Transfer service class or the

Transfer and Management service class, the support of the FADU identities of 'current', 'next' and 'previous'

and for NBS-8 the support of the FADU identity of 'end' are outside the scope of these Agreements.

For the document types NBS-6, NBS-7 and NBS-8 parameters are used for which the Agreements apply as

specified in table 2.

11
Part 9 - FTAM Phase 2 December 1990 (Stable)

Table 2 - Parameters for NBS-6, NBS-7, NBS-8

Parameter Prim Type String-length Length-1 Length-2

int INTEGER Number of octets

required to represent, in 2's

complement

format, the largest

integer to be

passed

bit BIT STRING Number of bits in string (non-varying)

ia5 IA5STRING Max number of

characters in string

graphic Graphic String Max number of

characters in string

general General String Max number of

characters in string

octet OCTET

STRING

Max number of

octets in string

privateclassnumDerFloating Point

Number

The minimum

number of bits

recjuirea lo oe

maintained in the

mantissa for

relative precision

Number of bits

required to

represent ine

largest

unbiased

integer

exponent in 2's

complement

univer-time UTCTime <not applicable >

gen-time Generalized

Time

<not applicable >

boolean BOOLEAN <not applicable >

null NULL <not applicable >

NOTE - The string length parameter specifies the actual number of from the referenced character set. It does

not include any escape sequences or overhead from the encoding.

12
part 9 - FTAM Phase 2 September 1991 (Stable)

jrhe primitive data types and minimal size ranges tliat an implementation must accept for storage are given

= n table 3.

Table 3 - FTAM primitive data types

iiiiiiiiw woia 1 yuv iviinirnuni nanyo ^wcxcis^

ASN.1 INTEGER 1 - 2 ASN.1 BIT STRING 0-1

ASN.1 lASString 0- 134

ASN.1 GeneralString 0- 134

ASN.1 GraphicString 0-134

ASN.1 OCTET STRING 0-512

ASN.1 BOOLEAN

ASN.1 NULL

ASN.1 GeneraiizedTlme

ASN.1 UniversalTime

NBS-AS1 FloatingPointN umber mantissa 1-23 bits exponent 0-8 bits

NOTES

1 The primitive data types and their maximum ranges for a specific file as described by the parameters above

are maintained in the < contents type> file attribute. The < contents type> file attribute value is established

at the file's creation and cannot be changed via FTAM for the life of the file. This implies that the data element

types and ranges and data unit formats are fixed for all accessors of that file as long as the file exists.

2 The syntax for floating point numbers is part of the definition of NBS abstract syntax ASI in annex C.3. It

is derived from existing standards lEC 559 and IEEE 754.

10.1 Character set

implementation of a cliaracter set in FTAM is understood as:

a transfer syntax is defined for tlie character set

document types are defined using the character set in their abstract syntactic definition

documents of those types are stored in the Virtual File Store as defined in the character set

specification. They are written into the VFS and read from the VFS as defined by the abstract

syntax and the transfer syntax for the document type. It is not in the scope of FTAM Agreements

to specify the local representation of those documents in the Real Filestore, nor to specify rendition

of graphic characters or control characters on character imaging devices. These renditions are possible agreements between applications using FTAM for their communication.

13

Part 9 - FTAM Phase 2 March 1991 (Stable)

10.1.2 Format effectors

When a single format effector for vertical (or horizontal) movement is optionally permitted to effect a combined vertical and horizontal movement, implementations shall not use the single format effector for

1 effecting the combined vertical and horizontal movement. It is recommended that NfST Implementations

i use <CR><LF> pairs as line terminators. Failure to follow this recommendation may result in an

j Implertientation which does not interoperate with other implementations conforming to these agreements;

NOTES

1 For further information see ISO 646:1983, clauses 4.1.22 and 6.4, ISO 6429:1988, clause E.1.2 and ISO

j 4873:1986, clause A.3.2.

2 The Agreements require only support of CO control characters of ISO 646, containing among others the format effectors <CR> and <LF>. I t i s r ecommended that N I ST i mple mentati ons use <CR> <LF^ pai rs as

li ne terminators.

10.1.3 8859-1 Character set

The Latin Alphabet No.1 (ISO 8859-1) is used to specify the printable characters of GO and Gl. CO control characters and their associated rules are taken from the ISO 646 definition.

10.2 Document type Negotiation rules

10.2.1 Connection establishment

In connection establishment the < contents type list> parameter is used only to establish presentation

contexts. Both the < document type name> form and the < abstract syntax name> form are supported for Responders; they are optionally supported for Initiators.

15
Part 9 - FTAM Phase 2

10.2.2 File creation

An <F-CREATE request> FPDU must contain a <document type name> value in its < initial attrlbutes> parameter.

If the specified document type requires parameterization, then these parameters must be supplied, otherwise

the <F-CREATE request> may be rejected.

NOTES

1 It is understood that < permitted actions> sub-field of < initial attributes> parameter will always be used at <F-CREATE request>. The value may be changed by the Responder.

2 If the < document type name> used requires DU syntax parameters and one of the parameters specifies

'FIoatingPointNumber' as a primitive data type, the request may be rejected, in case the optional type 'FioatingPointNumber' is not supported by the Responder.

10.2.3 File opening

The < document type name> form (with appropriate parameters as specified in 8871-2, clause 12.3) shall always be used when proposing a < contents type>; as an alternative the 'ContentsTypeUnknown' value

may be used in the <F-OPEN request >. An <F-OPEN response > shall use the < document type name>

option (with appropriate parameters) in the < contents type> field.

This allows the receiving entity to use the < document type name> attributed to the file Instead of receiving a < constraint set name> and < abstract syntax name> pair, which does not reflect the file information

contained in the FTAM and NBS document types.

This document type name is either a value from the set of base document type names as negotiated upon

connection establishment or a document type name, for which an appropriate presentation context was

established.

NOTES

1 An <F-OPEN response> without a < document type name> (but carrying the <constraint set name> and

obstract syntax name> form) may cause the Initiator to issue an <F-CLOSE request>.

2 If the < document type name> used requires DU syntax parameters and one of the parameters specifies

'FioatingPointNumber' as a primitive data type, the request may be rejected, in case the optional type

'FioatingPointNumber' is not supported by the Responder.

10.3 Reiationship between DUs, DEs and document types

"Abstract Syntax" is used to refer to the syntactic information which is architecturally passed between the Application and Presentation Layers. The Abstract Syntax defines Data Element (DE) types which are not necessarily ASN.1 primitive types. A Data Element (DE) is the smallest piece of data whose identity is

16
I

Part 9 - FTAM Phase 2 December 1990 (Stable)

necessarily preserved by the Presentation Service. Data types may be made up of otiier data types. Data

Elements are not defined in terms of other Data Elements.

' A Data Unit (DU) is a sequence of one or more Data Elements. Architecturally, entire, single DEs are passed

into and out of the application process. In a real implementation, DUs may be passed.

'I To maintain DU boundaries during transfer, file structuring information must be passed (IS08571-FADU

j definition in ISO 8571-2, clause 7.5). A Data Element is referred to as a File-Contents- Data-Element in the

j 1808571 -FADU definition.

Document types refer to aspects of local processing and storage. They describe:

- structural relationship between DUs,

! - structure of DUs, called DU syntax, and

J - DE types found in the file

Because document types pertain to local processing and storage, the DU syntax makes assertions about

the syntax and the size of DUs (records) in storage. Parameters on the document types provide this information about the syntax and size of the DUs.

When an F-CANCEL is sent or received, the following occurs:

- no more data is sent,

- checkpoint numbers are removed, and

- state of the file is implementation dependent.

NOTE - When mapping F-CANCEL on P-RESYNCHRONIZE (abandon) it is required that P-SYNC-MINOR be

used after F-READ/ F-WRITE (see ISO 8571-4 clauses 13, 14).

12 Implementation information agreements

The < implementation information > parameter of <F-INITIALIZE> FPDU is not required by these

Agreements.

It may be used to pass user version information as a series of values, separated by ';'

The following will indicate conformance to the NIST Phase 2 Agreements: NBS-Phase2.

11 F-CANCEL action

17
Part 9 - FTAM Phase 2 December 1990 (Stable)

NOTE - The list of possible values may be enlarged for future FTAM phases or FTAM profiles of other bodies.

^

This parameter is for information on!y; It Is not used for negotiation.

The establishment of an FTAM regime should not be rejected only because of an unknown < implementation

information > value.

13 Diagnostic agreements

The <diagnostic> parameter is supported; a value in the <response> PDU is needed when the <action

result > or < state result > is not zero. (The nature of these agreements Is to provide <diagnostic>

information when any result parameter is not 'success'.)

General catch-all diagnostic action is discouraged.

The <further details> subfield is supported. It will be encoded as GraphlcString, but is restricted to ISO 646

(IRV, graphic characters) and ISO 8859-1 only.

Use of F-P-ABORT for other than protocol errors and catastrophic situations is discouraged.

When returning an error status in a file management related diagnostic (i.e., <F-READ-ATTRIBUTE

response> or <F-CHANGE-ATTRIBUTE response>), Identify the erroneous attribute by using the first two

characters of < further details > to hold a 2-digit number (encoded as lASString) from the

<F-READ-ATTRIBUTE request> attributes abstract syntax definition (ISO 8571-4, clause 20.3).

00 Filename

01 Permitted Actions

02 Contents Type

03 Storage Account

04 Date and Time of Creation

05 Date and Time of Last Modification

06 Date and Time of Last Read Access

07 Date and Time of Last Attribute Modification

08 Identity of Creator

09 Identity of Last Modifier

10 Identity of Last Reader

11 Identity of Last Attribute Modifier

12 File Availability

13 File Size

14 Future Filesize 15 Access Control

16 Legal Qualifications

17 Private Use

The set of file management diagnostics, found in ISO 8571-3 annex A, must be supported.

18
Part 9 - FTAM Phase 2 December 1990 (Stable)

In the case where a specific parameter can in no way be acconnmodated then the request fails and a <diagnostic> indicating one such parameter should be returned by the responder. In the case where a

negotiable parameter cannot be accommodated with exactly the value requested but is negotiated to a

different value (as defined in the standard) then the request formally succeeds but informative < diagnostics >

indicating those parameters negotiated should be returned.

In order to provide for robust applications using FTAM, well defined and precise diagnostics are required

to be returned by responding implementations whenever an action cannot be carried out precisely as

requested with respect to non-negotiable parameters. All such applicable diagnostics will be returned in those cases. An action is carried out precisely as requested with respect to a parameter when the value

of that parameter on the < request > FPDU is equal to the value in effect during or subsequent to the action,

depending on whether the action is regime control.

Diagnostics exist to signal 'parameter not supported' and Responder implementations shall issue all appropriate diagnostics. The < further details > subfield of the <diagnostic> parameter shall specify the

parameter which is not implemented.

14 Concurrency

The < concurrency control > used by default on actions requested by an <F-SELECT indication > or <FCREATE indication > service are:

- 'shared' for read and read attribute

- 'exclusive' for all other actions

The default for actions not requested is specified as 'not required' as per ISO 8571-3.

NOTE - A local implementation may choose to be more restrictive in order to assure file consistency for concurrent accessors.

FADU locking is not required.

15 Requested access

The < requested access > parameter on <F-SELECT> or <F-CREATE> is used to specify the actions which

the Initiator may perform during the file selection. The value of the < requested access > parameter is compared by the Responder to the < access control > and < permitted actions > file attributes and

concurrency controls (including those requested by the Initiator) currently in place on the file. If the value

of the < requested access > parameter is not consistent with either < access control >, < permitted actions >, or concurrency controls in place, then the <F-SELECT> or <F-CREATE> must be rejected.

<requested access> is consistent with <access control > if, for each action requested, that action either requires no password, or the required password has been specified on the <F-SELECT request> or <FCREATE request >.

19
Part 9 - FTAM Phase 2 December 1990 (Stable)

< requested access> is consistent with < permitted actions> if, for each action requested, that action is allowed by the < permitted actions > file attribute.

< requested access > is consistent with < concurrency control > requested on the <F-SELECT> or <FCREATE> if, for each action requested, that action has not been specified as 'not required' or 'no access'

in the < concurrency control > parameter.

< requested access > is consistent with concurrency controls in place on the file if for each action requested no other accessor of the file has set the concurrency control for that action to either 'exclusive' or 'no access'.

16 Security

16.1 Initiator identity and filestore password

The < initiator identity > and <filestore password > parameters for an implementation acting as an Initiator are supported. These parameters are optional for an implementation acting as a Responder.

The syntax of < initiator identity > and <filestore password > is system-dependent. < initiator identity > and

<filestore password > will represent account information on the local system, which may be different from

the < account > parameter.

16.2 Access passwords

The < access passwords > and < create password > parameters for an implementation acting as an Initiator are supported if the Security Group of attributes is supported. These parameters for an implementation

acting as a Responder are optionally supported if the Security Group is supported.

16.3 Implementation responsibilities

It is the responsibility of each local system to provide security for its own real filestore. Encryption of passwords will not be done by FTAM.

A user of the file service must be known by the Responder. "Known" is defined by the local Filestore, and

is dependent on the level of security provided by the local Filestore.

17 Requirement for conformant implementations

This clause gives the criteria to be satisfied by every implementation of FTAM that conforms to these

Agreements.

20
Part 9 - FTAM Phase 2 September 1991 (Stable)

Conformance to these Agreements is stated in terms of tlie different roles occupied by FTAM

Implementations. The interoperability of certain configurations of these roles motivates this approach.

Interoperable configurations of these roles are given in 17.1.

The only function provided by every conformant implementation is the transfer of unstructured binary files

j in their entirety. It must be recognized that such simple transfer, while commonly understood and generally

I important, will not support all applications of FTAM. Clause 18 defines Implementation Profiles of FTAM

I services and protocol that can provide other specific functions. Those other functions exploit the access

j and management capabilities of FTAM. The unconstrained service class (with appropriately chosen functional

! units) can be used to provide the functions of any of the Implementation Profiles. Users of FTAM must

consider carefully what functions they require. They must examine all the Implementation Profiles and select according to their needs.

Implementation conforming to these Agreements require adherence to the General Agreements in clauses

5 through 16 of these Agreements.

l^mp^enientations conforming to these agreemems shall im|:Memenf the defect report solutions contained mi

tSO 8571

t$08571

-1/Cor<t:1990

-2/CQf.tt1990

ISO B67t »a/Cor>1:1990

ISO 857f-4/Cor.t:1990

! tSO 8571 -3/CQr.2t1 990

fSO 8$7t-4/Cor.a:1990

Editor's l4ote - The corrigmda ISO 857i'3/Cof.2 ancJ ISO ^7l-4/Cof.2 to be published, until it j$ ItvaJlahl^, the $oluftor»& csn be found In the documents t$0/l£C .ITCl/$C2 1 N 5234 and ISO/IEG JTC1 /$C2$

17.1 Interoperable configurations

Any implementation conforming to this specification must be able to act in at least one of the following role

Ij combinations:

1 . initiator and receiver,

2. Initiator and sender,

3. responder and sender,

I 4. responder and receiver.

Minimal Implementations of combination 1 will interoperate with minimal implementations of combination 3. Minimal implementations of combination 2 will interoperate with minimal implementations of combination 4.

21
Part 9 - FTAM Phase 2 September 1991 (Stable)

Any implementations of roles 1 and 3 will be able to interoperate at the intersection of their capabilities

(which will be at least the minimal capabilities described in 17.3 to 17.8). Any implementations of roles 2 and 4 will be able to interoperate at the intersection of their capabilities (which will be at least the minimal

capabilities described in 17.3 to 17.8).

These role combinations and this interoperability are shown in table 5 below.

Table 5 - Interoperable configurations.

InHlator Responder

sender receiver sender receiver

initiator sender X

receiver X

Responder

sender X

receiver X

17.2 Relationship to ISO 8571 -The FTAM Standard

Any implementation in conformance to ISO 8571 (as defined in ISO 8571-4, clause 22 (Conformance)), in addition to the implementation of the minimal protocols and roles enumerated in subclauses 17.3 to 17.8,

is considered to be in conformance with these Agreements. Any implementation violating any of the conformance statements in ISO 8571-4 is considered to be in violation of these Agreements.

17.3 Requirements for document type support

The document type FTAM-3 shall be supported for purposes of transfer and storage. The details regarding

support for FTAM-3 in the FTAM dialogue are given in clause 10.

Support of document types other than FTAM-3 is not required for conformant implementations. Support

for document types described in these Agreements also entails support for:

the semantics given in their description and further qualified in clause 10

the preferred transfer syntax "Basic Encoding of a single ASN.1 type"

22
Part 9 - FTAM Phase 2 September 1991 (Stable)

9 17.4 Initiators

' Every implementation of an FTAM Initiator shall support:

' the kernel protocol and its nnandatory parameters with minimum ranges [Minimum required ranges

are specified in 17.8.],

j the grouping protocol and the <threshold> parameter with a value of at least 2 for use in the file

I transfer class,

22-1
I

i

\

i
Part 9 - FTAM Phase 2 December 1990 (Stable)

Should the supporting services break down, such that FTAM communication is impossible, the FTAM

protocol machine shall notify the user with an <F-P-ABORT indication> and <diagnostic> with identifier 1011, as well as inform the user of any known <further details>.

17.6 Senders

Every implementation of an FTAM sender shall support the read functional unit as Responder or the write

functional unit as Initiator, and support the applicable procedures defined in ISO 8571-4 clauses 11 (State

of the bulk data transfer activity), 12 (Bulk data transfer protocol data units), 15 (Bulk data transfer sending

entity actions), 17.1 (Discarding), and 17.2 (Cancel).

To support those procedures the Implementation shall be able to send files of the document type FTAM-3

and shall be able to send them as user data in PPDUs In blocks of up to 7168 octets.

17.6.1 Initiator Senders

Every implementation of an FTAM sender which is also an FTAM Initiator shall support:

- the write functional unit and protocol, and

- for the document type FTAM-3 the following bulk data transfer specification parameters:

- FADU operation replace

- FADU identity first

and support the applicable procedures, defined in ISO 8571-4 clause 13 (Bulk data transfer

initiating entity actions).

17.6.2 Responder Senders

Every implementation of an FTAM sender which is also an FTAM Responder shall support:

- the read functional unit and protocol, and

- for the document type FTAM-3 the following bulk data transfer specification parameters:

1) FADU identity first

2) Access context UA

and support the applicable procedures, defined in ISO 8571 -4 clause 1 4 (Bulk data transfer responding entity

actions).

25
Part 9 -

17.7

FTAM Phase 2

Receivers

December 1990 (Stable)

Every implementation of an FTAM receiver shall support the read functional unit as Initiator or the write functional unit as Responder, and support the applicable procedures, defined in ISO 8571-4 clauses 11 (State of the bulk data transfer activity), 12 (Bulk data transfer protocol data units), 16 (Bulk data transfer receiving entity actions), 17.1 (Discarding), and 17.2 (Cancel).

To support those procedures the implementation shall be able to receive files of the document type FTAM-3

and shall be able to receive them as user data in PPDUs in blocks of at least 7168 octets.

17.7.1 Initiator Receivers

Every implementation of an FTAM receiver which is also an FTAM Initiator shall support:

- the read functional unit and protocol, and

- for the document type FTAM-3 the following bulk data transfer specification parameters:

1) FADU identity first

2) Access context UA

and support the applicable procedures, defined in ISO 8571-4 clause 13 (Bulk data transfer initiating entity

actions).

17.7.2 Responder Receivers

Every implementation of an FTAM receiver which is also an FTAM Responder shall support:

- the write functional unit and protocol, and

- for the document type FTAM-3 the following bulk data transfer specification parameters;

1) FADU operation replace

2) FADU identity first

and support the applicable procedures, defined in ISO 8571 -4 clause 1 4 (Bulk data transfer responding entity

actions).

26
Part 9 - FTAM Phase 2 December 1990 (Stable)

17.8 Minimum ranges

Any implementation of any conformant FTAM configuration sfiall be able to receive and meaningfully process

all mandatory parameters for all functional units supported as well as the <diagnostic> parameter within

at least the minimum ranges of values given in table 6. A conforming implementation may support a wider

range of values for any parameter.

27
Part 9 - FTAM Phase 2

Table 6 - Required minimal parameter support

December 1990 (Stable)

Parameter Minimum Range

general diagnostic Values as specified in ISO 8571-3 annex A

(Diagnostic parameter values) tables 44, 45

and 46 which correspond directly to

mandatory parameters.

action result Mil values

state result All values

Tunciionai uniis 'read' (for initiator/receivers and

responder/senders) and 'grouping'

or

'write' (for initiator/senders and

responder/receivers) and 'grouping'

presentation context

1 1 lai laycll ici U

'False'

all Others As specified in 17.4 and 17.5 above

F-SELECT attributes Only <fi!ename> is used with a minimum

supportable length of 8 characters. Any

other attribute supported for other services

must have minimum supported lengths as

in ISO 8571-2 clause 15 (Minimum attribute

ranges), table 2.

requested access 'read' for initiator/receivers

'read' for responder/senders

'replace' for initiator/senders

'replace' for responder/receivers

F-CREATE override For Responders, the values 'create-failure',

'select-old-file' and 'delete-and-create-withnew-attributes' are supported. The value

'delete-and-create-with-old-attributes' is optionally supported. All values are optional

for Initiators.

28
Part 9 - FTAM Phase 2 December 1990 (Stable)

Table 6 - Required minimal parameter support, (concluded)

Parameter Minimum Range

F-OPEN processing mode 'read' for initiator/receivers

'read' for responder/senders

'replace' for initiator/senders

'replace' for responder/receivers

contents type 'FTAM-3'

F-READ FADU identity 'first'

access context 'UA'

F-WRITE FADU operation 'read' for initiator/receivers

'read' for responder/senders

'replace' for initiator/senders

'replace' for responder/receivers

FADU identity 'first'

F-BEGINGROUPthreslnold^ For file transfer (a minimal required

function) 2

For any other supported parameters, minimum ranges are taken from the minimum ranges for the attribute corresponding to each as in ISO 8571-2 table 4.

NOTES

1 The parameters, functional units, and presentation context management are not ordered, so "minimum

value" cannot be formally defined. The above values are those required for conformance to these Agreements

but no value conformant to ISO 8571 for use in other applications is regarded to be in violation of these

Agreements.

2 Other functional units (and service classes) for defined implementations may also be valid provided that they

are implemented in accordance with these Agreements, specifically subclause 1 7.8.

3 Every implementation must support the < threshold > value 2 to provide the basic required function of file transfer; any other value in other applications is acceptable.

29
Part 9 - FTAM Phase 2 December 1990 (Stable)

|

17.9 Range of values for INTEGER type parameters

The general range for parameters of type INTEGER to the FTAM PCI is as specified in the UNIVERSAL

ASN.1 ENCODING RULES clause of the Upper Layers part.

, The parameters

^

- FTAM Attributes |

X

- filesize ^

- future-filesize I

- FADU-ldentity I

- fadu-number 1

may be encoded so that the length of its contents octets is no more than eight octets.

In the case of receiving more than 4 contents octets, the receiver may reject the corresponding FTAM PDU.

NOTE - To guarantee interworking, encoding should be restricted to the range -2^^ to 2^^-1.

j |

\ 17.10 Use of lower layer services

Support for the Presentation Context Management functional unit is not required.

implementations will support the Session, Presentation, and ACSE requirements as stated in part 5 of this document. i NOTE - Implementation of the Session Resychronize and the Minor Synchronize functional units is highly

' recommended, since the F-CANCEL service may be less effective v\/hen mapped to S-DATA.

18 Implementation Profiles

This clause defines Implementation Profiles for the specific functions of:

- File Transfer

- File Access

- File Management

30

m
Part 9 - FTAM Phase 2 December 1990 (Stable)

Those definitions are expressed in terms of:

- Document Types

- Attributes

- Service Classes (both service elements and their parameters).

This by no means defines all possible Implementation Profiles. The following Implementation Profiles are

defined:

- T1 : Simple File Transfer

- T2 : Positional File Transfer

- T3 : Full File Transfer

- A1 : Simple File Access

- A2 : Full File Access

- M1 : Management.

Implementation Agreements have been reached for the following service classes.

- File Transfer

- File Access

- File Management

- Unconstrained

- File Transfer and Management

NOTE - Any given implementation may support more than one service class.

Support of an Implementation Profile requires adherence to:

- corresponding definition in 8571-3 clause 8 and any related procedures in 8571-4

clause 8-17,

- requirements given in clauses 5-18 of these Agreements, and

- requirements for parameter and attribute support as defined in 17.8.

31
Part 9 - FTAM Phase 2 December 1990 (Stable)

18.1 General requirements for the defined Implementation Profiles

Implementations will be able to act either as Initiator or Responder or both.

Implementations must support diagnostics as described in clause 13 of these Agreements.

Implementations that support the file access service class will support access to sequential files. Support

of sequential files entails hierarchy of depth and arc length equal to 1 . Other hierarchy depth and arc lengths are not precluded by these agreements.

18.2 (deleted)

18.3 Document type requirements for the defined Implementation

Profiles

Implementations conformant to Implementation Profiles defined in table 7 will support the following

document types with the caveats and procedures given.

- FTAM-1

- FTAM-2

- FTAM-3

- NBS-6

- NBS-7

- NBS-8

- NBS-9

NOTES

1 Support of this document type entails the naming of FADUs by their position in preorder traversal.

2 Caveat: Other methods of naming FADUs depend on the system, application, and specific file, and as such

are not described here.

3 Those document types are defined in annex A and clause 10 of these Agreements, and in ISO 8571-2.

Support for any document type requires the ability to transfer and store the abstract syntax given in its definition. These Agreements do not specify techniques or formats for storage.

32
Part 9 - FTAM Phase 2 December 1990 (Stable)

NOTE - Specific abstract syntaxes for the parameterized document types NBS-6,7,8 are not specified in these

Agreements.

Any document type supported must be identifiable by its document type name as given in ISO 8571-2 and

in annex A of these Agreements and, where defined, the parameterization scheme given in clause 10 of these Agreements.

For conformance to NBS-9 a Responder is only required to return the <filename> attribute, subject to local security and access control. All other requested attributes need not be returned.

Systems supporting the NBS-9 document type shall make available an NBS-9 document called 'DIRLIS'. This document can be used to obtain a listing of files and their associated attributes from a remote Filestore.

Creation and deletion of NBS-9 files are outside the scope of these Agreements.

File security issues related to NBS-9 are subject to the security agreements outlined in clause 16.

18.4 Parameters for the defined Implementation Profiles

1 Implementations will support the <contents type list> parameter on the <F-INITIALIZE> service element.

The initiating service must supply a value for this fDarameter.

Implementations will support the <diagnostic> parameter as stated in clause 13 of these Agreements.

j The < initiator identity > parameter is supported. Use must be consistent with clause 16 of these

' Agreements.

I Implementations are not precluded from using other parameters for security and/or accounting. Responders

! must state the syntax and the semantics applying to < account > and < charging > parameters. The

Responder's minimum implementation is to accept but ignore the < account >.

18.5 Parameter ranges for the defined Implementation Profiles

Parameter ranges for Implementations Profiles are as stated for primitive data types in clause 10 of these

Agreements.

18.6 File attribute support for Implementations

Implementations of the Implementation Profiles will support file attributes or attribute groups in the following

ways:

a) mandatory - This feature is mandatory in the ISO 8571-2 standard and shall therefore

be implemented by all implementations claiming conformance to these Agreements;

33
Part 9 - FTAM Phase 2 December 1990 (Stable)

b) supported - This feature shall be implemented by all implementations claiming

conformance to these Agreements (for attributes, this implies that at least the minimum

range of attribute values, as defined in ISO 8571-2 clause 15, shall be supported).

Conformant implementations shall also be able to interwork with other implementations

that do not support this feature by negotiating out the corresponding features;

c) optionally supported - Implementations claiming conformance to these Agreements

may or may not implement this feature (for attributes, this implies that at least either the

minimum range of attribute values, as defined in ISO 8571-2 clause 15, shall be

supported or that the 'no value available' result shall be supplied). If an attribute group

with a support level of 'optionally supported' is chosen to be supported, then all the

attributes of this group that are classified as 'mandatory' or 'supported' shall be

supported;

d) not supported - This feature is outside the scope of these Agreements.

34
Part 9 - FTAM Phase 2 December 1990 (Stable)

Kernel Group

Filename

Permitted Actions

Contents Type

mandatory

mandatory

mandatory

mandatory

Storage Group

Storage Account

Date and Time of Creation

Date and Time of Last IVIodification

Date and Time of Last Read Access

Date and Time of Last Attribute Modification

Identity of Creator

Identity of Last Modifier

Identity of Last Reader

Identity of Last Attribute Modifier

File Availability

Filesize

Future Filesize

optionally supported

optionally supported

optionally supported

optionally supported

optionally supported

optionally supported

optionally supported

optionally supported

optionally supported

optionally supported

supported

supported

optionally supported

Security Group

Access Control

Legal Qualifications

optionally supported

supported

optionally supported

Private Group not supported

35
Part 9 - FTAM Phase 2 December 1990 (Stable)

Table 7 - Implementation profile support requirements

Functional Units

Service Classes (see note 8)

T M A TM Unconstrained

Kernel T1 , 12, 13 Ml A1, A2

see

note 4

see

note 5

Read (see note 3) T1 , T2, T3 A1, A2

Write (see note 3) 11 , 12, T3 A1, A2

Limited File

Management

see note 6 Ml see note 6

Enhanced File

Management

Ml

Grouping T1 , T2, 13 Ml

File Access A1, A2

Document Types

FTAM-1 11 , T2, T3 [Ml] A1, A2

FTAM-2 12, 13 [Ml] A1, A2

FTAM-3 71 , 12, T3 [Ml] A1, A2

NBS-6 [T2], 73 [Ml] [A1], A2

NBS-7 [72], 73 [Ml] [A1], A2

NBS-8 73 [Ml] A2

NBS-9 [T1], [72],

[73]

[Ml]

NOTES

to 18.3 and table 7

1 The Management Implementation Profile is only to be implemented in conjunction with one of the Transfer or Access Profiles.

2 Profile T2 is subset of T3. A1 and T1 are subsets of A2 and T2, respectively.

3 Profiles T1, 12, and T3 require the support of read and/or write functional units.

36
Part 9 - FTAM Phase 2 December 1990 (Stable)

4 Support of the <File Transfer and Management> service class is optional. The rules for including it in a

request and for the response to it are as given in ISO 8571-3, clause 10.1. Any implementation including TM

in the request must be prepared for the possibility that it might be removed from the response.

5 The support of the < Unconstrained > service class is outside the scope of these Implementation Profiles.

6 Limited File Management is not required for the T- and A- Implementation Profiles, but very often it be

a user request to have limited file management functionality available together with file transfer and file access

functions. So Limited File Management may be added as an option to the T- and A- Implementation Profiles.

7 [ ] in table 7 specifies that the document type is optional for the respective Implementation Profile. For M1

the support level depends on the T- or A- Implementation Profile, in conjunction with which Ml is implemented.

8 The Implementation Profiles specify functionality which includes the requirements for conformant

implementations as specified in clause 1 7. This is a general basic requirement and is not also reflected in table

7.

19 PROVISION OF SPECIFIC FUNCTION

19.1 Implementation Profile T1 : Simple File Transfer

Implementation Profile T1 provides the function of transferring entire files at the external file service level for

files with an unstructured constraint set. This includes support of the document types:

- FTAM-1 "ISO FTAM unstructured text"

- FTAM-3 "ISO FTAM unstructured binary"

- NBS-9 "NBS-9 file directory file" (optional)

This Implementation Profile supports file transfer and not file access, that is, the ability to

- read a complete file, and/or

- write (replace, extend) to a file.

19.2 Implementation Profile T2: Positional File Transfer

Implementation Profile T2 provides the function of transferring files at the external file service level for files with an unstructured or flat constraint set. This includes support of the document types:

- FTAM-1 "ISO FTAM unstructured text"

- FTAM-2 "ISO FTAM sequential text"

37
Part 9 - FTAM Phase 2 December 1990 (Stable)

- FTAM-3 ISO FTAM unstructured binary'

- NBS-6 NBS-6 FTAM sequential file" (optional)

- NBS-7 NBS-7 FTAM random access file' (optional)

- NBS-9 NBS-9 file directory file" (optional)

This Implementation Profile supports file transfer and not file access, that is, the ability to

- read a complete file or a single FADU which is identified by position, and/or

- write (replace, extend, insert depending on constraint set and document type) to a file or an FADU.

This Implementation Profile is upwardly compatible to T1 for the transfer of unstructured files.

19.3 Implementation Profile T3: Full File Transfer

Implementation Profile T3 provides the function of transferring files at the external file service level for files with an unstructured, flat or general hierarchical constraint set. This includes support of the document

types:

- FTAM-1 "ISO FTAM unstructured text"

- FTAM-2 "ISO FTAM sequential text"

- FTAM-3 "ISO FTAM unstructured binary"

- NBS-6 "NBS-6 FTAM sequential file"

- NBS-7 "NBS-7 FTAM random access file"

- NBS-8 "NBS-8 FTAM indexed file"

- NBS-9 "NBS-9 file directory file" (optional)

This Implementation Profile supports file transfer and not file access, that is, the ability to

- read a complete file or a single FADU which is identified by key or by position, and/or

- write (replace, extend, insert depending on constraint set and document type) to a file or an FADU.

This Implementation Profile is upwardly compatible to T1 for the transfer of unstructured files.

38
Part 9 - FTAM Phase 2 December 1990 (Stable)

19.4 Implementation Profile A1: Simple File Access

Implementation Profile A1 provides the function of transfer of and access to files witfi unstructured or flat constraint sets at the external file service level. This includes support of the document types:

- FTAM-1 "ISO FTAM unstructured text"

- FTAM-2 "ISO FTAM sequential text"

- FTAM-3 "ISO FTAM unstructured binary"

- NBS-6 "NBS-6 FTAM sequential file" (optional)

- NBS-7 "NBS-7 FTAM random access file" (optional)

This Implementation Profile supports file transfer and file access, that is the ability to

- read a connplete file or FADUs which are identified by position,

- write (replace, extend, insert depending on constraint set and document type) to a file or an FADU,

- locate and erase within files.

19.5 Implementation Profile A2: Full File Access

Implementation Profile A2 provides the function of transfer of and access to files with unstructured or flat constraint sets at the external file service level. This includes support of the document types:

- FTAM-1 "ISO FTAM unstructured text"

- FTAM-2 "ISO FTAM sequential text"

- FTAM-3 "ISO FTAM unstructured binary"

- NBS-6 "NBS-6 FTAM sequential file"

- NBS-7 "NBS-7 FTAM random access file"

- NBS-8 "NBS-8 FTAM indexed file"

This Implementation Profile supports file transfer and file access, that is, the ability to

39
Part 9 - FTAM Phase 2 December 1990 (Stable)

- read from a complete file, or from a series of FADUs which are identified by key or by

position,

- write (replace, extend, insert depending on constraint set and document type) to a file or an FADU,

- locate and erase within files.

19.6 Implementation Profile M1 : Management

Implementation Profile M1 provides the function for an Initiator to manage the files within the Virtual Filestore, to which access is provided by the Responder. Management includes the services of:

- creating a file

- deleting a file

- reading attributes of a file

- changing attributes of a file.

20 Harmonization

The Implementation Protiles for File Transfer, File Access and Management correspond to the Profiles of SPAG (Standards Promotion and Application Group) in Europe, so that interworking will be possible. Those

Profiles are described in the 'Guide to the Use of Standards' (GUS); they are the basis for the Functional

Standards as defined by CEN/CENELEC (Comite Europeenne de Normalization).

Table 8 - Implementation Profiles (NIST) and Profiles (SPAG/CEN-CLC)

Implementation Profile SPAG / CEN-CENELEC

T1 A/111

T2 A/112

T3 A/113

A1 A/ 122

A2 A/ 123

M1 A/13

40
Part 9 - FTAM Phase 2 September 1991 (Stable)

Annex A (normative)

FTAM Document Types

thd obiecte defi nad i» A^Hirough AA^ 9^^, <X3 and 0.4 beremoved from this document

after ISO/lEC ISP 10607*2 end tSO/$eC 1^ %Q&Sr-2/AmtiA «Pe puWj$h«d< Dt^Jng the pertod between

publishing ihe i$P aitd renfio«Ed of the di^nitions kom this 4[locument, the defini^ons in the ISP will take precedencsa

and C.2 vm9 changed to point

When

tolhd

me ob|ect <;jeiitni^n& are removed, claoeee At through ^i^j^Af^C^^

mm

The objects defined in A.5 through A.8, B.2, C.3 and C.4 will be removed from this document after ISO/lEC

j ISP 10607-2 and ISO/lEC ISP 10607-2/Amd.1 are published. During the period betweem publishing the ISP

and removal of the definitions from this document, the definitions in the ISP will take preceedence over this

j document. When the object definitions are removed, clauses A.1 through A.4, B.1, C.I and C.2 will be

' changed to point to the ISP.

; A.1 NBS-6 Sequential file document type

This object with Object Identifier

{iso identified-organization icd(9999) organization-code(1 ) document-type(5) sequential (6)}

was withdrawn on March 16, 1990. It was replaced with the object NBS-6 Sequential file document type

with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document-type(5) sequential (6)}

defined in part 9, A.5.

i A.2 NBS-7 Random access file

1 This object with Object Identifier

I {iso identified-organization icd(9999) organization-code(1 ) document-type(5) random-file(7)}

was withdrawn on March 16, 1990. It was replaced with the object NBS-7 Random access file document

type with the Object Identifier

j {iso identified-organization oiw(14) ftamsig{5) document-type(5) random-access(7)}

defined in part 9, A.6.

41
Part 9 - FTAM Phase 2 September 1991 (Stable)

A.3 NBS-8 Indexed sequential file

This object with Object Identifier

{iso identified-organization icd(9999) organization-code(1 ) document-type(5) indexed-file(8)}

was withdrawn on March 16, 1990. It was replaced with the object NBS-8 Indexed sequential file document

type with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document-type(5) indexed-file(8)}

defined in part 9, A.7.

This object with Object Identifier

{iso identified-organization icd(9999) organization-code(1 ) document-type(5) file directory(9)}

was withdrawn on March 16, 1990. It was replaced with the object NBS-9 File directory file document type

with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document-type(5) file-directory(9)}

defined in part 9, A.8.

A.4 NBS-9 File directory file

A.5 NBS-6 Sequential file document type

A.5.1 Entry Number: NBS-6

A.5.2 Information objects

42
Part 9 - FTAM Phase 2 September 1991 (Stable)

Table 9 - Information objects in NBS-6

document type name {iso identified-organization oiw(14) ftamsig(5) document-type(5)

sequential(6)}

NBS-6 FTAM sequential file"

abstract syntax names:

a) name for asnamel

{iso identified-organization oiw(14)

ftamsig(5) abstract-syntax(2) nbs-as1(1)}

"NBS abstract syntax ASr

b) name for asname2

{iso standard 8571 abstract-syntax(2) ftam-fadu(2)}

FTAM FADU"

transfer syntax names: {joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic Encoding of a single ASN.1 type"

parameter syntax:

PARAMETERS ::= SEQUENCE OF CHOICE {ParameterO, Parameterl, Parameter2}

ParameterO ::= [0] INTEGER {univer-time (23), gen-time (24), boolean (1), null (5) }

Parameterl ::= [1] SEQUENCE {

universal-class-number-1 INTEGER { int (2), bit (3), ia5 (22), graphic (25), general (27), octet (4)},

string-length INTEGER }

Parameter2 ::= [2] SEQUENCE {

private-class-number INTEGER {float (0)},

length-1 INTEGER,

length-2 INTEGER }

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set(4) sequential-ftat(2)}

"FTAM sequential flat constraint set"

file contents:

Datatypel ::= PrimType - as defined in annex C.3 NBS-AS1

Datatype2 ::= Node-Descriptor-Data-Element

43
Part 9 - FTAM Phase 2 September 1991 (Stable)

Mi

A.5.3 Scope and field of application

The document type defines the contents of a file for storage, for transfer and access by FTAM.

NOTE - Storage refers to apparent storage within the Virtual Filestore.

A.5.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and

Management

A.5.5 Definitions

This definition mal<es use of the terms data element, data unit and file access data unit as defined in ISO

8571-1.

A.5.6 Abbreviations

FTAM File Transfer, Access and Management

A.5.7 Document semantics

The document consists of zero, one or more file access data units. Each FADU contains precisely zero or one data unit which consists of zero, one or more data elements. The order of each of these elements is significant.

The document structure takes any of the forms allowed by the FTAM hierarchical file model as constrained

by the sequential flat constraint set (see table 9) These definitions appear in ISO 8571-2. As additional

constraints FADU identity will be limited to 'begin', 'end', 'first' and 'next'.

For a specific file the number of data elements in a data unit is given by the parameters. Each data element

is a data type from the set of primitive data types defined in the annex C.3 of this document. Each data

unit contains the same data element types in the same order as all other data units. These types are determined by the parameters 0 through 2.

For datatype 1, the string length field of Parameterl specifies the length of the value in octets for the

INTEGER, BIT STRING and OCTET STRING types. For character-type data elements, the string-length

indicates the actual number of characters from the specified character set, not including any escape

sequences or overhead from the character encoding.

For floating point numbers, finite form, length-1 and length-2 specify the length in bits of mantissa and

exponent, respectively. The length-1 and length-2 values are irrelevant for the other choices of floating point

44
Part 9 - FTAM Phase 2 September 1991 (Stable)

I A.5.8 Abstract syntactic structure

I The abstract syntactic structure of the document is a hierarchically structured file as defined in the ASN.1

I module IS08571-FADU in ISO 8571, in which each of the file access data units has the abstract syntactic

I structure of NBS-AS1 as defined by the parameters.

i

I A.5.9 Definition of transfer

A.5.9.1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 9, where the PrimType in the datatype is given by the NBS-AS1

definition; or

b) Datatype2 defined in table 9, the ASN.1 datatype declared as "Data-Element" in the ASN.1

module IS08571-FADU.

A.5.9.2 Presentation data values

The document is transferred as a series of presentation data values, each of which is either

a) one value of the ASN.1 datatype "Datatypel," carrying one of the data elements from the

document. All values are transmitted in the same (but any ) presentation context established to support the abstract syntax name "asnamel " or

b) a value of "Datatype2." All values are transmitted in the same (but any) presentation context

established to support the abstract syntax name "asname2".

NOTES

1 Specific carrier standards may impose additional constraints on the presentation context to be used, where

the above permits a choice.

2 Any document type defined in this entry either makes no use of Datatype2, or starts with a Datatype2

transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between

P-DATA primitives, are chosen locally by the sending entity at the time of transmission, and carry no

semantics of the document type. Receivers which support this document type shall accept a document with

any of the permitted transfer options (e.g., document type parameters and transfer syntaxes).

45
Part 9 - FTAM Phase 2 September 1991 (Stable)

A.5.9.3 Sequence of presentation data values

The sequence of presentation data values of type a) and the sequence of presentation data values of types

a) and b) is the same as the sequence of data elements within a Data Unit, and Data Units in the hierarchical

structure, when flattened according to the definition of the hierarchical file model in ISO 8571 -2.

A.5.10 Transfer syntax

An implementation supporting this document type shall support the transfer syntax generation rules named

in table 9 for all presentation data values transferred. Implementation may optionally support other named

transfer syntaxes.

A.5.11 ASE specific specifications for FTAM

A.5.1 1 .1 Si mpli fi cati on and relaxati on pi^(^ur^rSlmpific^^

Structural oi mplifi oati on l oooo i nformati on.

This structurs^ ^rt»pllfIcatlon loses informatior*-

The document type NBS-6 may be simplified to the document type FTAM-3 (allowed only when reading the

file). The octet representation of the transferred data is unpredictable. It will usually correspond to the data

j values as stored in the local Real Filestore of the Responder.

A.5.1 1 .2 Access context selection

A document of type NBS-6 may be accessed in any one of the access contexts defined in the sequential

flat constraint set. The presentation data units transferred in each case are those derived from the structuring elements defined for that access context in ISO 8571-2.

A.5.1 1.3 The INSERT operation

When the <INSERT> operation is applied at the end of flie, the transferred material shall be the series of FADUs which would be generated by reading any NBS-6 document with the same parameter values in access context FA.

46 i
Part 9 - FTAM Phase 2

A.6 NBS-7 Random access file

A.6.1 Entry number: NBS-7

A.6.2 Information objects

September 1991 (Stable)

47
Part 9 - FTAM Phase 2 September 1991 (Stable)

Table 10 - Information objects In NBS-7

document type name {iso identified-organization oiw(14) ftamsig(5) document-type(5)

random-file(7)}

"NBS-7 FTAM random access file"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2)

nbs-as1(1)}

"NBS abstract syntax AS1"

{iso standard 8571 abstract-syntax(2) ftam- fadu(2)}

"FTAM FADU"

transfer syntax names: {joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic Encoding of a single ASN.1 type"

parameter syntax:

PARAMETERS ::= SEQUENCE OF CHOICE {ParameterO. Parameterl, Parameter2}

ParameterO :: = [0] INTEGER {univer-time (23), gen-time (24), boolean (1), null (5) }

Parameterl ::= [1] SEQUENCE {

universal-class-number-1 INTEGER { int (2), bit (3), ia5 (22), graphic (25), general (27), octet (4)},

string-length INTEGER }

Parameter2 ::= [2] SEQUENCE {

private-class-number INTEGER {float (0)},

length-1 INTEGER,

length-2 INTEGER }

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model"

constraint set {iso identified-organization oiw(14) ftamsig(5) constraint-set(4)

nbs ordered-flat(l)}

"NBS ordered flat constraint set"

file contents:

Datatypel :: = PrimType -- ac defined in annex C.3 NiSSsiVSl

Datatype2 :: = CHOICE { Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element }

Exit-Subtree-Data-Element }

48
Part 9 - FTAM Phase 2 March 1991 (Stable)

= A.6.3 Scope and field of application

^ The document type defines the contents of a file for storage, for transfer and access by FTAM.

i j NOTE - Storage refers to apparent storage within the Virtual Filestore.

A.6.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and

Management

A.6.5 Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined in ISO

8571-1.

A.6.6 Abbreviations

FTAM File Transfer, Access and Management

A.6.7 Document semantics

The document consists of zero, one or more file access data units. , each of Each FADU contains precisely zero or me data unit which consists of zero, one or more data elements. The order of each of these

elements is significant.

The document structure takes any of the forms allowed by the FTAM hierarchical file model as constrained

by the NBS-ordered-flat constraint set (see table 10). These definitions appear in annex B.2 of this document.

For a specific file the number of data elements in a data unit is given by the parameters. Each data element

is a data type from the set of primitive data types defined in the annex C.3 of this document. Each data

unit contains the same data element types in the same order as all other data units. These types are determined by the parameters 0 through 2.

For datatype 1^ the string length field of Parameterl specifies the length of the value in octets for the INTEGEPi, BIT STRI NG and OCTET STRING types. For character-type data elements, the string-length

indicates the actual number of characters from the specified character set, not including any escape

sequences or overhead from the character encoding.

For floating point numbers, finite form, length-1 and length-2 specify the length in bits of mantissa and

exponent, respectively. The length-1 and length-2 values are irrelevant for the other choices of floating point

49

)
Part 9 - FTAM Phase 2 March 1991 (Stable)

numbers.

A.6.8 Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically structured file as defined in the ASN.1

module IS08571-FADU in ISO 8571, in which each of the file access data units has the abstract syntactic

structure of NBS-AS1 as defined by the parameters.

A.6.9 Definition of transfer

A.6.9.1 Datatype definitions

The file consists of data values which are of either:

a) Datatypel defined in table 10, where the PrimType in the datatype is given by the NBS-AS1

definition;

b) Datatype2 defined in table 10, the ASN.1 datatype declared as "Data-Element" in the ASN.1

module IS08571-FADU.

A.6.9.2 Presentation data values

The document is transferred as a series of presentation data values, each of which is either

a) one value of the ASN.1 datatype "Datatypel," carrying one of the data elements from the

document. All values are transmitted in the same (but any ) presentation context dofi nod

estali^tshed to support the abstract syntax name "asnamel ";

b) a value of "Datatype2." All values are transmitted in the same (but any) presentation context dofi nod established to support the abstract syntax name "asname2".

NOTES

1 Specific carrier standards may impose additional constraints on the presentation context to be used, where

the above permits a choice.

2 Any document type defined in this entry either makes no use of Datatype2, or starts with a Datatype2

transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between

P-DATA primitives, are chosen locally by the sending entity at the time of transmission, and carry no

semantics of the document type. Receivers which support this document type shall accept a document with

any of the permitted transfer options (e.g., document type parameters and transfer syntaxes).

50
Part 9 - FTAM Phase 2 September 1991 (Stable)

A.6.9.3 Sequence of presentation data values

I The sequence of presentation data values of type a) and the sequence of presentation data values of types

a) and b) is the same as the sequence of data elements within a Data Unit, and Data Units in the hierarchical

structure, when flattened according to the definition of the hierarchical file model in ISO 8571 -2.

A.6.10 Transfer syntax

An implementation supporting this document type shall support the transfer syntax generation rules named

i in table 10 for all presentation data values transferred. Implementation may optionally support other named

transfer syntaxes.

j A.6.1 1 ASE specific specifications for FTAM

A.6.1 1 .1 Simpl ifi cati on and rel axati on Structural simplification

' Structural si mpli fi cati on l oses i nformati on.

This s&ructural simplification loses Informai^n.

The document type NBS-7 may be accessed as a document type FTAM-3 (allowed only when reading the

!i file) by specifying document type FTAM-3 in the < contents type> parameter in <F-OPEN request >, and

I limiting access context to UA on F-READ.

ij

' The octet representation of the transferred data is unpredictable. It will usually correspond to the data

values as stored in the local Real Filestore of the Responder.

! A document of type NBS-7 can be accessed as a document of type NBS-6 (allowed only when reading the

' file) by specifying document type NBS-6 with appropriate data type parameters in the < contents type>

j parameter on the <F-OPEN request >.

i A.6.1 1.2 Access context selection

i A document of type NBS-7 may be accessed in any one of the access contexts defined in the NBS ordered

I flat constraint set. The presentation data units transferred in each case are those derived from the

j structuring elements defined for that access context in ISO 8571-2.

When the < INSERT > operation is applied at the end of file, the transferred material shall be the series of

FADUs which would be generated by reading any NBS-7 document with the same parameter values in access context FA.

A.6.11.3 The INSERT operation

51

Part 9 - FTAM Phase 2

A.7 NBS-8 Indexed sequential file

A.7.1 Entry Number: NBS-8

A.7.2 Information Objects

September 1991 (Stable)

53
Part 9 - FTAM Phase 2 September 1991 (Stable)

Table 11 - Information objects in NBS-8

documsnt type nam6 {iso identified-organization oiw(14) ftamsig(5) document-type(5)

indexed-file(8)}

"NBS-8 FTAM indexed file"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14) ftamsig(5) abstract syntax(2)

nbs-as1(1)}

"NBS abstract syntax AS1"

{iso standard 8571 abstract-syntax(2) ftam- fadu(2)}

"FTAM FADU"

transfer syntax names: {joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic Encoding of a single ASN.1 type"

parameter syntax:

PARAMETERS ::= SEQUENCE {DataTypes, KeyType, KeyPosition}

DataTypes ::= SEQUENCE OF CHOICE {ParameterO, Parameterl, Parameter2}

KeyType ::= CHOICE {ParameterO, Parameterl, Parameter2} - ParameterO, Parameterl , Parameter2, as defined for the ~ document types NBS-6, NBS-7

KeyPosition:: = INTEGER

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set(4) ordered-flat(3) }

"FTAM ordered flat constraint set"

file contents:

Datatypel ::= PrimType -- as defined in annex C.3 NBS-AS1

Datatype2 ::= CHOICE {Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element,

Exit-Subtree-Data-Element }

Datatypes ::= Primtype ~ as defined by the NBS abstract syntax AS1

A.7.3 Scope and field of application

The document type defines the contents of a file for storage, for transfer and access using FTAM.

54
Part 9 - FTAM Phase 2 September 1991 (Stable)

NOTE - Storage refers to apparent storage within the Virtual Filestore.

A.7.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection -File Transfer, Access and

Management

A.7.5 Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined In ISO

8571-1.

A.7.6 Abbreviations

RAIVI File Transfer, Access and Management

A.7.7 Document semantics

The document consists of zero, one or more file access data units. Each FADU contains precisely one data

unit which consists of zero, one or more data elements. The order of each of these elements Is significant.

The document structure takes any of the forms allowed by the FTAM hierarchical file model as constrained

by the FTAM ordered flat constraint set (see table 11). These definitions appear in ISO 8571-2.

The following additional requirements are specified for the use of the ordered flat constraint set:

The FADU Identities 'first', 'last', and 'node number' are not required for conformant implementations

The Identities 'next' and 'previous' are allowed for all FADUs

Each data element Is a data type from the set of primitive data types defined In annex 0.3 of this document.

Each data unit contains the same data element types In the same order as all other data units. These types

and their respective maximum lengths are defined by the <DataTypes> parameter.

For Datatypel and Datatypes, the string length field of Parameterl specifies the length of the value in octets

for the INTEGER, BIT STRING and OCTET STRING types. For character-type data elements, the stringlength Indicates the actual number of characters from the specified character set, not including any escape

sequences or overhead from the character encoding.

For floating point numbers, finite form, length-1 and length-2 specify the length In bits of mantissa and

exponent, respectively. The length-1 and length-2 values are Irrelevant for the other choices of floating

point numbers.

55
Part 9 - FTAM Phase 2 September 1991 (Stable)

Each data unit in tlie file lias a key associated with it, which is the user-coded form of Node-Name whiet)

i o tho UGor oodod form of NodoNamo. The key of each data unit is of the same data type as the key of all t other data units in the file and is a single data element from the set of primitive data types defined in annex

C.3 .

The type and length of the key are defined by the <KeyType> parameter.

The primitive data types and minimum size ranges of each unit which an implementation must accept as a key value are given in the following table 12.

Table 12 - Datatypes for keys

Key Type Minimum Range

(octets)

Order

ASN.1 INTEGER (1-2) increasing numeric value

ASN.1 IA5String (1-16) lexical order

ASN.1 GraphicString (1-16) lexical order

ASN.1 GeneralString (1-16) lexical order

ASN.1 OCTET STRING (1-16) increasing value

ASN.1 GeneralizedTime increasing time value

ASN.1 UniversalTime increasing time value

NBS-AS1

FloatingPointNumber

increasing numeric value

The position of the key in the data unit is specified by the < KeyPosition> parameter.

KeyPosition = 0 implies the key is not part of the data

position > 0 specifies the actual data element in the data unit.

A.7.8 Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically structured file as defined in the ASN.1

module IS08571-FADU in ISO 8571, in which each of the file access data units has the abstract syntactic structure of NBS-AS1 as defined by the parameters.

56
Part 9 - FTAM Phase 2 September 1991 (Stable)

A.7.9 Definition of transfer

A.7.9.1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 11, where the PrimType in the datatype is given by the NBS-AS1

definition; or

b) Datatype2 defined in table 11, the ASN.1 datatype declared as "Data-Element" in the ASN.1

module IS08571-FADU; or

c) Datatypes defined in table 1 1 , which specifies the user-coded form of the Node-Name in the

FTAM FADU abstract syntax, where user-coded is defined as EXTERNAL.

The document is transferred as a series of presentation data values, each of which is ei ther

a) one value of the ASN.1 datatype "Datatypel," carrying one of the data elements from the

document. All values are transmitted in the same (but any) presentation context established to support the abstract syntax name "asnamel " or

b) a value of "Datatype2." All values are transmitted in the same (but any) presentation context

established to support the abstract syntax name "asname2"; m

c) a value of ^'Datatypes* carrylntgi a k«y. All values are transmitted in the same (but an^

presentalioh cc^itext established to support the abstract syntax name "asnamet".

1 specific carrier standards may impose additional constraints on the presentation context to be used, where

the above permits a choice.

2 Any document type defined in this entry either makes no use of Datatype2, or starts with a Datatype2

transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between

P-DATA primitives, are chosen locally by the sending entity at the time of transmission, and carry no

semantics of the document type. Receivers which support this document type shall accept a document with

any of the permitted transfer options (e.g., document type parameters and transfer syntaxes).

A.7.9.3 Sequence of presentation data values

The sequence of presentation data values of type a) and the sequence of presentation data values of types

a) and b) is the same as the sequence of data elements within a Data Unit, and Data Units in the hierarchical

Presentation data values

NOTES

57
Part 9 - FTAM Phase 2 September 1991 (Stable)

structure, when flattened according to the definition of the hierarchical file model in ISO 8571-2.

A.7.10 Transfer syntax

An implementation supporting this document type shall support the transfer syntax generation rules named

in table 1 1 for all presentation data values transferred. Implementation may optionally support other named

transfer syntaxes.

A.7.11 ASE specific specifications for FTAM

A.7.11.1 Structural simplification

This simplification loses information.

The document type NBS-8 may be accessed as a document type FTAM-3 (allowed only when reading the

file) by specifying document type FTAM-3 in the < contents type> parameter in <F-OPEN request >, and

limiting access context to UA on F-READ.

The octet representation of the transferred data is unpredictable. It will usually correspond to the data

values as stored in the local Real Filestore of the Responder.

A document of type NBS-8 can be accessed as a document of type NBS-6 (allowed only when reading the

file) by specifying document type NBS-6 with appropriate data type parameters in the < contents type>

parameter on the <F-OPEN request >. The traversal order of the FADUs must be maintained.

NOTE - The traversal order is as reading the file as NBS-8 in key order.

A.7.1 1 .2 Access context selection

A document of type NBS-8 may be accessed in any one of the access contexts defined in the FTAM ordered

flat constraint set. The presentation data units transferred in each case are those derived from the structuring elements defined for that access context in ISO 8571-2.

A.7.11 .3 Thie INSERT operation

When the < INSERT> operation is applied the transferred material shall be the series of FADUs which would

be generated by reading any NBS-8 document with the same parameter values in access context FA.

The insertion of a new FADU after an already existing FADU will be indicated via a diagnostic on TRANSFEREND.

58
J Part 9 - FTAM Phase 2 September 1991 (Stable)

A.7.1 1 .4 The EXTEND operation

This operation is excluded for use with this document type.

A.8 NBS-9 File directory file

A.8.1 Entry Number: NBS-9

A.8.2 Information objects

59
Part 9 - FTAM Phase 2 September 1991 (Stable

Table 13 - Information obiects in NBS-9

document type name {iso identified-organization oiw(14) ftamsig(5) document-type(5)

Tiie-uir©ciory^yj f "NBS-9 FTAM file directory file" abstract syntax names: {iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2)

nbs-as2(2)}

"NBS file directory entry abstract syntax"

transfer syntax names:

parameter syntax

PARAMETERS ::= [0] IMPLICIT BIT STRING {

- Kernel group

read-filename (0), read-pernnitted-actions (1), read-contents-type (2),

- Storage group

read-storage-account (3), read-date-and-ti me-of-creation (4)

,

read-date-and-time-of-last-modification (5), read-date-and-time-of-last-read-access (6), read-date-and-time-of-last-attribute-modification(7),

read-identity-of-creator (8), read-identity-of-last-modifier (9), read-identity-of-last-reader (10), read-identity-of-last-attribute-modifier (11), read-file-availability (12), read-filesize (13), read-future-filesize (14),

- Security group

read-access-control (15), read-legal-qualifications (16),

- Private group

read-private-use (17) }

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set(4) unstructured(l)}

"FTAM unstructured constraint set"

File contents:

Datatypel ::= FileDirectoryEntry

-As defined by NBS-AS2 in annex C, -C.4 of this document

60
Part 9 - FTAM Phase 2 March 1991 (Stable)

A.8.3 Scope and field of application

This document defines the contents of a file for transfer (not for storage) using FTAM.

A.8.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection -File Transfer, Access and

Management.

A.8.5 Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined in ISO

8571-1

A.8.6 Abbreviations

FTAM File Transfer, Access and Management.

A.8.7 Document Semantics

The document consists of one file access data unit, which consists only of zero, one or more data elements

of type <FileDirectoryEntry> (defined in NBS-AS2).

The document structure takes any of the forms allowed by the FTAM hierarchical file model as constrained

by the unstructured constraint set. These definitions appear in ISO 8571-1.

The parameter of the document type is used on < F-OPEN request > to specify the desired attributes of each

of the files on the Filestore, when reading the document.

A.8.8 Abstract syntactic structure

The abstract syntactic structure of the document is a series of file directory entries, each of which is defined

by the <FileDirectoryEntry> definition in NBS-AS2.

Additional constraints are defined for this document type: File access actions are restricted to Read. File- directory files may not be Written or Modified (except as a side effect of actions performed on individual files contained within a file directory).

61
Part 9 - FTAM Phase 2 March 1991 (Stable)

A.8.9 Definition of transfer

A.8.9.1 Datatype definition

The file consists of zero or more values of Datatypel defined in table 13.

A.8.9.2 Presentation data values

The document is transferred as a series of presentation data values. Each presentation data value shall consist of one value of the ASN.1 data type "Datatypel," carrying one of the file directory entries from the

document.

All values are transmitted in the same (but any) presentation context established to support the abstract

syntax name "asnamel" declared in table 13.

A.8.9.3 Sequence of presentation data values

The sequence of presentation data values is the same as the sequence of file directory entries within the

Data Unit in the file.

A.8.10 Transfer syntax

An implementation supporting this document type shall support the transfer syntax generation rules named

in table 13 for all presentation data values transferred. Implementations shall optionally support other named

transfer syntaxes.

A.8.11 ASE specific specifications for FTAM

Relaxation is allowed to any bitstring combination of the document type parameter.

62
Part 9 - FTAM Phase 2 March 1991 (Stable)

Annex B (normative)

Constraint Sets

1 B.1 NBS Ordered ordered flat constraint set

This object with Object Identifier

{iso identifled-organization icd(9999) organization-code(l) constraint-set(4) nbs-ordered-flat(l)}

jj was withdrawn on March 16. 1990. It was replaced with the object NBS ordered flat constraint set with the

' Object Identifier

{iso identified-organization oiw(14) ftamsig(5) constraint-set (4) nbs-ordered-flat(l)}

defined in part 9, B.2.

j

63
Part 9 - FTAM Phase 2 March 1991 (Stable)

B.2 NBS Ordered g|difii flat constraint set definition

B.2.1 Field of application

The NBS-ordered flat constraint set applies to files which are structured into a sequence of individual FADUs

and to which access may be made on an FADU basis by position in the sequence.

B.2.2 Basic constraints

64
Part 9 - FTAM Phase 2 March 1991 (Stable)

Table 14 - Basic constraints for NBS Ordered (xrdered flat

I'IIm'vJ UCI IICIl loll dll H OOl

^Oiloirallli oci luciiiiiioi •fi^n ^lO^ iHpntififiH-nrn?ini7?itir»n lUd llllloU \Ji ^Cll II^ClUwl 1 ri\\/jlAA\ WIWI 1 *tJ fl"amcin/'-i\ lldl 1 Idl^^O J constraint-set(4) nbs-ordered-flat(1 )}

Node name None

File access actions Locate, Read, Insert, Erase, Replace

Qualified action None

AVQiiauiG access cuniexis HAriM, FAnrt, 1 lA

Rnnt FIWWl nnrlfl 1 l^i^VJO withniit Will IWUI anOl 1 a^^opij^tpH ClOOwWICIl%3U Hati^ UdLO iinit Ul III

Location after open Root node

Beginning of file Root node

End of file No node selected; 'previous' gives last node in traversal sequence,

'current'and 'next' give an error. RoaH u/KhIa flip Rp^^H in ?ippp<5^ pnntpyt FA nr 1 JA with FAHI 1 iripntitv nf 'hpnin*

Write whole file (append)

Write whole file (replace)

Transfer the series of leaf FADUs which would be generated by reading

the whole file in access context FA; perform the transfer with an FADU

identity of 'end' and a file access action of 'insert'.

Transfer the series of leaf FADUs which would be generated by reading

the whole file in access-context HA; perform the transfer with FADU

identity 'begin' and file action of 'replace'.

B.2.3 Structural constraints

The root node shall not have an associated data unit; all children of the root node shall be leaf nodes and

may have an associated data unit; all arcs from the root node shall be of length one.

B.2.4 Action constraints

Insert : The < Insert > action is allowed only at the end of file.If the FADU identity is 'end' the new node is inserted following all existing nodes in the file. If the FADU identity is 'node number', the number

must be at least one greater than the node number of the last existing node. Any nodes between

65
Part 9 - FTAM Phase 2 March 1991 (Stable)

the last existing node and the new node are empty, I.e., nodes without data. If the FADU Identity

is a 'node number' not greater than that of the last existing node, an error will occur. The location

following < insert > is 'end'.

Erase: The Erase action is only allowed at the root node to empty the file, with FADU identity of 'begin'.

The result is a solitary root node without an associated data unit. NOTE - It is the intention when using this constraint set to allow for emptying an FADU, i.e., leaving an FADU

with a DU of data length 0 (or without a DU); afterwards data may be reinserted into this hole. In order to

• empty an FADU, the < Replace > operation may be used with new data of length zero (or with an FADU whose

<data exists> bit is set to 'false' and no DU). Refilling the hole is accomplished by a <Replace> operation

with the new DU (or with the new FADU, whose <data exists> bit is set to 'true' and the new DU).

B.2.5 Identity constraints

The FADU identity associated with the file action shall be one of the identities 'begin', 'end', 'first', 'last', 'current', 'next', 'previous' or a 'node number' greater than or equal to one. The actions with which these

identities can be used are given in the following table.

Table 15 - Identity constraints in NBS Ordered icurd^riec) flat

Action Begin End First Last Current Next Previous Node No.

Locate valid valid valid valid valid valid valid valid

Read whole leaf leaf leaf leaf leaf leaf

Insert leaf leaf

Erase whole

Replace whole leaf leaf leaf leaf leaf leaf

66
Part 9 - FTAM Phase 2 March 1991 (Stable)

Annex C (normative)

Abstract Syntaxes

C.1 Abstract Syntax NBS-AS1

; This object with Object Identifier

{iso identified-organization icd(9999) organization-code(l) abstract-syntax(2) nbs-as1(1)}

was withdrawn on March 16, 1990. It was replaced with the object Abstract syntax NBS-AS1 with the Object

I Identifier

{iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-asl(l)}

i defined in part 9, C.3.

C.2 Abstract Syntax NBS-AS2

} This object with Object Identifier

^ {iso identified-organization icd(9999) organization-code(l) abstract-syntax(2) nbs-as2(2)}

ii was withdrawn on March 1 6, 1 990. It was replaced with the object Abstract syntax NBS-AS2 with the Object

Ii identifier

|| {iso identified-organization oiw(14) ftamsig(5) abstract-syntax (2) nbs-as2(2)}

! defined in part 9, 0.4.

i C.3 Abstract Syntax NBS-AS1 definition

' Abstract syntax name: {iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-asl(l)}

I "NBS abstract syntax AS1"

' This is an abstract syntax for the set of presentation data values, each of which is a value of the ASN.1 type

NBS-ASI.PrimType

I

j

i

67
Part 9 - FTAM Phase 2 March 1991 (Stable)

NBS-AS1 DEFINITIONS :: BEGIN

PrimType ::= CHOICE

{ INTEGER,

BIT STRING,

BOOLEAN.

lASString,

GraphicString,

GeneralString,

OCTET STRING,

UTCTIme,

GenerallzedTlme,

NULL,

FloatingPointNumber } j

The support for lASString is the ISO 646, IRV GO | character set and the ISO 646, IRV CO set The minimum level of support for GraphicString is the ISO 646, IRV GO character set and the 8859-1

GO and Gl sets.

, The minimum level of support for GeneralString is the ISO 646, IRV GO character set and the 8859-1

GO and Gl character sets, and ISO 646, IRV CO set.

first bit must be 1 exponent INTEGER},

infinity [1] IMPLICIT Sign,

signalling-nan [2] IMPLICIT NaN,

quiet-nan [3] IMPLICIT NaN,

zero [4] IMPLICIT NULL }

FloatingPointNumber :: = [PRIVATE 0] CHOICE {

finite [0] IMPLICIT SEOUENCE

Sign,

mantissa BIT STRING,

{

Sign ::= INTEGER { positive (0), negative (1) }

NaN ::= INTEGER

END

For this abstract syntax the following transfer syntax can be used

{joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic Encoding of a single ASN.1 type'

68
Part 9 - FTAM Phase 2 March 1991 (Stable)

NOTES

1 The mantissa is a number in the range (1/2 <mantissa<1).

2 The value is equal to mantissa * 2

«"p°"«"'.

3 The first bit in the mantissa is most significant.

4 See IEEE 754 for definitions of terminology, such as NaN.

5 A minimum length range (in bits) is required for the components of <FloatingPointNumber>, as follows: mantissa 1-23 bits, and exponent 0-8 bits.

C.4 Abstract Syntax NBS-AS2 definition

Abstract syntax name: { iso identlfied-organlzation oiw(14) ftamsig(5) abstract-syntax(2) nbs-as2(2) }

"NBS file directory entry abstract syntax"

This is an abstract syntax for the set of presentation data values, each of which is a value of the ASN.1 Type

NBS-AS2.FileDirectoryEntry.

NBS-AS2 DEFINITIONS :: = BEGIN

FileDirectoryEntry :: = [PRIVATE 2] Read-Attributes

Read-Attributes :: = IS08571 -FTAM.Read-Attributes

END

For this abstract syntax the following transfer syntax will be used

{ joint-iso-ccitt asn1(1) basic-encoding(l) }

"Basic Encoding of a single ASN.1 type"

C.5 Abstract Syntax "FTAM unstructured text abstract syntax"

This abstract syntax is defined as DataTypel (File Contents) in table 19 of ISO 8571-2, annex B.

69
I
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 10 - FTAM Phase 3

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair: Darryl Roberts UNISYS

SIG Editor: Larry Friedman DEC
PART 10 - FTAM Phase 3 September 1991 (Stable)

\

Foreword

This part of the Stable Implementation Agreements was prepared by the File Transfer, Access and j Management Special Interest Group (FTAM SIG) of the National Institute of Standards and Technology j (NIST) Workshop for Implementors of Open Systems Interconnection (OSI). 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. There is no significant technical change from this text as

j previously given. References to Part 9 are made in this part. 1

Five Normative Annexes are included. Three alignment errata were approved in December 1990, as follows:

a) add requirement to conform to amendments and corrigenda;

b) change support level of erase in requested access and processing mode;

c) change support level of concurrency control in F-select, F-create, and F-open.

j

Future changes and additions to this version of these Implementor Agreements will be published as change j pages. Deleted and replaced text will be shown as stri keout. New and replacement text will be shown as I shaded.

ii

I
PART 10 - FTAM Phase 3 September 1991 (Stable)

Part 1Q - ISO Fa« Transfer^ Aeo^ss and ManaQement Phase u , _ . ; :Z"'/'ftf^XW£fM^^B.

p Introduction . . . . |

t Soope . , , » • • 0,

a Momtative References v7i

3 Status 3

t Assumptions . . ... 64

7 Filestore Agreements . . . . , 6-1

7>1 Ooc^iD^nt Types 6*1 7.2 FADU tdetitiltes a

7<3 Acx;ess Cwtrdl Attnbute 9

6 Protocol Aij^reeinents '>>>v<<4'4''>>>x<<4''f'>>>>.<<«''>'»»>x<4»*'»»>A<<.^«»^>•<<4^«>>><< id 8.t Jftiplementaiioft Profile Mi.^ 10

9.3 ItnplementatiDn liitormatloti Parameter , 10

3.5 Esior Recov^ tO

8.6>1 Docket Handling .y4<** + »>x<<***>>x<«***>>. 11 8.5.2 P^a»ieter$ for Errca" fieooveiy ii

8.€ti Conourranoy Cc«itr<^ to whole flte . ^ ^ 11

0.7 Create Password , . , , . . . , 12

8*8 initiator Id^itity, Passwwds and Account x x < 12

d Range of Values for ltiteger»Type Paramet^ , ... 12

Annex A (nomnatlve)

Profile Requirements list , , , , 14

Annex B (nontiatlve)

ftegistar of FTAM Objects ..... • iMI

Hi
PART 10 - FTAM Phase 3

Atir^ 0 <normativQ)

Doeum0(it Types

.

,

C>tJ?

C.1.4

CAJ

liiiillllli

CAM

ai>ii

CJH MS?

* p r y 'K

* h h A •

:

'ues

September 1991 (Stable)

68

68

*

4- « > A A «

* A ^ 4 4- +

+ >

•

4- » >

> V * • +

A A 4 4 4-

+ + f >

+ f r * •< <

4- « k « :

A A A 4 4-

•» r

4- • « :

• V If f 4- :

4- 4' )•

4 * * *

A « 4 4-

^ EXTEND OperE

lEPlACE ope

4- +•

4- -fr

r y ¥

4- + +;

+

4-

+

4- *

> V

« A .4

+

* * *

* * *

4- 4-

4- «

4- *

Abbreviations ......

68

60

n

n

n

n

70*171

n

7i

n

72

, 75

, n

. n

. n

. 75

. 7S

. 76

. 75

, 76

. 77

. 77

. 77

. 77

. 76

. 78

. 76

- 76

. 79

, 79

. 79

. 60

. 60

, 80

» 61

, 62

. 62

iv
PART 10 - FTAM Phase 3 September 1991 (Stable)

0.3.7 Document $emantlo$ 'yfWWWMW^M^

^3>B Abstract syntactic structure 83

D$ltnltlon<jftrs(rt$fer 8|

i C^^A C^tatype d€liin?tor» . . , , ........ i|

<^Z^ Pr0S0ntatioft<iatiaval«$$ ... - V $|

0>3>^ Sequence of presentiation data vakjes . > 8$

I 0.3.10 Traasier syntax , $1

C,3J1 . ASE Specific %)edRcatlo«8 x < . < 8i

C.3.11.1 $lm(^81cailcwiarw3l f$l$)fi9tlon 85

0»3>11>11 Simpljficffl&mto RAM-t . * * > x , , * , 85

C.3.1 t.i i^eiaxatiofl to 85

C,3Jt1*^ 0*3ra(^r set reteixatian > x x * - 85

j 0.3.11.1.4 Sttlrt5ji^i0»reias($tloii 86

C^3>11,2 Access ccsntext s^ectltHi » . - , < 86

, C.3.1t.3 The operation , 86

I Aiinex D <fiofmatK^o)

1 Constraint SetSi » . ,

, . , . , .87

I D.1 NB3 random access constraint set > .87 i 0,1.1 field of apptlcatibn . . . . 88

DJ.2 Basic c^straiints . .88

0,1*3 Stmctur^ constraints 88

AcSon constraints . . . 88

0.1.6 lden%^ constraints . ... 89

]

I

i Ab^adt Si)^iit8x63i x<,***>>^<i***, .... 90

1 £.1 MBS Node Nani$ Abstract Syntax 90

E<2 NBS Random BIrmry Access File Abstract Syntax 91

E3 NBS Simple Text Abstract Syntax . . . 92

Annex F (normative}

i Delta Protocol tmplemenlatlon Cofttormance Siatentent (PiCS) Pro forma 93

j Annex G (noniiative^

' Amendments and Corrigenda , . .

, . . . ... « < - > • • _, < < ^ • > • — - r . Jl

V
PART 10 - FTAM Phase 3 September 1991 (Stable)

lllilllllliil

laiM 2 « UsS <rf Errata . . * * * , . . . . * * * 5

T^ye3 - ttnpJementatiW PfoSes^nd Docurne?it T

" i , . * . B

T^e 4 * Infofmation objeds In NBS-io ... * * , 69

TbI:*© 6 - Informa^rr objeds in NB$-1 1 74

T£l^fi 6* l^tatypesforJ<eys ....... . . * * 76

Tabfe7-|t?forrnaliortobiec^inNB$-l2 81

TaMe 8 Baste cscmstralnts in tha NBS Random Access Constraint Set .... , 67

Tat?t« 9 - tden^ constraints! m the NB$ Random Aqcjsss Constrair^ ^et . 80

vi
PART 10 - ISO FTAM PHASE 3 December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the File Transfer, Access and

Management Special Interest Group (FTAM SIG) of the National Institute of Standards and Technology

(NIST) Workshop for Implementors of Open Systems Interconnection (OSI). 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. There is no significant technical change from this text as

previously given. References to Part 9 are made in this part.

Five Normative Annexes are included. Three alignment errata were approved in December 1990, as follows:

- add requirement to conform to amendments and corrigenda;

- change support level of erase in requested access and processing mode;

- change support level of concurrency control in F-select, F-create, and F-open.

(i

r

vii
Ij
Part 10 - ISO File Transfer, Access and Management Phase 3

Editor's Note - The "NBS" designation remains in effect for document types, abstract syntaxes, and constraint

sets defined in all FTAM agreements up to 1 /1/89. After 1 /1 /89, any new functionality references the "NIST"

designation. This is to reflect the change in identifying organization from "NBS" to "NIST."

0 Introduction

This clause contains Implementors Agreements based on ISO 8571 File Transfer, Access and Management,

i These Agreements define enhancements to the Stable FTAM Implementation Agreements for OSI Protocols,

I Version 1, Edition 1, December 1987 (FTAM Phase 2 Agreements, NBS 500-150), including all their

I subsequent Errata changes through Version 4, Edition 1 (NIST Special Publication 500-183, this document

Therefore It is assumed that the reader is familiar both with the contents of the base standard ISO 8571 and

its underlying layers, and also with the above-mentioned NIST FTAM Phase 2 specifications.

Phase 2 Agreements define six Implementation Profiles which are T1, T2, T3, A1, A2, and Ml. In order to avoid ambiguity when referring to these Implementation Profiles the above designations will apply only to Phase 2 functionality, references to Phase 3 enhanced Implementation Profiles will be by the addition of a

'.3', i.e.. T1.3, T2.3, T3.3, A1.3, A2.3, and Ml.3.

The following clauses specify the functionality of NIST OIW FTAM Phase 3:

IliClauses 1 and 8 specify the technical details of FTAM Phase 3 which are defined in addition to the functionality of FTAM Phase 2. Included is also a status overview regarding statements on

Phase 2/Phase 3 compatibility and interworking;

iHlAnnex A is a Profile Requirements List for the Implementation Profiles T1 .3, T2.3, A1 .3 and Ml .3, summarizing all features of FTAM Phase 3, including those of FTAM Phase 2. This Profile Requirements List is fully based on the FTAM PICS Proforma ISO 8571-5;

c) Annex B is an index of Object Identifiers. It is the official NIST OIW Register of NIST OIW

defined FTAM objects. It contains the Object Descriptors and Object Identifiers for these objects,

Including a reference to the clause in the NIST OIW Stable Agreements where the respective object

is being defined;

HIIAnnexes C, D, and E provide definitions for additional document types, constraint sets and

abstract syntaxes;

1
PART 10 - FTAM Phase 3 September 1991 (Stable)

1 Scope

These Phase 3 Agreements specify additional functionality to the FTAM Phase 2 Agreements. These

additional functions include:

Further specifications of document types;

Specification for Restart Data Transfer and Recovery functional units;

Specification of FADU Locking functional unit;

More details on Access Control and Concurrency Control.

All Phase 2 systems are upward compatible to a Phase 3 system and can therefore interwork with it, if the

additional functions are negotiated out (e.g., use of Recovery) or not used for the interconnection (e.g., additional features for document types).

2 Normative References

Ameixlments and corrigenda to the base starKiards referenced: See arwiex G Jor a oomji^^e list of these

ISO 8571-1: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management Part 1: General Introduction

ISO 8571-2: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management Part 2: Virtual Filestore Definition

ISO 8571-3: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management Part 3: The File Service Definition

ISO 8571-4: 1988(E), Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management Part 4: File Protocol Specification
PART 10 - FTAM Phase 3 September 1991 (Stable)

3 Status

These FTAM Phase 3 Agreements were completed December 15, 1989. No further enhancements will be

made to this version (see also next clause ERRATA).

The following tables summarize the functions and features which are defined for FTAM Phase 3 In addition

to the FTAM Phase 2 specifications. They also state the degree of possible interworking and the backward

compatibility.

Table 1^ - Phase 2/Phase 3 Interworking

Additional requirements in FTAM phase 3 Backv^ard compatibility to FTAM phase 2

FTAM-1 : GraphicString.VisibleString

FTAM-2: VisibleString

concurrency-control parameter for Initiator

create-password parameter for Initiator

Profile M1.3: Requires support of

(1)-T service class including Limited File Management FU, Enhanced FM FU; TM service class including Enhanced FM FU or

(2)-A service class including Limited File Management FU, Enhanced FM FU

full backv«/ard compatibility if the

additional features of Phase 3

are not being used (character

sets in FTAM-1, -2), or not requested by an Initiator (functional units) or not

required by a Responder

(parameters) not requested by

an Initiator (functional units)

3
PART 10 - FTAM Phase 3 September 1991 (Stable)

Table 1(b> - Phase 2/Phase 3 Interworking (continued)

Additional optional features in FTAM phase 3 Backvt/ard compatibility to FTAM phase 2

FTAM-2: GeneralString, lASString

FTAM-4

NBS-8 in T2.3, A1.3

NBS-9 in A1.3, A2.3

NBS-10

NBS-11

NBS-12

Recovery functional unit

Restart-data-transfer functional unit

FADU-locking functional unit and FADU-lock parameters in A1 .3, A2.3

Concurrencv-control Darameters for ResDonder

create-password parameter for Responder

location-field of access-control element

suggested-delay term of diagnostic parameter supported conditionally on

Recovery functional units

full backward compatibility if the

additional features of Phase 3 are not requested, negotiated out or not being

used

4
PART 10 - FTAM Phase 3 September 1991 (Stable)

Table 1(g> - Phase 2/Phase 3 Interworking (concluded)

Relaxation for FTAM phase 3 Backward compatibility to FTAM phase

2

Profiles A1 .3, A2.3 do not require transfer service class

no minimum requirements for maximum-string-length parameters for document

types

if T service class not being used

if a Phase 3 system stays below this minimum requirement

4 Errata

Table 2 - List of Errata

No. of

errata Type Referenced

document

Clause Description

CP 3/91-1 Editorial NIST-SP 500-183 All Update to ISO style. General

formatting and error corrections. Alignment with the wording of the ISP. Consistent naming conventions.

CP 6/91-1 Editorial NIST-SP 500-183 8.6.1 Previous errata changed the Profile Requirements List (PRL) lUpport of Concurrency Control but not the

tGXtr fmm 'W to "q°. This change was not reflected.

A.13.9.1.2

A.13.9.1.3

A.13.9.1.4

Alignment with the ISP.

5
PART 10 - FTAM Phase 3 September 1991 (Stable)

NO. OT

errata Type Referenced

document

Clause Description

CP Tabid 4

CP 9/91-2 Table 5

tor consi$ti&ncy with oD16^ OiW

9/91-2 Table 8

WC;*U IUIWII:-:IWI-:-:1iMUCKiy|J(C?w

Iprevtous change incompiete].

CP 9/91-4 At.i2.iej

Add reference lo wwrigenda.

Support l0ver from Vto *ni'. Add

ntotd that must mjppor! at least one

A.12.17.5 action, Add rjote^tjoutsupportiRg

at Jeast one optional FU.

CPsiPSl^

A.13.6,1 Change to spelllrig of ASM.t le>d

0-2.9.2

descriptions

"Structural Simpliflcjatior^' to C.2J1J

C x*i 1 1

1

"Simplification^'

CP s/ms 11 Changed "wllr lo *can^

Annex B Added Editors notfe of Ihtentiort td remove object definltlcms when the ISP is pubtished.

ii

New annex to tist corrigenda

6
PART 10 - FTAM Phase 3 September 1991 (Stable)

5 Conformance

In addition to the specific requirements specified in the following subclauses, confornnance to this Phase

3 specification requires

conformance to ISO 8571: 1988

conformance to Phase 2 FTAM, unless specified otherwise In this part 10.

The access Profiles A1 .3 and A2.3 do not include the requirement for transferring files using the File Transfer service class.

6 Assumptions

FTAM Phase 3 Agreements specify additional functionality to the Implementation Profiles T1, T2, T3, A1,

A2, and Ml as defined in the FTAM Phase 2 Agreements. So all definitions and requirements for these

Implementation Profiles apply also to the Phase 3 Agreements.

7 Filestore Agreements

7.1 Document Types

In addition to the Phase 2 Document Type Agreements the document types FTAM-4 (see ISO 8571-2,

Annex B) and NBS-10, NBS-11, NBS-12 (see Annex C) are defined for optional support.

Table 2 gives the support levels for ail document types with respect to the Implementation Profiles.

For FTAM-1, FTAM-2, FTAM-3 and FTAM-4 the supported parameter values for < universal class

number > and < string significance >, respectively are listed. Other values are outside the scope of these

Agreements. No restriction or minimum requirement is defined for the < maximum string length >

parameter of these document types.

6-1
II
PART 10 - ISO i=TAM PHASE 3 December 1990 (Stable)

Table 3(a) - Implementation Profiles and Document Types - FTAM-1 Through FTAM-4

Implementation

Profile

(Note 1)

Document

Type

Universal Class

Number

(Notes 1,3,4,5)

String Significance

T1.3, T2.3, T3.3,

A1.3, A2.3

FTAM-1 GraphicString (25) ^variable' 'fixed'

VisibleString (26) 'variable' 'fixed'

GeneralString (27) 'not-significant

IA5String (22) 'not-significant

T2.3, T3.3, A1.3, FTAM-2 GraphicString (25) 'not-significant

VisibleString (26) 'not-significant

[GeneralString (27)] 'not-significant

[lASString (22)] 'not-significant

T1.3, T2.3, T3.3,

A1.3, A2.3

FTAM3'not-significant'

[T2.3], [T3.3],

[A1.3], [A2.3]

FTAM-4 'not-significant

Table 3(b) - Implementation Profiles and Document Types - NBS-6 Through NBS-11 (continued)

Implementation Profile

(Note 1)

11 Document

Type 1 [T2.3], T3.3, [A1.3], A2 .

3

NBS-6

[T2.3], T3.3, [A1.3], A2 .

3

NBS-7

[T2.3], T3.3, [A1.3], A2 .

3

NBS-8

[T1.3], [T2.3], [T3.3],

[Al,3], tA2.3]

NBS-9

[T2.3], [T3.3], [A1.3],

[A2.3]

NBS-10

[T2.3], [T3.3], [A1.3],

[A2.3]

NBS-11

7
PART 10 - ISO FTAM PHASE 3 December 1990 (Stable)

Table 3(c) - Implementation Profiles and Document Types - NBS-12 (concluded)

Implementation

profile (Note 1) Document

type

Universal class

number

Character-set escape

sequences as defined

for reg. numbers

CO GO G1

String-significance

[T2.3], [T3.3],

[A1.3],

[A2.3]

NBS-12

See Note 6

lASString [22] (parameter absent) 'variable' 'fixed'

GraphicString [25] (parameter absent) 'variable' 'fixed'

GraphicString [25] 6 100 'variable' 'fixed'

VisibleString [26] (parameter absent) 'variable' 'fixed'

GeneralString [27] (parameter absent) 'variable' 'fixed'

GeneralString [27] 1 6 100 'variable' 'fixed'

NOTES

1 Brackets around a Profile designator or a parameter value indicate tiiat tlie respective document type or parameter value is optionally supported in this Implementation Profile.

2 The support level for document types in Implementation Profile Ml.3 depends on the T- or A-lmplementation

Profile, in conjunction with which M1.3 is implemented.

3 The support for IA5 String is the ISO 646, IRV GO character set and the ISO 646, IRV CO set.

4 The minimum level of support for Graphic String is the ISO 646, IRV GO character set and the 8859-1 GO

and G1 sets.

5 The minimum level of support for General String is the ISO 646, IRV GO character set and the 8859-1 GO

and G1 sets, and ISO 646, IRV CO set.

6 If the Character-Set parameter is absent, the following defaults apply:

8
PART 10 - ISO FTAM PHASE 3 December 1990 (Stable)

1Vi/Inivpr^al-rl^i^^-nNrnhpr 1 II V wl OOI Vi/ldOO 1 ILJI i ik^wl CO GO G1

lASString [22]

GraphicString [25]

VisibleString [26]

GeneralString [27]

1 2

2

2

1 2

Character-Sets and Escape Sequences:

1 Registration Content Escape

number Sequence

1 CO set of ISO 646 ESC 2/1 4/0

2 ISO 646, IRV

6 ISO 646, USA Version-X 3.4 - 1968 (Left-hand part ESC 2/8 4/2

of ISO 8859-1)

100 Right-hand part of Latin Alphabet No 1 ISO 8859-1, ESC 2/13 4/1

ECMA-94

7.2 FADU Identities

In addition to the Phase 2 FADU Identity Agreements the following is specified:

- For the document type NBS-1 1 used in conjunction with the Transfer service class or the Transfer and Management service class, the support of the FADU identities of

'current', 'next', 'previous' and 'end' is outside the scope of these Agreements.

7.3 Access Control Attribute

The location field of access control element is optionally supported. It is the implementor's choice which

combinations of fields in an access control element are supported. The ACE combination should be stated

in the PICS.

8 Protocol Agreements

9
PART 10 - ISO FTAM PHASE 3 December 1990 (Stable)

8.1 Implementation Profile Ml .3

The functions defined for tlie Innplementation Profile M1.3 shall always be implemented in conjunction with one or more of the Implementation Profiles T1.3, T2.3, A1.3, or A2.3. The service classes and functional

units that shall be implemented are specified in Annex A, A. 12.4 and A. 12.5.

For an implementation supporting the Profile M1.3 in conjunction with T1.3 or T2.3, any of the service

classes Transfer, Management or (Transfer, Management, Transfer-and -Management) may be requested and

any of the classes Transfer, Management, Transfer-and-Management may be responded on F-INITIALIZE.

For an implementation supporting the Profile Ml.3 in conjunction with A1.3 or A2.3, any of the service

classes Access or Management may be requested and responded on F-INITIALIZE.

8.2 Functional Units

For FTAM Phase 3 implementations Recovery and Restart Data Transfer are optionally supported.

FADU locking is optionally supported for Implementation Profiles A1.3 and A2.3.

8.3 implementation Information Parameter

In addition to the Agreements as specified for FTAM Phase 2, part 9 clause 12 , the following value is defined

- NBS-Phase3.

8.4 F-Check

In order to maximize interoperability, implementations of FTAM service providers should not restrict the

amount of data transmitted between successive F-CHECK requests to a single quantity. Variations in the

amount of data transmitted between checkpoints may be required to accommodate differences in real end

systems supporting FTAM Virtual Filestores and/or in the communications media underlying FTAM

associations. It is required that all FTAM implementations are able to receive at least one PSDU between

checkpoints.

8.5 Error Recovery

Procedures for Class I, II and III errors are defined and supported for FTAM Phase 3 implementations. It

is the implementor's choice whether to handle class I errors using F-RESTART PDUs or whether to use the

class II error procedure.

10
PART 10 - FTAM Phase 3 June 1991 (Stable)

8.5.1 Docket Handling

When a class III error occurs, the length of time a docket is maintained is determined by the local system.

Recovery from a class III error is only possible as long as both end systems maintain the docket.

It is also a local decision how many dockets can be maintained simultaneously.

8.5.2 Parameters for Error Recovery

The following information is given:

The semantics of the <FTAM quality of service> parameter is as defined in ISO 8571 ; including the

local knowledge of FERPM;

No minimum requirement for the < checkpoint window > parameter or the checkpoint size is defined;

For the < recovery mode> parameter of F-OPEN, the values 'none' and 'at-start-of-transfer' are supported. The value 'at-any-active-checkpoint' is optionally supported. If recovery mode 'at-start- of-transfer' is negotiated, no F-CHECK shall be issued. When recovering at the start of the transfer,

the < recovery point> value of 0 shall be used;

It is required that Responders implementing the Restart-data-transfer or the Recovery functional unit must be able to negotiate < recovery mode> parameter to a value other than 'none';

For the <diagnostic> parameter of F-INITIALIZE, F-P-ABORT and F-RECOVER PDUs, the term < suggested delay > shall be supported if the Recovery functional unit is implemented. The Basic

FERPM should wait at least the amount of time as given by the < suggested delay > term before

attempting to recover.

If < concurrency contrd[> param&ters are supportedJTho <conourronoy control > paramotcro of F SELECT,

F CREATE and F OPEN wi th or without the <aooooo control > attri bute of Soourity Group arc oupportod for

I nitlatoro and opti onall y oupportcd for Roopondors.

tf supported by a Rospondor, details of their possible usage is a local matter and shall be specified in the

8.6 Concurrency Control

8.6.1 Concurrency Control to whole file

PICS.

Default values for concurrency control are as specified for FTAM Phase 2 Agreements.

11
PART 10 - FTAM Phase 3 June 1991 (Stable)

No minimum requirement is defined for < concurrency control > parameter values.

For a first accessor either the specified concurrency locks or the default values are assigned. For a subsequent accessor the access to a file is granted only if this concurrency control requirement, as specified

in this concurrency control parameter or given by the default values, can be met. Otherwise the subsequent

request shall be rejected.

8.6.2 FADU Locking

FADU locking functional unit and the respective <FADU lock> parameters are optionally supported for the

Implementation Profiles A1.3 and A2.3.

It is understood that ISO 8571-4 Clause 18.4 also applies to FADU locks; that means that as long as a docket is maintained, FADU locks locking any FADUs recorded in that docket should be maintained.

8.7 Create Password

The < create password > parameter for an implementation acting as an Initiator is supported. This parameter

is optionally supported for an implementation acting as a Responder.

8.8 Initiator Identity, Passwords and Account

An Initiator must be capable of sending and not sending the parameters < initiator identity >, <filestore

password >, < access passwords > and < create password > to satisfy the requirements of the Responder.

The contents of the < initiator identity >, < filestore password >, < access passwords >, < create password > and < account > parameters shall be in the convention of the responding implementation.

9 Range of Values for Integer-Type Parameter

In addition to the parameters specified for FTAM Phase 2 under the same heading, the parameters

F-RECOVER request

bulk-transfer-number

NBS-AS3

NBS-Node-Name

starting-fad u fadu-count

may be encoded so that the length of its contents octets is no more than eight octets.

12
PART 10 - FTAM Phase 3 September 1991 (Stable)

ANNEX A:

ANNEX B :

ANNEX C:

ANNEX D:

ANNES E:

ANNEXE S

PROFI LE REQUIR EMENTS LI ST FOR NIST OI W FTAM PHASE 3

NI ST OI W REGI STER OF FTAM OBJECTS

CONSTRAI NT SETS

CONSTRAI NT SETS

ABSTRACT SYNTAXES

13
PART 10 - FTAM Phase 3 September 1991 (Stable)

Annex A (normative)

Profile Requirements List

Editor's Note - The page numbering of the PICs tables may not be aligned with the text of this document. The reason for this problem is that the PICs tables are coded using a different wordprocessor.

The tables are being converted, but until this is completed the page numbering, and format of the tables may be aligned with the test of this document.

In the event of a discrepancy becomming apparent in the body of these agreements and the tables in this annex, this annex is to take precedence.

Editor's Note - Delete lines A.13.9.1.2, A.13.9.1.3, A.13.9.1.4, when the PICS tables are converted to WordPerfect Version 5.1 format.

Editor's Note « Change taWe A.5 to reference Annex (a. ISO/iECiSP 10607-4:1990 When

Annex A is converted to WordPerfect V5,l.

Editor's Note - A.12 16 1, a,12 16.5, A 12.17,1, and A,12.175 replace the *o' vm W bihd Al<3 cohm>

Adti a t0 tafctes A 12. 16 and A. 12. 17 Tor the profile A1.3, the support of at ^©a$t ^om ol ln$$^^ fepi?8}«,

Of extend ts required.' Also add a note to tables A.12.I6 and A>t2.i7 • For profiles Ti.3 T2>3t fhe support of at feast one of read, insert, replace or extend is required." When Annex A ts converted to

Editor's Note - A,1 3,6,1, and A. 13,6.2 d-tange parameter names to "Universal time", "Generalized tfme*

"]A5Strtng", "Boolean", "Bit", Imeger", When Annex A is converted to WordPerfect V5,1.

14
Part 10 - FTAM Phase 3 December 1990 (Stable)

Annex A

(normative)

Profile Requirements List for NIST OIW FTAM Pliase 3

A.O Introduction

This annex to NIST FTAM Phase 3 Agreements defines a Profile Requirements List (PRL) for the Implementation

Profiles

T1.3 - Simple File Transfer T2.3 - Positional File Transfer A1.3 - Simple File Access

Ml.3 - Management

This annex specifies the constraints and characteristics of NIST OIW FTAM Phase 3 on what shall or may appear in the supplier columns of an FTAM Phase 3 PICS. This annex is completely based on ISO 8571-5. It uses only a

selection of the tables from ISO 8571-5 which are necessary for the specification of the FTAM Phase 3 status, and

retains their numbering, in order to facilitate for a supplier to fill in the respective PICS Proforma.

This annex is a summary of all definitions of FTAM Phase 3 as they appear in the Stable Implementation Agree- ments for OSI Protocols, Version 4 Edition 1, December 1990, parts 9 and 10.

A.0.1 Conformance requirement of Base Standards

The D-column of clauses A.I to A.I 3 specifies the conformance requirement of the base standards ISO 8571, as

written in ISO 8571-5. The definitions apply as defined in ISO 8571-5 clause 8.1 : m - mandatory support

0 - optional support

f - full support of attributes p - partial support of attributes

- not applicable

A single value in the D-column applies to the Initiator role of a system as well as to the Responder role. If two

values are specified in the D-column separated by a space, they apply to the Initiator (I) role and to the Responder

(R) role, respectively.

A.0.2 Conformance requirement of Profiles

The Conformance requirement of the Implementation Profiles is specified in the 'Profiles' column/columns in clauses

A.I to A.I 3. The following convention is applied for this purpose :

0 a 'PROFILES' column is valid for all Profiles T1 .3, T2.3, A1 .3 and Ml .3

0 if different conformance requirements apply to different Profiles, separate columns are included in the tables, each

bearing the corresponding Profile name as its heading, or separate tables for these Profiles are used

15
Part 10 • FTAM Phase 3 December 1990 (Stable)

o a single value in these colunnns applies to the Initiator as well as to the Responder role of an implementation

o if two values are specified in a column separated by a space, they apply to the Initiator (I) role and to the Re- sponder (R) role, respectively.

For the conformance requirements of the NIST FTAM Phase 3 Profiles the following abbreviations are used.

mandatory; m : This is a mandatory or optional feature in the base standard, h shall be supported, i.e., its syntax and procedures

shall be implemented as specified in the base standard or in FTAM Phase 3 by all implementations claiming

conformance to the Profile.

However, it is not a requirement that the feature shall be used in all instances of communication, unless mandated

by the base standard or stated othenA/ise in FTAM Phase 3.

For fully supported attributes, this implies that at least the minimum range of attribute values, as defined in ISO

8571-2, shall be supported unless stated otherwise in FTAM Phase 3.

Also for features which are optional in the base standard, conformant implementations shall be able to interwork

with other implementations not supporting this feature.

The support of a feature can be conditional, depending on the support of a class of features to which it belongs,

e.g., an attribute in an attribute group, a parameter in a PDU, a PDU in a functional unit.

optional; o

It is left to the implementation as to whether this feature is implemented or not.

If an attribute group with a support level of 'o' is chosen to be supported, then all the attributes in this group that are

classified as 'm' shall be supported.

The support for PDUs is determined by the negotiation of functional units when the connection is established.

If a parameter is optionally supported, then its syntax shall be implemented, but it is left to each implementation

whether its procedures are implemented or not.

When receiving an optional parameter which is not subject of negotiation and is not supported by the Receiver, the Receiver shall at least inform the Sender by informative diagnostic and interworking shall not be disrupted.

conditional; c

This feature shall be supported under the conditions specified in FTAM Phase 3. If these conditions are not met, the feature is outside the scope of the Profile.

excluded; x

This feature is excluded from the Profile. The implementor's answer in the PICS shall always be 'no',

outside the scope; I

This feature is outside the scope of the Profile, i.e., it may be ignored, and will therefore not be subject of a Profile conformance test. However the syntax of all parameters of supported PDUs shall be implemented, even if their procedures are not (i.e., the Receiver shall be able to decode the PDU).

not applicable; -

This feature is not defined in the context where it is mentioned, e.g., a parameter which is not part of the respective

PDU. The occurrence of 'not applicable' features is mainly due to the format of the tables in the Phase 3 Profiles Requirements List.

16
Part 10 - FTAM Phase 3 March 1991 (Stable)

Section 1

A.1 (void)

I A.2 (void)

I Section 2: General ISO 8571 Detail

A.3 ISO 8571 Protocol versions

1 FTAM protocol version number(s) version-1

A.4 ISO 8571 Addenda

1 ISO 8571-1 —

2 ISO 8571-2 —

3 ISO 8571-3 —

4 ISO 8571-4 —

5 ISO 8571-5 —

A.5 Defect report numbers and amendments

1 ISO 8571-1 —

2 ISO 8571-2 —

3 ISO 8571-3 —

4 ISO 8571-4 —

5 ISO 8571-5 —

i A.6 Global statement of conformance

1 Does FTAM Phase 3 conform to ISO 8571 ? yeS

17

I
Part 10- FTAM Phase 3 March 1991 (Stable:

A.7 Initiator / Responder capability

ROLES D PROFILES

1 R

Sender 0 O 0

Receiver 0 o o NOTE - See part 9 18.1

A.8 Application Context Name details

ISO 8571-4 defines a value for a simple transfer mechanism. Other values are not defined for FTAM Phase 3 (see part 9 5.9).

18
PART 10 - FTAM Phase 3 September 1991 (Stable)

Annex B (normative)

Register of FTAM Objects

Thft objects defined In B^*1 and will be removed from this document after iSO/lEC tSP tOfiOM

mi ISO/tEC i$P 10607-a/Amd«1 are publistied. During the period between publishing tine ISP and the

removal of tbe definitions tram this document the defimtions in tbe \SP wil take precedence ovjr^thlf

docutnertt.

Wtfi^tbe obiect definltiotis are removed, dauses S,a.t and BJLZyM be chm^W

18-1
:
Part 10 - FTAM Phase 3

A.9 Abstract syntaxes

Section 3 : Syntax Detail

December 1990 (Stable)

Object Descriptor Object Identifier D T1.3 T2.3 A1.3 M1.3

1 FTAM PCI {iso standard 8571 abstract-syntax(2)

ftam-pci(l)

}

m m m m m

2 FTAM FADU {iso standard 8571 abstract-syntax(2)

ftam-tadu(2)

}

o m m

3 {joint-iso-ccitt association-control(2)

abstract-syntax(l) apdus(O) versionl(l)

}

m m m m m

4 FTAM unstructured

text abstract syntax

{iso standard 8571 abstract-syntax(2)

unstructured-text(3)

}

0 m m m -

5 FTAM unstructured

binary abstract syntax

{iso standard 8571 abstract-syntax(2)

unstructured-binary(4) }

0 m m m

6 NBS file directory

entry abstract syntax

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-as2(2)

}

c c c

7 NBS abstract syntax AS1

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-as1(1) }

-

i c c

8 NBS random access node name abstract syntax

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-node-name(3)

}

- c c

see clause 9

-

9 NBS random binary access file abstract syntax

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-random-binary(4)

}

i c c

10 NBS simple text

abstract syntax

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-simple-text(5)

}

i c c

NOTES

1 The abstract syntaxes whichi are supported in tfie implementation Profile W.S depend on the T-or A-Profile in conjunction with which M1.3 is implemented.

2 The support requirements for the conditional abstract syntaxes depend on the constraint sets and document types which are implemented (see clause A. 13).

3 ISO 8571 requires the presence of the transfer syntax derived from the "Basic Encoding of a single ASN.1 type "{joint-iso-ccitt asnl (1) basic-encoding (1)} encoding rules for transfer of the "FTAM PCI" and the "FTAM FADU" abstract syntaxes. Implementation detail of this transfer syntax, and other transfer syntaxes supported, is specified in the PICS of ISO 8823.

19
Part 10 - FTAM Phase 3 December 1990 (Stable)

Section 4 : Virtual Filestore Detail

A.10 Virtual filestore

This clause details the conformance to the file model, file attribute support and to file structure support.

A.10.1 File model

FILE MODEL D PROFILES

R

Hierarchical 0 m

Other models i

A.I 0.2 Attributes

A.1 0.2.1 Attribute groups

ATTRIBUTE GROUP NAME D PROFILES

1 Kernel m m

2 Storage 0 o

3 Security 0 o

4 Private 0 i

A.10.2.2 Attribute values

KERNEL GROUP

(INITIATOR)

D PROFILES

1 full RANGE OF VALUES

1 Filename f m see A.10.2.3

2 Permitted Actions f m

3 Contents Type f m see A. 12.7

KERMEL GROUP

(RESPONDER)

D PROFILES

R full RANGE OF VALUES

4 Filename f m see A.10.2.3

5 Permitted Actions f m

6 Contents Type f m see A.I 2.7

20
Part 10- FTAM Phase 3 March 1991 (Stable)

STORAGE GROUP

(INITIATOR)

D PROFILES

1 full RANGE OF VALUES

7 Storage account f m

8 File availability f m

9 Future filesize f m see part 9 1 7 9

NOTE - An initiator shall not partially support attributes

STORAGE GROUP

(RESPONDER)

D PROFILES

R full R partial RANGE OF VALUES

10 Storage account P o o

11 Date and time of creation P o o

12 Date and time of last modification P o o

13 Date and time of last read access P o o

14 Date and time of last attribute modification P o o

15 Identity of creator P o o

16 Identity of last modifier P o o

Identity of last reader P o o

|ia Identity of last attribute modifier P o o

|i. File availability P m X

Filesize P m X see part 9 17.9

(21 Future filesize P o o see part 9 17.9

1

3 SECURITY GROUP

(INITIATOR)

D PROFILES

1 full RANGE OF VALUES

Access control f m see A.12.2

la Legal qualifications f m

|i NOTE - An initiator sfiall not partially support attributes

SECURITY GROUP

(RESPONDER)

D PROFILES

R full R partial RANGE OF VALUES

Access control P m X see A.12.2, part 9 9.2

Legal qualifications P o o

21
PartIO- FTAM Phase 3

A.10.2.3 Riename detail

March 1991 (Stabl[

A.I 0.3 File structures

A«10.3.1 Constraint sets

See part 9 9.1

CONSTRAINT SET NAME D T1.3 T2.3 A1.3 M1.3

Unstructured 0 m m fn

Sequential Flat 0 i m m

Ordered flat 0 i @ o

Ordered flat widi unique names 0 1 o ©

Ordered hierarchical 0 i !8

General hierarchical 0 i i i

General hierarchical with unique names 0 i i i

NBS ordered flat - 1 @ © -

NBS random access i o o

A.1 0.3.2 File and filestore actions

A.1 0.3.2.1 Filestore Actions

Support for filestore actions is dependent upon the functional units implemented (see A.I 2.4 and A.I 2.5)

A.10.3.2,2 File Actions

CONSTRAINT SET

RESPONDER

unstructured

ACTION D T1.3

Locate

Read 0 0

Insert

Replace 0 o

Extend 0 0

Erase 0 i

22
Part 10 - FTAM Phase 3 December 1990 (Stable)

CONSTRAINT SET

RESPONDER unstructured sequential

flat

ordered

flat

ordered flat with unique names

NBS

ordered

flat

NBS

random

access ACTION D T2.3 D T2.3 D T2.3 D T2.3 D T2.3 D T2.3

7 Locate 0 i 0 0 i i

e Read 0 o 0 o 0 o 0 o o o

9 Insert 0 o 0 o 0 o o o

10 Replace 0 o 0 o 0 o o o

11 Extend 0 o 0 o 0 o

12 Erase 0 1 0 1 0 i 0 i i

CONSTRAINT SET

RESPONDER unstructured sequential

fiat

ordered

flat

ordered flat witfi unique namesNBS

ordered

flat

NBS

random

access ACTION D A1.3 D A1.3 D A1.3 D A1.3 D A1.3 D A1.3

13 Locate 0 o 0 o 0 o o o

14 Read 0 o 0 o 0 o 0 o o o

15 Insert 0 o 0 o 0 o o o

16 Replace 0 o 0 o 0 o o o

17 Extend 0 o 0 o 0 o

18 Erase 0 o 0 o 0 o 0 o o o

NOTE - File actions are not defined in Implementation Profile M1.3

23
Part 10 - FTAM Phase 3

A.1 0.3.2.3 Access contexts supported

December 1990 (Stable)

CONSTRAINT SET

RESPONDER unstructured

ACCESS CONTEXT D T1.3

US

UA o m

FS

FL

FA

HN

HA

CONSTRAINT SET

RESPONDER unstructured sequential ordered ordered flat NBS NBS

with unique ordered random

flat flat names flat access ACCESS CONTEXT D T2.3 D T2.3 D T2.3 D T2.3 D T2.3 D T2.3

US

UA 0 m 0 m 0 m 0 m m m

FS

FL

FA 0 m 0 m 0 m m

HN

HA o o 0 o o

24
Part 10 - FTAM Phase 3 December 1990 (Stable)

CONSTRAINT SET

RESPONDER unstructured sequential

flat

ordered

fiat

ordered flat with unique names

NBS

ordered

flat

NBS

random

access ACCESS CONTEXT D A1.3 D A1.3 D A1.3 D A1.3 D A1.3 D A1.3

US

UA 0 m 0 m 0 m 0 m m m

FS

FL

FA 0 m 0 m 0 m m

HN

HA 0 o 0 o o

NOTE - The supported access contexts for Impementation Profile M1.3 are defined in the T- or A-Profile in conjunction with which M1.3 is implemented.

A.10.4 Additional information

( Void

)

A.10.5 Override

RESPONDER OVERRIDE D PROFILES

R

1 Create failure 0 m

2 Select old file 0 m

3 Delete and recreate with old attributes 0 o

4 Delete and create with new attributes 0 m

NOTE - The specification of the role of initator is given in A. 12. 15.

25
Part 10 - FTAM Phase 3 December 1990 (Stable)

Section 5 : File Protocol Detail

A.11 File protocol

See part 9 clauses 5.1 • 5.3 and 17

Subclauses A.11. 2 to A.1 1.24 specify an indication of which PDUs are supported. The conformance requirements

for PDUs are dependent on the particular functional units implemented. PDUs indicated in A.1 1.8 to A. 11.24 as

conditional shall be considered as mandatory when a particular functional unit is implemented, according to the

following table.

PDUs Clause

Functional Units

Kernel Read Write Ac- cess LFM EFM GroupingRecoveryRestart

F-CREATE A.11.

8

m

F-DELETE A.11.

9

m

F-READ-ATTRIB A.11. 10 m

F-CHANGE-ATTRIB A.11. 11 m

F-OPEN A.11. 12 m m

F-CLOSE A.11. 13 m m

F-BEGIN-GROUP A.11. 14 m

F-END-GROUP A.11. 15 m

F-RECOVER A.11. 16 m

F-LOCATE A.11. 17 m

F-ERASE A.11. 18 m

F-READ A.11. 19 m

F-WRITE A.1 1.20 m

F-DATA-END A.1 1.21 m m

F-TRANSFER-END A.1 1.22 m m

F-CANCEL A.1 1.23 m m

F-RESTART A.1 1.24 m

NOTES

1 In order to keep the protocol tables compact some forward references have been introduced to clauses which expand upon the

detail of field support.

2 The FTAM protocol will require a number of optional lower layer services to be available (e.g., Application Entity Titles in ACSE).

This requirement is outside the scope of this Profiles Requirements List.

26
Part10-FTAM Phase 3

A.11.1 GraphicString support

December 1990 (Stable)

( Void )

A.11.2 FTAM regime establishment

1 UR

rHUrlLco

i R

1 F-INITIALIZE PDU m m m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 State result - m m all values defined in ISO 8571

3 Action result - m m all values defined in ISO 8571

4 Protocol version m m m m see Section 2

5 Implementation information 0 0 o o see A. 12.1

6 Presentation context management m m m m see note 1, part 9 17.10

7 Service class m m m m see A. 12.4

8 Functional units m m m m see A. 12.5

9 Attribute groups m m m m see A. 10.2

10 Shared ASE information 0 o i 1 see part 9 5.8

11 FTAM Quality of Service m m m m see A. 12.8

12 Contents type list 0 0 m m see A.I 2.7.1, part 9 18.4

13 Initiator identity 0 m see 8.8, part 9 16.1 and 18.4

14 Account 0 o see 8.8, part 9 18.4

15 Filestore password 0 m see A,12.11, 8.8, part 9 15.1

15 Diagnostic 0 m see A.12.6, 8.5.2, part 9 13

17 Checkpoint window m m m m see note 2, 8.5.2

NOTES

1 The values available for the presentation context management field depend upon the functional units implemented in ISO 8823.

2 Checkpoint window field is indicated as mandatory in accordance with ISO 8571-4. The field is defaulted to the value 1.

27
Part 10 - FTASWi Phase 3

A.1 1.3 FTAM regime termination (orderly)

December 1990 (Stable)

D

S R

PROFSLES

1 R

F-TERMINATE PDU m m m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Shared ASE information o o i i see part 9 5.8

Charging - o - o see A.12.10

A.11.4 FTAM regime termination (abrupt) by service user

D PROFSLES

F-U-ABORT PDU m m

FIELD HAME

RANGE OF VALUES

OR REFERENCE

Action result m m all values defined in ISO 8571

Diagnostic o m see A. 12.6, part 9 13

A.11.5 FTAM regime termination (abrupt) by service provider

D PROFILES

F-P-ABORT PDU m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m m all values defined in ISO 8571

Diagnostic o m see A.12.6, 8.5.2, part 9 13

28
Part 10 - FTAM Phase 3

A.11.6 File selection

December 1990 (Stable)

D

1 R

PROFILES

1 R

F-SELECT PDU m m in m

RANGE OF VALUES

FIELD NAME OR REFERENCE

State result m m all values defined in ISO 8571

Action result m m all values defined in ISO 8571

Attributes m m m m see A. 10.2, part 9 17.9

Requested access m m see A.12.16

Access passwords 0 m see 8.8, part 9 16.2

Concurrency control o o see A.12.13, 8.6.1

Shared ASE information 0 0 1 1 see part 9 5.8

Account 0 o see 8.8, part 9 18.4

Diagnostic 0 m see A.I 2.6, part 9 13

A.1 1.7 File deselection

D

1 R

PROFILES

1 R

F-DESELECT PDU m m m m

RANGE OF VALUES

FIELD NAME OR REFERENCE

Action result m - m all values defined in ISO 8571

Charging o o see A. 12. 10

Shared ASE information 0 0 1 i see part 9 5.8

Diagnostic 0 - m see A. 12.6, part 9 13

29
Part 10- FTAM Phases December 1990 (Stable)

A.11.8 File creation

D

I R

PROFILES

1 R

1 F-CREATE PDU c c c c see A.11, A.12.5 RANGE OF VALUES

FIELD NAME OR REFERENCE

2 State result m m all values defined in ISO 8571

3 Action result m m all values defined in ISO 8571

4 Override m m see A.I 2.1

5

5 Initial attributes m m m m see A.10.2, part 9 10.2.2,17.9

5 Create password 0 m - see A.12.12, 8.7, 8.8,

part 9 16.2

7 Requested access m m see A.12.16

8 Access passwords 0 m see 8.8, part 9 16.2

9 Concurrency control 0 o - see A.12.13, 8.6.1

10 Shared ASE information 0 0 see part 9 5.8

11 Account 0 o - see 8.8, part 9 18.4

12 Diagnostic 0 m see A. 12.6, part 9 13

A.1 1.9 File deletion

D

1 R

PROFILES

1 R

1 F-DELETE PDU c c c c see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result m m all values defined in ISO 8571

3 Shared ASE information 0 0 i i

4 Charging - 0 - o see A. 12.10

5 Diagnostic 0 rn see A.I 2.6, part 9 13

30
Part 10- FTAM Phase 3

A.11.10 Read attributes

March 1991 (Stable)

0

1 R

PRORLES

1 R

1 F-READ-ATTRIB PDU c c c c see A.11. A. 12.5

RANGE OF VALUES

FIELD NAME OR REFERENCE

2 Action result - m - m all values defined in ISO 8571

3 Attribute names m m -

4 Attributes - 0 - m see A. 10.2, part 9 17.9

5 Diagnostic - 0 - m see A.12.6, part 9 13

A.1 1 .1 1 Change attributes

D

1 R

T1.3, T2.3, A1.3 Ml.

3

1 R

1 F-CHANGE-ATTRIB c c i m m see A.11, A.12.5

RANGE OF VALUES

FIELD NAME OR REFERENCE

2 Action result m i - m all values defined in ISO 8571

1 Attributes m 0 i m m see A.10.2, part 9 17.9

4 Diagnostic 0 1 - m see A.12.6, part 9 13

A.11.12 File open

D

1 R

T1.3, T2.3, A1.3

1 R

M1.3

1 F-OPEN PDU c c tn m i see A.11, A.12.5

RANGE OF VALUES

FIELD NAME OR REFERENCE

2 State result m • m 1 ail values defined in ISO 8571

1 Action result m m i all values defined in ISO 8571

i* Processing mode m m i see A. 12.1

1.5 Contents type m m m m 1 see A.12.7.2

31
Part 10- FTAM Phase 3 March 1991 (Stable)

6 Concurrency control 0 0 o o see A. 12. 13, 8.6.1

7 Shared ASE information 0 0 i i see part 9 5.8

a Enable FADU locking m m ——

false for T1.3 and T2.3

9 Activity identifier 0 o

10 Diagnostic 0 m see A.I 2.6, part 9 13

11 Recovery mode m m m m see A. 12.18

12 Remove contexts 0

1

1

13 Define contexts 0 i i

14 Presentation action m m i see note

NOTE - The values depend upon the functional units implemented in ISO 8823.

A.11.13 File close

D T1.3, T2.3, A1.3 M1.3

F-CLOSE PDU c m i see A.11. A.12.5

FIELDNAME

RANGE OF VALUES

OR REFERENCE

Action result m m i all values defined in ISO 8571

Shared ASE information o i i see part 9 5.8

Diagnostic o m 1 see A.I 2.6, part 9 13

A.11.14 Beginning of grouping

D

1 R

T1.3, T2.3

1 R

A1.3

1 R

F-BEGIN-GROUP PDU c c m m o o see A.11, A.12.5

FIELDNAME

RANGE OF VALUES

OR REFERENCE

Threshold m - m m

A.11.15 End of grouping

D T1.3, T2.3 A1.3

F-END-GROUP PDU c m o see A.11, A.12.5

The F-END-GROUP PDU carries no fields.

32
Part 10 - FTAM Phase 3

A. 1 1 . 1 6 RegIme recovery

December 1990 (Stable)

See 8.5 D

1 R

T1.3, T2.3, A1.3

1 R

Ml.

3

1 F-RECOVER PDU c c c c 1 see A.1 1, A. 12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 State result - m - m 1 all values defined in ISO 8571

3 Action result - m - m i all values defined in ISO 8571

4 Activity identifier m - m -i

5 Bulk transfer number m m 1 see clause 9

6 Requested access m m i see A.12.16

7 Access passwords 0 - m 1 see 8.8, part 9 16.2

8 Contents type m - m 1 see A. 12.7.2

9 Recovery point m m m m i

10 Diagnostic - 0 m 1 see A.12.6, 8.5.2, part 9 13

11 Remove contexts 0 -

i - 1 see notes

12 Define contexts 0 - i - i see notes

13 Presentation action m m see notes

NOTES

1 The values available for the presentation action field depend upon the functional units implemented in ISO 8823.

2 Presentation action field is indicated as mandatory in accordance with ISO 8571-4. The field is defaulted to no action.

A.11.17 Locate file access data unit

D

1 R

T1.3, T2.3 A1.3

1 R

M1.3

1 F-LOCATE PDU c c i m m see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result - m 1 - m 1 all values defined in ISO 8571

3 FADU identity m 0 i m o see part 9 17.9

4 FADU lock 0 -

i o - see A.12.14

5 Diagnostic 0 i • m i see A.12.6, part 9 13

33
Part 10 - FTAM Phase 3

A.11.18 Erase file access data unit

December 1990 (Stable)

D T1.3, T2.3

i R

A1.3

i R

Ml.

3

F-ERASE PDU c c 1 m m 1 see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m i - m all values defined in ISO 8571

FADU identity m - i m see part 9 17.9

Diagnostic - 0 i - m see A.I 2.6, part 9 13

A.11. 19 Read bulk data

D

1 R

T1.3, T2.3

1 R

A1

1

.3RMl.

3

F-READ PDU c c c c m m see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

FADU identity m m m see part 9 17.9

Access context m - m - m see A. 10.3. 2.3

FADU lock 0 o 1

A.11.20 Write bulk data

D

! R

T1.3, T2.3

1 R

A1.3

1 R

Ml.

3

F-WRITE PDU c c c c m m i see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

FADU operation m - m m

FADU identity m - m m - see part 9 17.9

FADU Lock 0 -

1 o i

34
Part 10 - FTAM Phase 3

A.1 1 .21 End of data transfer

December 1990 (Stable)

D T1.3, T2.3, A1.3 Ml.

3

F-DATA-END PDU c m i see A.1 1, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m m i all values defined in ISO 8571

Diagnostic 0 m see A.1 2.6, part 9 13

A.11.22 End of transfer

D

1 R

T1.3, T2.3, A1.3

1 R

Ml.

3

F-TRANSFER-END PDU c c m m i see A.11, A.12,5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m - m i all values defined in ISO 8571

Shared ASE information 0 0 i i see part 9 5.8

Diagnostic - 0 - m see A. 12.6, part 9 13

A.11.23 Cancel data transfer

See part 9 clause 1

D T1.3, T2.3, A1.3 Ml.

3

F-CANCEL PDU c m see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m m i all values defined in ISO 8571

Shared ASE information 0 1 see part 9 5.8

Diagnostic 0 m i see A. 12.6, part 9 13

A.1 1 .23.1 F-CANCEL mapping

See part 9 clauses 11 and 17.10

35
Part 10 -FTAM Phase 3

A.11.24 Restart data transfer

December 1990 (Stable)

D T1.3, T2.3, A1.3 M1.3

F-RESTART PDU c c see A.11, A,12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Checkpoint identifier m m i

A.12 Expanded PDU field and filestore detail

This clause identifies further PDU field and filestore detail to expand on that given in A. 10 and A.11.

A.12.1 Smplementation information detail

See 8.3, part 9 5.6 and 12

A.12.2 Access control detail

See 7.3, part 9 9.2 Access control element terms

D PROFILES

RANGE OF VALUES

Action list m m

Concurrency access o o see A. 12.3,3

identity o o

Passwords o o see A.I 2.3.5, A.I 2.3.6, 8.8

Location o o

A.12.3 Access control element detail

A.I 2.3.1 Action list detail (initiator)

( Void )

A.I 2.3.2 Action list detail (responder) « ( Void )

36
Part 1 0 - FTAM Phase 3 December 1 990 (Stable)

A.1 2.3.3 Concurrency access term

If the concurrency access term is supported in \he access control element the following details of the concurrency

control shall be available with each action.

T1.3 Action

not required

D T1.3

shared

D T1.3

exclusive

D T1.3

no access D T1.3

1 Read 0 o 0 o 0 o 0 o

2 Insert 0 i 0 i 0 1 0 1

3 Replace 0 o 0 o 0 o 0 o

4 Extend Q Q o o 0 o 0 o

5 Erase 0 i 0 0 0 i

6 Read attributes 0 o 0 o 0 o 0 o

7 Change attributes 0 1 0 1 0 1 0 i

8 Delete file 0 o o o 0 o 0 o

T2.3 Action

not required

D T2.3

shared

D T2.3

exclusive

D T2.3 no access D T2.3

9 Read 0 o 0 o 0 o 0 o

10 Insert 0 o 0 o 0 o 0 0

11 Replace 0 o 0 o 0 o 0 0

12 Extend 0 o 0 o 0 o 0 o

13 Erase 0 0 1 0 i 0 i

14 Read attributes 0 o 0 o 0 o 0 o

15 Change attributes 0 i 0 1 0 1 0 i

16 Delete file 0 o 0 o 0 o 0 o

I

I

37
Part 10 - FTAM Phase 3 December 1990 (Stable) »]

A1.3

Action

not required

D A1.3

sliared

D A1.3

exclusive

D A1.3 no access D A1.3

17 Read 0 o 0 o 0 o 0 o

18 Insert 0 o o o 0 o 0 o

19 Replace 0 o 0 o 0 o 0 o

20 Extend 0 o 0 o 0 o o o

21 Erase 0 o 0 o 0 o 0 o

22 Read attributes 0 o o o 0 o 0 o

23 Change attributes 0 i 0 1 o i 0 i

24 Delete file o o 0 o 0 o 0 o

Ml .3 not required

Action D M1.3

shared

D Ml.

3

exclusive

D

no access

Ml.3 D M1.3

25 Read 0 i 0 0 i 0 1

26 Insert 0 i 0 0 1 0 1

27 Replace 0 i 0 0 0 i

28 Extend 0 1 0 0 0 1

29 Erase 0 1 0 i 0 0 i

30 Read attributes 0 o 0 o 0 o 0 o

31 Change attributes 0 o 0 o 0 o 0 o

32 Delete tile 0 o 0 o 0 o 0 o

A.1 2.3.4 Identity term

( Void )

A.1 2.3.5 Initiator access passwords

if the passwords term of the access control element is implemented the following values shall be supported for the

initiator role. See part 9 16.3

Initiator Access Passwords D PROFILES

1 OctetString 0 o

2 GraphicString 0 o

38
Part 10 - FTAM Phase 3 December 1990 (Stable)

A.I 2.3.6 Responder access passwords

If the passwords term of the access control element is implemented the following values shall be supported for the responder role. See part 9 16.3 Responder Access

Passwords

D T1.3

OctetString

GraphicString

T2.3

OctetString

GraphicString

A1.3

OctetString

GraphicString

M1.3

OctetString

GraphicString

Read-password 0 o o o i

Insert-password 0 i o o i

Replace-password 0 o o o 1

Extend-password o o o o

Erase-password 0 o

Read-attribute-password o o o o o

Change-attribute-password 0 i i o

Delete-password 0 o o o o

A.I 2.3.7 Location term

( Void )

A.1 2.3.7.1 Application Entity Titles detail

See part 9 5.7

A.I 2.3.8 Access control element combinations

Combinations D PROFILES

R

Identity Password Location 0 o

Identity Password 0 o

Identity Location 0 o

Password Location 0 o

Identity 0 o

Password 0 o

Location 0 o

NOTE - Implementation of access control without any of the above combinations is valid.

39
Part 10- FTAM Phase 3

A.12.4 Service class field detail

December 1990 (Stable)

See 5.1, 8.1, part 9 table 7

D T1.3, T2.3 A1.3 Ml .3 (T) Ml.3 (A)

1 Transfer class o m 1 m i

2 Access class 0 i m i m

3 Management class 0 1 1 m m

4 Transfer and management class 0 o i m i

5 Unconstrained class 0 i i 1

NOTES

1 The initiator is only permitted to specify those combinations defined in ISO 8571-3

2 The notation M1.3(T) indicates M1.3 combined with a Transfer Profile T1.3 or T2.3. M1.3(A) means Ml .3 combined with the Access Profile A1.3.

A.12.5 Functional unit field detail

See 8.1, 8.2, part 9 table 7

T1.3, T2.3 SERVICE CLASSES

Transfer Transfer and Management

FUNCTIONAL UNITS D T1.3, T2.3 D T1.3, T2.3

1 Kernel m m m m

2 Read (see note 2) c o c o

3 Write (see note 2) c o c o

4 File Access

5 Limited File Management 0 0 m m

6 Enhanced

File Management 0 1 0 i

7 Grouping m m m m

8 FADU Locking

9 Recovery 0 o 0 o

10 Restart 0 o 0 o

NOTES

1 The recovery and the restart functional units are only available at the internal file service interface and should only be explicitly referenced in the protocol. 2 The c indicates that either or both of the read and write functional units shall be implemented in the particular service class.

40
Part 10 FTAM Phase 3 December 1 990 (Stable)

A1.3

FUNCTIONAL UNITS

SERVICE CLASSES

Access

D A1.3

11 Kernel m m

12 Read m m

13 Write m m

14 File Access m m

15 Limited File Management 0 o

10 Enhanced

File Management 0 i

17 Grouping 0 o

18 FADU Locking 0 o see 8.6.2

19 Recovery 0 0

20 Restart 0 o

See 8.1

M1.3(T) SERVICE CLASSES

Transfer Management Transfer and Management

FUNCTIONAL UNITS D M1.3{T) D M1.3(T) D M1.3(T)

Kernel m m m m

Read c o

Write c o

File Access

Limited File Management o m m m m m

Enhanced

File Management o m 0 m 0 m

Grouping m m m m

FADU Locking

Recovery 0 o

Restart 0 o

NOTE - Ml.3(1) indicates Ml.3 in conjunction with a Transfer Profile T1.3 or T2.3. This table lists only the additional functionality as defined by M1.3.

41
Part 10 - FTAM Phase 3 December 1990 (Stable)

Ml.3(A)

FUNCTIONAL UNITS

See 8.1 SERVICE CLASSES

Access

D M1.3(A)

Management

D M1.3(A)

Kernel m m

32

33

34

Read

Write

36

37

38

39

File Access

Limited File Management

Enhanced

File Management

m m

Grouping m m

FADU Locking

Recovery

Restart

NOTE - M1.3(A) indicates M1.3 in conjunction with the Access Profile A1.3. This table lists only the additional functionality as defined by Ml .3.

A.I 2.6 Diagnostic field detail

D T1.3, T2.3, A1.3 Ml.

3

Diagnostic type m m m

Error identifier m m m

Error observer m m m

Error source m m m

Suggested delay 0 c 1 see 8.5.2

Further details 0 m m

For values of the 'further details' term only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1) character sets is required (see part 9 clause 13).

42
Part 10 - FTAM Phase 3 December 1990 (Stable)

A.12.7 Contents type detail

A.I 2.7.1 Contents type list parameter

See part 9 10.2.1 D PROFILES

1 R

Maximum number of elements

document type specifications

abstract syntax specifications

0 o m

0 o m

A.1 2.7.2 Contents type parameter

See part 9 10.2.3 D PROFILES REFERENCE

document type specifications 0 m see part 9 9.1

abstract syntax / constraint set pair

specifications

0 i

HOTE - The detail of document types supported is contained in clause A. 13.

A.I 2.8 FTAM Quality of service details

See 8.5.2

A.1 2.9 Details of shared ASE information

( Void )

A.1 2.10 Details of charging

See part 9 5.8 and 18.4 Charging D PROFILES

R

Resource identifier term m m

Charging unit term m m

Charging value term m m

43
Part 10 - FTAM Phase 3 December 1990 (Stable) , A.12.11 FiSestore password detaii

Filestore password detail D PROFILES

OctetString 0 o

GraphicString 0 o

A.I 2.1 2 Create password detail

See part 9 16.3

Create password detail D PROFILES

OctetString 0 o

GraphicString 0 o

A.I 2.1 3 Concurrency control

A.12.13.1 Supported values

See 8.6.1

T1.3 not required shared exclusive no access

Action D T1.3 D T1.3 D T1 3 D T1.3

Read 0 o 0 o 0 o o o

Insert 0 i 0 0 o i

Replace 0 o 0 o 0 o 0 o

Extend 0 o 0 o 0 o 0 o

Erase 0 1 0 i 0 i 0 i

Read attrib 0 o 0 o 0 o o o

Change attrib 0 i 0 0 1 0 i

Delete file 0 o 0 o 0 o 0 o

44
Part 10 - FTAM Phase 3 December 1990 (Stable)

T2.3 not required shared exclusive no access

Action D T2.3 D T2-3 D T2.3 D T2.3

9 0 o Q Q 0 o 0 o

10 InsGrt o o Q Q 0 o o o

11 0 o 0 O 0 o 0 o

12 0 o 0 o 0 o 0 o

13 Er3S6 0 1 \J

1

1 0 1 o i

14 0 o 0 o 0 o 0 o

25 Change attrib 0 i 0 i o i 0 1

16 Delete file 0 o 0 o 0 o 0 o

A1.3

not required shared exclusive no access

Action D A1.3 D A1.3 D A1.3 D A1.3

17 Read 0 o 0 o 0 o 0 o

18 Insert 0 o 0 o 0 o 0 o

19 Replace 0 o 0 o 0 o 0 o

20 Extend 0 o 0 o 0 o 0 o

21 Erase 0 o 0 o 0 o 0 o

22 Read attrib 0 o 0 o o o o o

23 Change attrib 0 0 0 o i

24 Delete file 0 o 0 o 0 o o o

45
Part 10 - FTAM Phase 3 December 1990 (Stable)

M1.3

not required shared exclusive no access

Acxion D M1.3 n M 1 -O nU MiM 1 .«3t U M 1 .J

25 Read o o

I

1 0 i 0 [

26 Insert 0 0 i 0 1 0 1

27 Replace 0 0

11 0 i 0 1

28 Extend 0 0

1

1 0 i 0 i

29 Erase 0 0 0 i 0 1

30 Read attrib 0 o 0 o 0 o 0 o

31 Change attrib 0 o 0 o 0 o 0 0

32 Delete file o o 0 o 0 o 0 o

A.I 2.13.2 Responder Default values

See 8.6.1, part 9 clause 14

A.I 2.14 FADU Locking

A1.3

not required

FADU Locking Support Values

shared exclusive no access

D A1.3 D A1.3 D A1.3 D A1.3

1 Read 0 o 0 o 0 0 0 0

2 Insert 0 o 0 o 0 o 0 o

3 Replace 0 o 0 o 0 o 0 o

4 Extend 0 o 0 o 0 o 0 o

5 Erase o o 0 o 0 o o o

46
Part 10 - FTAM Phase 3

A.I 2.1 5 Initiator Override

March 1991 (Stable)

initiator override D PROFiLES

i

1 Create failure 0 o

2 Select old file 0 o

3 Delete and reaeate with old attributes 0 o

4 Delete and create with new attributes 0 o

NOTE - The specification of the role of responder is given in A. 10.5

A.12.16 Requested Access

See part 9 clause 15

Action D T1.3 T2.3 A1.3 M1.3

1 Read 0 o o o

2 Insert 0 1 o o

3 Replace 0 o 0 o

4 Extend 0 o o o

5 Erase o 1 1 o

6 Read attribute 0 o o o m

7 Change attribute 0 1 1 i m

8 Delete file o o o o m

A.12.17 Processing mode

Processing mode D T1.3 T2.3 A1.3 Ml.

3

1 Read 0 o o o

2 Insert 0 i o o

3 Replace o o o o

4 Extend 0 o o o

5 Erase 0 i i o

47
Part 10- FTAM Phase 3

A.12.18 Recovery mode

March 1991 (StabII

See 8.5.2 Recovery mode D T1.3,T2.3, A1.3 M1.3

None 0 m 1

At start of transfer 0 m 1

Any active checkpoint 0 o

48
Part10-FTAM Phase 3 December 1990 (Stable)

Section 6 : Document Type Detail

A.13 Document types

See 7.1

Conformance to document types is given at two levels. The following table indicates which document types have some level of support. The detail of that level of support is stated in the following tables.

Entry number FTAM-1 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor

Object identifier

ISO FTAM unstructured text o

{iso standard 8571 document-type(5) unstructured-text(l)}

m m m

see A, 13.1

i

Entry number FTAM-2 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor

Object identifier

ISO FTAM sequential text o

{iso standard 8571 document-type(5) sequential-text(2)}

i m m

see A. 13.2

i

Entry number FTAM-3 D 11.

3

T2.3 A1.3 M1.3

Object descriptor

Object identifier

ISO FTAM unstructured binary o

{iso standard 8571 document-type(5) unstructured-binary(3)}

m m m

see A. 13.3

i

Entry number FTAM-4 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor

Object identifier

ISO FTAM sequential binary o

{iso standard 8571 document-type{5) sequential-binary(4)}

i o o

see A. 13.4

i

Entry number NBS-6 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-6 FTAM sequential file i o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) sequential(6)

}

see A. 13.5

Entry number NBS-7 D 11.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-7 FTAM random access file i o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) random-file(7)

)

see A. 13.6

49
Part 10 - FTAM Phase 3 December 1990 (Stable)

Entry number NBS-8 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-8 FTAM indexed file i o o j

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) indexed-file(8)

}

see A. 13.7

Entry number NBS-9 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-9 FTAM file directory file o o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) file-directory (9)

}

see part 9 18.3

Entry number NBS-10 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-10 FTAM random binary access file i o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) random-binary(IO) } see 7.

1

Entry number NBS-11 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-1 1 FTAM indexed file witfi unique keys i o o i

Object identifier {iso identified-organization oiw(14) ftamslg(5)

document-type(5) indexed-file-with-unique-keys(1 1)

}

see A. 13.8

Entry number NBS-1

2

D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-1 2 NBS FTAM simple text file i o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) simple-text-file(12)

}

see A. 13.9

50
Part 10 - FTAM Phase 3 December 1990 (Stable)

Constraint sets and FADU identities for document types

For the constraint set / FADU identity tables the following notation is used:

mandatory

optional not supported

not applicable excluded

in the constraint set definition, or optional in the constraint set definition but shall be implemented by implementations

claiming conformance to the Profile. The support of the FADU identity will be dependent on the actions which have been implemented.

in the constraint set definition (outside the scope of this ISP, may be Ignored)

(not defined in the constraint set definition) (disallowed in the document type definition or in FTAM Phase 3)

Implementation Profile T1.3.

FADU Identity Constraint Set

Begin End First Last Current Next Previous Node

Seq

Node

Number

FTAM unstructured

constraint set m

FTAM-1 m

FTAM-3 m

NBS-9 m

51
Part 10 - FTAM Phase 3

Implementation Profile T2.3 (see 7.2, part 9 clause 10)

December 1990 (Stable)

FADU identity

Constraint Set

Begin End First l-ast Current Next Previous Node

Seq

Node

Number

FTAM unstructured

constraint set m

FTAM-1 m

FTAM-3 tn

NBS-9 m

FTAM sequential flat constraint set o o 0 o o o o o

FTAM-2 m m i i i i i

FTAM-4 m m i i i i

NBS-6 m m i X X i X X

NBS-12 m m X X X X X X

FTAM ordered flat constraint set o o o o o o o o o

NBS-8 m i i i i m i

FTAM ordered flat constr

set with unique names

o o o o o o

NBS-11 m i m

NBS ordered flat constraint set o o o o o o o 0

1

NBS-7 m m m m i i i m

NBS random access

constraint set 0 o o o

1 NBS-10 m m m m

1

52
Part 10 - FTAM Phase 3

Implementation Profile A1.3 (see pan 9 clause 10)

December 1990 (Stable)

FADU Identity Constraint SetBegin End First Last Current Next Previous Node

Seq

Node

Number

FTAM unstructured

constraint set

- - m - - - - -

FTAM-1 m

FTAM-3 vn

NBS-9 m

FTAM sequential flat constraint set o o o o o o o °

1 FTAM-2 m m m i m i i

FTAM-4 m m m i m i

NBS-6 m m m X X m X X

NBS-12 m m m X X m X ^ 1

FTAM ordered flat constraint set Q o o o o o o o o

NBS-8 m m i i m m m m i

FTAM ordered flat constr

set with unique names

o o o o o o o

NBS-11 m m m m m m i

NBS ordered flat constraint set o o o o o o o o

NBS-7 m m m m m m m m

NBS random access

constraint set o o o o

1

NBS-10 m m m m

53
Part 10 • FTAM Pha^ "i

A.13.1 FTAM-1 (See 7.1)

A.13.1.1 Universal class number parameter (See part 9 10.1)

D T1 1 TO T A1 1

1 Universal class number parameter supported 0 m

2 PrintableString - Universal class 19 o i

3 TeletexString - Universal class 20 0 1

4 VideotexString - Universal class 21 o 1

5 lASString - Universal class 22 0 m see part 9 10.1.1-2

6 GraphicString - Universal class 25 0 m see A.I O.I .3

7 VisibleString - Universal class 26 0 m

8 GeneralString - Universal class 27 o m see A. 13. 1.4

A.I 3. 1.2 String length parameter and string significance parameter combinations

D T1.3, T2.3, A1.3

1 Maximum string length parameter and

variable length strings

0. m

2 Maximum string length parameter and

fixed length strings

0 m

3 Maximum string length parameter and

not significant strings

0 m

4 Unbounded strings and

variable length strings

0 m

5 Unbounded strings and

not significant strings

0 m

A.1 3.1.3 G sets supported

G sets which are supported in FTAM-1 GraphicString.

1 For values of GraphicString only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1)

character sets is required,

(see part 9 10.1.1 and 10.1.3)

54
Part 10 - FTAM Phase 3

A.13.1.4 G and C sets supported

G and C sets which are supported in FTAM-1 GeneralString

December 1990 (Stable)

For values of GeneralString only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1)

character sets and ISO 646 IRV (CO) control character set Is required

(see part 9 10.1-3)

A.13.2 FTAM-2 (see 7.1)

A.I 3.2.1 Universal class number parameter (see part 9 10.1)

D T2.3, A1.3

Universal class number parameter supported 0 m

PrintableString - Universal class 19 0 i

TeletexString Universal class 20 0 i

VideotexString - Universal class 21 0

lASString Universal class 22 0 o see part 9 10.1.1-2

GraphicString Universal class 25 0 m see A. 13.2.3

VisibleString Universal class 26 0 m

GeneralString Universal class 27 0 o see A. 13.2.4

A.I 3.2.2 String length parameter and string significance parameter combinations

D T2.3, A1.3

Maximum string length parameter and

variable length strings

0 i

Maximum string length parameter and

fixed length strings

0 1

Maximum string length parameter and

not significant strings

0 m

Unbounded strings and

variable length strings

0

Unbounded strings and

not significant strings

0 m

55
Part 10 - FTAM Phase 3

A.1 3.2.3 G sets supported

December 1990 (Stable)

G sets which are supported in FTAM-2 Graph icString.

For values of GraphicString only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1)

character sets is required,

(see part 9 10.1.1 and 10.1.3)

A.13.2.4 G and C sets supported

G and C sets which are supported in FTAM-2 GeneralString

For values of GeneralString only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1)

character sets and ISO 646 IRV (CO) control character set is required,

(see part 9 10.1.1-3)

A.1 3.3 FTAM-3

A.I 3.3.1 String length parameter and string significance parameter combinations (see 7.1)

D T1.3, T2.3, A1.3

Maximum string length parameter and

variable length strings

0

Maximum string length parameter and

fixed length strings

0 i

Maximum string length parameter and

not significant strings

0 m

Unbounded strings and

variable length strings

0

Unbounded strings and

not significant strings

0 m

56
Part 10 - FTAM Phase 3 December 1990 (Stable)

A.I 3.4 FTAM-4 (see 7.1)

A.I 3.4.1 String length parameter and string significance parameter combinations

D T2.3, A1.3

Maximum string length parameter and

variable length strings

0 1

Maximum string length parameter and

fixed length strings

0 1

Maximum string length parameter and

not significant strings

0 m

Unbounded strings and

variable length strings

0 1

Unbounded strings and

not significant strings

0 m

57
Part 10 - FTAM Phase 3

A.13.5 NBS-6

December 1990 (Stable)

See part 9 tables 2, 3

A.I 3.5.1 ParameterO

D T2.3, A1.3

ParameterO supported m

Universal-time Universal class 23 m

Generalized-time Universal class 24 m

boolean Universal class 1 m

null Universal class 5 m

A.I 3.5.2 Parameterl (see part 9 10.1)

D T2.3, A1.3

Parameterl supported m

integer Universal class 2 m

bit Universal class 3 m

IA5 Universal class 22 m

GraphicString Universal class 25 m

GeneralString Universal class 27 m

OctetString Universal class 4 m

A.I 3.5.3 Parameter2

D T2.3, A1.3

Parameter2 supported - o

58
Part 10 - FTAM Phase 3

A.13.6 NBS-7

December 1990 (Stable)

A.I 3.6.1 ParameterO

See part 9 tables 2, 3

D T2.3, A1.3

1 ParameterO supported m

2 Universal-time 1 Iniv/prQ^il place 0"^ nn

3 Generalized-time Universal class 24 m

4 boolean Universal class 1 m

5 null Universal class 5 m

A.I 3.6.2 Parameterl (see part 9 10.1)

D T2.3, A1.3

1 Parameterl supported m

2 integer Universal class 2 m

3 bit Universal class 3 m

4 IA5 Universal class 22 m

5 GraphicString Universal class 25 m

6 GeneralString Universal class 27 m

7 OctetString Universal class 4 m

A.I 3.6.3 Parameter2

D T2.3, A1.3

1 Parameter2 supported o

59
Part 10 - FTAM Phase 3

A.13.7 NBS-8

December 1990 (Stable)

See part 9 tables 2, 3

A.1 3.7.1 ParameterO

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

ParameterO supported m m

Universai-time Universal ciass 23 m m

Generalized-time Universal class 24 m m

boolean Universal class 1 m

null Universal class 5 m

A.1 3.7.2 Parameterl (see part 9 10.1)

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

Parameterl supported m m

integer Universal ciass 2 m m

bit Universal class 3 m

IA5 Universal class 22 m m

GraphicString Universal class 25 m m

GeneralString Universal class 27 m m

OctetString Universal class 4 m m

A.1 3.7.3 Parameter2

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

Parameter2 supported o o

60
Part 10 - FTAM Phase 3

A.13.8 NBS-11

March 1991 (Stable)

See part 9 tables 2, 3

A.1 3.8.1 ParameterO

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

ParameterO supported m m

Universai-time Universal class 23 m m

Generalized-time Universal class 24 m m

boolean Universal class 1 m

null Universal class 5 m

A.1 3.8.2 Parameterl (see part 9 10.1)

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

Parameter 1 supported m m

integer Universal class 2 m m

bit Universal class 3 m

IA5 Universal class 22 m m

GraphicString Universal class 25 m m

GeneralStnng Universal class 27 m m

OctetString Universal class 4 m m

A.1 3,8.3 Parameter2

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

Parameter2 supported o o

61
Part 10 - FTAM Phase 3 March 1991 (Stable)

A.13.9 NBS-12 (see 7.1)

A.13.9.1 Universal class number parameter (see part 9 10.1)

D T2.3, A1.3

1 Universal class number parameter supported m

2 PrintableString - Universal class 19 - 1

3 TeletexString - Universal class 20 - i

4 VideotexString - Universal class 21 - i

5 lASString - Universal class 22 m

6 GraphicString - Universal class 25 m see A, 13.9.5

7 VisibleString - Universal class 26 m

S GeneralString - Universal class 27 m see A. 13.9.

6

A.I 3.9.2 String length parameter

D T2.3, A1.3

Maximum string length parameter supported tn

A.I 3.9.3 String significance parameter

D T2.3, A1.3

1 String significance parameter supported m see 7.1 table 3(c)

2 Variable length strings supported m

3 Fixed length strings supported m

A.I 3.9.4 Character set parameter

D T2.3, A1.3

1 Character set parameter supported m see 7.1 table 3(c)

62
Part 10 - FTAM Phase 3 December 1990 (Stable)

A.1 3.9.5 G sets supported

G sets which are supported in NBS-12 GraphicString.

For values of GraphicString only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1)

character sets is required,

(see part 9 10.1.1 and 10.1.3)

A.1 3.9.6 G and C sets supported

G and C sets which are supported in NBS-12 GeneralString.

I For values of GeneralString only the support of character strings of the ISO 646 IRV (GO) and ISO 8859-1 (GO and G1)

character set and ISO 646 IRV (CO) control character sets is required,

(see part 9 10.1.1-3)

- END OF FTAM PHASE 3 PROFILES REQUIREMENTS LIST -

t

63
Part 10 - FTAM Phase 3 December 1990 (Stable)

Annex B

(normative)

NIST OIW Register of FTAM Objects

BJ. Introduction

This Index, the NIST OIW Register of OIW FTAM objects, contains a complete list of all FTAM objects as defined by NIST OIW.

NIST OIW was authorized by BSI in its letter dated August 09, 1989, as Registration Authority for NIST OIW defined

objects. The Object Identifier Prefix for OIW is

{ iso(1) identified-organization(3) oiw(14)

}

NIST OIW Plenary has delegated the authority and the task for maintenance of the NIST OIW Register of FTAM

objects to its FTAM Special Interest Group (SIG) at its meeting on September 15, 1989. The Object Identifier Prefix

for the FTAM SIG is

{ iso(1) identified-organization(3) oiw(14) ftamsig(5)

}

For each new OIW FTAM object to be registered, a complete technical definition, that describes the purpose, scope

and the unique characteristics of the object, must be prepared and presented to OIW FTAM SIG for technical discussion and acceptance, and for final approval by OIW Plenary.

64
Part 10- FTAM Phase 3

Index of QIW FTAM Objects

FTAM Phase 2 Defined Ob|ects

March 1991 (Stable)

Object Identifier Prefix : nist-adhoc ::= {iso(1) identified-organization(3) icd(9999) organization-code(l)}

Object Object Descriptor Object Identifier Date of

Registration

Reference to

Definition

MDC e NBo-D INDO-D r 1 rtivl sequential file tnisi-aunoc

document-type(5)

sequential(6)

}

uec 15, oy

Withdrawn

March 16, "90

Stable Agreements

Vers. 4, Ed. 1, December '90 NISI SP 500-183

part 9, annex A clause A.I

MPC 7 iNDo-/ r 1 MM ranaom

access file tnisi-aanocdocument-type(5)

random-file(7)

}

Uec 15, 89

Withdrawn

fwlarch 16, '90

Stable Agreements

Vers. 4, Ed. 1, December '90 NISTSP 500-1 83

part 9, annex A clause A.2

MDC Q Nbo-o MOO Q CTAkA Nbo-o r 1 AM

indexed file {nist-adhocdocument-type(5)

indexed-file(8)

}

Uec 15, 89

Withdrawn

March 1 6, '90

Stable Agreements

Vers. 4, Ed. 1 , December '90 NISTSP 500-183

part 9, annex A clause A.3

iNDo-y Kipo Q PTAM r filo 1 MM me

directory file |nisi-aunucdocument-type(5)

file-directory(9)

}

uec 15, oy

Withdrawn

March 1 6, '90

oiauie Mgreemenis

Vers. 4, Ed. 1, December '90 NISTSP 500-183

part 9, annex A clause A.4

KIR^ rtrHorari flat constraint set

^1 liol ClUI lULr constraint-set(4)

nbs-ordered-flat(l)

}

Han UQC 1 1; 'flQ 1 o, oy

Withdrawn

March 16, '90

QtaKIo An ante OLctUtc MUl eel I lol 1 Lo Vers. 4, Ed. 1, December '90 NISTSP 500-183

part 9, annex B clause B.I

NBS-AS1 NBS abstract syntax AS1

{nist-adhoc

abstract-syntax(2)

nbs-asl(l)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 4, Ed. 1, December '90 NISTSP 500-183

part 9, annex C clause C.I

NBS-AS2 NBS file directory

entry abstract syntax

{nist-adhoc

abstract-syntax(2)

nbs-as2(2)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 4, Ed. 1, December '90 NISTSP 500-1 83

part 9, annex C clause C.2

AP-Title {nist-adhoc

ftam-nil-ap-title(7)

}

Dec 15, '89 Stable Agreements

Vers. 4, Ed. 1, December '90 NIST SP 500-183

part 5 12.1.1.1

65
Part 10 - FTAM Phase 3

Object Identifier Prefix : nist-oiw-ftam

March 1991 (Stable)

:= {iso(1) identified-organi2ation(3) oiw(14) ftamsig(5)}

UDjeci Object Descriptor vjojeci laeniiTier Date of

Registration

Reference to

Definition

NBS-6 NBS-6 FTAM

sequential file {nist-oiw-ftamdocument-type(5)

sequential(6)

}

March 1 6, '90 Stable Agreements

Vers. 4, Ed. 1 , December '90 NIST SP 500-183

part 9, annex A clause A.5

NBS-7 NBS-7 FTAM random

access file

{nist-oiw-ftam

document-type(5)

random-file(7)

}

March 1 6. '90 Stable Agreements

Vers. 4, Ed. 1 , December '90 NISTSP 500-183

part 9, annex A clause A.6

NBS-8 NBS-8 FTAM

indexed file {nist-oiw-ftamdocument-type(5)

indexed-file(8)

}

March 16, '90 Stable Agreements

Vers. 4, Ed. 1, December '90 NIST SP 500-183

part 9, annex A clause A.7

NBS-9 NBS-9 FTAM file directory file{nist-oiw-ftam

document-type(5)

file-directory(9)

}

March 16, '90 Stable Agreements

Vers. 4, Ed. 1 , December '90 NIST SP 500-183

part 9, annex A clause A.8

NBS ordered flat constraint set{nist-oiw-ftam

constraint-set(4)

nbs-ordered-flat(1 )

}

March 16, '90 Stable Agreements

Vers. 4, Ed. 1 , December '90 NISTSP 500-183

part 9, annex B clause B.2

NBS-AS1 NBS abstract syntax AS1

{nist-oiw-ftam

abstract-syntax(2)

nbs-asl(l)

}

March 1 6. '90 Stable Agreements

Vers. 4, Ed. 1 , December '90 NIST SP 500-183

part 9, annex C clause C.3

NBS-AS2 NBS file directory

entry abstract syntax

{nist-oiw-ftam

abstract-syntax(2)

nbs-as2(2)

}

March 16, '90 Stable Agreements

Vers. 4, Ed. 1 , December '90 NISTSP 500-1 83

part 9, annex C clause C.4

66
Part 10 - FTAM Phase 3

B.2.2 FTAM Phase 3 Defined Qbfecta

March 1991 (Stable)

Object Identifier Prefix : nist-oiw-ftam := iso(1) identified-organization(3) oiw(14) ftamsig(5)

Object Object Descriptor Object Identifier Date of

Registration

Reference to

Definition

NBS-10 NBS-10 random

binary access file

{nist-oiw-ftam

document-type(5)

random-binary(IO)

}

Dec 15, '89 Stable Aqreements

Vers. 4, Ed. 1 , December '90 NIST SP 500-183

part 10, annex C clause C.I

NBS-11 NBS-11 FTAM indexed

file with unique keys

{nist-oiw-ftam

document-type(5)

indexed-file-with-uniquel<eys(11)

}

Dec 15, '89 Stable Aqreements

Vers. 4, Ed. 1 , December '90 NISTSP 500-183

part 10, annex C clause C.2

NBS-12 NBS-12 FTAM

simple text file

{nist-oiw-ftam

document-type(5)

simple-text-file(12)

}

Dec 15, '89 Stable Agreements

Vers. 4, Ed. 1 , December '90 NISTSP 500-183

part 10, annex C clause C.3

NBS Random Access {nist-oiw-ftam

constraint-set(4)

nbs-random-access(2)

}

Dec 15, '89 Stable Aqreements

Vers. 4, Ed. 1 , December '90 NIST SP 500-183

part 10, annex D clause D.I

NBS-AS3 NBS random access node name abstract syntax{nist-oiw-ftam

abstract-syntax(2)

nbs-node-name(3)

}

Dec 15, '89 Stable Aqreements

Vers. 4, Ed. 1 , December '90 NIST SP 500-183

part 10, annex E clause E.I

NBS-AS4 NBS random binary access file abstract syntax

{nist-oiw-ftam

abstract-syntax(2)

nbs-random-binary(4)

}

Dec 15, '89 Stable Aqreements

Vers. 4, Ed. 1, December '90 NIST SP 500-183

part 10, annex E clause E.2

NBS-AS5 NBS simple text abstract syntax

{nist-oiw-ftam

abstract-syntax(2)

nbs-simple-text(5)

}

Dec 15, '89 Stable Agreements

Vers. 4, Ed. 1, December '90 NIST SP 500-183

part 10, annex E clause E.3

67
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

Annex C (normative)

Document Types

C.1 NBS-10 Random Binary Access File

C.1.1 Entry Number: NBS-10

C.I.2 Information objects

68
PART 10 - FTAM Phase 3 September 1991 (Stable)

Table 4 - Information objects in NBS-10

document type name {iso identified-organization oiw(14) ftamsig(5) document-type(5)

random-binary( 1 0)

}

'NBS-10 FTAM random binary access file"

abstract syntax names:

a) name of asnamel

b) name of asname2

c) name of asnameS

{iso identified-organization oiw{14) flamsig(5) abstract-syntax(2)

nbs-random-binary(4)

}

"NBS random binary access file abstract syntax" {iso standard

8571 abstract-syntax(2) ftam-fadu(2)}

"FTAM FADU"

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-node-name(3)

}

"NBS random access node name abstract syntax"

transfer syntax names: {joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic encoding of a single ASN.1 type"

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model"

constraint set {iso identified-organization oiw(14) ftamsig(5)

constraint-set(4) nbs-random-access(2)

}

"NBS random access constraint set"

File contents: Datatypel ::= OCTET STRING

Datatype2 ::= Node^iName

-The type to be used for Node^iName is defined in ISO 8571 -FADU

-The only Choice for Nodei^Name is user-coded

Datatypes :: = NBS-Node-Name

-As defined by the NBS Random Access NodelName Abstract Syntax

C.I.3 Scope and field Of application

This document type defines the contents of a file for storage, for transfer and access by FTAM.

69
PART 10 - FTAM Phase 3 September 1991 (Stable)

C.1.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection - File Transfer,

Access and Management

C.1 .5 Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined in ISO

8571-1.

C.I.6 Abbreviations

FTAM File Transfer, Access and Management

C.1 .7 Document semantics

The document consists of zero, one, or more File Access Data Units. Each FADU contains precisely one

data unit which consists of precisely one data element. The data element is made up of one octet. The

order of each of these elements is significant. The semantics of the data elements is not specified by

this document type.

The document structure takes any of the forms allowed by the FTAM hierarchical file model as

constrained by the NBS random access constraint set. The definition for FTAM hierarchical file model

appears in 8571 -2.

There are no size or length limitations imposed by this definition.

C.1.

8

Abstract syntactic structure

The abstract syntactic structure of the document is a series of octets.

C.1.

9

Definition of transfer

70
PART 10 - FTAM Phase 3 September 1991 (Stable)

C.I .9.1 Datatype definition

The presentation data value used for transfer is an ASN.1 OCTET STRING.

Datatype2 is used to specify the FADU-ldentity of "name-list" in the FTAM PDUs specifying FADUIdentity, where "name-list" is defined as a SEQUENCE of EXTERNAL. The EXTERNAL is defined as Node-Name in the FTAM FADU abstract syntax. The use of Datatype2 is defined in "NBS random

access constraint set."

70-1
Jis1
PART 10 - FTAM Phase 3 September 1991 (Stable)

Datatypes specifies tiie "user-coded" form of tlie Node|Name in the FTAM FADU abstract syntax, whiere

"user-coded" is defined as an EXTERNAL. That EXTERNAL is defined by Datatypes. The use of Datatypes is defined in "NBS random access constraint set."

The document is transmitted as a series of presentation data values. Each presentation data value shall consist of the "data" from one or more FADUs concatenated together. The result is one value of the

ASN.1 data type OCTET STRING. The "fadu-count" field supplied in the NodeiName specifies the

number of FADUs to transfer during a Read operation. The requested FADUs may be transferred as one

or more presentation data values.

All values are transmitted in the same (but any) presentation context established to support the abstract

syntax name "asnamel " declared in table 4. NOTE - Specific carrier standards may impose additional constraints on the presentation context to be

used, when the above permits a choice.

Boundaries between P-DATA primitives and between presentation data values are chosen locally by the

sending entity at the time of transmission. The boundaries are not preserved when the file is stored and

they carry no semantics of the document type. Receivers which support this document type shall accept a document with any of the permitted transfer options.

The sequence of presentation data values is the same as the sequence of Data Units within the file.

C.1.10 Transfer syntax

An implementation supporting these document types shall support the transfer syntax generation rules named in table 4 for all presentation data values transferred.

Implementations may optionally support other transfer syntaxes.

C.I. 11 ASE Specific Specifications

C.1.11.1 Simplification and rol axation

1 The document type NBS-10 may be simplified to the document type FTAM-3. The resultant document

contains the same sequence of data values as would result from accessing the file as an NBS-10 file.

0.1.9.2 Presentation data values

0.1.9.3 Sequence of presentation data values
PART 10 - FTAM Phase 3

C.1.11.2 The READ operation

September 1991 (Stable)

A READ operation may be applied to a range of FADUs via the FADU-ldentity of "NodeSeq". Tfie

"starting-fadu" part of the node name specifies the node number of the first FADU; the "fadu-count"

specifies the number of consecutive FADUs to be transferred.

A READ operation applied to a range of FADUs that spans beyond the end of file is valid. All available

data in the range is transferred. An informative diagnostic (5005) is returned on the F-Data-End request

indicating that the end of file was reached and a portion of the request was satisfied.

C.I .1 1 .3 The REPLACE operation

When the REPLACE operation is applied to the root FADU of an NBS-10 document, the transferred data

shall be any NBS-10 document.

The REPLACE operation applied to a FADU-ldentity of "node number" is used to replace a series of FADUs, starting at the specified position in the file, by the new FADUs being transferred. The number of replaced FADUs is determined by the number of transferred FADUs.

If the replacement spans beyond the end of the existing file, then the additional FADUs are inserted at the end of the file.

C.I .1 1 .4 The INSERT operation

When the INSERT operation is applied at the end of file, the transferred data shall be a series of FADUs

which would be generated by reading any NBS-10 document type in access context UA.

72
PART 1 0 - FTAM Phase 3 September 1 991 (Stable)

C.2 NBS-11 Indexed File With Unique Keys

C.2.1 Entry Number: NBS-11

C.2.2 Information objects

73
PART 10 - FTAM Phase 3 September 1991 (Stable)

Table 5 - Information objects In NBS-11

document name {iso identified-organization oiw(14) ftamsig(5) document-type(5)

indexed-file-witli-unique-keys(1 1 )

}

"NBS-11 FTAM indexed file with unique keys"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14) ftamsig(5) abstract syntax(2)

nbs-asl(l)}

"NBS abstract syntax ASl"

{iso standard 8571 abstract-syntax(2) ftam-fadu(2)}

"FTAM FADU"

transfer syntax names: {joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic Encoding of a single ASN.1 type"

parameter syntax:

PARAMETERS ::= SEQUENCE {

DataTypes,

KeyType,

KeyPosition }

DataTypes ::= SEQUENCE OF CHOICE {

ParameterO, Parameter1

,

Parameter2 }

KeyType ::= CHOICE {

ParameterO, Parameter1

,

Parameter2 } - ParameterO, Parameterl , Parameter2, as - defined for the document types NBS-6, - NBS-7, NBS-8

KeyPosition:: = INTEGER

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model'

constraint set {iso standard 8571 constraint-set(4)

ordered-flat-unique-names(4)

}

"FTAM ordered flat constraint set with unique names"

file contents: Datatypel ::= PrimType - as defined in Annex OC, NBS-ASt

C.3 of NIST SP 600 183

Datatype2 ::= CHOICE {

Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element,

Exit-Subtree-Data-Element }

Datatypes^ « Prtm Typs as d^ned by the NBS ab^ract syntax ASl

74
PART 10 - FTAM Phase 3 September 1991 (Stable)

C.2.3 Scope and field of application

The document type defines the contents of a file for storage, for transfer and access using FTAM.

NOTE - Storage refers to apparent storage within the Virtual Filestore.

C.2.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection - File Transfer,

Access and {Management

C.2.5 Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined in ISO

8571-1.

C.2.6 Abbreviations

FTAM File Transfer, Access and Management

I C.2.7 Document semantics

The document consists of zero, one, or more File Access Data Units. Each FADU consists of precisely

I one data unit which consists of zero, one, or more data elements. The order of each of these elements

i is significant.

The document structure takes any of the forms allowed by the FTAM hierarchical file model as

i constrained by the FTAM ordered flat constraint set with unique names (see table 5). These definitions

: appear in ISO 8571-2.

[ The following additional requirements are specified for the use of the ordered flat constraint set with

unique names:

The FADU identity 'node number' is not required for conformant implementations

The Identities 'next' and 'previous' are allowed for all FADUs

Each data element is a data type from the set of primitive data types defined in part 9 Annex C, NBS

abstract syntax ASl . Each data unit contains the same data element types in the same order as all

! other data units. These types and their respective maximum lengths are defined by the <DataTypes>

parameter.

75

I
PART 10 - FTAM Phase 3 September 1991 (Stable)

For Datatypel and Datatypes, the string-length field of Parameterl specifies the length of the value in octets for the INTEGER, BIT STRING and OCTET STRING types. For character-type data elements, the

string-length indicates the actual number of characters from the specified character set, not including

any escape sequences or overhead from the character encoding.

For floating point numbers, finite form, length-1 and length-2 specify the length in bits of mantissa and

exponent, respectively. The length-1 and length-2 values are irrelevant for the other choices of floating

point numbers.

Each data unit in the file has a key associated with it, which is the user-coded form of Node-Name. The

key of each data unit is of the same data type as the key of all other data units in the file and is a single

data element from the set of primitive data types defined in part 9 Annex C, C.3 of NIST SP 500-183.

The type and length of the key are defined by the <KeyType> parameter.

The primitive data types and minimum size ranges of each unit which an implementation must accept

as a key value are given in the following table 8.

Table 6 - Datatypes for keys

Key Type Minimum Order

Range

(octets)

ASN.1 INTEGER (1-2) increasing numeric value ASN.1 lASString (1-16) lexical order

ASN.1 GraphicString ASN.1 GeneralString (1-16) lexical order

ASN.1 OCTET STRING (1-16) lexical order

ASN.1 GeneralizedTime (1-16) increasing value ASN.1 UniversalTime increasing time value NBS-AS1 FloatingPointN umber increasing time value

increasing numeric value

The position of the key in the data unit is specified by the <KeyPosition> parameter.

KeyPosition = 0 implies the key is not part of the data

KeyPosition > 0 specifies the actual data element in the data unit.

C.2.8 Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically structured file as defined in the

ASN.1 module IS08571-FADU in ISO 8571, in which each of the file access data units has the abstract

syntactic structure of NBS-ASI as defined by the parameters.

76
PART 10 - FTAM Phase 3 September 1991 (Stable)

C.2.9 Definition of transfer

C.2.9.1 Datatype definitions

The file consists of data values which are of oithor

a) Datatypel defined in table 5, where the PrimType in the datatype is given by the NBS-AS1

definition; or

b) Datatype2 defined in table 5, which is the ASN.1 datatype declared as "Data-Element" in the

ASN.1 module IS08571-FADU; or

c) Datatypes, defined in Table 5. which specifies the user-coded form of the Node-Name In the

FTAM FADU abstract syntax, where user-coded is defined as EXTERNAL.

C.2.9.2 Presentation data values

The document is transferred as a series of presentation data values, each of which is

a) one value of the ASN.1 datatype "Datatypel." carrying one of the data elements from the

document. All values are transmitted in the same (but any) presentation context established to support the abstract syntax name "asnamel " or

I b) a value of "Datatype2." All values are transmitted in the same (but any) presentation context

j established to support the abstract syntax name "asname2."; or

c) a value of "Datatypes" carrying a Key. All values are transmitted in the same (but any)

presentation context established to support the abstract syntax name "asnamel".

NOTES

1 Specific carrier standards may impose additional constraints on the presentation context to be used,

where the above permits a choice.

I 2 Any document type defined in this entry either makes no use of Datatype2, or starts with a Datatype2

transmission.

[i Boundaries between presentation data values in the same presentation context, and boundaries between

f P-DATA primitives, are chosen locally by the sending entity at the time of transmission, and carry no

I semantics of the document type. Receivers which support this document type shall accept a document

with any of the permitted transfer options (e.g., document type parameters and transfer syntaxes).

C.2.9.3 Sequence of presentation data values

! The sequence of presentation data values of type a) and the sequence of presentation data values of

j types a) and b) is the same as the sequence of data elements within a Data Unit, and Data Units in the

77
PART 10 - FTAM Phase 3 September 1991 (Stable)

hierarchical structure, when flattened according to the definition of the hierarchical file model in ISO

8571-2.

C.2.10 Transfer syntax

An implementation supporting this document type shall support the transfer syntax generation rules named in table 5 for all presentation data values transferred. Implementation may optionally support

other named transfer syntaxes.

C.2.1 1 ASE Specific Specifications

C.2.11.1 Simplification and rel axati on

This simplification loses information.

The document type NBS-1 1 may be accessed as a document type FTAM-3 (allowed only when reading

the file) by specifying document type FTAM-3 in the < contents type> parameter In <F-OPEN request >, and limiting access context to UA on F-READ.

The octet representation of the transferred data is unpredictable. It will usually correspond to the data

values as stored in the local Real Filestore of the Responder.

A document of type NBS-1 1 can be accessed as a document of type NBS-6 (allowed only when reading

the file) by specifying document type NBS-6 with appropriate data type parameters in the < contents

type> parameter on the <F-OPEN request>. The traversal order of the FADUs must be maintained.

NOTE - The traversal order is as reading the file as NBS-1 1 in key order.

A document of type NBS-1 1 may be accessed as a document of type NBS-8 (allowed only when reading

the file) by specifying document type NBS-8 in the < contents type> parameter in the <F-OPEN

REQUEST>.

C.2.1 1 .2 Access context selection

A document of type NBS-1 1 may be accessed in any one of the access contexts defined in the FTAM

ordered flat constraint set with unique names. The presentation data units transferred in each case are those derived from the structuring elements defined for that access context in ISO 8571-2.

78
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

C.2.11.3 The INSERT operation

When the < INSERT > operation is applied^; the transferred material shall be the series of FADUs which

would be generated by reading any NBS-11 document with the same parameter values in access

context FA.

A transferred FADU whose name duplicates that of an already existing FADU will cause the <INSERT>

operation to fail. The failure shall be signalled by issuing an F-CANCEL Request with a corresponding

diagnostic.

C.2.11.4 The EXTEND operation

This operation is excluded for the use with this document type.

C.2.11.5 The REPLACE operation

When the < REPLACE > operation is applied with FADU Identity 'begin', a transferred FADU whose name

duplicates that of a previously transferred FADU will cause the < REPLACE > operation to fail. The

failure shall be signalled by issuing an F-CANCEL Request with a corresponding diagnostic.

79
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

C.3 NBS-12 Simple Text File Document Type

C.3.1 Entry Number: NBS-12

C.3.2 Information objects

80
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

Table 7 - Information objects in NBS-12

document type names {iso identified-organization oiw/(14) ftamsig(5) document-type(5)

Oil llpl©-IeXI-Hl©^ 1 ] "NBS-12 FTAM simple text file"

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2)

nbs-simple-text(5)}

"NBS simple text abstract syntax"

{iso standard 8571 abstract-syntax(2) ftam-fadu(2)}

"FTAM FADU"

transfer syntax names: {joint-iso-ccitt asnl (1) basic-encoding (1)} "Basic Encoding of a single ASN.1 type"

Parameter Syntax

PARAMETERS ::= SEQUENCE{

universal-class-number [0] IMPLICIT INTEGER,

maximum-string-length [1] IMPLICIT INTEGER,

string-significance [2] IMPLICIT INTEGER

{variable (0), fixed (1)}. character-set [3] IMPLICIT OctetString OPTIONAL}

file model {iso standard 8571 file-model(3) hierarchical(l)}

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set(4) sequential flat(2)}

"FTAM sequential flat constraint set"

File contents Datatypel ::= NBSfText -as defined in the NBS Simple Text

-Abstract Syntax registration entry

Datatype2 ::= Node-Descriptor-Data-Element

C.3.3 Scope and field of application

The document type defines the contents of a file for storage, and for transfer and access by FTAM.

N01^ - Storage refiars to apparent storage withm the virtual filestore.

81
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

C.3.4 References

ISO 8571, Information Processing Systems - Open Systems Interconnection - File Transfer,

Access and Management

ISO 8824, Information Processing Systems - Open Systems Interconnection-Specification of Abstract Syntax Notation 1 (ASN.1).

ISO 8825, Information Processing Systems - Open Systems Interconnection-Basic Encoding

Rules for Abstract Syntax Notation One (ASN.1).

ISO 6429, Information Processing - ISO 7-bit and 8-bit coded character sets-Additional control functions for cfiaracter imaging devices.

C.3.5 Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined in ISO

8571-1. In addition, it mal<es use of the terms character string, graphics character, and format effector as defined in document type registration entry "FTAM-2" in ISO 8571-2.

C.3.6 Abbreviations

FTAM File Transfer, Access and Management

C.3.7 Document semantics

This document consists of zero, one or more file access data units. , each of Each FADU consl^s of precisely one data unit which consists of one character string. The order of each of these elements is significant. The semantics of the character strings is not specified by this document type.

The document structure takes any of the forms allowed by the FTAM hierarchical file model as

constrained by the sequential flat constraint set. These definitions appear in ISO 8571-2. As additional

constraintsi FADU identity will be limited to the following values:

a) 'begin' and 'end' when using the Transfer or Transfer and Management service classes.

b) 'begin', 'end', 'first', and 'next' when using the Access service class.

Each character string consists of characters from the character set defined by the ASN.1 (ISO 8824)

character set type whose universal class number is given by the "universal-class-number" parameter and

by the escape sequences contained in the optional "character-set" parameter. If the character set type

allows explicit escape sequences, the "character-set" parameter, if present, contains escape sequences

which designate and invoke specific character sets. If the "character-set" parameter is not present,

character sets are assumed to be designated and invoked as specified in table 2 in ISO 8825. Character

strings shall not contain escape sequences.

82
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

There are no size or length limitations imposed by this definition, except those specified here. Each

character string is of a length determined by the number of characters given by the "maximum-stringlength" parameter.

NOTE - The length restriction refers to the number of characters from the applicable character set, not to the number of octets in the encoding, nor to the line length in any rendition of the document, where these

are different.

The exact significance of the character strings is determined by the "string-significance" parameter. If its value is "variable," the length of the character strings is less than or equal to the length given. If the

value Is "fixed," the length of each character string is exactly equal to the length given.

If the document is interpreted on a character imaging device (outside the scope of ISO 8571), the

interpretation depends on the character set in use.

a) If the character set contains format effectors, they shall be interpreted as defined in ISO

6429; end of string and end of file access data unit are given no formatting significance, and do

not contribute to the document semantics;

b) If the character set does not contain format effectors, the end of each character string is Interpreted as implying carriage return and line feed formatting actions in any rendition. The end

of file access data unit is given no formatting significance beyond that attached to the end of the

string in it.

C.3.8 Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically structured file as defined in the

ASN.1 modules IS08571-FADU and ISO 8571 -CONTENTS in ISO 8571, in which each of the file contents

data elements has the abstract syntactic structure of "NBS S i mpi o Text." "NBS-Text."*

83
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

C.3.9 Definition of transfer

C.3.9.1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 7, the ASN.1 datatype declared as "NBS-Text" in the NBS Si mple

Text Abotract Syntax simple teirt lbstract s^^ definition. The choice in "NBS-Text" is deternnined by the universal-class-number parameter; or

b) Datatype2 defined in table 7, the ASN.1 datatype declared as "Data-Element" in the ASN.1

module ISO 8571 -FADU.

C.3.9.2 Presentation data values

The document is transferred as a series of presentation data values, each of which is either

a) one value of the ASN.1 datatype "Datatypel," carrying one of the character strings of the

document. Each character shall be transmitted using one of the character sets identified by the

universal-class-number parameter. All values are transmitted in the same (but any) presentation context established to support the abstract syntax name "asnamel" declared in table 7, or

b) one value of the ASN.1 datatype "Datatype2." All values are transmitted in the same (but

any) presentation context established to support the abstract syntax name "asname2" declared

in table 7. NOTES

1 Specific carrier standards may impose additional constraints on the presentation context to be used,

where the above permits a choice.

2 Any document type defined in this entry either makes no use of Datatype2, or starts with a Datatype2

transmission.

Boundaries between P-DATA primitives are chosen locally by the sending entity at the time of transmission, and carry no semantics of the document type. Receivers which support this document

type shall accept a document with any of the permitted transfer options.

84
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

C.3.9.3 Sequence of presentation data values

The sequence of presentation data values of type {a) and the sequence of presentation data values of types {a) and {b) is the same as the sequence of character strings within a Data Unit, and Data Units in the hierarchical structure, when flattened according to the definition of the hierarchical file model in ISO

8571-2.

C.3.10 Transfer syntax

An Implementation supporting this document type shall support the transfer syntax generation rules named in table 7 for all presentation data values transferred.

C.3.11 ASE specific specifications

C.3.11.1 Simplification and relaxation

C.3.11. 1.1 Simplification to FTAM-1

This simplification loses information.

The document type NBS-12 may be accessed as a document type FTAM-1. The resultant document

contains the same sequence of data values as would result from accessing the structured text file in access context UA. That is, only the presentation data values in the abstract syntax "asnamel" are

present. If the "character-set" parameter was present before the simplification, its contents will be added

to the beginning of each string.

NOTE - The boundary between file access data units remains a boundary between strings, but any special

significance given to it is lost.

The document type NBS-12 may be relaxed to the document type FTAM-2. If the "character-set" parameter was present before the relaxation, its contents will be added to the beginning of each string.

C.3.11. 1.2 Relaxation to FTAM-2

C.3.11. 1.3 Character set relaxation

This operation loses explicit information in the document type identification. A document of type NBS-12 may be relaxed to a different document of type NBS-12 with

85
PART 10 - ISO FTAM PHASE 3 March 1991 (Stable)

a different "universal-class-number" parameter value;

a different "character-set" parameter value;

different values for both of these parameters;

a different "universal-class-number" parameter value and no "character-set" parameter value; or

no "character-set" parameter value.

if the resultant document type permits all characters from the original document type. If this relaxation

involves including format effectors and none were present before the simplification, the characters

"carriage return" and "line-feed" shall be added to the end of each string.

NOTE - If the characters "carriage return" and "line feed" are not part of the format effectors, the formatting action may be represented by "newline," or some other implementation specific choice if there is no

representation of "newline" defined.

C.3.11.1.4 String length relaxation

This operation loses explicit information in the document type identification.

A document of type NBS-12 may be relaxed to another document type NBS-12 with a larger "maximumstring-length" parameter.

C.3.11.2 Access context selection

A document of type NBS-12 may be accessed in any one of the access contexts defined in the

sequential flat constraint set. The presentation data units transferred in each case are those derived

from the structuring elements defined for that access context in ISO 8571-2.

C.3.11.3 The INSERT operation

When the INSERT operation is applied at the end of file, the transferred material shall be the series of FADUs which would be generated by reading any NBS-12 document type with the same parameter

values in access context FA.

86
PART 10 - FTAM Phase 3 September 1991 (Stable)

Annex D (normative)

Constraint Sets

D.1 NBS random access constraint set

Table 8 - Basic constraints in the NBS Random Access Constraint Set

Constraint set descriptor "NBS random access constraint set"

Constraint set identifier {iso identified-organization oiw(14) ftamsig(5) constraint-set(4)

nbs-random-access(2)

}

Node names All names shall be of the same type; the type of the names

and an ordering of the names shall be defined when reference

is made to the constraint set.

File access actions Locate, Read, Insert, Erase, Replace

Qualified actions None

Available access context UA

Creation state Root node without an associate data unit

Location after open Root node

Beginning of file Root node

End of file No node selected

Read whole file Read in access context UA with FADU-ldentity of "begin"

Write whole file Transfer a series of leaf FADUs which would be generated by

reading the whole file in access context UA; perform the

transfer with a FADU Identity of "end" and a file access action

of "insert", or with a FADU Identity of "begin" and an action of

"replace," orwftfj an FADU identtty of "node number* and an

action of 'reii^ace^' Here "node number" identifies the first FADU in tho preorder traversal sequence.

87
PART 10 - FTAM Phase 3 September 1991 (Stable)

Table 9 - Identity constraints in the NBS Random Access Constraint Set

Action Begin End NodeSeq Node number

Locate leaf

Read whole leaf

Insert leaf

Erase whole leaf

Replace whole leaf

NOTE - NodeSeq = A sequence of NodefNames with a single member

D.1.1 Field of application

The NBS Random Access constraint set applies to files which are structured into a sequence of

individual FADUs and to which access may be made randomly by NodeSeq. The structuring of the file into individual FADUs is determined by the NodeiName.

D.I .2 Basic constraints

The basic constraints in the NBS Random Access constraint set are given in table 8.

D.I.3 Structural constraints

The root node shall not have an associated data unit; all children of the root node shall be leaf nodes

and shall have an associated data unit; all arcs from the root node shall be of length one.

D.I.4 Action constraints

Insert: the insert action is allowed only at the end of the file, with FADU-ldentity of "end"; the new node

is inserted following all existing nodes in the file. The location following the insert is "end".

Erase: the erase action is allowed at the root node to empty the file, with FADU-ldentity of "begin". The

result is a solitary root node without an associated data unit. Erase with the FADU-ldentity of "node

number" means truncation of the file.

Replace whole file: the FADU-ldentity is "begin" and the complete series of new FADU contents is sent.

Replace new leaves: the FADU-ldentity is "node number" and the number of FADUs being replaced is given by the number of FADUs sent.

88
PART 10 - FTAM Phase 3 September 1991 (Stable)

D.I.5 Identity constraints

The FADU-ldentity associated with the file action shall be one of the identities: begin, end, Node

Number and NodeSeq. The actions with which these identities can be used are given in table 9.

89
PART 10 - FTAM Phase 3 September 1991 (Stable)

Annex E (normative)

Abstract Syntaxes

E.1 NBS Node Name Abstract Syntax

Abstract Syntax Name

{ iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2) nbs-node-name(3) }

"NBS random access node name abstract syntax"

This is an abstract syntax for tlie user-coded Nod^Name In the FTAM FADU abstract syntax.

NBS-AS3 DEFINITIONS:: =

BEGIN

NBS-Node-Name::= SEQUENCE

{ starting-fadu [0] IMPLICIT INTEGER,

fadu-count [1] IMPLICIT INTEGER }

--a "fadu-count" of 0 specifies the

-range of FADUs

-beginning at "starting-fadu" and

-ending at "end of file"

END

For this abstract syntax the following transfer syntax wiH can be used.

{ joint-iso-ccitt asn1(1) basic-encoding(l) }

"Basic Encoding of a single ASN.1 type"

90
PART 10 - FTAM Phase 3 September 1991 (Stable)

E.2 NBS Random Binary Access File Abstract Syntax

Abstract Syntax Name

{ iso identified-organization oiw(1 4) ftamsig(5) abstract-syntax(2) nbs-random-binary(4) }

"NBS random binary access file abstract syntax"

This is an abstract syntax for the transfer of the file contents for NBS random binary files.

NBS-AS4 DEFINITIONS:: =

BEGIN

NBS-Random Binary ::= OCTET STRING

-contains one or more presentation data values

--concatenated together.

-Each presentation data value is defined as

-Datatypel in table 4. END

For this abstract syntax, the following transfer syntax will ||| be used:

{ joint-iso-ccitt asn1(1) basic-encoding(l) }

"Basic Encoding of a single ASN.1 type"

91
PART 10 - FTAM Phase 3

E.3 NBS Simple Text Abstract Syntax

Abstract Syntax Name

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-simple-text(5) }

"NBS simple text abstract syntax"

NBS-AS5 DEFINITIONS:: =

BEGIN

NBS-Text::= CHOICE {

IA5String,--Universal Class 22

GraphlcString, --Universal Class 25

VisibleString, -Universal Class 26

GeneralString -Universal Class 27 }

END

For this abstract syntax, the following transfer syntax wiU Odn be used:

{joint-iso-ccitt asn1(1) basic-encoding(l)}

"Basic encoding of a single ASN.1 type"

September 1991 (Stable) i

92
PART 10 - FTAM Phase 3 September 1991 (Stable)

Annex F (normative)

Delta Protocol Implementation Conformance Statement (PICS) Pro

forma

(Refer to the Working Implementation Agreements.)

93
PART 10 - FTAM Phase 3 September 1991 (Stable)

Annex G (normative)

Amendments and Corrigenda

(Refer to the Working Implementation Agreements.)

94
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 1 1 - Directory Services

Protocols

Output from the December 1990 NIST Workshop for

j Implementors of OSI

1 SIG Chair: You Bong Weon-Yoon, AT&T Bell Labs

i| SIG Editor: Michael Ransom, NIST
'i

I

I
Part 1 1 - Directory Services Protocols

Table of Contents

September 1991 (Stable)

Part 1 1 - Directory Services Protocols 1

0 Introduction 1

1 Scope 1

2 Normative references 2

3 Status 4

4 Use of the Directory 4

5 Directory ASEs and Application Contexts 4

6 Schema 5

6.1 Support of Structures and Naming Rules 5

6.2 Support of Object Classes and Subclasses 5

6.3 Support of Attribute Types 6

6.4 Support of Attribute Syntaxes 6

6.5 Naming Contexts 6

6.6 Common Profiles 6

6.6.1 01W Directory Common Application Directory Profile 6

6.6.1.1 Standard Application Specific Attributes and Attribute Sets 6

6.6.1.2 Standard Application Specific Object Classes 6

6.6.2 OIW Directory Strong Authentication Directory Profile 7

6.6.2.1 Other Profiles Supported 7

6.6.2.2 Standard Application Specific Object Classes 7

6.7 Restrictions on Object Class Definitions 8

7 7 Pragmatic Constraints 8

7.1 General Constraints 8

7.1.1 Character Sets 8

7.1.2 APDU Size Conoidorati onG DSP Result APDU Size 8

7.1.3 Service Control (SC) Considerations 9

7.1.4 Priority Service Control 9

7.2 Constraints on Operations 9
Part 11 - Directory Services Protocols September 1991 (Stable)

7.2.1 Filters 9

7.2.2 Errors 9

7.2.3 Error Reporting - Detection of Search Loop 9

7.3 Constraints Relevant to Specific Attribute Types 10

8 8 Conformance 10

8.1 DUA Conformance 11 8.2 DSA Conformance 11 8.3 DSA Conformance Classes 12

8.3.1 Conformance Class 0 - Centralized DSA 12

8.3.2 Conformance Class 1 - Distributed DSA 12

8.4 Authentication Conformance 12

8.5 Directory Service Conformance 13

8.5.1 Sen/ice Conformance 13

8.5.1.1 r: required 14

8.5.1.2 n: not required 14

8.5.2 Protocol Conformance 14

8.5.2.1 M: mandatory 14

8.5.2.2 G: generate 14

8.5.2.3 S: support 15

8.5.2.4 O: optional 15

8.6 The Directory Access Profile 15 8.7 The Directory System Profile 16

8.8 Digital Signature Protocol Conformance Profile 16

8.9 Strong Authentication Protocol Conformance Profile 16

9 9 Distributed Operations 16

9.1 Referrals and Chaining 16

9.2 Traceinformation 17

10 Underlying Services 17

10.1 ROSE 17

10.2 Session 17

10.3 ACSE 17

11 11 Access Control 18

12 12 Test Considerations 18

12.1 Major Elements of Architecture 18

12.2 Search Operation 19

13 13 Errors 19

13.1 Permanent vs. Temporary Service Errors 19

13.2 Guidelines for Error Handling 20

13.2.1 Introduction 20

13.2.2 Symptoms 20

13.2.3 Situations 20

iv
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

13.2.4 Error Actions 19

13.2.5 Reporting 20

14 Specific Authentication Schemes 20

14.1 Specific Strong Authentication Schemes 20

14.1.1 ElGamal 20

14.1.1.1 Background 20

14.1.1.2 Digital Signature 21

14.1.1.3 Verification 22

14.1.1.4 Known Constraints on Parameters 22

14.1.1.5 Note on subjectPublicKey 23

14.1.2 One-Way Hash Functions 23

14.1.2.1 SQUARE-MOD-N Algorithm 23

14.1.2.2 MD2 Algorithm 24

14.1.2.3 Study of Other One-Way Hash Functions 24

14.1.2.4 Use of One-Way Hash Functions in Forming Signatures 24

14.1.3 ASN.l for Strong Authentication Algorithms 24

14.1.4 Note on the ENCRYPTED MACRO 25

14.2 Protected Simple Authentication 25

14.3 Simple Authentication 26

Annex A - Maintenance of Attribute Syntaxes 27

A.l Introduction . 27

A. 2 General Rules 27

A. 3 Checking Algorithms 27

A. 3.1 distinguishedNameSyntax 27

A. 3. 2 integerSyntax 27

A. 3. 3 telephoneNumberSyntax 28

A. 3. 4 countryName 28

A. 3. 5 preferredDeliveryMethod 28

A. 3. 6 presentationAddress 28

A. 4 Matching Algorithms 28

A.4.1 UTCTimeSyntax 28

V
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

A. 4. 2 distinguishedNameSyntax 29

A. 4. 3 caselgnoreListSyntax 29

Annex B - Glossary 30

Annex C - Requirements for Distributed Operations 32

C.l General Requirements 32

C. 2 Protocol Support 32

C.2.1 Usage of ChainingArguments 32

C. 2. 2 Usage of ChainingResults 33

Annex D - Guidelines for Applications Using the Directory 34

D. l Tutorial 34

D. 1.1 Overview 34

D.l. 2 Use of the Directory Schema 34

D.l. 2.1 Use of Existing Object Classes 34

D. 1.2.2 Kinds of Object Classes 34

D. 1.2.3 Use of Unregistered Object Classes 35

D. 1.2.4 Side Effects of Creating Unregistered Object Classes 36

D.2 Creation of New Object Classes 37

D.2.1 Creation of New Subclasses 37

D.2. 2 Creation of New Attributes 37

D.3 DIT Structure Rules 37

Annex E - Template for an Application Specific Profile for Use of the Directory 38

Annex F - Bibliography 39

vi
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

List of Figures

1 Structure of this Implementation Agreement 1

2 Centralized Directory Model 3

3 Distributed Directory Model 3

4 APDU Exchange 8

5 Logical DSA Application Environment 9

6 Three Ways of Creating Two Object Classes 36

vii
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

List of Tables

1 Pragmatic Constraints for Selected Attributes (Part 1 of 2) 40

1 Pragmatic Constraints for Selected Attributes (Part 2 of 2) 41

2 Directory Access Service Support 42

3 DAP Protocol Support (Part 1 of 7) 43

3 DAP Protocol Support (Part 2 of 7) 44

3 DAP Protocol Support (Part 3 of 7) 45

3 DAP Protocol Support (Part 4 of 7) 46

3 DAP Protocol Support (Part 5 of 7) 47

3 DAP Protocol Support (Part 6 of 7) 48

3 DAP Protocol Support (Part 7 of 7) 49

4 Directory System Service Support 50

5 DSP Protocol Support (Part 1 of 9) 51

5 DSP Protocol Support (Part 2 of 9) 52

5 DSP Protocol Support (Part 3 of 9) 53

5 DSP Protocol Support (Part 4 of 9) 54

5 DSP Protocol Support (Part 5 of 9) 55

5 DSP Protocol Support (Part 6 of 9) 56

5 DSP Protocol Support (Part 7 of 9) 57

5 DSP Protocol Support (Part 8 of 9) 58

5 DSP Protocol Support (Part 9 of 9) 59

6 DAP Support for Digital Signature Protocol Conformance Profile 60

7 DSP Support for Digital Signature Protocol Conformance Profile 60

8 DAP Support for Strong Authentication Protocol Conformance Profile. ... 61

9 DSP Support for Strong Authentication Protocol Conformance Profile 62

10 Error Symptoms (Part 1 of 3) 63

10 Error Symptoms (Part 2 of 3) 64

10 Error Symptoms (Part 3 of 3) 65

11 Error Situations 66

12 Notation Used to Describe Error Actions 67

13 Error Actions (Part 1 of 6) 68

viii
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

13 Error Actions (Part 2 of 6) 69

13 Error Actions (Part 3 of 6) 70

13 Error Actions (Part 4 of 6) 71

13 Error Actions (Part 5 of 6) 72

13 Error Actions (Part 6 of 6) 73

14 Simple Credential Fields and Protected Simple Authentication 75

ix
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Foreward

This part of the Stable Implementation Agreements was prepared by the Directory Services

Special Interest Group (DSSIG) of the National Institute of Standards and Technology

(NIST) Workshop for Implementors of Open systems Interconnection (OSI). 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 Directory Services Protocol. There is no

significant technical change from this text as previously given.

X
PART 11 - DIRECTORY SERVICES PROTOCOLS

0 Introduction

This is an Implementation Agreement developed by the Implementor's Workshop sponsored

by the National Institute of Standards and Technology to promote the useful exchange of data between devices manufactured by different vendors. This agreement is based on and

employs protocols developed in accord with the OSI Reference Model. While this agreement

introduces no new protocols, it eliminates ambiguities in interpretations.

This is an Implementation Agreement for the OSI Directory based on the ISO and CCITT

documents cited in clause 2 of this part (hereafter referenced as Directory Documents).

This agreement is aligned with the UNOFFICIAL 'FINAL' version of the X.500 Series

of Recommendations, December 1988. Where technical differences between the ISO and

CCITT versions of these documents exist (e.g.. Transport Requirements) the ISO versions

are given precedence. Figure 1 displays the structure of this Implementation Agreement.

References to corresponding CCITT documents are included for information.

Directory Access Protocol

(DAP)

Directory System Protocol

(DSP)

Remote Operations Services and Protocols

(CCITT X.219 and X.229/ISO 9072/1 and 9072/2)

Association Control Services and Protocols

(CCITT X.217 and X.227/ISO 8649 and 8650)

Figure 1 - Structure of this Implementation Agreement.

The Directory User Agents (DUAs) and Directory System Agents (DSAs) provide access

to The Directory on behalf of humans and applications such as Message Handling and File Transfer, Access, and Management. See clause 1 for more information on the model used

in the Directory.

This document covers both the Directory Access Protocol (DAP) and the Directory System

Protocol(DSP) defined in the Directory Documents. A good working knowledge of the

Directory Documents is assumed by this chapter. All terminology and abbreviations used

but not defined in this text may be found in those documents.

1 Scope

Centralized and distributed directories can both be accommodated in this Agreement by

the appropriate choice of protocols and pragmatic constraints from those specified. Figure 2 illustrates a centralized directory and figure 3 illustrates a distributed directory.

1
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

This agreement does not cover interaction between co-located entities, such as a co-resident

DUA and DSA. It also does not specify the interface between a user (person or application)

and a DUA. Bilateral agreements between a DUA and DSA or DSA and DSA may be

implemented in addition to the requirements stated in this document. Conformance to this agreement requires the ability to interact without the use of bilateral agreements other than

those required in the Directory Documents.

The logical structure of the Directory Information Base (DIB) is described in the Directory

Documents. The manner in which a local portion of the DIB is organized and accessed by

its DSA is not in the scope of this agreement.

2 Normative references

ISO/IEC 9594-l:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 1: Overview of Concepts, Models, and Services.

ISO/IEC 9594-2: 1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 2: Models.

ISO/IEC 9594-3:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 3: Abstract Service Definition.

ISO/IEC 9594-4:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 4: Procedures for Distributed Operation.

ISO/IEC 9594-5:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 5: Protocol Specifications.

ISO/IEC 9594-6:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 6: Selected Attribute Types.

ISO/IEC 9594-7:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 7: Selected Object Classes. ISO/IEC 9594-8:1990(E), Information Technology - Open Systems Interconnection - The

Directory - Part 8: Authentication Framework.

CCITT Recommendation X 500 1988, The Directory -- Overview of concepts. Models an

Services.

CCITT Recommendation X 501 1988, The Directory -- Models.

CCITT Recommendation X 509 1988, The Directory -- Authentication Framework.

CCITT Recommendation X 511 1988, The Directory -- Abstract Service Definition.

CCITT Recommendation X 518 1988, The Directory -- Procedures for Distributed Opera

tions. CCITT Recommendation X 519 1988, The Directory -- Protocol Specifications.

CCITT Recommendation X 520 1988, The Directory -- Selected Attribute Types.

CCITT Recommendation X 521 1988, The Directory -- Selected Object Classes.

2
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

USER

USER ->

DUA

DUA

i The Directory

i

DSA

Figure 2 - Centralized Directory Model.

User

User

DUA

DUA PThe Directory

DSA

DSA DSA

DSA

E

DUA User

Figure 3 - Distributed Directory Model.

3
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

3 Status

This version was completed in December 1990.

4 Use of the Directory

Given the rapid multiplication and expansion of OSI applications, telecommunication sys- tems and services, there is growing need for users of OSI applications, as well as the applications themselves, to communicate with each other. In order to facilitate their communications, a Directory protocol, as referenced in these agreements, has been tailored to meet

their respective needs.

In one instance. The Directory will be used as a service to provide humans, in an on-line

fashion, rapid and easy retrieval of information useful for determining what telecommunications services are available, and/or how to access, and address their correspondents. Further,

service providers offering such a Public Directory may also use this service internally with

other various telecommunications services (e.g., MHS) for the proper addressing of calls or messages. Likewise, this does not preclude the usage of these agreements to similarly generate a privately operated Directory that supports both human and application information

exchanges.

In another instance, The Directory, will be used as a service by computer applications

without direct human involvement. One important service is to provide Presentation Address resolution for named objects, on behalf of OSI applications. The Directory may be

used by applications to search for objects (i.e.. Application Entities), without direct human

involvement, by the use of the "search" or "list" operations.

To support the many possible usages, The Directory is a general purpose system. It is capable of storing data of many different forms as attributes within entries, and is also capable of supporting simple or complex hierarchical structures, with variations in structure possibly occurring between one part of The Directory and another.

Compliant DSA implementations should safeguard this generality, where possible, by placing

the minimum of restrictions in "hard-wired" form.

5 Directory ASEs and Application Contexts

This clause highlights the ASEs (Application Service Elements) and Application Contexts

defined in the Directory Documents and of concern in these Agreements. The functionality

of the Directory AEs (DUAs and DSAs) is defined by a set of ASEs, each Directory ASE

specifying a set of Directory operations.

The interaction between these AEs is described in terms of their use of ASEs. This specific

combination of a set of ASEs and the rules for their usage defines an application context. The following ASEs are described in the Directory Documents:

- Read ASE

- Chained Read ASE

4
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

- Search ASE

- Chained Search ASE

- Modify ASE

- Chained Modify ASE

ROSE and ACSE also form part of the Directory Application Contexts. The following Application Contexts are described in the Directory Document:

- Directory Access Application Context - Directory System Application Context

6 Schema

There are seven (7) major topics that relate to schema:

6.1 Support of Structures and Naming Rules

DSAs shall be capable of supporting (subject to refinements laid down in these Agreements)

the structure and naming rules defined in the Directory Documents, Part 7, Annex B.

Part 7, Annex B of the Directory Documents provides a framework for the basic use of the

Directory in terms of the objects defined in Part 7. It does not, however, form part of the

standard and, in any case, permits structures and practices which may be undesirable. The

guidelines below provide tighter control within the Annex B framework.

It is recommended that only an entry subordinate to Root or Country may use a StateOrProvinceName AVA as an RDN.

6.2 Support of Object Classes and Subclasses

The DSAs shall be able to support all superclasses of the supported object classes (e.g.. Top, Person).

Use of an object class in this profile or the standard (or a subclass derived from one or more of these object classes) is recommended wherever the semantics are appropriate for the application. The derivation of a new object class as an immediate subclass of Top should

be avoided. For example, to represent printers in the Directory, one can derive a subclass

of Device.

An entry of a particular object class may contain any optional attribute listed for it in the Directory Documents; a conformant DSA shall be able to support all these optional

attributes.

In addition, a DSA may permit any locally registered attribute, or a subset of these, by pro- viding the local extension facilities permitted by unregistered object classes (viz. Directory

Documents, Part 2, clause 9.4.1 (a) and Note).

1-

5
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

6.3 Support of Attribute Types

DSAs shall be able to support the storage and use of attribute type information, as defined

in the Directory Documents, Part 6, including their use in naming and access to entries; they shall also support the definition of new attribute types, making use of pre-existing

attribute syntaxes.

DSAs shall support the encoding, decoding, and matching of all the attributes in the Naming

Prefixes of every naming context they hold (ref Directory Documents, Part 4, clause 9). These attributes may include attributes that are not permitted to appear in entries in those

naming contexts.

6.4 Support of Attribute Syntaxes

Suggested methods for the interpretation of selected Attribute Syntaxes are defined in annex

A.

6.5 Naming Contexts

The root of a naming context shall not be an alias entry.

6.6 Common Profiles

This subclause identifies profiles that are commonly useful for various applications while an

application-specific profile(s) is identified by the application.

6.6.1 OIW Directory Common Application Directory Profile

6.6.1.1 Standard Application Specific Attributes and Attribute Sets

The attributes and attribute sets in the Directory Document, Part 6, associated with the

object classes listed below are required.

6.6.1.2 Standard Application Specific Object Classes

DSAs shall be able to support storage and use of the object classes below, as defined in the

Directory Documents, Part 7, and these object classes are expected to be useful for a range

of applications.

The following object classes are mandated by the standard:

- Top

- DSA

- Alias

6
Part 11 - Directory Services Protocols September 1991 (Stable)

The following object classes are expected to be generally useful in the creation of the DIT upper portion:

a) Country

b) Locality

c) Application Process

d) Organization

e) Organizational Unit

The following object classes are expected to be generally useful in the creation of DIT leaf entries:

a) Alias

b) ApplicationProcess

c) ApplicationEntity

d) DBA

e) Device

f) Group of Names

g) OrganizationalPerson

h) OrganizationalRole

i) ResidentialPerson

6.6.2 OIW Directory Strong Authentication Directory Profile

6.6.2.1 Other Profiles Supported

This profile is used in conjunction with the OIW Directory Common Application Directory Profile.

6.6.2.2 Standard Application Specific Object Classes

The following object classes are expected to be generally useful for applications to support strong

authentication:

a) Strong Authentication User

b) Certification Authority

7
Part 11 - Directory Services Protocols September 1991 (Stable)

»fc — ] > . , - ,

\ r->, DUA

<—

DSA DSA

^

37K

»A nay paaa w

33k

Rguro 4 APDU Exohango

6.7 Restrictions on Object Class Definitions

An object class may not be defined as a subclass of itself, as thte chain of superclasses of such an object

class would be a closed loop, isolated from all other object classes, specifically Top. Such isolation is clearly

illegal.

7 Pragmatic Constraints

This clause describes pragmatic constraints to which a conformant implementation shall adhere In addition to those specified in the Directory Documents. The pragmatic constraints can be divided into two major

areas. The first includes those aspects of pragmatic constraints which apply to scope of service (see 7.1 and

7.2). The second includes those aspects of pragmatic constraints which are specific to particular attribute types (see 7.3).

7.1 General Constraints

7.1.1 Character Sets

It is a requirement to support all character sets and other name forms defined in the Directory Documents,

Part 6. Those character sets include:

a) T.61

b) PrintableString

c) NumericString

7.1 .2 APDU Size Considerations DSP BesuR APDU Size

In the process of chaining requests it is possible that a ciiaining DSA may receive, invoke or return APDUs

that exceed its capacity. It is a minimum requirement tiiat invoke APDUs and return result APDUs shall be

accepted unless they exceed 32767 W^Ml octets in size;in this case they may be discarded and an

"unwillingToPerform" error reporting service shall be used.

Editor's Note - The above change in DSP result APDU size is to align with other regional implementors' agreements.

Rgure 4 (APDU Exchange) has been dropped in conjunction with the alignment change.

8
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

-> High ->

Medium -> DSA

Scheduler

Lou ->

Underlying

Protocol Services

Underlying OS

Services

Figure 5 - Logical DSA Application Environment.

7.1.3 Service Control (SC) Considerations

This agreement recognizes that DUAs may automatically supply defaults for any SC pa- rameter. The choice of default values selected (if any) is seen to be a matter of local policy

and consumer needs.

7.1.4 Priority Service Control

Priority is specified as a service control argument in the Directory Documents. The fol- lowing statements represent a clarification of the semantics that may be used by a DSA in interpreting and operating on this parameter.

The logical model in figure 5 ( page 9) may be considered as an example by DSAs that

implement this Service Control. In figure 5, note that: - the DSA maintains three logical queues corresponding to the three priority levels;

- the DSA Scheduler is separate and distinct from any scheduling function provided by

the underlying operating system or control program services;

- the DSA Scheduler presents jobs to the Underlying Operating Services for execution

and always presents jobs of a higher priority before those of a lower priority;

- the DSA Scheduler will not preempt a request once it has been passed to the underlying

operating system service.

7.2 Constraints on Operations

There are no overall constraints upon service arguments or results except those implied

in 7.1.2 of this document.

9
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

7.2.1 Filters

It is required that DSAs, at a minimum, support 8 nested "Filter" parameters, and a total

limit of 32 Filter Items. If these limits are exceeded, the recipient of that SearchArgument

may return the ServiceProblem "unwillingToPerform".

7.2.2 Errors

There are no constraints upon any Error service except the APDU size limit as defined

in 7.1.2.

7.2.3 Error Reporting — Detection of Search Loop

A search operation may encounter a looping situation when the search encompasses "wholesubtree", and an alias is encountered which is a superior to some other subtree that has

been encountered during the search. DSAs should be able to detect this situation. One possible method is by:

1. Maintaining a list of the base objects of searches initiated as a consequence of Step 5 of Part 4, clause 18.7.2.2.1 of the Directory Documents (this may require an analysis

of the Tracelnformation field).

2. Determining whether a new base object is superior to any base object on this list. A new base object which would cause a loop in this way should be discarded (i.e., should

not cause a new search), but no error should be reported by an error-reporting service. The

circumstances should be logged so that it may be reported to an appropriate Administrative

Authority for rectification.

7.3 Constraints Relevant to Specific Attribute Types

Table 1

( pages 40 and 41) gives pragmatic constraints associated with selected attribute

types specified in the Directory Documents; many of these constraints also appear and are the same in the CCITT version of the Directory Documents. Each constraint in table 1 is given in terms of a length constraint. The length constraint for a given attribute value is the number of units which a sending entity shall not exceed and which a receiving entity

shall accept and process. A sending entity need not be capable of sending attribute values

as large as the length constraints.

Note that in table 1 the length constraint for strings is expressed as the number of allowable

characters.

In addition to the constraints given in table 1, the following constraints apply to alphabets

and integer values.

- Alphabets: T.61 Strings used as attribute values shall only encode graphic characters

and spaces. They shall not contain formatting characters (such as subscript) or other

control characters.

10
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

- Integer Values: DSAs shall be required to "pass through" encoded integer attribute

values of arbitrary length (e.g., when chaining a Directory operation). No Directory

component (i.e., DUA or DSA) shall be deemed non-conformant if it encodes integer

attribute values of arbitrary length.

Components of the Directory are required to support (for storage and processing), as a minimum, integer attribute values encoded in 4 octets.

8 Conformance

The following subclauses will describe various aspects of Directory conformance. It should

be noted that conformance to the various ASEs and conformance to the Authentication

Framework are viewed as separate issues and are presented in that context.

8.1 DUA Conformance

Conformance requirements for DUAs are adequately specified in the Directory Documents,

Part 5, clause 9.1 and the Directory Access Profile (see 8.6). It should be noted that the

DUA conformance is based on DAP Protocol and not the User Interface. Not all options

available in the standard need to be made available to the user of the DUA.

It is recognized that DUAs will be widely differing in nature:

- Some are intended to support human users, some application users. - Particular DUAs may not support particular operations because the application that

they support has no requirement; others will be general purpose, and will support all operations. - Some DUAs will have a fixed view of the Directory content and structure, reflecting

the usage of The Directory by a particular application; others will have a more flexible view which can be adapted to new usages.

- Some DUAs will provide automatic referral services with automatic establishment and

release of associations; others will place the burden on the user. - Some DUAs will provide a variety of authentication means; others will support no

authentication

- Some DUAs will handle operations synchronously; others will have the capability of

maintaining several identifiable dialogues with The Directory at one time.

In the next subclause, different types of DSAs are discussed. The DUA is independent of

the type of DSA it is communicating with and does not need to know what type of DSA it

is communicating with.

8.2 DSA Conformance

Basic conformance requirements for a DSA are defined in the Directory Documents, Part 5, clause 9.2. Some of the terms used to describe DSA conformance are summarized below.

11
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

- Centralized: A centralized DSA is defined as one that contains its entire relevant DIT;

it follows that it will not make use of the DSP or generate referral responses. Since

this model only contains a single DSA it is not subject to DSA interworking issues and will always provide a consistent level of service and results. A centralized DSA

shall be fully "protocol" conformant to the DAP.

- Cooperating: In a distributed directory, responsibility for various portions of the DIT

may be "distributed" among multiple DSAs. On a per operation basis we define a DSA to be holding when it is responsible for the fragment of the DIB in which a given

entry will appear if it exists; we define a DSA to be propagating when it is unable to complete the name resolution process.

All DSAs shall be capable of acting as a holder and a propagator.

8.3 DSA Conformance Classes

A DSA implementation shall satisfy the conformance requirements as defined in the Directory Documents, Part 5, subclause 9.2, and shall support the "Versions" argument of

"Bind".

Per the conformance clause of the Directory Documents, a DSA shall conform to the abstract

syntax of the attribute types for which conformance is claimed. These attribute types shall include those required by 6.3 of this Implementor's Agreement.

Additionally, an implementation conformant to these agreements shall state which of the

following conformance classes it implements:

- Conformance Class 0 — Centralized DSA

A DSA conformant to this class only supports the DirectoryAccessAC.

As the performance of Search and List operations can consume significant resources, the policies of some centralized DSAs may be such that these operations will not be performed. For these cases, the reply to requests for such operations would be a

ServiceError with the "unwillingToPerform" ServiceProblem. - Conformance Class 1 - Distributed DSA

A DSA implementation conformant to this class shall implement all the operations in the ASEs that are part of the Application context for which it claims conformance. It shall support the DirectoryAccessAC and it may optionally support the DirectorySystemAC.

DSAs conformant to these Agreements shall support the OIW Directory Common Application Directory Profile. In addition, DSAs may optionally conform to the OIW Directory

Strong Authentication Directory Profile. Future versions of these Agreements may allow

additional possibilities for minimal profile conformance.

8.4 Authentication Conformance

A Directory System may choose to implement various levels of authentication (Directory

Documents, Part 8). We define the following levels of authentication in the DS:

12
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

- No authentication at all; (None)

- Simple Uncorroborated: identification without verification - Simple Uncorroborated authentication with verification: verified identification

without a password.

- Simple Corroborated authentication: verified identification with a password; in- tended to make masquerading difficult. - Strong authentication: identification with verification using cryptographic techniques

intended to make masquerading, in practical terms, nearly impossible.

The "Authentication Framework" document describes the specific goal of each authentication level; listed below are several practical uses of the various levels. ^

Simple Uncorroborated authentication may be desired to maintain access

statistics or in a private network where the initiator is implicitly trusted and there

is no need to incur the additional overhead of more sophisticated authentication

methods.

Simple Corroborated authentication may be necessary in situations where

strong authentication is not practical, (i.e., international connection, no knowledge of algorithms in use, etc).

Strong authentication will be required for secure environments.

A DSA that implements Simple Corroborated authentication will check the user password

by means of a compare operation on the user's entry. If no user password is supplied (Simple

Uncorroborated authentication) the DSA will validate the presence of the entry for the user, by a read operation or otherwise. The authentication will fail if the password is incorrect

or if the user's entry does not exist. A DSA that implements Simple Uncorroborated authentication without verification will accept simple credentials without validating them.

Implementations claiming conformance shall, as a minimum, implement None and Simple

Uncorroborated authentication without verification.

8.5 Directory Service Conformance

The following subclauses will describe various aspects of Directory conformance. Confor- mance to the Authentication Framework is viewed as a separate issue from conformance to the rest of the Directory document and is presented in that context.

Directory Profiles are broken into two subclauses. Service support specifies the level of

support for operations and errors. Protocol support specifies the protocol elements required

for implementations which claim conformance to specified operations.

To specify the support for operations and errors, two classifications are used as follows.

^It is the case that some DSAs containing public information may not require authentication.

13
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

1. r: required

The operation shall be implemented and the respective error shall be handled for conformance to these agreements.

For DUAs, required means:

- For ARGUMENT parameters, create the DAP protocol elements to convey the

service request to the DSA.

- For RESULT and ERROR parameters, accept the DAP protocol elements.

For DSAs, required means:

- For ARGUMENT parameters, accept the protocol elements when received and

create the protocol elements when acting as a requesting DSA.

- For RESULT and ERROR parameters, be able to convey all possible results w when responding in either the DAP or DSP protocols and when receiving results,

perform additional processing as defined for cooperating DSAs.

2. n: not required

It is left to implementations as to whether the operation or error is implemented or

not.

To specify the support for protocol elements, four classifications are used as follows.

1. M: mandatory

Generation of element is a mandatory static conformance requirement (i.e., a confor-

' mant implementation shall be capable of generating the element).

Generation of element is a mandatory dynamic conformance requirement (i.e., the

element shall be present in all instances of communication which use the element).

The terms static conformance and dynamic conformance are defined in ISO 9646-1,

"OSI Conformance Testing Methodology and Framework, Part 1: General Concepts."

2. G: generate

Generation of element is a mandatory static conformance requirement.

Generation of element is a conditional dynamic conformance requirement; the condition is: Where a DSA is a propagating DSA, it shall be capable of generating the

protocol element as received in related APDUs received from other DSAs.

, , Where the DSA is a holding DSA, it shall be capable of creating all possible

values of a protocol element unless otherwise noted in the "Comments" line.

3. S: support

When receiving protocol elements, implementations of these agreements shall be ca^ pable of accepting these elements without error. Actions specified in the Directory

documents and in these agreements shall be taken.

4. O: optional

When generating protocol elements:

14
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

- Generation of element is an optional static conformance requirement. If the

implementor claims support for the corresponding Directory capability, then the

implementation shall be capable of generating the element. - Generation of element is an optional dynamic conformance requirement. If the

implementor claims support for the corresponding Directory capability, then the

element shall be present in instances of communication which use the element

(except where defaults allow otherwise).

When receiving protocol elements, implementations of these agreements shall be capable of accepting these elements without error. However, actions specified in the beise standard and in these agreements may be taken but are not required.

Where protocol elements are nested, the classification of the nested protocol elements is of relevance only when the immediately containing protocol element is generated. The

classification of the protocol elements at the highest level is relative with respect to support

of the operation.

Also note that in table 3, some rows contain two support classifications in the DSA column.

In such cases, the support classification in parentheses applies to centralized DSA's only.

When there is only one support classification given, it applies equally to centralized and

non-centralized DSA's.

8.6 The Directory Access Profile

This agreement requires implementations of the DUA to provide access to the Directory

Services as defined in the DUA column in table 2. For the services in table 2 which are supported, these agreements further require DUAs to support the protocol elements as defined in the DUA column in table 3 (parts 1-7).

These agreements require implementations of the DSA to support the Directory Services as defined in the DSA column in table 2 (page 42). These agreements further require DSAs to support the protocol elements as defined in the DSA column in table 3. Table 3 is listed in seven parts (page 43 through page 49). Note that the requirements for a centralized DSA

and a cooperating DSA are different.

8.7 The Directory System Profile

These agreements require implementations of distributed DSAs which provide DSP to sup- port the responder role for services as defined in table 4 (page 50). Further, these agreements

require DSAs to support the protocol elements as specified in table 5. Table 5 is listed in nine parts (page 51 through page 59).

DSAs are required to support the requestor role for all the services as defined in table 4 if conforming to the chained mode of interaction.

8.8 Digital Signature Protocol Conformance Profile

Table 6 on page 60 and table 7 on page 60 provide information on the digital signature

protocol conformance profile.

15
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Note that elements in CommonArguments and CommonResults SecurityParameters that are not specified in table 6 and table 7 are covered in the Directory Service Protocol Support

(table 5) and Directory Access Protocol Support (table 3).

8.9 Strong Authentication Protocol Conformance Profile

Table 8 on page 61 and table 9 on page 62 provide information on the strong authentication

protocol conformance profile.

9 Distributed Operations

The following requirements apply to DSAs supporting distributed operations:

- DSAs supporting authentication (e.g., simple authentication by name and password)

shall be able to invoke DSP operations to carry out authentication by reference to other DSAs. Thus all such DSAs shall support the DSP protocol. The requirement is implied by the Directory Documents.

9.1 Referrals and Chaining

It is recommended that a DSA which has chained a request act upon any referrals it receives

rather than returning them to the requestor if the "preferChaining" service control is present.

9.2 Trace Information

A Tracelnformation value carries forward a record of the DSAs which have been involved in the performance of an operation. It is used to detect the existence of, or avoid, loops which

might arise from inconsistent knowledge or from the presence of alias loops in the DIT.

Each DSA which is propagating an operation to another, adds a new item to the trace information. If the propagation of a Search operation involves the creation of a new Search

(cf Directory Documents, Part 4, clause 18.7.2.2.2), the trace information shall not be reset, but the full trace information for the overall Search operation to the point where the new Search was generated shall be included in the new Search.

10 Underlying Services

This section specifies requirements over and above those given in the Directory Documents.

10.1 ROSE

It should be noted that support of "abandon" implies support of operation class 2.

16
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

10.2 Session

All directory implementations are required to support Session Version 2.

10.3 ACSE

The A-ABORT service is required by association-accepting DSAs to escape unwanted associ- ations, which, under the ROSE protocol, they cannot release. In all other cases (associationinitiating DSAs and DUAs) it may be preferable (though not required) to escape associations

using UNBIND rather than abort.

The aborting DUA or DSA may optionally use the user information field of the A-ABORT.

Such information, however, is only meaningful for diagnostic purposes and its use is not covered by these Agreements.

11 Access Control

Guidelines relating to access control can be found in Annex F of the Directory Documents,

Part 2.

12 Test Considerations

This clause outlines some items that implementors may wish to consider in terms of testing

expectations; additionally, future conformance testers may wish to consider these items

when developing tests.

12.1 Major Elements of Architecture

One important aspect of testing is to confirm the correct behavior of DSAs and DUAs with

respect to major elements of the directory architecture.

Such major elements include:

a) Conformance Statement

b) Distinguished names (e.g., name resolution, equivalence of various forms)

c) Entries and Attributes (e.g., accessibility by operations, compliance with rules)

d) Handling of distributed operations (e.g., naming contexts and knowledge)

e) Schemas

1) Structure rules (e.g., storage and maintenance of structure and of naming rules)

2) Object classes and sub-classes (e.g., storage and extension of rules for object

attributes)

3) Attribute types (e.g., storage and maintenance of syntax classes and rules for multi or single valued attributes)

17
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

4) Attribute syntax (e.g., maintenance and support for attribute value testing and

matching, to specification for a defined set of attribute types)

f) Operations

1) all operations

2) correct function

3) correct result

4) correct responses

g) Aliases (e.g., correct resolution, error responses)

h) Authentication and Access Control (e.g., limitation of modify access)

i) ROSE (e.g., correct handling of invokes, results, rejects, and invoke ids)

j) ACSE (e.g., association establishment / refusal for invalid application contexts, etc.)

12.2 Search Operation

Testing of support for filter items should be reasonable. It is not expected that DBAs will be able to handle worst case testing in this area.

13 Errors

This clause provides clarification of the semantics of various operation errors and implementation guidelines on their usage.

13.1 Permanent vs. Temporary Service Errors

This subclause provides some clarification regarding the usage of the Service Errors busy,

unavailable, and unwillingToPerform.

The error busy is particularly transient. It is returned when one or more of The Directory's

internal resources are being used to their capacity and, hence, the requested operation

cannot, for the moment, be performed. The Directory should be able to recover from this type of resource depletion after a short while.

The error unavailable is also temporary but somewhat less transient. It indicates that The

Directory (or some part of it) is currently unavailable and may continue to be unavailable

for a reasonably long period of time. For example, this error is returned when a given DSA

is functionally disabled, or when a specific part of the DIB is undergoing reconfiguration.

The error unwillingToPerform has a permanent connotation. It indicates that The Directory cannot perform the requested operation because it would require resources beyond its capacity. For example, this error may be returned by a DSA if satisfying a request would

result in the generation of an APDU in excess of 32767 octets.

18
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

13.2 Guidelines for Error Handling

13.2.1 Introduction

This subclause provides a recommended mapping of error situations which may be encountered to ROSE Rejects or to the errors provided in the DAP and DSP protocols of the

Directory Documents.

The Directory Documents are not adequately definitive about the handling of errors. In

this document, more explicit guidelines are given.

Error situations are defined by:

- Symptom (i.e., the manner in which the error was detected). - Situation (i.e., the circumstance or phase during which the error was detected. For each possible situation, the error-handling procedure needs to be defined).

13.2.2 Symptoms

Table 10 (page 63 to page 65) describes a set of symptoms; the set is not necessarily ex- haustive. Each is identified by a title which is used later in describing error actions. The

title used for each symptom is not intended to imply any particular usage in a particular

implementation.

13.2.3 Situations

Table 11 (page 66) identifies recognized situations within which particular symptoms may

give rise to distinct error actions.

13.2.4 Error Actions

Table 13 (page 68 to page 73) summarizes specific error actions for each possible combination

of symptom and situation. Symptoms are described in 13.2.2 and situations are described

in 13.2.3.

Each entry in table 13 corresponds to the symptom in the left-most column and the situation

given in the column header. Each entry may specify: - a specific error action. The error action is described using the notation shown in table 12.

- a specific error action and a relevant note. The note will be indicated by a number

enclosed in parentheses. The notes can be found on page 74.

- only a relevant note.

- a blank (which indicates the corresponding combination of symptom and situation is not meaningful in the context of these Agreements).

The entries in table 13 which specify a specific error action will do so using the notation

shown in table 12 (page 67).

19
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

13.2.5 Reporting

In addition to the use of error-reporting services, DSAs should implement logging services to assist in management of the Directory. The list below describes classes of error which

should be logged. Note that the list is not necessarily complete.

1. Errors indicating attempted breaches of security.

2. Errors indicating local software or hardware malfunction.

3. Errors indicating malfunction or other unacceptable behavior on the part of the invoker

of an operation.

4. Errors indicating loss of chaining service by another DSA.

5. Error conditions that would be difficult to diagnose with the level of detail supplied

over the protocol.

6. Aborts and other exceptional communications events.

The form and accessibility of any such logs is for further study.

14 Specific Authentication Schemes

This clause describes identified authentication algorithms. Use of algorithms in this clause

is not mandatory. Use of algorithms other than those described in this clause or described

in the Directory Documents is by bilateral agreement.

14.1 Specific Strong Authentication Schemes

This subclause provides information on one alternative to the RSA digital signature scheme.

The alternative is identified as the "ElGamal" digital signature scheme. Future contributions

may result in other alternatives being added to this subclause.

Implementors may choose to provide digital signature capability based on RSA, ElGamal,

or some other scheme appropriate for use in the OSI Directory environment.

It should be noted that use of RSA is governed by U.S. patent law.

14.1.1 ElGamal

The information in this subclause includes a tutorial description of the ElGamal scheme

for digital signature using the notation defined in the Directory Documents, Part 8. It is intended that much of the tutorial information provided in this subclause will be moved to the security agreements sometime in the future.

14.1.1.1 Background

The ElGamal digital signature scheme is based on earlier work done by Diffie and Hellman

[DIFF76] in which it was suggested that a likely candidate for a one-way function is the

20
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

discrete exponeniial function

f{x) = a'= (modp) (1) where x is an integer between 1 and p— 1 inclusive, where p is a very large prime number, and

where a is an integer such that I <a <p and {a mod p, mod p, • •

• , a?" ^ mod p} is equal

to the set {1, 2, • • • ,p — 1}. In algebraic terminology, such an a is called a primitive element

References on the topic of primitive roots and elements are [McC179] and [PATT87].

Now, in the real number system, if y = a^, then by definition of the logarithm we can solve

for X using X — log|^(j/). The same idea extends to solving eq (1) for x so that inverting f{x)

requires calculating discrete logarithms. The reason Diffie and Hellman suspected eq (1) is one-way is that for suitable p, it is computationally difficult to invert f{x). According to the current state of the art, computing discrete logs for suitable p has been found to require a number of operations roughly equivalent to

exp(\/c61n b) (2)

where b is the number of bits in p, and c is estimated at c = .69 according to [ODLY]. This can be compared to only about 2 logj p multiplications for discrete exponentiation. If in fact the best known algorithm for computing discrete logs is near optimal then Expression (2)

is a good measure of the problem's complexity (for a properly chosen p) and the discrete

exponential function has all the qualities of a one-way function as described by Difhe and

Hellman.

14.1.1.2 Digital Signature

• Private Key: Xs denotes the private key for user X. Xg is a randomly chosen integer

which user X keeps secret.

• Public Key : Xp denotes the public key for user X and is calculated using the corre- sponding private key such that

Xp = ct^s (mod p) (3)

where — p is a prime satisfying the requirements listed in 14.1.1.4. — a is a primitive element mod p. — Note that p and a could be used globally, but because they should be easily

changeable (see 14.1.1.4 for information about why these two parameters should

be easily changeable) it would probably be preferable for each user to choose

his/her own p and a. If users choose their own, then p and a must be made

available to the recipient for use in the signature verification process.

• Signing Procedure: Suppose user A wants to sign a message intended for recipient B.

The basic idea is to compute a two part signature (r, s) for the message m such that

a^{rn) ^ ^ApYr' (mod p) (4)

where /i is a one-way hash function.

Compute the signature (r, s) as follows.

21
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

1. Choose a random number k, uniformly between 0 and p — 1 such that k and p—l

have no common divisor except 1 (i.e., gcd(fc,p— 1) = 1).

2. Compute r such that

r = a'' (mod p) (5)

3. Use r to solve for the corresponding s as follows.

(a) rewrite eq (4) using eq (5) and the definition of the public key to get

Combining exponents, get

^him) - ^(As)r+ks (rnodp) (7)

eq (7) implies that

, ; : h{m) = {As)r + ks (modp-1) (8)

Note that eq (8) has a single solution for s because k was chosen such that

gcd(fc,p— 1) = 1. See [SIER88] for supporting theorem.

(b) now solve for s and get

s = I{h{m) - (As)r) (modp-1) (9)

where / is computed such that k * I = 1 (mod p—l).

The ElGamal signature is comparable in size to the corresponding RSA signature.

14.1.1.3 Verification

The recipient receives Ap,m,r,s,a, and p and computes both sides of eq (4) and then

compares the results.

14.1.1.4 Known Constraints on Parameters

The following list of constraints is the result of a search of current literature and may not be complete.

1. p must be prime

2. p must be large.

Note that Expression (2) can be used to speculate on the level of security afforded by

cryptosystems based on the discrete log problem. Breaking the ElGamal scheme has

not been proven to be equivalent to finding discrete logs, but if we assume equivalence

then we can estimate how large p should be for a desired level of security. For instance, suppose we wanted to use Expression (2) to decide how large p should

be so that we can be reasonably sure the system cannot be broken (using the best known algorithm) in a practical amount of time. To be on the conservative side, we

decide we want to protect against a special purpose machine that can perform 10-^^

22
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

operations per second. Specifically, we want to know how large p should be so that

such a machine would take at least one year to break the system.

In one year, the hypothetical machine can perform 3 x 10^^ operations. To find the

size of the desired p, solve the following equation for b.

exp(\/cMn6) = 3 X 10^2 (10)

We get h 1^ 606. This is the number of bits in the desired p. So, the magnitude of the

desired p is about 2^°^ which is roughly 266 x 10^^°.

Hence, to be reasonably sure of attaining the desired level of security, we find a prime

number greater than 266 x 10^*° which satisfies all the other criteria listed in this subclause. Our confidence, however, is strictly based on the assumption that breaking

ElGamal is as difficult as finding discrete logs and the assumption that the best known

algorithm for finding discrete logs is near optimal.

3. p should occasionally be changed. This requirement is discussed in [ODLY84] and is related to the discovery of new algorithms for computing discrete logarithms in GF{p).

4. p — 1 must have at least one large prime factor. This requirement is discussed in [ODLY84] and is imposed by the Silverman-Pohlig-Hellman algorithm which computes discrete logarithms in GF(p) using on the order ^/r operations and a comparable

amount of storage, where r is the largest prime factor in p — 1.

5. p should not be the square of any prime. A subexponential-time algorithm for computing discrete logarithms in GF{j?) has been found. See [ELGA85b] for details.

14.1.1.5 Note on subjectPublicKey

The ASN.l data element subjectPublicKey, defined as BIT STRING in Annex (G) of

Directory Documents, Part 8, should be interpreted in the case of ElGamal as being of type:

SEqUENCE{ INTEGER, INTEGER }

where the first integer is the Arithmetic Modulus and the second is the primitive element

for the finite field. The sequence is represented by the ASN.l Basic Encoding Rules.

Implementors should take note that the size of the integers used for these parameters is expected to exceed the pragmatic constraints specified for integers by the upper layers SIG.

14.1.2 One-Way Hash Functions

14.1.2.1 SQUARE-MOD-N Algorithm

Recent research regarding the square-mod-n one-way hash function described in Annex D

of the Directory Documents, Part 8, has revealed that the function is not secure. Its use, therefore, is discouraged.

23
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

14.1.2.2 MD2 Algorithm

MD2 is a one-way hash function and is described in [RFC1115]. Implementors should note

that the use of MD2 may be subject to license agreements.

14.1.2.3 Study of Other One-Way Hash Functions

The Directory SIG is studying the applicability of alternative one-way hash functions. One

recent development in this area was the announcement by Ralph Merkle that 2-pass SNEFRU is broken; its use is therefore discouraged. Refer to the Working Agreements for further status on the study of one-way hash functions.

14.1.2.4 Use of One—Way Hash Functions in Forming Signatures

MD2 may be used to form digital signatures in conjunction with RSA or ElGamal.

14.1.3 ASN.l for Strong Authentication Algorithms

This subclause defines object identifiers assigned to authentication algorithms. The defini- tions take the form of the ASN.l module, "OIWAlgorithmObjectldentifiers".

OIWAlgorithmObject Identifiers {iso(l) identif ied-organization(3)

oiw(14) dssig(7)

oIWAlgor ithmObj ect Ident if iers ( 1 )

}

DEFINITIONS : := BEGIN

EXPORTS

md2, md2WithRSA, elGamal, md2WithElGamal

;

IMPORTS

authenticationFramework

FROM UsefulDef initions {joint-iso-ccitt ds(5) modules(l)

usefulDef initions(0)]

ALGORITHM FROM AuthenticationFramework

authenticationFrconework; — categories of object identifiers

algorithm OBJECT IDENTIFIER ::= {iso(l) identif ied-organization(3)

oiw(14) dssig(7) algorithm(2)>

encriptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1}

hashAlgorthm OBJECT IDENTIFIER ::= {algorithm 2}

24
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3} — algorithms

md2 ALGORITHM

PARAMETER NULL

::= {hashAlgorithm l}

md2WithRsa ALGORITHM

PARAMETER NULL

::= {signatureAlgorithm 1}

elGamal ALGORITHM

PARAMETER NULL

::= {encryptionAlgorithm 1}

Editor's Note: Refer to the June 1990 Working Agreements for information re- garding why PARAMETER NULL is specified above for the ElGamal encryption

algorithm.

md2WithElGamal ALGORITHM

PARAMETER NULL

::= {signatureAlgorithm 2}

END — of Algorithm Object Identifer Definitions

14.1.4 Note on the ENCRYPTED MACRO

The value associated with the ENCRYPTED MACRO, as defined in Directory Documents,

part 8, clause 8.4 shall be interpreted in the case of ElGamal as being type:

SEQUENCE{ INTEGER, INTEGER }

The first integer in the sequence is r (see eq (5), 14.1.1.2). The second integer is 5 (see eq

(9), 14.1.1.2).

14.2 Protected Simple Authentication

Protecting the user's distinguished name and password provides greater degrees of security

than where passwords are not protected.

The procedure for achieving this protection, referred to as protected simple authentication,

is outlined in the Directory Documents, Part 8, clause 5.3. The approach by which protected

identifying information may be generated is outlined in the Directory Documents, Part 8, clause 5.4. For the purpose of these agreements, fl and /2 as specified in the Directory

Documents, Part 8, clause 5.4 are identical MD2 one-way functions. The algorithms for implementation of the MD2 one-way function are described in [RFC1115] (see D.3). Note

25
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

that the use of MD2 may be subject to licensing agreement. Use of other algorithms for other one-way functions is by bilateral agreement.

User A generates Protected2 as specified in the Directory Documents, Part 8, clause 5.4. Authenticator2 is then conveyed to B in the form of SimpleCredentials. Table 14 on page 75

shows the relationship between SimpleCredential fields and the elements of protected simple

authentication as shown in figure 2 of the Directory Documents, Part 8.

14.3 Simple Authentication

There are two major classes of authentication supported by the Directory (i.e., simple and

strong authentication). Simple authentication is based on a password being passed between

the two associated entities (e.g., between a Directory User and a DUA, or between two

DBAs). In the case of interaction between a Directory User and a DUA, the password is compared in some way with the password attribute in the user's entry in the Directory. In the case of interaction between two DSAs, this cannot be done since the DSA object class, as defined in the Directory Documents (Part 7, clause 6.14) does not contain a password

attribute.

To facilitate simple authentication between DSAs, it is recommended that a DSA have local access to a list of one or more known DSAs, with a copy of each known DSA's password.

Maintenance of that information is done through the use of bilateral agreements between

DSA administrators.

26
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Annex A

(normative)

Maintenance of Attribute Syntaxes

A.l Introduction

The attribute types defined in the Directory Documents, Part 6, and listed in table 1 (page 40) have requirements, in DSAs which support them, for underlying algorithms that:

- check attribute values for syntactical correctness and compliance with pragmatic constraints;

- match attribute values (comparing for equality, for matching substrings, and for rela- tive ordering).

A. 2 General Rules

A DSA may receive a legitimately encoded attribute or AVA that is unsupported by the

DSA. If the DSA is not required to act on it, or to store it within an entry, it may handle

it by passing it on without error. Such attributes may also be used in search filter-item

definitions: in this case, no error is reported, but the filter-item shall be deemed to be

undefined for all entries in the DSA. This rule applies to occurrences of attributes in both

operation arguments and results.

Conversely, a DSA must return a suitable error if an operation requires it to act on or store an attribute or AVA of type unsupported by the DSA. This constraint applies even for AVAs

that are contained in attributes that take names as values, since the DSA will be unable

correctly to match the attribute values without this attribute information.

A. 3 Checking Algorithms

The subclauses below give additional checks (beyond those directly implied by the Directory

Documents) which shall be applied to attributes before they are stored in the DSA.

A.3.1 distinguishedNameSyntax

Each component AVA must be checked, unregistered attribute types comprising an error; check also that no two AVAs in the same RDN have the same attribute type.

A.3. 2 integerSyntax

Local implementations may apply local limitations.

27
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

A.3. 3 telephoneNumberSyntax

The value of policing further rules is for further study (this applies also to telexNumber, tele- texTerminalldentifier, facsimileTelephoneNumber, G3FacsimileNonBasicParameters, xl21Address,

and iSDNAddress).

A.3. 4 countryName

The value must be checked for compliance with IS03166: 1981 (E/F). (Note that from time

to time further codes may be allocated.)

A.3. 5 preferredDeliveryMethod

The values of the integer elements should not be restricted.

A.3. 6 presentationAddress

No further checks should be applied.

A. 4 Matching Algorithms

Matching algorithms are conveniently defined in terms of a two-step process:

1. Take the checked reference value, and the value to be matched, and, if necessary, reduce them to a canonical (i.e., standard) form (normalization) appropriate to each

attribute syntax.

2. Carry out the comparison in the specified way (e.g., equality, substrings or ordering)

using the appropriate rules for the value - character string, integer, boolean, etc.

Note that the lexical ordering of character strings (when supported) may be subject to local

rules. IMPORTANT NOTE: The combination of normalization and comparison may be re- placed, in a particular implementation, by equivalent procedures. Additional notes on nor- malization are given below.

A.4.1 UTCTimeSyntax

If the "seconds" field is absent, it shall be inserted, and set to "00", and the form converted

to the "Z" form. Note. The normalization strategy does not match times where the stored

form omits the seconds field, and the compared form contains it, e.g.,

8804261919Z

880426191926Z

28
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

(It might have been expected that these two forms, which coincide in time to within a few

seconds, would be considered identical.)

A.4. 2 distinguishedNameSyntax

For each attribute value, carry out normalization in accordance with the normalization rules defined for the type (if registered); values corresponding to unregistered attribute types are

left unchanged at this stage.

A.4. 3 caselgnoreListSyntax

To facilitate matching, particularly for substrings, normalization may be considered in terms

of a representation which replaces the separate ASN.l elements by a single string with a

delimiter.

29
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Annex B

(informative)

Glossary

The following abbreviations may be useful; not all are used within these agreements.

JV Ij Access Control List Association Control Service Element

ALJ 1) iVl U Administration Directory Management Domain

ArLi i itle Application ilintity iitle

A Ty in T T Application rrotocol Data Unit

A CTT Application Service Element

A CM 1 Abstract Syntax Notation - 1 AAA A Attribute Value Assertion

Jj rCiVl Basic Reference Model

C A Certification Authority

ine International ielegrapn and ielepnone Consultative Committee

Committee for European Normalization

Committee for European Normalization Electronique

(Committee of European Posts and Telephones)

Corporation for Open Systems

T\ A ! ) Directory Access Protocol

JJIJ3 Directory Information Base

TilT Directory Information Tree UJVIU Directory Management Domains

T~» UaC AA Directory System Agent

Directory System Protocol

FllTT A Directory User Agent

European Workshop for Open Systems

File Transfer, Access & Management

ilN 1 AP T i. L'l'x rn 1_*1A ' J.' r T ^ i.*T> ' T interoperability iechnical Association lor Information Processing, Japan

TO T\ XT Integrated Services Digital Network

International Organization tor Standardization

TyK 1 Knowledge iree

T T

JLLi Lower layers of OSI model (layers 1-4)

\/T A T* Manufacturing Automation Protocol

MHS Message Handling Systems

NIST National Institute of Standards and Technology

NSAP Network Services Access Point

OSI Open Systems Interconnection

PKCS Public Key Crypto System

POSI Promotion for Open System Interconnection

PRDMD Private Directory Management Domain

PSAP Presentation Service Access Point

RDN Relative Distinguished Name

ROSE Remote Operations Service Element

SSAP Session Service Access Point

SIG Special Interest Group

SPAG Standards Promotion & Application Group

30
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

TOP Technical and Office Protocols

TSAP Transport Service Access Point

UL Upper layers of OSI model (layers 5-7)

UPU Universal Postal Union

31
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Annex C

(informative)

Requirements for Distributed Operations

The following material is included for tutorial purposes, and does not represent material

additional to the Directory Documents. It is also not intended as a complete statement

of requirements (the Distributed Operations part of the Directory Documents should be

referred to for a complete treatment).

C.l General Requirements

DSAs supporting distributed operations and claiming support of chaining must fully support

DSP, as defined by the Directory Documents. DSAs supporting distributed operations must

always be able to accept incoming DSP associations and invocations. DSAs claiming support

of chaining must support:

- Loop detection

- Loop avoidance

In passing on operations (when chaining or multi-casting), the original DAP-supplied in- vocation must be passed on without change of content. In particular, there must be no

alteration in any way of any primitive content. The support of a facility for returning cross-references (Directory Documents, Part 4, clause

10.4.1) is optional.

To ensure that tracelnformation can be analyzed properly, DSAs shall only possess names

that are compliant with the recommendations of the Directory Documents, Part 7 (including

Annex B).

C.2 Protocol Support

C.2.1 Usage of ChainingArguments

When using ChainingArguments: ^

- originator need not be used if requestor in CommonArguments is used;

- targetObject shall not be used unless the target object differs from object/base object

(if it is present, object/base object are ignored for purposes of name resolution);

- operationProgress, tracelnformation, aliasDereferenced, aliasedRDNs, referenceType,

and timeLimit shall be generated, accepted, and used in accordance with the Directory

Documents;

- returnCrossReferences and info may optionally be generated, and shall always be ac- cepted.

^In this subclause, the names of protocol elements (within ChainingArguments) are italicized.

32
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

C.2.2 Usage of ChainingResults

When using ChainingResults: ^ crossReferences and info may optionally be generated, and

shall always be accepted.

^In this subclause, the names of protocol elements (within ChainingResults) are italicized.

33
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Annex D

(informative)

Guidelines for Applications Using the Directory

D.l Tutorial

D.1.1 Overview

Applications may have a requirement for Directory functionality. This tutorial provides

assistance to those groups intending to specify Directory usage for a specific application

(e.g., Message Handling Systems).

D.l.2 Use of the Directory Schema

D.l.2.1 Use of Existing Object Classes

Applications wishing to use the Directory should have determined within a standard, Implementor's Agreements, or on a propriety basis, the relevant Directory schema for their objects. Consider the following two examples:

1. Network management applications may with to define a SMAE object class.

2. File transfer applications may with to define a File Store object class.

Groups should examine relevant standards to determine if application-specific object classes or attributes have been already defined before considering any additional definition. These

object classes and attributes may be found in a variety of places including a specific application standard (e.g., [Recommendation CCITT '88 X.402 | ISO 10021-2] and the Directory

Documents). Standardized object classes and attributes should be strongly considered before additional schema elements are created.

D.1.2.2 Kinds of Object Classes

There are effectively two kinds of object classes permitted within the Directory Documents:

structural and auxiliary. The terms structural and auxiliary are used here for convenience

when referring to particular kinds of object classes. The terms themselves are not defined

in the Directory Documents.

Structural object classes have associated DIT structure rules (which control naming). Entries of this object class type are intended to be instantiated in Directory entries. A struc- tural object class provides information on the base mandatory and optional content of a DIT entry.

An auxiliary object class provides information to enhance the mandatory and optional contents of entries. It is always used in conjunction with a structural object class.

34
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

The object class hierarchy is formed as a result of the definition of structural object classes,

and the addition of auxiliary object classes.

For example, all object classes in the Directory Documents, Part 7, are structural except

for strongAuthentication User and certificationAuthority. These two object classes should

be considered auxiliary and used in conjunction with other, structural object classes.

D.1.2.3 Use of Unregistered Object Classes

The Directory Documents, Part 2, clause 9.4.1 provides a "special" form of object class called "unregistered." An unregistered object class is not assigned an object identifier. One of the uses for unregistered object classes is to provide a means of creating a single

Directory entry which logically represents a variety of object classes. Uses for unregistered

object classes include: - Locally adding attributes to a predefined superclass; - Locally making optional attribute types in a predefined superclass mandatory;

- Creating an object class derived from multiple superclasses, without needless proliferation of registered object classes.

For example, it may be advantageous to provide an entry which represents a person who is both a MHS and a FTAM user.

Unregistered object classes may best be illustrated by example. Consider an entry which

represents a collection of company entries for Fizzy Company whose users have MHS 0/R

addresses. Using the guidelines above, the Fizzy Company defines an unregistered object

class using the structural object class organizationalPerson from the Directory Documents,

Part 7, and the auxiliary object class mhs-user from the MHS standards [Recommendation

X.402 I ISO 10021-2] as follows:

f izzyCompanyPerson ::= OBJECT-CLASS

SUBCLASS OF organizationalPerson, mhs-user

MUST CONTAIN {}

MAY CONTAIN {}

Note that no object identifier is assigned.

Also note that since there are not MUST or MAY CONTAIN's in the fizzyCompanyPerson

Object Class, the last two lines of the object class assignment (i.e., "MUST CONTAIN MAY

CONTAIN ") are optional. As with the registered form of object classes, an unregistered object class always inherits all the attributes in any of its superclasses. There is no mechanism

defined whereby a subclass may selectively inherit attributes from its superclasses.

An unregistered object class always appears as a leaf in the Object Class tree (i.e., an

unregistered object class may not be a superclass of some other object class).

Using unregistered object classes in conjunction with multiple inheritance is useful as shown

by figure 6 in which three ways of creating the same two object classes are shown. Either

three, four, or five registered object classes are used.

35
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

per mhs ae

\ / \ /

mhs-per[ur] mhs-ae[ur]

Example a

[ur] = unregistered

per = person

mhs = mhs-user

ae = applicationEntity

Figure 6 - Three Ways of Creating Two Object Classes.

Examples (a) and (c) in figure 6 are both better ways of defining the object classes than

that in example (b), even though example (c) needs to use one more registered object class than example (b). This is because the multiple inheritance technique, used in examples (a) and (c), enables a Directory User searching the Directory to easily create a filter to find all entries that contain mhs-user attributes, based on a value in the object class attribute (Each

Directory entry contains a list of the object identifiers of the object classes it has inherited

from, so the filter would just have to find all entries that held the object identifier value of

mhs-user).

Example (a), which uses three registered object classes, is better than example (c), which

uses five, because registering the extra two object classes does not provide any advantage

over not registering them, and the first method avoids needless proliferation of registered

object classes.

per ae I per mhs ae

I I I \ / \ /

mhs-per mhs-ae I mhs-per mhs-ae

I Example b Excunple c

D.1.2.4 Side Effects of Creating Unregistered Object Classes

This subclause discusses two side eff'ects of creating unregistered object classes.

1. When an unregistered object class is defined from a single superclass, there is no means available to distinguish between the two. Within the local scope for which

the unregistered class is defined, all relevant entries are considered to belong to the

unregistered class. The following is an example of this problem:

An object class of oCl(reg) has attribute type atl mandatory and at2 optional. An unregistered form of this, oCl(unreg) is created, which makes at2

mandatory. When an Add Entry operation is received with both attributes

present, the entry could belong to either form of oCl; it is indeterminate.

After the entry is added a Modify Entry operation is received which requests

the removal of attribute type at2. It is not clear if this operation should

succeed, or whether an object class violation should be reported. If the

attribute may be removed, then the entry belonged to the oCl(reg) object

class and the unregistered form never existed, otherwise if the attribute may

not be removed, then the entry belonged to oCl(unreg) and the registered

form no longer exists.
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

2. More than one unregistered object class cannot be defined from the same superclass(es)

for use within the same local scope, as there is no means available to distinguish the

classes from one another.

D.2 Creation of New Object Classes

If no appropriate object class is available, a new object class may be defined. This should

only be done if no standardized object classes and attributes can fulfill the requirements.

D.2.1 Creation of New Subclasses

Generally, an application-specific object class is defined as a subclass of a pre-existing Directory object class. These object classes are specified in the Directory Documents, Part 7. The subclass may be structural or auxiliary. Optional attributes of the superclass may be

made mandatory. New attributes may also be added.

For example, MHS has used the Directory structural object class applicationEntity to derive

the object class for their MHS-specific application entity MTAs.

If absolutely no relevant object class is available, an object class maybe defined as a subclass

of the basic object class called "Top".

If no appropriate object class is available, a new object class may be defined. This should

only be undertaken if no standardized object class can fulfill the requirements. When

defining new object classes the object-class macro, as defined in the Directory Documents,

Part 2, clause 9.4.6, should be used.

If new subclasses are defined, suggested or required name forms may also be specified in text.

D.2. 2 Creation of New Attributes

If no appropriate attributes are available, a new attribute type may be defined. This should

only be undertaken if no standardized attributes can fulfill the requirements. ¥/hen defining new attributes the attribute macro, as defined in the Directory Documents, Part 2, clause

9.5.3, should be used.

D.3 DIT Structure Rules

Applications may desire to provide guidance on DIT structure rules and naming. As with

object classes, standardized or suggested structure (including naming) rules from the Directory Documents part 7, Annex B and application-specific standards should be consulted

before providing new structure rules. Annex B in the Directory Documents, Part 7, provides

guidelines on how to specify this information. Structure rules associated with superclasses

should be adopted wherever suitable.

37
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Annex E

(informative)

Template for an Application Specific Profile for Use of

the Directory

The template defined below should be used by OIW SIGs intending to specify Directory

usage. Such application specific profiles shall be contained in application specific chapters

of the OIW agreements. The information under each heading should be filled in (the text under each heading provides guidance on the meaning of the heading and should not be

included in the profile).

- PROFILE TITLE

Application specific profiles are named in the following way:

OIW <SIG-NAME> <DESCRIPTOR> DIRECTORY PROFILE

(e.g., OIW DIRECTORY STRONG AUTHENTICATION DIRECTORY PROFILE )

- OTHER PROFILES SUPPORTED

other OIW Directory profiles which are to be used by this specific application are listed here. Attributes, attribute sets, object classes and structure rules that are referenced

in these profiles need not be enumerated below.

- STANDARD APPLICATION SPECIFIC ATTRIBUTES AND ATTRIBUTE SETS

Any attributes supported from the relevant standards. For example, the MHS SIG

might include mhs-or-address here.

- STANDARD APPLICATION SPECIFIC OBJECT CLASSES

Any object classes supported from the relevant standards. For example, the MHS SIG

might include mhs-user here.

- OIW APPLICATION SPECIFIC ATTRIBUTES AND ATTRIBUTE SETS

This, optional, component of this profile allows for the specification of OIW application

specific attributes and attribute sets. This section of this template should be used

rarely and with consideration that no standard profile or attribute/attribute set exists which can be used.

- OIW APPLICATION SPECIFIC OBJECT CLASSES

This, optional, component of this profile allows for the specification of OIW application

specific object classes. This section of this template should be used rarely and with

consideration that no standard profile or object class exists which can be used.

- STRUCTURE RULES

Guidance for DIT structural rules, provided only when structure rules associated with

superclasses are not adopted. The Directory Documents, Part 7, Annex B provide an example and guideline to use in specifying this information.

38
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Annex F

(informative)

Bibliography

[ ELGA85 ] ElGamal T., "A Public Key Cryptosystem and a Signature Scheme Based on

Discrete Logarithms," IEEE Trans, on Inform. Theory, vol. IT-31, No. 4, July 1985.

[ DIFF76 ] Diffie W., Hellman M., "New Directions in Cryptography," IEEE Trans. Inform.

Theory, vol. IT-22, Nov. 1976

[ COPP86 ] Coppersmith, D., Odlyzko, A., Schroeppel, R., "Discrete Logarithms in GF{p),"

Algorithmica, vol. 1, 1986.

[ McC179 ] McClellan, J., Rader, C, Number Theory in Digital Signal Processing, PrenticeHall, 1979.

[ PATT87 ] Patterson, W., Mathematical Cryptology for Computer Scientists and Mathematicians, Rowman Sz. Littlefield, 1987.

[ ODLY ] Odlyzko, A., "On the Complexity of Computing Discrete Logarithms and Factoring Integers," to appear in Fundamental Problems in Communication and Computation, B. Gopinath and T.Loven, Eds., New York, NY:Springer.

[ ODLY84 ] Odlyzko, A., "Discrete Logarithms in Finite Fields and Their Cryptographic

Significance," in Advances in Cryptology, Proceedings of EUROCRYPT 84- New York,

NY:Springer-Verlag, pp. 224-314.

[ ELGA85b ] ElGamal, T., "A Subexponential-time Algorithm for Computing Discrete

Logarithms over GF{p^);' IEEE Trans. Inform. Theory, vol. IT-31, July 1985.

[ SIER88 ] Sierpinski, W., Elementary Theory of Numbers, North-Holland 1988.

[ RFC1115 ] Linn, J., Privacy Enhancement for Internet Electronic Mail: Part III - Algorithms, Modes, and Identifiers, RFC-1115, August 1989, lAB Privacy Task Force.

39
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 1 - Pragmatic Constraints for Selected Attributes (Part 1 of 2)

Attribute Type Content Constraints Primary

Source

Notes

Aliased Object Name Distinguished

Name

Note 3 (page 41)

Business Category T.61 or Printable

String

ub-business-category

128

CCITT

X.520

Common Name T.61 or Printable

String

ub-common-name

64

CCITT

X.520

Country Name Printable String 2 ISO

3166

Description T.61 or Printable

String

ub-description

1024

CCITT

X.520

About 1 screen full

Destination Indicator Printable String ub-destination-indicator

128

CCITT

X.520

Facsimile Telephone

Number

Facsimile Telephone

Number

ub-telephone-number

32

CCITT

X.520

Optionally includes 03

non-basic parameters

(Upper bounds ffs) International ISDN

Number

Numeric String ub-isdn-address

lb

CCITT

A.OZU

E.164 Internat'l ISDN

Number

Knowledge Informat ion

T.61 or Printable

^'^ n n cr 1024 OIW About 1 screen full

Locality Name T.61 or Printable

otrmg

ub-locality-name

1 o o izo

CCITT

Member Distinguished

Name

Note 3 (page 41)

Object Class Object Identifier 256 octets OIW

Organization Name T.61 or Printable

String

ub-organization-name

64

CCITT

X.520

Organizational Unit

Name

1.61 or rrmtable

String

ub-organizational-unit- name 64CCITT

X.520

Owner Distinguished

Name

Note 3 (page 41)

Physical Delivery

Office Name

l.bl or Prmtable

String

ub-physical-omce-name

128

CCITT

X.520

Post Office Box T.61 or Printable

String

ub-post-office-box

40

CCITT

X.520

Postal Address Postal Address ub-postal-line 6 ub-postal-string 30CCITT

X.520

UPU

Postal Code T.61 or Printable

String

ub-postal-code

40

CCITT

X.520

Presentation Address Presentation

Address

224 octets NIST Note 2 (page 41), ISO

7498.3 & X.200

40
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 1 - Pragmatic Constraints for Selected Attributes (Part 2 of 2)

Attribute Type Content Constraints Primary

k—J Li 1. Notes

Registered Address Postal Address ub-postal-line 6 ub-postal-string 30

CCITT

X.520

Role Occupant Distinguished

Name

Note 3 (page 41)

Search Guide Guide 256 OIW

See Also Distinguished

Name

Note 3 (page 41)

Serial Number Printable String ub-serial-number

64

CCITT

X.520

State or Province

Name

T.61 or Printable

String

ub-state-name

128

CCITT

X.520

Street Address T.61 or Printable

String

ub-street-address

128

CCITT

X.520

Supported

Application Context

Object Identifier 256 OIW

Surname T.61 or Printable

String

ub-surname

64

CCITT

X.520

Telephone Number Printable String ub-telephone-number

32

CCITT

X.520

E.123

Teletex Terminal

Identifier

Teletex Terminal

Identifier

ub-teletex-terminal-id

1024

CCITT

X.520

Optionally includes Telstex non-basic pa- rameters (upper bound

ffs) Telex Number Telex Number ub-telex-number 14

ub-country-code 4

ub-answerback 8

CCITT

X.520

Contains sequence of telex number, country

code, and answerback

Title T.61 or Printable

String

ub-title 64CCITT

X.520

User Password Octet String ub-user-password

128

CCITT

X.520

Allow long passwords

generated by machine

X.121 Address Numeric String ub-xl21-address

15 CCITT

X.520

X.121

Notes for table 1

1. The pragmatic constraints of these parameters are defined in other standards. We

will accommodate these values in our pragmatic constraints.

2. Presentation address is composed of "X" NSAP addresses, and three selectors, (20^" + 32 + 16 + 16), e.g., i{ X = 1, this would be 84. These numbers are based on the most recent implementors' agreements. With 8 NSAP addresses this value is 224.

3. Pragmatic constraints are only applied to the individual components of DistinguishedName as defined in the Directory Documents, Part 2. Not aU components of a DN will necessarily be understood by an implementation.

4. Implementors should be aware that constraints on Postal Address may not be suffi- cient for some markets.

41
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 2 - Directory Access Service Support.

Support

Classification

DUA DSA (.r»Tn mf^n f c - BIND and UNBIND -

DirectoryBind r r L-'ircci*jiy uiiuixiu. r r

- OPERATIONS -

Read n r

v_/oiiipa.re n r n r (note 2)

- SEARCH OPERATIONS -

T iof n r (note Ij

Sc3.rcli n r (note 1)

- MODIFY OPF,R ATTONS -

A HHF.ntrv n11 1 XCClliW V CXjII 1 1 V n r MoHifvFntrv n

ivi o(J 1 1 y xvJU' IN n r

- ERRORS - Abandoned (note 4) r AbandonedFailed (note 4) r AttributeError (note 4) r NameError (note 4) r Referral (note 4) r (note 3) SecurityError (note 4) r ServiceError (note 4) r UpdateError (note 4) r

Notes for table 2

1. As performance of Search and List operations can consume significant resources, the

policies of some centralized DSAs may be that such operations wlU not be performed. For these cases, the reply to the requests for such operations would be ServiceError

with the "unwillingToPerform" Service Problem.

2. Reference Directory Documents, Part3, clause 9.3.6

3. Centralized DSAs would not generate referrals.

4. See EntrylnformationSelection under Common Data Types (table 3, Part 6).

42
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 1 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

- BIND and UNBIND -

DirectoryBind

DirectoryBindArgument M s

credentials O s simple O s name G s

validity 0 o

password G

cb

strong (J

r\U See Strong Authentication Protocol Conformance Profile for re- quirements when strong authentication is supported.

externalProcedure o o

vcroiuiio o s Supported value: vl988

DirectoryBindResult s G

credentials o G Shall be the same CHOICE as in DirectoryBindArgument.

simple 0 G

name s G

validity 0 O

password o 0

strong o O See Strong Authentication Protocol Conformance Profile for re- quirements when strong authentication is supported.

externalProcedure o 0

versions s O Supported value: vl988

Directory BindError s G

versions s O Supported value: vl988

ServiceProblem s G Supported value: unavailable SecurityProblem s G Supported values: inappropriateAuthentication, invalidCredentials

DirectoryUnbind The DirectoryUnbind has no arguments.

43
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 2 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

- OPERATIONS, ARGUMENTS AND RESULTS -

- READ OPERATIONS - Read

ReadArgument M s

object M s

selection O s See note 2 on page 49. CommonArguments O s ReadResult S G

entry S M

CommonResults S G

Compare

CompareArgument M b

object M s purported M S

CommonArguments O s CompareResult s G

DistinguishedName s G

matched s M

fromEntry s G

CommonResults s G

Abandon

AbandonArgument M s

invokeld M s AbandonResult s G

- SEARCH OPERATIONS -

List ListArgument M s

object M s CommonArguments O s

ListResult S G

listlnfo s G

DistinguishedName s G

subordinates s M

Rel. DistinguishedName s M For the case where subordinates is empty set, RDN is absent. aliasEntry s G

fromEntry s G

partialOutcomeQualifier s G

CommonResults s G

UncorrelatedListlnfo s G(0)

ListResult s G See note 1 on page 49 for additional information related to the DSA support classification.

44
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 3 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

Search

SearchArgument M s baseObject M s

subset O s

filter o s searchAliases o s

selection 0 s CommonArguments o s SearchResult s G

searchinfo s G

DistinguishedName s G

entries s M

partialOutcomeQualifier s G

CommonResults s G

uncorrelatedSearchinfo s G(0)

SearchResult s G

partialOutcomeQualifier s G

limit Problem s G

unexplored s G

unavailableCriticalExt s O

- MODIFY OPERATIONS - AddEntry

AddEntryArgument M S

object M S entry M s CommonArgument O S

AddEntryResult s G

RemoveEntry

RemoveEntryArgument M s

object M s CommonArguments 0 s RemoveEntryResult b G

ModifyEntry

ModifyEntryArgument M s

object M s changes M s At least one entry modification must be supported.

addAttribute O s removeAttribute O s addValues o s removeValues o s CommonArguments o s ModifyEntryResult s G

15-
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 4 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

ModifyRDN

ModifyRDNArgument M S

object M s newRDN M s deleteOldRDN O s O G

ModifyRDNResult s G

- ERRORS AND PARAMETERS -

Abandoned

AbandonFailed

problem s M

operation s M

AttributeError

object s M

problems s M Min. 1 error (See Directory Documents, Part 3, subclause 12.4.2.2) type s M

value s G

NameError

problem s M

matched s M

Referral

candidate s G

46
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 5 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

SecurityError

problem S M

ServiceError

problem S M

UpdateError

problem S M

- COMMON ARGUMENTS / RESULTS - CommonArguments

ServiceControls 0 S SecurityParameters o S See subclause 8.8. certification-path 0 S name o S time 0 s random o s

target o s

requestor 0 s OperationProgress o S(0)

nameResolutionPhase M S nextRDNToBeResolved o s aliasedRDNs 0 S(0)

extensions o S

iclentmer M s

critical 0 s item M s

CommonResults

SecurityParameters 0 G(0) See subclause 8.8. certification-path o G

name 0 G

time o G

random o G

target 0 G

performer o G(0)

aliasDereferenced 0 G

47
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 6 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

- COMMON DATA TYPES -

ServiceControls

options O s

priority 0 s timeLimit O s sizeLimit O s scopeOfReferral o s

EntrvInformationSelection

attributeTypes o s

allAttributes O s Must support at least one of the UJlOlCr/.

select O s infoTypes o s

Entrylnformation

DistinguishedName S M

fromEntry S G

SET OF CHOICE S G

AttributeType S G

Attribute S G

Filter Must support at least one of the CHOICE.

item o S

and o S

or o s not o s

Filterltem

equality o s

substrings o s type . ^' . '

M s

strings M s

initial 0 s Must support at least one of the CHOICE.

any 0 s

final o s greaterOrEqual 0 s lessOrEqual 0 s present 0 s approximateMatch o s

48
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 3 - DAP Protocol Support (Part 7 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

SecurityParameters O 0 See subclause 8.8. certification-path O S name O S

time O S

random O S

target 0 S

ContinuationReference

0 M

aliasedRDNs 0 G

OperationProgress 0 M

nameResolutionPhase 0 M

nextRDNToBeResolved O G

rdnsResolved 0 G

AccessPoint O M

AccessPoint

Name 0 M

PresentationAddress 0 M

pSelector 0 G

sSelector o G

tSelector o G

nAddress o M

Notes for table 3

1. As performance of Search and List operations can consume significant resources, the

policies of some centralized DBAs may be that such operations will not be performed. For these cases, the reply to the requests for such operations would be ServiceError

with the "unwiUingToPerform" Service Problem.

2. See EntrylnformationSelection information under Common Data Types (table 3, part

6)

49
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 4 - Directory System Service Support.

Operations and Errors

Support

Classification

Request XLCOL'^^lioC. Comments

— RTND DiriLJ anrl anQ TTNRTNn UlNlJliNU —

DSABind n (notes 1,2) r DSAUnbind n (notes 1,2) r

- OPERATIONS -

- CHAINED READ OPERATIONS - ChainedRead n (notes 1,2) r ChainedCompare n (notes 1,2) r n (note 1) r

- PHATNFD c;t?aPPH OPFP ATTON^: _

Vw* Hd1 1 1 C ±j 1 o t (note 1)

1*1 no. 1 ncu. oca.1 cn. n (note 1) T

- CHAINED XX S^1.X 1 MODIFY ITX \^ 1-J XX X OPERATIONS V-/ X X^ X vjTI. J. X X -

1

C^h^inf^H AHHEnfrv n (note 1) r ChainedRemoveEntry n (note 1) r ChainedEntry n (note 1) r ChainedModifyRDN n (note 1) r

- ERRORS - Abandoned n (note 1) r Abandonfailed n (note 1) r AttributeError n (note 1) r NameError n (note 1) r DSARefFeral n (note 1) r SecurityError n (note 1) r SeviceError n (note 1) r UpdateError n (note 1) r

Notes for table 4

1. Necessary when supporting the chained mode of interaction.

2. Some of these operations may be necessary to support distributed authentication. This requirement is distinct from support for chained mode of interaction.

50
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 1 of 9)

Protocol Element

Support

Classification

Request Response Comments

- BIND and UNBIND -

DSABind

DirectoryBindArgument M s

credentials G s simple G s name G s

validity O o

password G s

strong O o Sec Strong Authentication Protocol Conformance Profile

for requirements when strong authentication is supported.

externalProcedure r\\J

versions G s Supported value: vl988

JJoArJmarCesult S G

credentials c

Shall be the same CHOICE as in DirectoryBindArgument.

simple S G

name S G

validity o 0

password S G

strong 0 0 See Strong Authentication Protocol Conformance Profile for requirements when strong authentication is supported.

externalProcedure 0 0

versions S G Supported value: vl988

DirectoryBindError s G

versions s G Supported value: vl988

ServiceProblem s G Supported values: busy and unavailable. Security Problem s G Supported values: inappropriateAuthentication, invalid- Credentials.

DSAUnbind The DSAUnbind has no arguments.

i

51

r

1.1
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 2 of 9)

Protocol Element

Support

Classification

Request Response Comments

- OPERATIC)NS ARG JMENTS AND RESULTS -

- CHAINED READ OPERATIONS - ChainedRead

ChainingArgument M s ReadArgument M s

object M s

selection G s CommonArguments G s

ChainingResult S M

ReadResult S M

entry S M

CommonResults * S G

ChainedCompare

ChainingArgument M S

CompareArgument M S object M S purported M s CommonArguments ^ G s

ChainingResult S M

CompareResult S M

DistinguishedName S G

matched s S M

fromEntry S G

CommonResults s G

ChainedAbandon

AbandonArgument M S

invokeld M S

AbandonResult s G

52
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 3 of 9)

Protocol Element

Support

Classification

Request Response Comments

- OPERATIONS, ARGUMENTS AND RESULTS -

CnainedList

ChainingArguments M b

ListArgument M S

object M S

CommonArguments G s

ChainingResuIts S M

ListResult S M

listlnio c DistinguishedName co

n. subordinates co MiVl Rel. DistmguisnedN ame c

JVi T J. aliasEntry

/~\ \J

iromEntry b

partialOutcomeQualifier s G

CommonResults s G

uncorrelatedListlnfo co ex

T * i-T) li- ListKesuit cb

/-^ \J

C/nainedSearcn

SearchArgument M CO

baseObject M b

sugset

r \ G b

filter G S

searchAliases G S

selection co CommonArguments /-"I (J cb

s M

SearchResult S M

Searchinfo s M

DistinguishedName s G

entries s M

partialOutcomeQualifier s G

CommonResults s G

uncorrelatedSearchinfo s G

SearchResult s G

partialOutcomeQualifier s G

limitProblem s G

unexplored s G

unavailableCriticalExt s G

53
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 4 of 9)

Protocol Element

Support

Classification

Request Response Comments

- CHAINED MODIFY OPERATIONS - ChainedAddEntry

ChainingArguments M S

AddEntryArgument M S

object MIVi entry M s CommonArguments G s

ChainingResults S M

A HH En trvResiilts S M

ChainedRemoveEntry

ChainingArguments ! M S

RemoveEntryArgument M S

object ; M S

CommonArguments G S

i ChainingResults 1 S M

RemoveEntryResult \ s M

ChainedModifyEntry

ChainingArguments M s ModifyEntryArgument M S

object M S

changes M S

addAttribute G S

removeAttribute G S

addValues G S

removeValues G s CommonArguments Q

ChainingResults S M

ModifyEntryResult S M

ChainedModifyRDN

ChainingArguments M s ModifyRDNArgument M s

object M S

newRDN M s deleteOldRDN G s CommonArguments G S

ChainingResults S M

ModifyRDNResult S M

54
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 5 of 9)

Protocol Element

Support

Classification

Request Response Comments

- ERRORS and PARAMETERS - Abandoned

AbandonFailed

problem S M

operation S M

AttributeError Min. 1 error (see Directory Documents, part 3, subclause 12.4.2.2) object S M

problems S M

problem S M

type S M

value s G

NameError

problem s M

matched s M

DSARefferal

ContinuationReference s M

contextPrefix s G

SecurityError

problem s M

r

55

I
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 6 of 9)

Protocol Element

Support

Classification

Request Response Comments

ServiceError S G For Directory operations

problem S M

UpdateError S G

problem S M

- COMMON ARGUMENTS / RESULTS -

CommonArguments

ServiceControls G S SecurityParameters O S see subclause 8.8. requestor G s OperationProgress G s nameResolutionPhase M s nextRDNToBeResolved G s aliasedRDNs G s

extensions G s

identifier M s

critical G s item M s

CommonResults

SecurityParameters S O See subclause 8.8. requestor S G

aliasDereferenced S G

56
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 7 of 9)

Protocol Element

Support

Classification

Request Response Comments

- COMMON DATA TYPES -

ServiceControls

options G S

priority G S timeLimit G S

sizeLimit G s scopeOfReferral G s

LntrylniormationSeiection

attributeTypes G s

allAttributes G s

select G s infoTypes G s

bntrylniormation

DistinguishedName S M

fromEntry S G

bEi CHOICE S G

Attribute iype S G

AttriDUte S G

r liter item G s and G S

or G s not G s

h ilterltem

equality G s

substrings G s type G s

strings G s

initial G s any G s

final G s greaterOrEqual G s lessOrEqual G s

present G s approximateMatch G s

57
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 8 of 9)

Protocol Element

Support

Classification

Request Response Comments

- COMMOI^ DATA TYPES FOR DISTRIBUTED OPERATION -

ChainingArguments

originator vjr c targetObject G S

cinf^TPi t inn ProtTrp<^<; G s nameResolutionPhase M s nextRDNToBeResolved G s tracelnformation M s

aliasDereferenced G s aliasedRDNs G s returnCrossRefs G s See Directory Documents, Part 4, subclause 10.4.1 referenceType G s Domainlnfo 0 o

timeLimit G s SecurityParameters 0 s See note 1 (page 59) regarding the support classifica- tion for Request. Also see subclause 8.8

ChainingResults

Info 0 0

crossReferences s G

SecurityParameters s 0 See note 1 (page 59) regarding the support classifica- tion for Response. Also see subclause 8.8

CrossReference

contextPrefix s M See Directory Documents, Part 4, subclause 12.4.2.2 accessPoint M

Tracelnformation

Traceltem M s

Traceltem

dsa M S

targetObject G S operationProgress M S nameResolutionPhase M s nextRDNToBeResolved G s

58
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 5 - DSP Protocol Support (Part 9 of 9)

Protocol Element

Support

Classification

Request Response Comments

ContinuationReference

targetObject S M

aliasedRDNs S G

operationProgress S M

nameResolutionPhase S M

next RDNToBeResolved S G

rdnsResolved S G

referenceType S G

AccessPoint S M

AccessPoint

Name s M

PresentationAddress S M

pSelector S G

sSelector S G

tSelector s G

nAddress s M

Notes for table 5

1. The support classification is G when supporting the chained mode of interaction.

2. Some of these operations may be necessary to support distributed authentication. This requirement is distinct from support for chained mode of interaction.

59
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 6 - DAP Support for Digital Signature Protocol Conformance Profile.

Protocol Element

Support

Classification

DUA DSA Comments

- COMMON ARGUMENTS / RESULTS - CommonArguments

SecurityParameters

certification-path G S

name G S

time G S

random G S

target G S

requestor G S

CommonResults

SecurityParameters S G

performer S G

Table 7 - DSP Support for Digital Signature Protocol Conformance Profile.

Protocol Element

Support

Classification

DUA DSA Comments

- COMMON ARGUMENTS / RESULTS - CommonArguments

SecurityParameters

certification-path G S name G S

time G s random G s

target G s

requestor G s

CommonResults

SecurityParameters G s performer O G

60
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 8 - DAP Support for Strong Authentication Protocol Conformance Profile.

Protocol ililement

Support

Classification

DUA DSA Comments

• DirectoryBindArgument M S

credentials G s simple G s name G s

validity G s password G s strong

certification-path G s bind-token G s externalProcedure O o

versions O s

DirectoryBindResult S G

credentials S G

simple S G

name S G

validity S G

password S G

strong S G

certification-path s G

bind-token S G

externalProcedure 0 0

versions S O

61
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 9 - DSP Support for Strong Authentication Protocol Conformance Profile.

Protocol Element

Support

Classification

DUA DSA Comments

DirectoryBindArgument M S

credentials G s simple G s name G s

validity G s password G s

strong

certification-path G s bind-token G s externalProcedure O 0

versions 0 s

DirectoryBindResult S G

credentials S G

simple S G

name S G

validity S G

password S G

strong S G

certification-path S G

bind-token S G

externalProcedure 0 O

versions s 0

62
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 10 - Error Symptoms (Part 1 of 3) Symptom Descripton

EJlCCESS The initiator has insufficient access rights to carry out this operation.

E_ADMIN_LIMIT The Directory has reached some limit set by an administrative authority,

and no partial results are available to return to the user. EJ^LIAS_DEREF One of three situations exists:

1. An alias has been encountered while a previous alias was being deref- erenced, or

2. a name contained an alias plus one or more additional RDNs when

the dontDereferenceAliases service control was being used, or

3. the name, supplied in an operation that precludes alias dereferencing,

i^vjxi tdiiicu dii diictb pxuo one or iiiorc duciitioncii xxLyiib.

E-ALIAS-LOOP During a whole-subtree search operation, an alias has been encountered

which would lead to a loop (i.e., the alias points to an entry which is superior to entries which have already been evaluated in earring out the

search).

E-ALIAS-PROBLEM An alias has been encountered, but the entry to which it points does not

exist. E_A.RG_BOUNDS The argument does not comply with pragmatic constraints (defined locally or by functional standards).

E^RGJSYNTAX An operation argument either has incorrect ASN.l encoding or it has correct ASN.l encoding, but does not comply to the syntax as defined in the

Directory Documents. Note:

1. Within BindArgument, additional elements are permitted, to allow

future extensions, and do not create an error situation.

2. Errors within attribute values are not included in this codification

(see E_ATT_SYNTAX).

J? A "D IT'T/^T

til J\ixyj_\ lUL An operation argument has correct syntax, but it violates additional rules and constraints levied by the Directory Documents (e.g., use of a Priority

int^^p^^r vfllnp who^ip mepninp" is unnennedi Note*

1. Within a Relative Distinguished Name, having two AVAs of the same

attribute type is an error which is covered by E_DN, and not by

E_ARG-VIOL.

2. Errors within attribute values are not included in this codification

(see E_ATT^YNTAX).

Ej^TT-BOUNDS An attribute value does not comply with bounds specified either by the

Directory Documents or by functional standards.

e_att-Or_valuej:xists Within an entry, an attribute or attribute value already exists, causing an

error situation.

63
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 10 - Error Symptoms (Part 2 of 3)

Symptom Descripton

E_ATTJSYNTAX An attribute value either has incorrect ASN.l encoding or it has correct ASN.l encoding but does not comply witht the ASN.l encoding defined by

the attribute type.

T? ATT VA T TTP An attribute value, although of correct ASN.l encoding, and conformant

with the syntax defined for the attribute type, is not compliant with other

rules (e.g., a non-ISO 3166 country name encoding).

E_ACCESS The initiator has insufficient access rights to carry out this operation.

The authentication offered does not match that required by the object being

authenticated.

E_BUSY Tne r^S A 19 unable to nannle tni*? nr»f*ratir»Ti at. tni^ t.Tme (but. it tti^v ne able to do so after a short while).

E_CHAIN The DSA needs to use chaining to carry out this operation, but is prohibited

from doing so by Service Controls.

E.CREDENTIALS The credentials offered do not match those of the object with which au- thentication is taking place.

EJDBE An inconsistency has been detected in the DSA's data base, which may be

localized to a particular entry or set of entries. An attempt was made via an add operation to place an entry in the DIB

whose object class would violate the DIT structure rules. A DN contains an RDN with two AVAs of the same attribute type.

A DSA to which chaining is taking place is unable to respond.

"P VMTT3V TTYTCTC An entry of the given name already exists, causing an error. E_EXTENSION A DSA was unable to satisfy a request because one or more critical exten- sions were not available. EJLLEGAL-ROOT-OBJ Root's DN has been supplied as the object of a Read, Compare, AddEntry,

RemoveEntry, ModifyEntry, ModifyRDN, or as the Base Object of a single level search. EJLLEGAL.ROOT.VAL Root's DN has been supplied illegally as an attribute value (e.g., as an Aliased Object Name).

E.LOOP A loop has been detected in the knowledge information within the system.

E-MATCH The attribute specified does not support the required matching capability.

E_MISSING_AVA When creating, or after modifying, an entry, an AVA in the entry's RDN

is not represented within the entry's set of attributes.

EJvlISSING.OBJECT.CLASS When creating an entry, the entry does not possess an object class. E_MULTI_DSA The operation is an update operation which affects other DSAs.

E_NAMING-VIOLATION The name of the new or modified entry is incompatible with its object class. E_NON_LEAF.OPERATION The operation being attempted is illegal except on a leaf. E_NONNAMING_ATTRIBUTE In either an add or ModifyRDN operation, an attribute is included in the

last RDN that is not a valid naming attribute according to the DIT struc- ture rules.

64
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 10 - Error Symptoms (Part 3 of 3)

Symptom Descriptor!

E-NOT_SINGLE_VALUED An attribute, registered as single-valued, has been found with more than one value. E_NO^UCH_ATT The specified attribute has not been found.

E_NO_SUCH_OBJECT Ihe specified entry has not been found.

E_NO^UCH_VALUE The specified attribute value has not been found.

E_OBJECT_CLASS-MOD An (illegal) attempt has been made to alter or remove an object class attribute.

E_OBJECT_CLASS.VIOL There is a schema violation (e.g., missing mandatory attribute, or nonallowed attribute present).

XA X^ X^ X^ X^ X^ T *~«x^ E_REFERENCE An erroneous reference has been detected (e.g., DSA cannot handle name

even as far as the number of RDNs that have already been resolved).

E_SCOPE No referrals were available within the requested scope. E_SYSTEM_PERM A serious and permanent software or system error has been detected which

prevents completion of the operation.

E-SYSTEM_TEMP A serious but temporary software or system error has been detected which

prevents completion of the operation.

E-TIMEOUT The operation has not completed within the allotted time.

E.UNABLE_TO.COMPLETE The DSA is unable to complete this operation, or others like it (this applies

particularly to search).

E.UNABLE.TOJROCEED The DSA cannot satisfy the operation after receiving it on the basis of a

valid non-specific subordinate reference. E_UNDEFINED.ATT An unregistered attribute has been encountered.

E.UNSUPPORTED.OC The object class of the entry is not supported as a valid object class for entries within this DSA.

E.VERSION An unexpected version has been found in Bind.

E_ZERO_VALUES An attribute has been found (e.g., as a result of a modify-entry operation)

with no values.

65
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 11 - Error Situations.

Situation Description

BIND-LOCAL A bind is being attempted; either the entry named is (or should be)

within a local naming context, or name resolution is being carried out on the part of the name that is known locally.

rilJN U-Kr/MU 1 ti A bind is being attempted, and the entry named is not within a local naming context; remote validation of credentials is being

carried out. NAME-RESOLUTION Name resolution is being carried out. ADD-ENTRY-NAME-RESOLUTION During an add entry operation, name resolution has been successfully accomplished on the superior object, and is not being carried out to determine whether the new entry already exists. ADD-ENTRY The entry is being generated.

MODIFY-ENTRY The entry is being modified.

MODIFY-RDN The RDN is being modified.

REMOVE-ENTRY The entry is being removed.

READ The entry is being read. COMPARE A Compare operation is being carried out on the entry.

LIST A List operation is being carried out on the entry.

SEARCH-FILTER A Search operation is being carried out; the filter is being evaluated

or acted upon.

SEARCH-ENTRY A Search operation is being carried out; the required entry infor- mation is being evaluated or acted upon.

ABANDON An Abandon operation is being carried out. TRACE-EVALUATION The trace element is being evaluated for loops.

66
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 12 - Notation Used to Describe Error Actions.

Error Action

Notation Meaning

Rej A reject operation is generated, with problem mistyped-argument.

Ah{< qualifier>) Abandon Failed Error is generated. The qualifier may take on values codified as follows: CA — Cannot abandon

TL — Too late NSO — No such operation

A[< qualifier>) Attribute Error is generated. The qualifier may take on values codified as foUows: AVE - Attribute or value already exists IAS — Invalid attribute syntax

NSA - No such attribute

CV - Constraint violation IM — Inappropriate matching

UAT - Undefined attribute type

N(< qualifier>) NameError is generated. The qualifier may take on values codified as foUows: ADP — Alias dereferencing problem

IAS — Invalid attribute syntax

AP — Alias problem

NSO - No such object

SC{< qualifier>) Security Error is generated. The qualifier may take on values codified as follows;

lA — Inappropriate authentication

IC — Invalid credentials NI - No information

lAR — Insufficient access rights IS - Invalid signature

PR - Protection required

S{<qualifier>) Service Error is generated. The qualifier may take on values codified as foUows:

ALE - Administrative limit exceeded B Busy

CR - Chaining required DE - Dit Error IR - Invalid reference LD - Loop detected DOS - Out of Scope TLE - Time limit exceeded

UA - Unavailable UAP - Unable to proceed

UCE - Unavailable critical extension UWP - Unwilling to perform

V[< qualifier>) Update Error is generated. The qualifier may take on values codified as follows: AMD - Affects multiple DSA

NAN — Not allowed on non-leaf NV - Naming violation OMP - Object class modification prohibited

"ST"

EAE — Entry already exist NAR - Not allowed on RDN

OCV - Object class violation
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 13 - Error Actions (Part 1 of 6)

Situation (See Table 11)

Symptom Bind- Add-Entry-

(^oee laDie iu

j

Bind- Remote- Name- NameT .1 L/ocal Resolution Resolution Resolution A J J T7> J. Add-il/ntry Modiiy-iiyntry

SC(IAR)(14) SC(IAR)(14) SC(IAK)(14) SC(IAR)(14)

XT A'PVA/TTXT T TIV^fTT^ iii_AiJMlJN _blMi i

C / T T A \ b( U A) O / T T A ^ b(UA) S( ALE) S(ALE) S(ALE) S(ALE)

T? A T T A C rM^Dim^ Hi-ALilAb-UlljKlljr S(IC) S(IC) XT/ A T^T^ \ N(ADP)

17 ATTAC T r\r\'D

U* ATTAC DT5r^DTt?A/f 111 _A. Li iAb _r KUrJ Li Cj M S(IC) S(IC) 1n(AF)

ni _Ar\ Lj _t> U IN Ub (8) (7) b(U Wl-')(12) b( U Wr)(12j b(u WJr j(12) b^U WF

TT A T> CVMT'A'V" lli_aK(j_b I IN i AA (^\ (^ \ U) rtej rtej rtej rtej

(1) (1) Rej Rej Rej Rej

Ej^TT_BOUNDS SC(IC) (7) N(IAS) . N(IAS) A(CV) A(CV)

E_ATT.OR.VALUE_EXISTS A(AVE) A(AVE)

E-ATT.SYNTAX SC(IC) (7) N(IAS) N(IAS) A(IAS) A(IAS)

E,J\.TT.VALUE SC(IC) (7) N(IAS) N(IAS) A(IAS) A(IAS)

E_AUTHENTICATION SC(IA) SC(IA)

E-BUSY S(UA) S(UA) S(B) S(B) S(B) S(B)

E-CHAIN S(CR)

E-CREDENTIALS SC(IC) SC(IC)

E_DBE S(UA) S(UA) S(DE) S(DE) S(DE) S(DE)

EJDIT.STRUCTURE U(NV)

E_DN SC(IC) SC(IC) N(NSO) C(NV)

EJDSA S(UA) S(UA) S(UA)

E_ENTRY.EXISTS U(EAE)

E_EXTENSION S(UWP) S(UCE) S(UCE) S(UCE)

EJLLEGALJIOOT-OBJ SC(IC) SC(IC) N(NSO) N(NSO) N(NSO)

EJLLEGAL_ROOT_VAL SC(IC) (7) N(IAS) N(IAS) A(IAS) A(IAS)

E_LOOP S(UA) S(LD)

68
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 13 - Error Actions (Part 2 of 6)

Situation (See Table 11)

Symptom Bind- Add-Entry-

(See Table 10) Bind- Remote- Name- NameLocal Resolution Resolution Resolution Add-Entry Modify-Entry

EJvIATCH SC(IC) SC(IC) A(IM) A(IM) A(IM)

EJVIISSING-AVA U(NAR) U(NAR)

E_MISSING-OBJECT.CLASS U(OCV) U(OMP)

E-MULTI_DSA S(AMD)

E-NAMING-VIOLATION U(NV)

EJ^ON-LEAF.OPERATION

E-NONNAMING.ATTRIBUTE U(NV)

E_NOT-SINGLE.VALUED A(CV) A(CV)

E_NO-SUCH-ATT A(NSA)

E-NO-SUCH.OBJECT SC(IC) SC(IC) N(NSO)

E_NO.SUCH-VALUE A(NSA)

E-OBJECT-CLASS^MOD U(OMP)

E-OBJECT-CLASS-VIOL U(OCV) U(OCV)

E-REFERENCE S(UA) S(IR)

E_SCOPE S(OOS)

E-SYSTEM-PERM S(UA) S(UWP) S(UWP) S(UWP) S(UWP)

E.SYSTEM.TEMP S(UA) S(UA) S(UA) S(UA) S(UA)

E.TIMEOUT S(UA) (9) S(TLE) S(TLE) S(TLE) S(TLE)

E.UNABLE_TO.COMPLETE

E.UNABLE.TOJ>ROCEED (2) (2) E.UNDEFINED.ATT SC(IC) (3) U(NV) A(UAT) A(UAT)

E.UNSUPPORTED-OC U(OCV)

E-VERSION S(UA)

E-ZERO-VALUES A(CV) A(CV)

69
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 13 - Error Actions (Part 3 of 6)

(See Table 10)

Situation (See Table 11)

RDN

RemoveEntry Read CompareTrace

Evaluation EJ\.CCESS SC(IAR)(14) SC(IAR)(14) SC(IAR)(14) SC(IAR)(14)

E_ADMIN.LIMIT S(ALE) S(ALE) S(ALE)

E_A.LIAS-DEREF

EJ\.LIAS-LOOP

E_A.LIAS_PROBLEM

E_A.RG30UNDS S(UWP)(12) S(UWP)(12) S(UWP)(12)

E_A.RG^YNTAX Rej Rej Rej Rej Rej

EJIlRG_VIOL Rej Rej Rej Rej Rej

EJ1lTT_BOUNDS N(IAS) A(CV) (7) e^tt.or.value.exists

EJ\.TT.SYNTAX N(IAS) A(IAS) (7) EJ\.TT.VALUE N(IAS) A(IAS) (7) E.AUTHENTICATION

E3USY S(B) S(B) S(B) S(B)

E.CHAIN

E-CREDENTIALS

EJDBE S(DE) S(DE) S(DE) S(DE)

EJ3IT.STRUCTURE

EJ)N A(CV) A(IAS)

EJDSA

E.ENTRY.EXISTS U(EAE)

EJIXTENSION S(UCE) S(UCE) S(UCE) S(UCE)

EJLLEGALJIOOT.OBJ N(NSO) N(NSO) N(NSO) N(NSO)

EJLLEGALJIOOT.VAL N(IAS) A(IAS) (7) EXOOP

70
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 13 - Error Actions (Part 4 of 6)

Symptom

I Dec xauic iu 1

Situation (See Table 11)

ModifyrtUlN

RemoveEntry Kead Compare

Trace- Evaluation

E MATCH A ^TA/TX A(IM) in

EJMISSING^AVA

E_MISSING OBJECT CLASS

EJVIULTI DSA CI A AAn^ c/" A ^^^^^ EJ^IAMING VIOLATION U^lN V ) E NON LEAF OPERATION TI^N A N^ E_NONNAMING.ATTRIBUTE

E-NOT-SINGLE.VALUED A(CV)

E_NO_SUCH.ATT A(NSA)(4) A(NSA)(4)

EJSIO_SUCH_OBJECT

E_NO-SUCH_VALUB

E-OBJECT-CLASS-MOD

E-OBJECT-CLASS-VIOL U(OCV)

E-REFERENCE

E-SCOPE

E-SYSTEM-PERM S(UWP) S(UWP) S(UWP) S(UWP) S(UWP)

E^YSTEM.TEMP S(UA) S(UA) S(UA) S(UA) S(UA)

E.TIMEOUT S(TLE) S(TLE) S(TLE) S(TLE)

E.UNABLE.TO.COMPLETE

E.UNABLE.TO.PROCEED

E.UNDEFINED_ATT A(UAT) A(NSA)(4) A(NSA) (7) E-UNSUPPORTED-OC

E_VERSION

E^ERO-VALUES (11)

71
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 13 - Error Actions (Part 5 of 6)

(<i(.f. Table 1 0"!

Situation (See Table 11)

T icf

1 L 11 UCZ t

oc&rcri De circii

E_ACCESS SC(IAR)(14) SCfIAR'>Cl4"l SC(IAR)(14)

E_ADMIN.LIMIT SCALEVlS"* t Ji- i—J I—J J\ A. I Sf ALEVlSt

EjVLIAS_DEREF \^ 1 E_ALIAS_LOOP

E_ALIAS_PROBLEM

E-A.RG_BOUNDS

E_A.RG^YNTAX Rej Rei Rei Rej

E-ARG-VIOL Rej Rej Rej

E_A.TT30UNDS A(CV)

E-ATT.OR.VALUE-EXISTS

Ej^.TT_SYNTAX A(IAS)

E_ATT_VALUE A(IAS)

e_a.uthentication

E_BUSY S(B) S(B) S(B)

E-CHAIN

E-CREDENTIALS

EJDBE S(DE) S(DE) S(DE)

EJDIT.STRUCTURE

EJDN A(IAS)

EJDSA (5) EJINTRY.EXISTS

E_EXTENSION S(UCE)(13) S(UCE)(13) S(UCE)(13)

EJLLEGALJlOOT_OBJ (10) EJLLEGAL-ROOT.VAL A(IAS)

E-LOOP (5)

72
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 13 - Error Actions (Part 6 of 6)

Symptom

(See Table 10)

Situation (See Table 11)

List

(Filter)

Search

(Filter)

Search Entry Abandon

E3^ATCH A(IM)

EJV[ISSING-AVA

EJVIISSING_OBJECT-CLASS

E_MULTI.DSA

E_NAMING-VIOLATION

E_NON-LEAF_OPERATION

E_NONNAMING.ATTRIBUTE

E_NOT.SINGLE.VALUED

E_NO_SUCH.ATT

E_NO_SUCH_OBJECT

E_NO.SUCH.VALUE

E.OBJECT_CLASS-MOD

E.OBJECT_CLASS.VIOL

E_REFERENCE

EJSCOPE

EJSYSTEM_PERM S(UWP) S(UWP) S(UWP) Ab(CA)

E^YSTEM.TEMP S(UA) S(UA) S(UA) Ab(CA)

E.TIMEOUT S(TLE)(13) S(TLE)(13) S(TLE)(13)

E.UNABLE.TO.COMPLETE S(B) S(B) S(B) Ab(CA)

E.UNABLE.TO.PROCEED

E.UNDEFINED.ATT (6) (6) E_UNSUPPORTED_OC

E-VERSION

EJZERO-VALUES

73
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Notes for table 13

1. Use A-U-ABORT. Note, however, that extra elements are permitted here.

2. An "unable-to-proceed" error becomes SC(IC) for bind and N(NSO) for operations

if no DSA contacted can located the object.

3. An undefined attributed encountered during name resolution is only an error - N(NSO) - if the entry is identified as local. See cilso Note 10 below.

4. The A(NSA) condition is reserved in the case of "read" for the situation when no

attribute of the specific list provided can be returned (for reasons that include security

errors).

5. Any failure to propagate a search causes abandonment of that part of the search.

6. Undefined attributes are regarded as not matched or found, but cause no errors in search.

7. This error, if detected, should be ignored; processing continues.

8. This error would occur as a result of a bind argument with a name containing too many RDNs for the DSA. Use either S(UA) or S(IC).

9. DSAs should use the time-limit service control with local timeout to limit the remote

validation of credentials; if the operation fails as a result, S(UA) is used.

10. For a single-entry search, N(NSO) may be used.

11. Either the whole attribute should be removed, or the deleteOldRDNflag should be

ignored.

12. Wherever S(UWP) appears in the above tables beside E.ARG_BOUNDS, a ROSE

"Rej" is also admissible.

13. The error is returned when there are no partial results, otherwise a partialOutcomeQualifier with the appropriate limitProblem is returned (cf Directory Documents, Part

3, item g of clause 12.8.2, and Part 3, clause 10.1.3.3.1).

14. In every case where a security error occurs, except in bind, SC(NI) may be used

in place of the specified problem, to support a Security Policy which states that no

information on the problem may be divulged. In the case of the bind, SC(NI) is not

available.

74
PART 11 - DIRECTORY SERVICES PROTOCOLS December 1990 (Stable)

Table 14 - Simple Credential Fields and Protected Simple Authentication

SimpleCredential Field

Equivalent Notation

in Directory Documents,

Part 8, figure 2 name A

timel ^1

time2

random 1

random2

password protected2

75
f\I!J
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 12 - Security

Output from the March 1991 NIST Workshop for

Implementors of OSI

t

SIG Chair: Dr. James Galvin

SIG Editor: Maj Doug Naegele, USAF

i
PART 12 - SECURITY March 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Security Special Interest Group

(SECSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI). See Procedures Manual for Woprkshop charter.

Text in this part has been approved by the Pieanary of the above-mentioned Workshop. This part replaces

the previously existing chapter on this subject. There is significant technical change from this text as

previously given.

Future changes and additions to this version of 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 12 - SECURITY March 1991 (Stable)

Table of Contents

Part 12 - Security

0 Introduction

1 Scope

2 Normative References . . .

3 Definitions

4 Symbols and Abbreviations

5 Architectures 2

5.1 Introduction 2

5.2 General OIW Application Environments 2

5.3 Security Profiles 2

5.4 Guidelines for OIW Application Profile Development 2

6 Key Management 2

7 Lower Layers Security 2

8 Upper Layers Security 2

9 Message Handling System (MHS) Security 2

10 Directory Services Security 2

11 Network Management Security 2

11.1 Threats 2

11.2 Security Services 3

11.3 Security Mechanisms 3

12 Security Algorithms 3

12.1 Integrity 3

12.1.1 MD4 Hash 3

12.1.2 SQ-Mod-N 3

12.1.3 DES MAC 3

12.2 Authentication 3

12.2.1 MD4 with RSA Signature 3

12.2.2 EIGamal 3

12.2.2.1 Background 3

12.2.2.2 Digital Signature 4

12.2.2.3 Verification 5

12.2.2.4 Known Constraints on Parameters 5

iii
PART 12 - SECURITY March 1991 (Stable) ^

12.2.2.5 Note On subjectPublicKey 6

12.2.2.6 Note On the ENCRYPTED MACRO 7

12.2.3 Fl PS 112 Password Encryption 7

12.2.4 DES MAC 7

12.3 Confidentiality 7

12.3.1 DES in CBC Mode Encryption 7

12.4 ASN.1 Definitions 7

12.4.1 General Security Algorithms 7

12.4.2 ASN.1 for Directory Services Strong Authentication Algorithms 7

Annex A (normative)

ISPICS Requirements List 9

Annex B (normative)

Errata 10

Annex C (informative)

Bibliography 11

IV
PART 12 - SECURITY March 1991 (Stable)

List of Figures

Figure 1 - ASN.1 for directory services strong authentication 8

V
PART 12 - SECURITY

Table 1 - SI A part 12 changes

List of Tables

March 1991 (Stable) I

10

vi
Part 12 - Security

iditOr'$ Nolo - Previous material in thts part h9$ been t^eleted ^nd i$ no longer 9pplH<M^i

0 Introduction

1 Scope

2 Normative References

[1] ISO/IEC 9594-8 (CCITT X.509 Recommendation)//7formaf/on Technology - Open Systems

Interconnection - The Directory - Part 8: Authentication Framework.

[2] ISO 8649: 1988/DAD 1 Service Definition for the Association Control Sen/ice Element, Addendum

1: Peer-Entity Authentication During Association Establishment.

[3] ISO 8650: 1988/DAD 1 Protocol Specification for the Association Control Sen/ice Element,

Addendum 1: Peer-Entity Authentication During Association Establishment.

[4] ISO/IEC 9594-3 (CCITT X.511 Recommendation) Information Technology - Open Systems

Interconnection - The Directory - Part 3: Abstract Sen/ice Definition.

[5] ISO 10021-4 (CCITT X.411 Recommendation) Information Processing Systems - Text Communication - MOT/S - Message Transfer System : Abstract Sen/ice Definition and Procedures.

[6] ISO 7498-2 Information Processing Systems - Open Systems Interconnection Reference Model - Part 2: Security Architecture, February 1989.

3 Definitions

4 Symbols and Abbreviations

1
PART 12 - SECURITY March 1991 (Stable)

5 Architectures

5.1 Introduction

5.2 General OIW Application Environments

5.3 Security Profiles

5.4 Guidelines for OIW Application Profile Development

6 Key Management

7 Lower Layers Security

8 Upper Layers Security

9 Message Handling System (MHS) Security

All current MHS security relevant text appears in Part 8, clause 11.

10 Directory Services Security

11 Network Management Security

11.1 Threats
PART 12 - SECURITY

11.2 Security Services

March 1991 (Stable)

11.3 Security Mechanisms

12 Security Aigoritiims

12.1 Integrity

12.1.1 MD4Hash

12.1.2 SQ-Mod-N

! Recent research regarding the square-mod-n one-way hash function described in Annex D of the Directory

j Documents, ISO 9594 - Part 8, has revealed that the function is not secure. Its use, therefore, is

! discouraged.

; 12.1.3 DES MAC

12.2 Authentication

12.2.1 MD4 with RSA Signature

NOTE - This text was moved from Part 11, dause 14,

I 12.2.2 EIGamal

I The Information in this subclause includes a tutorial description of the EIGamal scheme for digital signature

j using the notation defined in the Directory Documents, ISO 9594 - Part 8. It is intended that much of the

j tutorial information provided in this subclause will be moved to the security agreements sometime in the

I future.

j 12.2.2.1 Background

I The EIGamal digital signature scheme is based on earlier work done by Diffie and Hellman [DIFF76] in which

it was suggested that a likely candidate for a one-way function is the discrete exponential function

/(x)«a*(modp) (1)
PART 12 - SECURITY March 1991 (Stable)

where x is an integer between 1 and p-1 inclusive, wliere p is a very large prime number, and where o is an integer such that 1<a>p and {a mod p, a mod p, mod p} is equal to the set {1, 2 p-1}. In algebraic terminology, such an a is called a primitive element. References on the topic of primitive roots and

elements are [McCI79] and [PATT87].

Now, in the real number system, if y = a, then by definition of the logarithm we can solve for x using x =

'oga(/)- The same idea extends to solving eq (1) for x so that inverting /(x) requires calculating discrete

logaritfims. The reason Diffie and Hellman suspected eq (1) is one-way is that for suitable p, it is computationally difficult to invert According to the current state of the art, computing discrete logs for suitable p has been found to require a number of operations roughly equivalent to

where b is the number of bits in p, and c is estimated at c = .69 according to [ODLY]. This can be

compared to only about 2 logg p multiplications for discrete exponentiation. If in fact the best known

algorithm for computing discrete logs is near optimal then Expression (2)is a good measure of the problem's

complexity (for a properly chosen p) and the discrete exponential function has all the qualities of a one-way

function as described by Diffie and Hellman.

12.2.2.2 Digital Signature

Private Key: denotes the private key for user X. X^ is a randomly chosen integer which user X keeps

secret.

Public Key: X^ denotes the public key for user X and is calculated using the corresponding private key such

that

a) p is a prime satisfying the requirements listed in 12.2.2.4.

b) a is a primitive element mod p.

c) Note that p and a could be used globally, but because they should be easily changeable (see

12.2.2.4 for information about why these two parameters should be easily changeable) it would

probably be preferable for each user to choose his/her own p and a. If users choose their own,

then p and o must be made available to the recipient for use in the signature verification process.

Signing Procedure: Suppose user>4 wants to sign a message intended for recipient B. The basic idea is to compute a two part signature (r, s) for the message m such that

expi/cttnb)

(3)

where

aM'n)=(Ap)V*(modp) (4)

where /? is a one-way hash function.

Compute the signature (r, s) as follows.

4
PART 12 - SECURITY March 1991 (Stable)

a) Choose a random number k, uniformly between 0 and p-1 such that k and p-1 have no common

divisor except 1 (i.e., gcd(/(,p-1) = 1).

b) Compute r such that

/^a*(modp) (5)

c) Use r to solve for the corresponding s as follows.

1) rewrite eq (4) using eq (5) and the definition of the public key to get

a/'(m).aWr«/«(modp) (6)

Combining exponents, get

«/K/»«.„W^*'«(modp) (7)

eq (7) implies that

/j(m)=(>4^/'+A^s(modp-1) (8)

Note that eq (8) has a single solution for s because k was chosen such that gcd(/(,p-1) = 1

See [SIER88] for supporting theorem.

2) now solve for s and get

s^l{him)-{A^i)imodp-1) (9)

I where / is computed such that /( * / = 1 (mod p-1).

The EIGamal signature is comparable in size to the corresponding RSA signature.

I

12.2.2.3 Verification

L The recipient receives Ap, m, r, s, a, and p and computes both sides of eq (4) and then compares the

'I results.

I 12.2.2.4 Known Constraints on Parameters

The following list of constraints is the result of a search of current literature and may not be complete,

[f a) p must be prime

b) p must be large.

Note that Expression (2) can be used to speculate on the level of security afforded by crypto

systems based on the discrete log problem. Breaking the EIGamal scheme has not been proven to
PART 12 - SECURITY March 1991 (Stable)

be equivalent to finding discrete logs, but if we assume equivalence then we can estimate how large

p should be for a desired level of security.

For instance.suppose we wanted to use Expression (2) to decide how large p should be so that we

can be reasonably sure the system cannot be broken (using the best known algorithm) in a practical

amount of time. To be on the conservative side, we decide we want to protect against a special

purpose machine that can perform 10^^ operations per second. Specifically, we want to know how

large p should be so that such a machine would take at least one year to break the system.

In one year, the hypothetical machine can perform 3x10^ operations. To find the size of the

desired p, solve the following equation for b.

We get ^"606 jhis is the number of bits in the desired p. So, the magnitude of the desired p is about 2^ which is roughly 266 x

10'®°

Hence, to be reasonably sure of attaining the desired level of security, we find a prime number

greater than 266 x 10^®° which satisfies all the other criteria listed in this subclause. Our confidence,

however, is strictly based on the assumption that breaking EIGamal is as difficult as finding discrete

logs and the assumption that the best known algorithm for finding discrete logs is near optimal.

c) p should occasionally be changed. This requirement is discussed in [ODLY84] and is related to the discovery of new algorithms for computing discrete logarithms in GF(p).

d) p-1 must have at least one large prime factor. This requirement is discussed in [0DLY84] and

is imposed by the Silverman-Pohlig-Hellman algorithm p which computes discrete logarithms in

GF(p) using on the order operations and a comparable amount of storage, where r is the largest

prime factor in p-1

.

e) p should not be the square of any prime. A subexponential-time algorithm for computing discrete

logarithms in GF(p^) has been found. See [ELGA85b]for details.

12.2.2.5 Note On subjectPublicKey

The ASN.1 data element subjectPublicKey, defined as BIT STRING in Annex (G) of Directory Documents,

ISO 9594 - Part 8, shall be interpreted in the case of EIGamal as being type:

SEQUENCE{ INTEGER, INTEGER }

Where the first integer is the Arithmetic Modulus and the second is the primitive element for the finite field. The sequence is represented by ASN.1 Basic Encoding Rules.

Implementors should take note that the size of the integers used for these parameters is expected to exceed

the pragmatic constraints specified for integers by the upper layers SIG.

6
PART 12 - SECURITY March 1991 (Stable)

12.2.2.6 Note On the ENCRYPTED MACRO

The value associated with the ENCRYPTED MACRO, as defined in Directory Documents, part 8. clause 8.4

shall be interpreted in the case of EIGamal as being type:

SEQUENCE{ INTEGER, INTEGER }

The first integer in the sequence is r (see eq (5), 12.2.2.2). The second integer is s (see eq (9), 12.2.2.2).

|iOTE - 12.2.3 to 12.4.1, a]ong wth fiCKtions ariripe^^^ not appeared in any workshop

documentation prior: to this t<me.

12.2.3 FIRS 112 Password Encryption

12.2.4 DES MAC

12.3 Confidentiality

12.3.1 DES In CBC Mode Encryption

12.4 ASN.1 Definitions

12.4.1 General Security Algorithms

Refer to Part 13, clause 12.4.1 of the Working Agreements as of March 1991.

12.4.2 ASN.1 for Directory Services Strong Authentication Algorithms

Editor's Note - The following algorithms were originally registered by the Directory Services SIG, hence the Object ID remains dssig(7).

This subclause defines object identifiers assigned to authentication algorithms. The definitions take the form

of the ASN.1 module, "OIWAIgorithmObjectldentifiers".

i
PART 12 - SECURITY March 1991 (Stable)

OIWAlgorithmObject Identifiers {iso(l) identif ied-orqanization(3

)

oiw(14) dssig(7) oIWAlgorithmObjectldentif iers ( 1 )

}

DEFINITIONS ::= BEGIN

EXPORTS

md2, md2WithRSA, elGamal, md2WithElGamal

;

IMPORTS

authent i cat ionFr amewor

k

FROM UsefulDef initions { joint-iso-ccitt ds(5) modules(l)

usefulDef initions ( 0 )

}

ALGORITHM

FROM AuthenticationFramework authent icationFramework; — categories of object identifiers

algorithm OBJECT IDENTIFIER ::= {iso(l) identif ied-organization(3)

oiw(14) dssig(7) algor ithm( 2 )

}

encriptionAlgorithm OBJECT IDENTIFIER ::= {algorithm l}

hashAlgorthm OBJECT IDENTIFIER ::= {algorithm 2}

signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3} — algorithms

md2 ALGORITHM

PARAMETER NULL

::= {hashAlgorithm 1}

md2WithRsa ALGORITHM

PARAMETER NULL

::= {signatureAlgorithm 1} .

. elGamal ALGORITHM

PARAMETER NULL

::= {encryptionAlgorithm l)

Editor's Note: Refer to the June 1990 Working Agreements for information

regarding why PARAMETER NULL is specified above for the elGamal

encryption algorithm.

md2WithElGamal ALGORITHM

PARAMETER NULL

::= {signatureAlgorithm 2}

END — of Algorithm Object Identifier Definitions

Figure 1 - ASN.1 for directory services strong authentication

8
PART 12 - SECURITY March 1991 (Stable)

Annex A (normative)

ISPICS Requirements List
PART 12 - SECURITY March 1991 (Stable)

Annex B (normative)

Errata

Table 1 - SIA part 12 changes

NO. OF ERRATA TYPE REFERENCED DOCUMENT CLAUSE NOTES

TECHNICAL SIA PART - 12 0..12 ADD OUTLINE 2ND LEVEL

TECHNICAL SIA PART - 12 9 ADD TEXT

TECHNICAL SIA PART - 12 12.1.2 ADD TEXT

TECHNICAL SIA PART - 12 12.2.2 ADD TEXT

TECHNICAL SIA PART - 12 12.4.1/.2 ADD TEXT

10
PART 12 -SECURITY March 1991 (Stable)

Annex C (informative)

Bibliography

Working Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 13 - OS Security

Architecture

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair: Dr. James Galvin, Trusted Information Systems

SIG Editor: John Hooder, NAVY, Dr. Mohammad Mirhakkak, Mitre
PART 13 -SECURITY September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Security Special Interest Group

(SECSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI). See Procedures Manual for Woprkshop 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. There is significant technical change from this text as

previously given.

Future changes and additions to this version of 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.
PART 13 - SECURITY September 1991 (Stable)

Table of Contents

Part 13 - Security

0 Introduction

1 Scope

2 Normative References . . . .

3 Definitions

4 Symbols and Abbreviations

5 Architectures 2

5.1 Introduction 2

5.2 General OiW Application Environments 2

5.3 Security Profiles 2

5.4 Guidelines for OIW Application Profile Development 2

6 Key lUIanagement 2

7 Lower Layers Security 2

8 Upper Layers Security 2

8.1 Security Mechanisms 2

8.1.1 Peer Entity Authentication 2

8.1.1.1 Simple-Strong Authentication 3

8.1.1.1.1 Operation 3

8.1.1.1.2 Data Structure 3

8.1.1.1.3 Options 4

8.1.1.2 External Authentication Mechanisms 4

8.1.1.2.1 Kerberos Version 5 5

9 Message Handling System (MI-IS) Security 5

10 Directory Services Security 5

1 1 Networl( Management Security 5

11.1 Threats 5

1 1 .2 Security Services 6

11.2.1 Basic Security Services 6

1 1 .2.2 Enhanced Security Services 6

1 1 .3 Security Mechanisms 7

11.3.1 Peer Entity Authentication 7

11.3.2 Connectionless Integrity 7

iii
PART 13 - SECURITY September 1991 (Stable)

List of Figures

Figure 1 - A-ASSOCIATE Authentication Infornnation 3

iv
PART 13 - SECURITY September 1991 (Stable)

List of Tables

Table 1 - Future Changes Planned for Part 12 1

V
iii
Part 1 3 - Security

Editor's Note

Previ ouc mater i al i n this part has been doleted and is no l ongor appli cabl o.

0 Introduction

This part is reserved for future stable Security agreemer^ts. Agreements may be found in the aligned part

of the Working Implementation Agreements document.

Editor's Note - The below outli ne represents the pl anned cl auses to move stable duri ng the Jun 9 1 OI W. Consult Part 13 of the Worki ng I mplementati on Agreements for current i nformati on. The foll owi ng i s the outli ne whi ch will repl ace the text i n Part 13:

Table 1 - Future Changes Planned for Part 12

Part 12 - Stable Clause Title 8 Upper Layers Security

11 Network Management Security

12 Security Algorithms

1 Scope

2 Normative References

3 Definitions

4 Symbols and Abbreviations

1
PART 13 -SECURITY

5 Architectures

September 1991 (Stable)

5.1 Introduction

5.2 General OIW Application Environments

5.3 Security Profiles

5.4 Guidelines for OIW Application Profile Development

6 Key Management

7 Lower Layers Security

8 Upper Layers Security

This clause addresses tfie provision of security services In the Upper tay©rs< The Upper iayws Security

MiXtel speotfle;& the Interactions among the Upper Layers In providing and using security services {Rel,

ISO/IEC CD 10746].

8.1 Security Mechanisms

MjA Peer Entity Authentication

AC$E authentication extensions [Ref. ISO 8649, ISO 6^50] support two-way authenticatlor^ through the

dei^^lon of 9 t^ew iunctlonat unit. When this functional unit 1$ employed, additional parameter$ are provided

by the A-A$SOCfATE service to ndicate this requirement and convey authenticaUon infonnsaion between

endties. The k$HA d^ltii^ for this information Isiigtlvenibedowii^
PART 13 -SECURITY September 1991 (Stable)

from

AutHeatlcatioai SEQUENCE {

tianisat-naae |03 tltPLlCt^ OBJECT identifi ER OPTIONAL,

c

h

e

Reni&i cat; i.an,*^vai.ue

hatstring

ther

Figure 1

IQ} IMPLICIT GraphicStri

ill ZtfPhlCm BXTSTRING,

12} IMPLICIT EXTERNAL,

C3} ANY DEFINID Blf mecha

- A-ASSOCiATJE Authentication informs

nism-name } }

ition

Tliese agreements define the following mechanisms for usa with this ACSE functtonaJ unit:

slmpte^strong authentication mechanism.

8.1.1.1 Simple-Strong Authentication

6.1.11.1 OpcH^tlon

The operation the simple-strong iauthenScatlon mechanisms are based upon ISO 96^-3 and 9S§4*8

Standards. The sending system isl hesentitysrequesting authentication of its identity, and the receiving

si^m is the entity performing the authentication. The sending system supplies data for the ACSE

authentication fMd<Jf the A-A$$OCiATE primitive. The receiving ACSE obtains the ACSE authentication data

lr«m the A-ASSOCIATE PDiJ. and it pedonns the authentication check. If this check fails, the receiving

ACSe returns an A-ABOfiT primitive to Ui6 sending ACSE. If the check is successful, the association

fomiatlon succeeds or iais depending upon otiw clrcymstances and parameters. The use c>l the ACSE

authentication fields support both the simple ^ind strong credentials variants of the ISO 9594 authentication

sxdhangesi

perflcates for use with strong authentication must be compatible with ISO 9594-8.

N0T1E - Certificates procured for use wi*» lntem« Privacy Enhanced Maif [T8D r&g^ ar* cdmptet$iy<X)ftlpatlbte with ISO 9594-8 and may {sutojea to llcen^ r«st^lons) \a u$ed by the strong authentication mechanism.

Hov«ver, Privacy Er*tanc6d Mii «S€i6 Only a5i*i6^<)f the suggested ISO 9594-7 name forms, and might not support «M!taln narwform$ of int^ttOSpecJIIcOIWap^llcatiori?. Examples include Application Entity names and c*tdln name for defined by ti^ North Aftierican Directory Forum in NADF-123 |ref. TBp|

8.1.1.1.2 Data Structtn^

Mechanism Name

The following is ^

A$N.1 description ^ tlie authentication data ^tmcture for ^Imple.jor, atfOjiig

iu^enScistflon;;

3
PART 13 - SECURITY September19gi (Stable)

> " »iffl|>le-»strong-autb~inechanlsin object IDENTIFIER %t« {iso

identif ied-organization (3)

OIW ( 4

)

SECSIG (3)

Autneni; ication-mecnanisma

simpl^-stcong-identity-authenticatioii (I)

}

Th^ authentloatton va^u0 is oonveyed in the tjtJwf (se^ figure t) cptlop of the ^utf»ettUoaUort-valufe fietd of

ACSE authentication.

Authentication-Value :t*

^T'- SJBQUENCE OF DirectoryAbstractService .Credentials

^

I This data type is defined in ASN.1 module DIrectoryAbstractService of ISO 9594-3 as modtfled tlvough

tesolution of Directory Defect Report No. 9594/058. The semantics of all fields are a$ speGified;tec^ 1 6»t.2.1 of ISO 9594-a \

Tte Autf>enttca^n-Va)ue Is defined as a

entities in the authentication value, it SEQUENCE because It Is permitted to pass credentials for multipleis the responsibility of the application to determine the specific

meaning <and use of multiple credentials in such a case. It is anticipated that specific applications (e.g*> Network Management) would provide> specifications for hand! Ing multiji^e credentials within thetf own cfetises of Part 13 * OS Security Architectura

TWs authentlcati<»i mechanism may employ any registered authentlcatfon algortthm^ however ft Is recommended that the authentication algorithims Identified In clause 12.2 be used,

iiii^l.t.1.3 options

For the Simj^e Credernlals oi^ion of Credentials, die foitowing agreerrjents applyl' Confc^mliig I implementations are not required to employ the OPTIONAL validity sequence of the SlmpleCredertfiat data

element Receiving implementations that do not employ the validity sequence must reject an authenticatloni

ys^ue which does contain this sequence. Corrforming Imj^ementatlons shall employ the optional passwonj

fl^ of the SimpleCredential data element

Ncjte ths* the password nmy be hashed using one way funt^ns and die other validity fields. Password Is

3 iSfither deartext, or Prolectedl or PfOtected2 per ISO 9594-8 (Directory Authentication Frameworl<). ^

8s1 . 1 ,2 External Authentication Mechanisms

Brternalfy d^ned authentication exchanges may employ the external [2] option of the authentication-value

fj^ of ACSE authentication. In this case it is recommended that the mechanism-name be omitted, with th6

particiiar mechanism !n use being implied by the abstract syntax identilied In the extemal construct

j

4
PART 13 -SECURITY September 1991 (Stable)

$.1 . 1 «2. 1 K«ti€^o«i Version 5

Qm instance of an external authentication mechanism is the Kerberos mechanism defined In RFC [TBD]:

TheK^^b^<»5 ^peC^liCfitttoll aligned the::J^^ abstract syntax suitable for use in ihlss*ayj MM

Piihcomli^

9 Message Handling System (MHS) Security

10 Directory Services Security

I 1 1 Network Management Security

This clause (KJtiines an approach to providing security services for OSI

Metwoii< Management. ThegdaJs

of this approach are to pr<yrfide seCajrity in a manner that is simple and s traight-forward to implement, arKj to avoid any unnecessary computaSonal and managerial overt^iead. The approach also takes into OOn^eraticKi the r?eed fordlfferer^fevelsof security services within different rietworl< management domains,

and the near tenu requirement for interopefabllity of n^oi1< management entities over disparate network

! ^ypes.

'i

1

i 111 Threats

i:

puipose of discussion, thread are dMded into two categories: primary and secondary threats. Primary threats are HiQse considered to be applicable to the full range of network management

fimplementagonSi while secondary treats are considered to be appilc^e to the more limited range of highly secure Im^emenjtattoRSi

il The primary threats to be pr^rtected against are the fotiowln0;

I a) The masqueratjing of a manager or agent entity;

b) the fabricattOn or rtiodiflcation of Common Management Infonnation Protocd (Cfi/IlP) data unitS}

j By countering primary iSireats, dlisruptlon d network management services by the casual user can b^

!

i The secondary threats to be i^otected against are the following;

a) All primary ^resd;s;

I b) Tf^e disclosure of CfvilP data units;

c) The replay, reflection, reordering* insertk>n, or deletion of CMIP data units<

5

I
PART 13 -SECURITY Septembenggi (Stable)

it.2 Security Services

ll.a. I Basic Security Services

The security si^vlces mqulred to counster prlftiary i^reats are:

a) Peef entity aifthentjcatlon;

b) Pata oilgln au^en^tloii;

c) Corviec^nless liitegrlty^

Peer entity authentlcato Is to occur dyrJng the establishment of an ai^lcation i- '

^

aasoclatiop is successfully establisliecf. tbe urelerfyliig security mechanism prwid

subsequenSy used In data origin au^en^atlon. Hieretiie infomiatton may be Indue

vivay, transform the (Ma units of ^bsequent exc^emges so that they ran be Identif! ai from an authenticated entity. Bd^ authenttcation secuitEy sendees are to be provided at the appiicauon level of tfeeiprotocc^i

0<»inectionless Negity Insures that <M9 Units (aiginating *rom an authwticated source are nc* modifiable

without detection. When combined with a strcmg data onlgint authentication mechanism, the ability to taNc^e ne»^ data units also countered, C<yi«©ctlonle$d integrity may be prov4ded at either ^e

application level of the protocol or within one of the lower levels of the protocol {le., transport or ntetwori<}<

; Services

The security services required to counter secot^ry ^eats are;

a) Alt ba^^c sectirity sen/ices wfth the^^^ integrity;

b) Ccmnectlonless confidentjaJit)^

c) Connection integrity wfth or tfl^h<»jt recovery.

Both connectior^ess cor*8dentlaiity and connection Ink^rity may be provided at either the application lev^

of {H'otocof or wtthirt one of the lower levels ci ii^otooc^ The latter provision is assumed here. Enhanced

security services are not discussed furUier in this ncto, t»it to iae Issued as a requirement for the lower layer

protocol and service standards, and according to lunci^onai standards to be developed.

6
PART 13 -SECURITY

|1.3 Security Mechanisms

September 1991 (Stable)

nXi feer Entity Authentlcatroti

P^^Erttfty Aai!h0nlloatio» w|l g$$tK9 AC^ authem^tion m^oKantsm and associated daia typ^s a$ d^aTfrr^

Iri clause 6 <^ Ms part of ihe lAs. The specPRc auther^cafcion mechanisms to be supported is the simpif

St«»t9-auth-m$t^ni$m de^&i lit 8.l.t.l.

^jpp(yr); df ACSE authentiDaUcm Is cptlonalx

iiXti Coiute<^onl6ss Integrity

(Refer to the Working Implementation Agreements.)

stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 14 - Virtual Terminal

1 Output from the September 1991 NIST Workshop for

I Implementors of OSI

SIG Chair: Luke Lucas, Control Data Corporation

SIG Editor: Luke Lucas, Control Data Corporation
Ii
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table of Contents

Part 14 - Virtual Terminal 1

0 Introduction 1

1 Scope 1 1.1 Phase la Agreements 1 1.2 Phase lb Agreements 1 1.3 Phase II Agreements 2

1.4 Status 2

1.4.1 Status of phase la 2

1.4.2 Status of phase lb 2

1.4.3 Status of phase II 2

2 Normative References 2

3 Status 3

4 Errata 3

5 Conformance 4

6 Protocol 6

6.1 Protocol Elements 6

6.2 Mapping of Protocol Elements 6

6.3 Protocol Data Unit Structure 6

7 OIW Registered Control Objects 6

7.1 Sequenced Application (SA) 6

7.1.1 Entry Number 7

7.1.2 Name of Sponsoring Body 7

7.1.3 Date 7

7.1.4 Identifier 7

7.1.5 Descriptor Value 7

7.1.6 CO Parameters 7

7.1.7 CO Values and Semantics 7

7.1.8 Additional Information 8

7.1.9 Usage 8

7.2 Unsequenced Application (UA) 8

7.2.1 Entry Number 8

7.2.2 Name of Sponsoring Body 9

7.2.3 Date 9

7.2.4 Identifier 9

7.2.5 Descriptor Value 9

Hi
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable) !

7.2.6 CO Parameters 9

7.2.7 CO Values and Semantics 9

7.2.8 Additional Information 9

7.2.9 Usage 9

7.3 Sequenced Terminal (ST) 10

7.3.1 Entry Number 10

7.3.2 Name of Sponsoring Body 10

7.3.3 Date 10

7.3.4 Identifier 10

7.3.5 Descriptor Value 10

7.3.6 CO Parameters 10

7.3.7 CO Values and Semantics 10

7.3.8 Additional Information 12

7.3.9 Usage 12

7.4 Unsequenced Terminal (UT) 13

7.4.1 Entry Number 13

7.4.2 Name of Sponsoring Body 13

7.4.3 Date 13

7.4.4 Identifier 13

7.4.5 Descriptor Value 13

7.4.6 CO Parameters 13

7.4.7 CO Values and Semantics 13

7.4.8 Additional Information 14

7.4.9 Usage 14

8 01W Defined Profiles 14

8.1 Telnet Profile 14

8.1.1 Introduction 14 i 8.1.2 Association Requirements 14

8.1.2.1 Functional Units 14

8.1.2.2 Mode 14

8.1.3 Profile Body 14

8.1.4 Profile Arguments 18

8.1.5 Profile dependent Control Object Information 18

8.1.6 Profile Notes 18

8.1.6.1 Definitive Notes 18

8.1.6.2 Informative Notes 20

8.1.7 Specific Conformance Requirements 21 8.2 Transparent Profile 21

8.2.1 Introduction 21 8.2.2 Association Requirements 21

j 8.2.2.1 Functional Units 21 '

8.2.2.2 Mode 22

8.2.3 Profile Body 22

8.2.4 Profile Arguments 22

8.2.5 Profile dependent Control Object Information 23

8.2.6 Profile Notes 23

iv
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

8.2.7 Specific Conformance Requirements 23

8.3 Forms Profile 23

8.3.1 Introduction 23

8.3.2 Association Requirements 24

8.3.2.1 Functional Units 24

8.3.2.2 Mode 24

8.3.3 Profile Body 24

8.3.4 FIXED Field Entry Instruction Definitions - non-parametric 29

8.3.4.1 Optional Field 29

8.3.4.2 Mandatory Field 29

8.3.4.3 Protected Field 30

8.3.4.4 Fill Field 30

8.3.4.5 Echo Received Character 30

8.3.4.6 Echo Off 30

8.3.4.7 Ignore Case 30

8.3.4.8 Inhibit Logical Rendition Attribute Operation 30

8.3.5 DYNAMIC Field Entry Instruction Definitions - parametric 31

8.3.5.1 Selectable field 31

8.3.5.2 Echo Specified Character 31

8.3.5.3 Minimum Entry 31

8.3.5.4 Allowed First Characters 32

8.3.5.5 Allowed Characters 32

8.3.5.6 Disallowed Characters 32

8.3.5.7 Entry Invoke Character 32

8.3.5.8 Waiting Time 32

8.3.5.9 Allowed String Values 33

8.3.5.10 Allowed Numeric Values 33

8.3.6 Mutually Exclusive FEIs 34

8.3.7 FEICO Update Syntax 36

8.3.8 FEICO "mandatory-feico" Initial Content 37

8.3.9 Field Entry Event Definitions 38

8.3.9.1 FEEOO 39

8.3.9.2 FEE01 Logical Keystroke event (Range) 39

8.3.9.3 FEE02 Field entry complete 39

8.3.9.4 FEE03 Field selected 39

8.3.9.5 FEE04 Field Waiting Time expired 39

8.3.9.6 FEE05 Field Entry Instruction violation 39

8.3.10 Field Entry Condition Definitions 40

8.3.10.1 FECOO 40

8.3.10.2 FEC01 No previous field 40

8.3.10.3 FEC02 No next field 40

8.3.10.4 FEC03 Start of field 40

8.3.10.5 FEC04 End of field 40

8.3.10.6 FEC05 At tab stop 41

8.3.10.7 FEC06 At characters (Set of character values) 41

8.3.10.8 FEC07 Exits field (Action) 41

8.3.10.9 FEC08 Exits forward path (Action) 41

V
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

i 8.3.10.10 FEC09 Exits backward path (Action) 41 8.3.10.11 FECI 0 Exits x-array (Action) 41 8.3.10.12 FEC1 1 Exits y-array (Action) 41 8.3.10.13 FECI 2 Not FEC (FEC) 42

8.3.10.14 FECI 3 And FECs (Set of FEC) 42

8.3.10.15 FECI 4 Or FECs (Set of FEC) 42

8.3.10.16 FECI 5 Violation (Set of FEIR identifiers) 42

8.3.10.17 FECI 6 Unconditional 42

8.3.11 Field Entry Reaction Definitions 42

8.3.11.1 FEROO 42

8.3.11.2 FER01 Transmit updates 43

8.3.11.3 FER02 Relinquisfi WAVAR 43

8.3.11.4 FER03 Erase field rigfit (Reset attribute) 43

8.3.11.5 FER04 Erase path right (Reset attribute) 43

8.3.11.6 FER05 Local action (Action) 43

8.3.11.7 FER06 Logical Keystroke (Action) 44

8.3.11.8 FER07 Update ST CO (Action) 44

8.3.11.9 FER08 Update UT CO (Action) 44

8.3.11.10 FER09 Execute RIO record (RIO record id) 44

8.3.11.11 FER010 Call RIO record (RIO record id) 44

8.3.11.12 FER1 1 Visual indication 44

8.3.11.13 FER1 2 Audible indication 44

8.3.11.14 FER1 3 Conditional branch 45

8.3.11.15 FER14 Prevent further entry 45

8.3.11.16 FER1 5 Write disallowed character 45

8.3.11.17 FER16 Write string (Character string) 45

8.3.12 Field Entry Pilot Update Syntax 45

8.3.13 Profile Arguments 49

8.3.14 Profile Dependent Control Objects 52

8.3.14.1 Sequenced Application CO 53

8.3.14.2 Unsequenced Application CO 53

8.3.14.3 Sequenced Terminal CO 53

8.3.14.4 Unsequenced Terminal CO 53

8.3.15 Profile Notes 53

8.3.15.1 Definitive Notes 53

8.3.15.2 Informative Notes 57

8.3.16 Specific Conformance Requirements 58

8.4 X3 Profile 58

8.4.1 Introduction 58

8.4.2 Association Requirements 58

8.4.2.1 Functional Units 58

8.4.2.2 Mode 58

8.4.3 Profile Body 58

8.4.4 Profile Arguments 66

8.4.5 Profile Notes 66

8.4.5.1 Definitive Notes 66

8.4.5.2 Informative Notes 71

vi
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

8.4.6 Specific Conformance Requirements 74

Annex A (normative)

Specific ASE Requirements 75

Annex B (normative)

Clarifications 76

Annex C (normative)

Object Identifiers 77

vll
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Virtual Terminal Special Interest Group (VTSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors

of Open Systems Interconnection (OSI). 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. There is no significant technical change from this text as

previously given.

Three normative annexes are given.

viii
Part 14 - Virtual Terminal

0 Introduction

The NIST/OSI Workshop Virtual Terminal (VT) SIG is making implementation agreements for the OSI Basic

Class VT Service and Protocol. ISO 9040 and ISO 9041.

These implementation agreements fall into the following categories:

Functionality to be implemented, i.e., functional units, etc.

Identification and specification of VT profiles to be supported by conforming implementations.

Agreements with regard to implementation issues not specified in ISO 9040 and ISO 9041.

Resolution of problems with ISO 9040 and ISO 9041 identified during implementation.

Statement of requirements to meet conformance to these agreements.

1 Scope

1.1 Phase la Agreements

The Telnet profile is intended to support the following usage:

a) a simple line at a time or character at a time dialogue, and

b) an application level gateway supporting Internet Telnet and ISO VTP interoperation.

;l The Transparent profile supports the exchange of uninterpreted sequences of characters. This includes

i! support of VT-users who wish to control terminals directly through the use of embedded control characters

I and escape sequences.

1.2 Phase lb Agreements

The Forms profile is intended to support forms-based applications with local entry and validation of data by

the terminal system. This profile is now aligned with the EWOS VT EG Functional Standard.
PART 1 4 - VIRTUAL TERMINAL September 1 991 (Stable)

1.3 Phase II Agreements

The X.3 profile supports functionality similar to the CCITT recommendations and could be used to implement an X.3 to ISO-VT gateway.

See Working Agreements regarding PageotpfFItIsmI 11 profiles.

1 .4 Status

1.4.1 Status of phase la

I Phase la of the VT Agreements was stabilized May 5, 1988. This phase covers the Telnet and Transparent

profiles. No future enhancements will be made to this phase. '

1.4.2 Status Of phase lb

Phase lb of the VT Agreements was first stabilized December 16, 1988. This phase covers the Forms profile.

Alignment with EWOS required substantial modifications which were ratified September 15, 1989.

1.4.3 Status Of phase II

Phase II is still in progress and includes the remaining profile work for Scroll, Page (S-mode) and Pago (A

mod«)Oeneralized Telnet profiles.

The X.3 profile of phase II was stabilized December 15, 1989.

I

2
PART 14 - VIRTUAL TERMINAL September 1991 (Stable)

2 Normative References

ISO 9040:t99Q, Information ProcoGeing SyGtomG^hmtogy - Open Systems Interconnection

- Virtual Terminal Service—Basic Class Service.

ISO 904141*1990, Information Proooooing Syotcmotechnofogy - Open Systems Interconnection

- Virtual Terminal Protocol Basic Class Protocol - Part I: Sp^tlk^tim.

^^i^^i^^^Mormatton iechnofogy Open Systems fnterconnectkm

^ Pfocedtjres for the Operation of OSt Registration Aud)0titi6$

' Part 4: Regist^ of VTE Proflies.

\SQ^^&34S, fr^ormatiorj technology ' 0pm Systems fntercormecffm

- Procedures for the Operation of 0$l Registration Aattiodties

' Part 5.' Register of VT Control Object Definitions,

2-1
PART 14 - VIRTUAL TERMINAL

This Page intentionally left blank.

September 1991 (Stable)

2-2
PART 14 - VIRTUAL TERMINAL September 1991 (Stable)

3 Status

This version of the agreements was completed in December 1990.

4 Errata

Editor's Note - 'Defect Report* material may be included here, including versions of implementor agreements

to which it applies.

Table 1 - Technical Errata

06/90-1 Forms Profile. The "FEICO Update Syntax" ASN.l connnent which

follows the definition of the PriValue type was corrected to

support multi-octet repertoires.

06/90-2 Forms Profile. The descriptive text for the Field Entry

Instruction Violation FEE was corrected to indicate that both an entry-control index and a FEPR index are required to

identify the FEPR concerned.

06/90-3 Forms Profile. The descriptive text and update syntax for the

Violation FEC were corrected to indicate that both a FEICO- name and an index are required to identify a FEIR.

06/90-4 Forms Profile. The update syntax for the writeString FER was corrected to align with the descriptive text for this FER.

06/90-5 Forms Profile. The descriptive text for the repertoire

assignment profile argument was corrected to properly identify

the default value as the GL set ISO 2375 Reg. No. 6 (ASCII).

06/90-6 Forms Profile. The concept of a "current keystroke" was

inserted into the definition of the FEICO to remove aunbiguity

in the use of the ST and UT COs . Various FEEs, FECs and FERs were redefined.

3
PART 1 4 - VIRTUAL TERMINAL September 1 991 (Stable)

Table 2 - Alignment Errata

06/90-7 Forms Profile. A definitive note was added to define how the

host is notified of the current entry location when data entry

terminates and the VTE-parauneter access-outside-f ields has the

value "allowed."

06/90-8 Forms Profile. Three font-assignment profile arguments were added to accomodate INTAP requirements.

09/90-1 Forms Profile. The emphasis subattribute "h" was added with

values "F" (Frcuned) and "C" (Encircled).

09/90-2 Telnet Profile. Four editorial comments were incorporated to

align with the corresponding EWOS Functional Standard.

Table 3 - Editorial Errata

06/90-9 Forms Profile. Two definitive notes were added to clarify the

secondary attributes comparison mechanisms for the FEIs and

FECs that test equality of characters.

06/90-10 Forms Profile. A definitive note was added to clarify the

effect of associating multiple Character-oriented FEIs of the same type with the Seune field.

06/90-11 Forms Profile. An introductory paragraph in the section "Field

Entry Condition Definitions" was rewritten for clarification.

06/90-12 Forms Profile. The descriptive text for the Write String field

entry reaction was modified to indicate precisely how and where

the associated string is to be written.

09/90-3 X3 Profile. The reference to COs P3 and P4 contained in

comments relating to DEVICE-1 were corrected to reference

elements 3 and 4 of the PAD CO.

12/90-1 X3 Profile. Changes were made to correct editorial errors discovered during the progression of the EWOS X3 Profile

Functional Standard.

09/91-1 Scope , S tatus, and Refe cences'' c laoaes' 7\i^W''tipS*

t

»

4
PART 14 - VIRTUAL TERMINAL September 1991 (Stable)

5 Conformance

Conformant VT implementations are required to support the ISO 9041 Clause 13 requirements plus the

additional conformance requirements identified below.

Table 4 shows conformance status for VT facilities which are optional in the ISO VT standard. The terms used

in the figure are defined as indicated below:

4-1
PART 14 - VIRTUAL TERMINAL

This page intentionally left blank.

September 1991 (Stable)

4-2
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

- "Mandatory" indicates tliat the facility must be provided by all innplementations which

conform to these agreements.

- "Optional" indicates that the VT facility is not required to meet minimum conformance

requirements but has been identified as providing additional useful capabilities.

- "Profile Dependent" indicates that the requirement for the facility, if any, is included in the profile definitions.

- "Not Addressed" indicates that the VT facility is outside the scope of these agreements.

Table 4 - Conformance Status for VT Facilities

Conformance Status Mandatory Optional Profile

Dependent

Not

Addressed

Switch Profile'^'' X

Multiple Interaction

Negotiation^ ' X

Negotiated Release^

X

Urgent Data^^ X

Break^) X

Delivery Control^

X

Enhanced Access Rules X

Structured COs^^ X

Blocks^ ^ X

Fields^) X

RIOs^) X

S-mode X

A-mode X

Mode Switching Capability X

1) It is not anticipated that new profiles will use quarantined delivery

control

.

2) Functional Units.

For each mode of operation (A-mode and S-mode) which is implemented, the default profile for that mode

as defined in ISO 9040 must be supported. Implementations that support A-mode must support the A-mode

default profile and at least one additional Workshop approved A-mode profile. The Transparent profile does

5
PART 14 -VIRTUAL TERMINAL December 1990 (Stable)

not count as an additional A-mode profile. Implennentations that support S-mode must support the S-mode

default profile and at least one additional Workshop approved S-mode profile.

For each profile implemented, VIE parameter ranges or values specified in the Workshop-agreed profile and

associated notes must be supported.

6 Protocol

6.1 Protocol Elements

All protocol elements required by the ISO 9040 VT kernel and Break functional units are selected.

All protocol elements required by the Switch Profile functional unit are selected if this functional unit is used.

See Table 4.

All protocol elements required by the Urgent Data functional unit are selected if this functional unit is used.

See Table 4.

6.2 Mapping of Protocol Elements

Mapping of protocol elements on to ACSE or Presentation Services is as defined in ISO 9041.

6.3 Protocol Data Unit Structure

Protocol data unit structure is as defined in ISO 9041.

7 OIW Registered Control Objects

The following Control Objects are used by more than one profile. Some of the CO parameters are left with

undefined values that must be assigned by the profile in which the Control Object is used.

7.1 Sequenced Application (SA)

This is a Control object used to convey signals from the application to the terminal in sequence with other

updates.

6
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

7.1.1 Entry Number

To be supplied by Registration Authority.

7.1.2 Name of Sponsoring Body

OSI Implementors' Wori<shop (OIW), VTSIG.

7.1.3 Date

The date of submission of this proposal is Septemtjer 15, 1989.

I 7.1.4 Identifier

j oiw-vt-co-misc-sa OBJECT IDENTIFIER ::= {oiw-vt-co-misc sa(0)}

7.1.5 Descriptor Value

"OIW VT CO for conveying Sequenced Application Signals"

7.1.6 CO Parameters

CO-structure 1 CO-priority "normal"

CO-category "symbolic"

CO-size 1

J 7.1.7 CO Values and Semantics

Table 5 lists the allowed symbolic values together with the integers used to reference these values in the

ASN.1 update syntax of ISO 9041:

7
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table 5 - SA/UA CO values and semantics

SymDoiic value Integer Value

audible_alarm 0

newlines_enabled 1 newlines disabled 2 restore 3 visuax ai.arin A keypad_enabled 5 keypad_disabled 6

keyboard_locked 7 keyboard_unlocked 8 deV i ce_d i s connect 9 break_signal 10

The semantics of each value must be specified in the VTE profile which references this CO.

7.1.8 Additional information

None.

7.1.9 Usage

Defined in profile.

7.2 Unsequenced Application (UA)

This is a Control object used to convey urgent signals from the application to the terminal.

7.2.1 Entry Number

To be supplied by Registration Authority.

8
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

7.2.2 Name of Sponsoring Body

OSI Implementors' Workshop (OIW), VTSIG.

7.2.3 Date

The date of submission of this proposal is September 15, 1989.

7.2.4 Identifier

oiw-vt-co-misc-ua OBJECT IDENTIFIER:: = {oiw-vt-co-misc ua(1)}

7.2.5 Descriptor Value

"OIW VT CO for conveying Unsequenced Application Signals"

7.2.6 CO Parameters

CO-structure 1 CO-priority "urgent"

CO-category "symbolic"

CO-size 1

7.2.7 CO Values and Semantics

Same as in SA.

7.2.8 Additional Information

None.

7.2.9 Usage

Defined in profile.

9
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

7.3 Sequenced Terminal (ST)

A keyboard can generate many signals that may be given special meaning to the application. This CO is general enough to convey any keyboard event.

OSI Implementors Workshop (OIW), VTSIG.

7.3.3 Date

The date of submission of this proposal is September 15, 1989.

7.3.4 Identifier

oiw-vt-co-misc-st OBJECT IDENTIFIER ::= {oiw-vt-co-misc st(2)}

7.3.5 Descriptor Value

"OIW VT CO for conveying Sequenced Terminal Signals"

7.3.6 CO Parameters

CO-structure 1 CO-priority "normal"

CO-category "integer"

CO-size 65535

7.3.7 CO Values and Semantics

The values of the CO are composite, with values from Table 6 giving meaning to the values in the hex range

00-FF when added to them.

7.3.1 Entry Number

To be supplied by Registration Authority.

7.3.2 Name of Sponsoring Body

10
PART 14 - VIRTUAL TERMINAL

Table 6 - ST/UT CO composite values

December 1990 (Stable)

hex value meaning

100 special key - labeled-'-^

200 function key depressed

400 control key depressed

800 shift key depressed

1000 alt key depressed

1) possible special key values are

as defined by the STCO ASN.l module.

The special key and the function key are mutually exclusive. If neither the function keys nor the special keys

are pressed, then the value in the hex range 00-FF will be that of the normal, unshifted code combination

generated by the alpha-numeric key. Values in the hex range 00-FF are not valid values for the data element

of this Control Object.

The control, shift, and alt keys may appear in any combination with the special or function keys.

The shift key must occur in combination with at least one of the other keys in the above table to cause the

value to fall outside the repertoire of the display object.

When the special key is depressed, the value of the CO content will be as given in the ASN.1 module below

for the value in the hex range of 00-FF. Othenwise, the value will be defined to be the IA5 value associated

with the key.

11
PART 14 - VIRTUAL TERMINAL

STCO DEFINITIONS ::= BEGIN

December 1990 (Stable)

Key ::= INTEGER {

break (0), tab (3), carReturn (6), escape (9), multiply (12),

rightArrow (15),

insert (18),

deleteLine (21),

PageUp (24),

pa2 (27),

status Process (30),

abortOutput (33),

print (36),

endOfRecord (39),

bell backTab

cancel

plus

divide

upArrow

delete

home

PageDown

pa3

interruptProcess

formFeed

refresh

endOfFile

(1).

(4),

(7), (10)

(13)

(16)

(19)

(22)

(25)

(28)

(31)

(34)

(37)

(40)

backspace

lineFeed

substitute

minus

leftArrow

downArrow

insertLine

end

pa1

help

terminateProcess

clear

systemRequest

suspendProcess

(2),

(5).

(8), (11)

(14)

(17)

(20)

(23)

(26)

(29)

(32)

(35)

(38)

(41)

-- Names for combination keystrokes are formed by converting the

-- initial letter to upper case and prefixing with 'Ctrl', 'shift' or

-- 'alt', which adds 1024, 2048 or 4096 respectively to the value.

-- These prefixes may be used in combination with one another by a - repetition of this conversion process, provided that they appear - from left to right in the order 'Ctrl', 'shift', 'alf. ASN.1 - formally does not allow such descriptive additions but it would be - very lengthy to write them all in full -- }

END *(STCO DEFINITIONS)*

VTE profile definitions may refer to this module for convenience in describing semantics.

7.3.8 Additional Information

None.

7.3.9 Usage

Defined in profile.

12
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

7.4 Unsequenced Terminal (UT)

Keyboard events may need to be conveyed urgently, out of sequence with nornrial updates. This CO is used

to signal such events from the terminal to the application.

7.4.1 Entry Number

To be supplied by the Registration Authority.

7.4.2 Name of Sponsoring Body

OSI Implementors Workshop (OIW), VTSIG

7.4.3 Date

The date of submission of this proposal is September 15, 1989.

7.4.4 Identifier

1 olw-vt-co-mlsc-ut OBJECT IDENTIFIER ::= {olw-vt-co-misc ut(3)}

7.4.5 Descriptor Value

"OIW VT CO for conveying Unsequenced Terminal Signals"

7.4.6 CO Parameters

j CO-structure 1

! CO-priority "urgent"

i CO-category "Integer"

' CO-sIze 65535

i 7.4.7 CO Values and Semantics

I Same as in ST.

13
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

7.4.8 Additional Information

None.

7.4.9 Usage

Defined in profile.

8 OIW Defined Profiles

These profiles are defined using tfie conventions specified in Annex A of ISO 9040.

8.1 Telnet Profile

OIW VTE-Profile TelneM988 (r1, r2)

8.1.1 Introduction

This profile provides support for TELNET-like operation for users of the ISO Virtual Terminal Service. It is based on the IS version of ISO 9040 and ISO 9041

.

8.1.2 Association Requirements

8.1.2.1 Functional Units

The Urgent Data Functional Unit is optional, but should be used whenever available.

8.1.2.2 Mode

This is an A-mode profile.

8.1.3 Profile Body

Display-objects = *(double occurrence)*

{

14
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

"unbounded,"

"no constraint," no,

profile-argument-rl

"unbounded,"

"higher only,"

"no,"

1

{

display-object-name = D, *{DISPLAY)

do-access = "WACA,"

dimensions = "two,"

x-dimension =

{

x-bound

x-addressing

x-absolute

x-window

}.

y-dimension =

{

y-bound

y-addressing

y-absolute

y-window

},

erasure-capability = "yes,"

repertoire-capability = 2,

repertoire-assignment = profile-argument-r2,

repertoire-assignment = <ESC> 2/5 2/15 4/2

}.

{

display-object-name = K, *(KEYBOARD)*

do-access = "WACI,"

dimensions = "two,"

x-dimension =

{

x-bound

x-addressing

x-absolute

x-window

}.

y-dimension =

{

y-bound

y-addressing

y-absolute

y-window

}.

erasure-capability = "yes,"

repertoire-capability = 2,

"unbounded,"

"no constraint," no,

profile-argument-r1

"unbounded,"

"higher only,"

"no,"

1

15
PART 1 4 - VIRTUAL TERMINAL

repertoire-assignment = profiie-argument-r2,

repertoire-assignment = <ESC> 2/5 2/15 4/2

}

Control-objects = *{multiple occurrence)*

{

{ *(SYNCHRONIZE)*

co-name = SY,

co-access = "NSAC,"

CO-category = "symbolic,"

CO-size = 1, CO-priority = "urgent"

},

{ *(DISPU\Y-SIGNAL)*

co-name = Dl,

co-access = "WACA,"

CO-category = "boolean,"

CO-size = 5,

CO-priority = "normal,"

co-trigger = "selected"

}.

{ *{KEYBOARD-SIGNAL)*

co-name = KB,

co-access = "WACI,"

CO-category = "boolean,"

CO-size = 5,

CO-priority = "normal,"

CO-trigger = "selected"

{ *(NEGOTIATION BY INITIATOR)*

CO-name = Nl,

co-access = "WACI,"

CO-category = "boolean,"

CO-size = 4,

CO-priority = "normal,"

CO-trigger = "selected"

{ *(NEGOTIATION BY ACCEPTOR)*

CO-name = NA,

co-access = "WACA,"

CO-category = "boolean,"

CO-size = 4,

December 1990 (Stable)

16
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

}.

CO-priority = "normal,"

co-trigger = "selected"

}.

{ * (GO-AHEAD)*

CO-name = GA,

co-access = "NSAC,"

CO-category = "boolean,"

co-size = 1,

CO-priority = "normal,"

CO-trigger = "selected"

}

Device-objects = * (double occurrence)*

{

{

device-name = DISPLAY-DEVICE,

device-display-object = D,

device-default-CO-initial-value = 1."true,"*("on")*

device-minimum-X-array-length = 1,*(no constraint)*

device-minimum-Y-array-length = 1,* (no constraint)*

device-control-object = SY,

device-control-object = NA,

device-control-object = Dl,

device-control-object = GA,

*(SYNC,NEGOTIATE-ACCEPTOR, DISPLAY-SIGNAL,

GO-AHEAD)*

device-default-CO-access = "WACA,"

device-default-CO-priority = "normal"

*(other device object parameters assume corresponding DO values)"

}.

{

device-name = KEYBOARD-DEVICE,

device-display-object = K,

device-default-CO-access = "WACI,"

device-default-CO-priority = "normal,"

device-default-CO-initial-value = 1."true,"*("on")*

device-minimum-X-array-length = 1,* (no constraint)*

device-minimum-Y-array-length = 1,*(no constraint)*

device-control-object = SY,

device-control-object = Nl,

device-control-object = KB,

device-control-object = GA,

17
PART 14 " VIRTUAL TERMINAL December 1990 (Stable)

*(SYNC,NEGOTIATE-INITIATOR,KEYBOARD-SIGNAU

GO-AHEAD)*

*(other device object parameters assume corresponding DO values)*

}

}.

Type of delivery control = "simple-delivery-controL"

8.1.4 Profile Arguments

r1 - is used to represent the line length as the vaiue of VIE parameter x-window for both display objects.

This argument is mandatory and takes a nonnegative integer value. This argument is identified by

the identifier for x-window for display object D.

r2 - is used to designate the default repertoire for both display objects. This argument is optional, if not present the full US ASCII set is the default. This argument is identified by the identifier for repertoire

assignment for the display object D.

8.1.5 Profile dependent Control Object information

This profile does not reference any Control Objects which are not defined within this profile.

8.1.6 Profile Notes

8.1=6,1 Definitive Notes

1. Booleans in the KB and Dl control objects are used in this profile to correspond to TELNET

commands as follows:

Table 7 - KB/Di CO value definitions

Control Object Booleein TELNET

18
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

The equivalent of a TELNET command is achieved by selecting the boolean that

corresponds to the desired TELNET command. Selecting a boolean in the Dl or KB control object means setting the value of the desired boolean to "true." The

usage of the mask element of the boolean update is as specified in ISO 9041.

2. The equivalent of a TELNET SYNCH command Is achieved by updating the SY control object with

the single symbolic value of "SYNCH" (which is mapped onto the integer value 1), and immediately

updating the Dl (or KB) control object selecting the DM boolean. IP, AO, AYT, or BREAK

commands may be accompanied by a SYNCH command by updating the SY control object and

then updating the Dl or KB control object selecting both the DM and the other desired boolean.

When an update to the SY control object is received subsequent display object updates are discarded until an update to the Dl or KB control object is received selecting the DM bit. If a 'VT- BREAK is received after an SY CO update has been received and prior to the corresponding Dl or KB CO update selecting the DM boolean, the discarding of updates is terminated. This is necessary

because the VT-BREAK may have caused the Dl or KB CO update to be purged.

3. The Nl and NA control objects are used to emulate the TELNET option negotiation facility. The

facility is symmetric, allowing either party to open negotiation for a change of mode, and every

negotiation must be accepted or rejected by the opposite party. The rules for negotiation for each

of the option controls are as stated in RFC 854 and as given below.

a. Only open negotiation for a change from the current state.

b. Only acknowledge negotiation for a change from the current state.

c. Do not send any object updates with a negotiation outstanding except an update to the

Nl (or NA) control object to acknowledge negotiation.

For full symmetry, both the Nl and NA control objects have the same value definition and consist

of 4 booleans with the semantics given in Table 8.

Table 8 - Ni/NA CO value definition

BIT

.... Option Value J

1 Remote Echo "false" Echo is Local;

"true" Echo is remote

2 Suppress Go Ahead "false" GO Ahead;

"true" Suppress Go Ahead

3 Binary WACA "true" use binary WACA;

"false" use default or negotiated

repertoire for WACA display object

4 Binary WACI "true" use binary WACI;

"false" use default or negotiated

repertoire for WACI display object

19
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Booleans 3 and 4 control the use of the Transparent character set for the D and K display objects

respectively. A value of '1rue" indicates the use of the binary repertoire; "false" indicates the use

of the negotiated repertoire. When a party wants to change a repertoire assignment, it must

complete a successful TELNET negotiation to change the option control. Then the party with the access rights to the display object in question is required to perform the corresponding secondary

attribute modal update.

4. The TELNET EC (erase character) command will be mapped to a pointer relative (x: = x-1) update

and an erase current update. The TELNET EL (erase line) command will be mapped to an erasefull-x-arrav update (an erase operation where the extent is defined as <"start-x,"(Yc,Xc-l)> and a

pointer update to set x = 1 . These X dimension updates are the only times when backward explicit

addressing is permitted.

5. The X address of the pointer can be moved forward only by implicit pointer addressing. Addressing

of the Y dimension is limited to the next X-array update operation.

6. The VT next X-arrav update operation wil! be sent in place of the TELNET NVT "CR.LF" sequence.

7. While the "binary" repertoire is being used no mapping to pointer addressing or erase operations

will be done.

8. The repertoire designation "7-bit ASCI! (GO + CO)" refers to the repertoire invoked by ISO 2022

defined character set designating escape sequences <ESC> 2/8 4/2, "void," <ESC> 2/1 4/0. The

repertoire designation "7-bit ASCII (GO only)" refers to the repertoire invoked by the ISO 2022

defined character set designating escape sequence <ESC> 2/8 4/2. The designation "binary"

; refers to the "Virtual Terminal Service Transparent Set" registered in the International Register under

ISO 2375 register value 125 and invoked by the escape sequence <ESC> 2/5 2/15 4/2.

9. No termination event list is specified so that data buffering and delivery can be controlled according

to context. If local echoing is enabled, the local newline or enter event shall trigger a VT-DEUVER

request. With remote echo a timeout or buffer length may be used to trigger a VT-DELIVER request.

This buffer length may be 1

.

8.1 .6.2 Informative Notes

1 . Users of this profile should refer to the TELNET specification (MIL-STD-1 782) and RFCs 854 and 855

for semantics of the TELNET commands. These documents can be obtained by contacting SRI

International, DDN Network Information Center, 333 Ravenswood Ave., Menio Park, CA 94025, (415)

859-3695.

2. An update to the GA control object is equivalent to the TELNET Go Ahead command.

3. If the "go ahead" facility has been negotiated then follovk/ing a VT-BREAK, only the association

acceptor has the right to send data. In the event of VT-BREAK the echo control objects are

20
PART 14 - VIRTUAL TERWIINAL December 1990 (Stable)

reinitialized to 'lalse," meaning local echo. If remote echo is desired it must be re-negotiated

following VT-BREAK.

4. Negotiation of TELNET options other than echo, transmit binary, and SUPPRESS GO AHEAD is not supported by this profile. Negotiations for these three options can take place at any time during a session.

8.1.7 Specific Conformance Requirements

The following character sets are required:

- The GO character set for U.S. 7-bit ASCII (values 32-126),

- The full U.S. 7-bit ASCII (values 0-127), and

- The transparent character set, see Definitive Note 8 in clause 8.1.6.1.

8.2 Transparent Profile

OIW VTE-Profile Transparent-1988 (r1)

8.2.1 introduction

This profile is intended to provide a transparent mode of operation which allows VT-users to exchange

transparently uninterpreted sequences of characters but with the added benefit of delivery control to enable

the VT-users to determine when the character sequences are to be delivered.

This profile may be used when VT-users wish to control terminals directly through the use of embedded

control characters.

8.2.2 Association Requirements

I 8.2.2.1 Functional Units

No additional functional units are required by this profile.

21
PART 14

8.2.2.2

- VIRTUAL TERMINAL

Mode

December 1990 (Stable)

This is an A-mode profile.

8.2.3 Profile Body

Display-objects * (double occurrence)* =

{

{

display-object-name = D1,

do-access = "WACA,"

dimensions = "one,"

x-dimension =

{

x-addressing = "not-permitted"

repertoire-assignment = profile-argument-r1

}.

{

display-object-name = D2,

do-access = "WACI,"

dimensions = "one,"

x-dimension =

{

x-addressing = "not-permitted"

}.

repertoire-assignment = profile-argument-r1

}

type-of-delivery-control = "simple-delivery-control."

8.2.4 Profile Arguments

r1 - is optional and enables negotiation of a value for the VTE-parameter repertoire-assignment for the

two display objects (which always have the same value of repertoire assignment when the profile

is called). The default value of this argument is the "Virtual Terminal Transparent Set" registered in the International Register under ISO 2375 register value 125, invoked by the escape sequence

<ESC> 2/5 2/15 4/2. This argument is identified by the identifier for repertoire-assignment for display object D1

.

22
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

8.2.5 Profile dependent Control Object Information

This profile does not reference any Control Objects.

8.2.6 Profile Notes

1 . This profile is intended primarily for applications requiring a sinnultaneous two way exchange of sequences of uninterpreted characters. The semantics usually associated with the display object are not used; for the purposes of this profile, the primary attributes of the character-box graphic

elements are actually octets which are passed directly to the real device. There is no relationship

between the elements of the X-array and the character boxes of the real device; the secondary

attributes of the display object are not utilized. The only operation on the display object which must

be supported is the text operation. An alternative repertoire may be selected.

8.2.7 Specific Conformance Requirements

Support for the default (transparent) character set is required. It is strongly recommended that the profile

argument not be used.

8.3 Forms Profile

OIW VTE-Profile Forms-1989 (r1,r2, . . . r28)

8.3.1 Introduction

This S-mode VTE-profile is intended for supporting the use of forms based, field oriented data entry

applications between a terminal and a host system.

It provides facilities for:

- defining and using screen forms,

- defining field validation and field entry rules, and

- controlling and validating field entry.

This VTE-profile includes support of an optional terminal-end locally attached printer.

23
PART 14

8.3.2

- VIRTUAL TERMINAL

Association Requirements

December 1990 (Stable)

8.3.2.1 Functional Units

The following VT functional units are required for operation with this profile:

- Enhanced access-rules,

- Structured COs,

- Fields, and

- Reference Information Objects

The following VT functional units are optional for operation with this profile:

- Urgent Data

8.3.2.2 Mode

This is an S-mode profile.

8.3.3 Profile Body

Display-objects * (single occurrence)* =

{

display-object-name = A,

DO-access = "WAVAR,"

dimensions = "three,"

x-dimension =

{

x-bound

x-addressing

x-absolute

x-window

y-dimension =

{

y-bound

y-addressing

profile-argument-r1,

"no constraint,"

"yes,"

x-bound

profile-argument-r2,

"no constraint,"

24
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

y-absolute

y-window

},

= "yes," = y-bound

z-dimension =

{

z-bound

z-addressing

z-absolute

z-window

}.

= "unbounded," = "no constraint," = no, = profile-argument-r3

erasure-capability = "yes,"

repertoire-capability * (implicitly defined by r4)*,

repertoire-assignment = profile-argument-r4,

font-capability * (implicitly defined by r5)*,

font-assignment = profile-argument-r5,

DO-emphasis = profile-argument-r6,

foreground-colour-capability = profile-argument-r7,

foreground-colour-assignment = profile-argument-r8,

background-colour-capability = profile-argument-r7,

background-colour-assignment = profile-argument-r9,

block-definition-capability = "no,"

field-definition-capability = "yes,"

max-fields = "unbounded,"

max-field-elements = profile-argument-r10,

access-outside-fields = profile-argument-r1

Control-objects =

{

{ *(Field Definition CO)*

CO-name

CO-type-identifier

CO-structure

= FD, = vt-b-sco-fdco, = "non-parametric," = "WAVAR" + profile-argument-r12, = "normal," = "not-selected"

CO-access

CO-priority

CO-trigger

}.

{ *(Field Entry Instructions CO)*

CO-name = El,

25
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

CO-type-identifier

CO-structure

CO-access

CO-priority

co-trigger

}.

{ *(Field Entry Pilot CO)*

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

}.

{ *(Context CO)*

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

= "mandatory-feico," = "non-parametric," = "WAVAR" + profile-argument-r12, = "normal," = "not-selected"

= EP, = "mandatory-fepco," = "non-parametric," = "WAVAR" -I- profile-argument-r12, = "normal," = "not-selected"

= CC,

= vt-b-sco-cco, = 6, = "WAVAR,"

= "normal," = "not-selected"

{ *{Transmission Policy CO)'

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

CO-category

co-size

}.

{ *(Multiple occurrence of optional COs. All unspecified VTE-parameters of such CDs

are determined by their CO-type-identifier through their registered definition. They may

include parameters specified to be additional profile arguments, which should follow the

appropriate CO-type-identifier argument value)*

TP,

vt-b-sco-tpco,

1,

"WAVAR" + profile-argument-r12,

"normal,"

"not-selected,"

"boolean."

4

CO-name

CO-type-identifier = profile-argument-r13, = profile-argument-r14

26
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

{ *{Form Waiting Time CO)*

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

CO-category

co-size

= WT,

= "waiting-time," = 1, = "WAVAR,"

= "normal," = "not-selected," = "integer," = 65535

*(The initial value for WT is zero, implying that a Form Waiting Time is not to be used.)*

*(The following four COs, (SA, UA, ST, and UT), are registered with the OIW registration authority

and are referenced by this profile.)*

{ *(As defined in clause 7)*

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

CO-category

CO-size

},

{ *{As defined in clause 7)*

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

CO-category

CO-size

},

{ *(As defined in clause 7)*

CO-name

CO-type-identifier

CO-structure

CO-access

SA,

oiw-vt-co-misc-sa,

1,

"WAVAR" + profile-argument-r12,

"normal,"

"not-selected,"

"symbolic,"

11

UA,

oiw-vt-co-misc-ua,

1,profile-argument-rl 2,

"urgent,"

"not-selected,"

"symbolic,"

11

ST,

oiw-vt-co-misc-st,

1,"WAVAR" + opposite of profile-argument-r1 2,

27
PART 14 " VIRTUAL TERMINAL December 1990 (Stable)

CO-priority

CO-trigger

CO-category

CO-size

}.

{ *(As defined in clause 7)*

CO-name

CO-type-identifier

CO-structure

CO-access

CO-priority

CO-trigger

CO-category

CO-size

"normal,"

"not-selected,"

"integer,"

65535

UT,

oiw-vt-co-misc-ut,

1.opposite of profile-argument-r12,

"urgent,"

"not-selected,"

"integer,"

65535

Device-objects *(single or double occurrence)* =

{

{

device-name = D,

device-default-CO-access = "WAVAR,"

device-default-CO-priority = "normal,"

device-default-CO-trigger = "not-selected,"

device-default-CO-initial-value = 1 ."true," device-repertoire-assignment = profile-argument-r15,

device-font-assignment = profile-argument-r16,

device-emphasis = profile-argument-r17,

device-foreground-colour-assignment = profile-argument-r1 8,

device-background-colour-assignment = profile-argument-r19,

device-minimum-X-array-length = profile-argument-r20,

device-minimum-Y-array-length = profile-argument-r21,

device-control-object = FD,

device-control-object = CC,

device-control-object = SA,

device-control-object = UA,

device-control-object = ST,

device-control-object = UT,

device-control-object = WT,

device-control-object = TP,

device-control-object = profiie-argument-r22,

device-display-object = A

28
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

}

IF r23 = "true" THEN *(define printer)*

{

device-name = P,

device-default-CO-access = "NSAC,"

device-default-CO-priority = "high,"

device-default-CO-trigger = "not-selected,"

device-default-CO-initial-value = 1 ."false,"

device-repertoire-assignment = profile-argument-r24,

device-font-assignment = profile-argument-r25,

device-emphasis = profile-argument-r26,

device-foreground-colour-assignment = profile-argument-r27,

device-background-colour-assignment = profile-argument-r28,

device-minimum-X-array-length = profile-argument-r29,

device-minimum-Y-array-length = profile-argument-r30,

device-control-object = FD,

device-control-object = SA,

device-control-object = UA,

device-control-object = profile-argument-r31,

device-display-object = A

type-of-delivery-control = "simple delivery control."

8.3.4 FIXED Field Entry instruction Definitions - non-parametric

Field entry Is optional. This FEI is provided for completeness only, as a field not linked to one of the

Mandatory field, Selectable field or Protected field FEIs is necessarily optional. This FEI can never be

violated.

}

}

8.3.4.1 Optional Field

8.3.4.2 Mandatory Field

29
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Field entry is mandatory. Violation of this FEI will occur if all array elements of this field are empty when

one of the reactions FER01 (Transmit updates) or FER02 (Relinquish WAVAR) is initiated. See also the

specification of these reactions given below.

8.3.4.3 Protected Field

The field is protected from field entry. Violation of this FEI will occur if an attempt is made to change the

primary or secondary attribute of any array element of this field.

8.3.4.4 Fill Field

All array elements k=1 through k=last must have a primary attribute. Violation of this FEI will occur if any

array element of this field is empty when one of the reactions FER01 (Transmit updates) or FER02

(Relinquish WAVAR) is initiated. See also the specification of these reactions given below.

8.3.4.5 Echo Received Character

Allowed field entry characters are to be echoed as received. This FEI is provided for completeness only, as by default characters will be echoed as received unless the field is linked to either the Echo Off or the

Echo Specified Character FEI. This FEI can never be violated.

8.3.4.6 Echo Off

Received field entry characters should not be echoed. This FEI can never be violated.

8.3.4.7 Ignore Case

If this FEI is linked to a field, upper and lower case alphabetic characters should be considered as equivalent

during the validation of field input against all other FEIs linked to the same field. This affects the

interpretation of the Allowed First Characters, Allowed Characters, Disallowed Characters and Allowed String

Values FEIs, including the precedence rules between the first three of these FEIs. This FEI can never be

violated.

8.3.4.8 Inhibit Logical Rendition Attribute Operation

No form of logical attribute operation, with the exception of character repertoire switching as given below, can be performed on the field. Character repertoire changes are permitted if also permitted by Allowed First Characters or Allowed Characters, see below. This FEI is intended to be used when the rendition secondary

30
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

attributes are to be l<ept under "application" control. See, for exannple, Allowed First Characters for a case

of reference to the field modal values.

8.3.5 DYNAMIC Field Entry Instruction Definitions - parametric

8.3.5.1 Selectable field

The field is selectable, i.e., field entry is not permitted but information is conveyed by the selection of one

such field from a number of alternatives.

The manner in which the field that is the current candidate for selection is displayed on the real device is determined by the optional "visit" parameter of this FEI. This parameter specifies the secondary attributes to be used for showing or highlighting this candidate to the user. If it is omitted, an implementationdependent default is used.

The manner in which the field that is actually selected is displayed on the real device is determined by the

optional "select" parameter of this FEI. This parameter specifies the secondary attributes to be used for showing or highlighting the selected field to the user. If it is omitted, an implementation-dependent default

is used.

t

I The mechanisms for moving among candidates and for actually selecting the current candidate are

1 implementation defined. Typically, a selectable field will be considered as a candidate for selection when

I the cursor is placed on a character within the selectable field. Actual selection generates the Field Selected

FEE. A selected field is indicated in a delivered update by an addressing operation setting k=1 and f and

z to indicate the selected field. These values will be reported to the host in the CCO if WAVAR is

j relinquished in reaction to this FEE. Violation of this FEI will occur if an attempt is made to change the

I primary or secondary attribute of any array element of this field.

8.3.5.2 Echo Specified Character

I Specifies the character which is to be echoed to the user in response to each allowed character entered

into the field. The secondary attributes of the echoed character may be specified. Any secondary attribute

j that is not given an explicit value in the FEI takes a default value in accordance with Definitive Note 4. This

I FEI can never be violated.

1

8.3.5.3 Minimum Entry

^ All array elements k= 1 through k= Minimum Entry must have a primary attribute. If Minimum Entry exceeds

J field size, then all positions in the field must be filled. Violation of this FEI will occur if any of the specified array elements are empty when one of the reactions FER01 (Transmit updates) or FER02 (Relinquish

WAVAR) is initiated. See also the specification of these reactions given below. When a field is associated

31
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

with both the Optional Field FEI and a Minimum Entry FEI, the field is optional but if entry is elected, the

number of characters specified by the Minimum Entry FEI must then be entered.

Specifies a set of allowed characters for the first character position of the field. Either primary attributes

alone or both primary and secondary attributes may be checl<ed; see Definitive Note 3.

Specifies a set of allowed characters for all character positions within the field. Either primary attributes

alone or both primary and secondary attributes may be checked; see Definitive Note 3. If Allowed First Characters and Allowed Characters are both specified for a particular field, then the set of Allowed First Characters applies to the first character position of the field and the set of Allowed Characters applies to the second through last character positions of the field.

8.3.5.6 Disallowed Characters

Specifies a set of disallowed characters for all character positions within a field. Either primary attributes alone or both primary and secondary attributes may be checked; see Definitive Note 3. If Allowed First Characters and Disallowed Characters are both specified for a particular field, then the set of Allowed First Characters applies to the first character position of the field and the set of Disallowed Characters applies

to the second through last character positions of the field. When a field is associated with Allowed

Characters FEI(s) and Disallowed Characters FEI(s) that have characters in common, the common

characters are considered as disallowed.

8.3.5.7 Entry Invoke Character

Specifies the attributes to be used for showing or highlighting to the user where the next character entry is to be made. Both primary and secondary attributes, or secondary attributes alone, may be specified to over-ride the corresponding values present in the array element concerned. Any secondary attribute that

is not given an explicit value in the FEI takes a default value in accordance with Definitive Note 4. Fields

that are not linked to an Entry Invoke Character FEI, utilize a device dependent entry invoke character

which may or may not be represented in the character repertoire negotiated for the device. This FEI can

never be violated.

8.3.5.8 Waiting Time

Specifies the number of seconds to wait for field entry to complete after the cursor has been positioned

within the field. Fields that are not associated with a Waiting Time FEI are not subject to the "Field Waiting

8.3.5,4 Allowed First Characters

8.3.5.5 Allowed Characters

32
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Time Expired" Field Entry Event. Note tliat an overall waiting time for an entire form may be set by use of the Vaiting-time" control object defined in Definitive Note 1. This FEI can never be violated.

8.3.5.9 Allowed String Values

Specifies a list of strings which identify valid field values. The strings are specified as either a discrete

OCTET STRING or a range of OCTET STRING, or combination of both.

Ranges are specified using a lower "value" OCTET STRING and a higher "value" OCTET STRING. The

"value" of an OCTET STRING is the integer value derived from the collating sequence corresponding to the

repertoire explicitly or implicitly specified for the OCTET STRING. For example, the ISO 646 string 'AB' has

the integer value 4142(16) and the string 'ABC has the value 414243(16).

When strings of unequal length are compared, the smaller string is filled on the right with enough spaces

to make the strings of equal length. The comparison of ISO 646 strings 'AB' and 'ABC would be

accomplished by first converting the string 'AB' to 'AB' thus creating the value 414220(16) to be compared

against the value 414243(16). The value of the space character is derived from the collating sequence

corresponding to the repertoire identified in the field modal attributes. If this repertoire does not contain a

space, then the value 20(16) is used.

Either primary attributes alone or both primary and secondary attributes may be checked; see Definitive Note

3. A single set of secondary attribute values may be specified for each individual OCTET STRING or range

of OCTET STRINGS.

8.3.5.10 Allowed Mumeric Values

Specifies a list of numeric strings which identify valid field values. The strings are specified as either a

discrete OCTET STRING or a range of OCTET STRING, or a combination of both.

' Ranges are specified using a lower "value" OCTET STRING and a higher "value" OCTET STRING. The

"value" of an OCTET STRING is the integer value derived from the collating sequence corresponding to the

! repertoire explicitly or implicitly specified for the OCTET STRING. For example, the ISO 646 string '12' has

i the integer value 3132(16) and the string '123' has the integer value 313233(16).

f

I When strings of unequal length are compared, the smaller string is filled on the left with enough zero

I characters to make the strings of equal length. The comparison of ISO 646 strings '12' and '123' would be

accomplished by first converting the string '12' to '012' thus creating the value 303132(16) to be compared

against the value 313233(16). The value of the zero character is derived from the collating sequence

corresponding to the repertoire identified in the field modal attributes. If this repertoire does not contain a

zero, then the value 30(16) is used.

I

33

i!
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Either primary attributes alone or botli primary and secondary attributes may be checked; see Definitive Note

3. A single set of secondary attribute values may be specified for each individual OCTET STRING or range

of OCTET STRINGS.

8.3.6 Mutually Exclusive FEIs

Some FEIs specify field entry validation rules that are in conflict with the rules specified by other FEis. For

example, a particular field cannot be both "protected' and "mandatory." Such conflicting FEIs cannot be

associated with the same field. Table 9 defines the sets of conflicting FEIs.

34
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Table 9 - Sets of conflicting FEIs

FEI Conflicting FEIs

Optional Field Mandatory Field, Selectable Field, Protected Field

Mandatorv Field Ootional Field Seler't'able Field Pro1"er'i"ed Field

Selectable Field AX 1 ©xcAT^t "Rnl" r V Tnvolcp' r^ha r act* p r and Wa 1

1* i nn T i mp

Protected Field All

Fill Field Selectable Field, Protected Field, Allowed String

Values, Allowed Numeric Values

Echo Received

Character

Selectable Field, Protected Field, Echo Off, Echo

Specified Character

Echo Off Selectable Field, Protected Field, Echo Received

Character, Echo Specified Character

Ignore Case Selectable Field, Protected Field

Inhibit Logical

Rendition

Attribute Operation

Selectable Field, Protected Field

Echo Specified

Pharaot'er

Selectable Field, Protected Field, Echo Off, Echo

Received Character

MiniTniim Entrv Selectable Field, Protected Field

Allowed First

Characters

Selectable Field, Protected Field, Allowed String

Values, Allowed Numeric Values

Allowed Characters Selectable Field, Protected Field, Allowed String

Values, Allowed Numeric Values

Disallowed Characters Selectable Field, Protected Field, Allowed String

Values, Allowed Numeric Values

Entry Invoke Character Protected Field

Waiting Time Protected Field

Allowed String Values Selectable Field, Protected Field, Fill Field,

Allowed First Characters, Allowed Characters,

Disallowed Characters, Allowed Numeric Values

Allowed Numeric Values Selectable Field, Protected Field, Fill Field,

Allowed First Characters, Allowed Characters,

Disallowed Characters, Allowed String Values

35
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.7 FEICO Update Syntax

In the following syntax, ASN.1 Value Assignments have been used to attach value references to values of type NULL This enables the values to be referenced by these names alone, without the need to follow the

identifier explicitly with the value NULL

FEI DEFINITIONS ::= BEGIN

FEI ::= CHOICE {

feiO [0] IMPLICIT NULL,

feil [1] IMPLICIT NULL,

fei2 [2] IMPLICIT NULL,

feiS [3] IMPLICIT NULL,

fel4 [4] IMPLICIT NULL,

feiS [5] IMPLICIT NULL,

feia [6] IMPLICIT NULL,

fei7 [7]

[8]

IMPLICIT NULL,

selectableFleld IMPLICIT SEQUENCE {

visit [0] IMPLICIT SecAttributes OPTIONAL,

select [1] IMPLICIT SecAttributes OPTIONAL },

IMPLICIT Character,

IMPLICIT INTEGER,

IMPLICIT CharacterValues,

IMPLICIT CharacterValues,

IMPLICIT CharacterValues,

CHOICE {

},

IMPLICIT INTEGER,

IMPLICIT CharacterValues,

IMPLICIT CharacterValues }

::= feiO NULL

::= fei1 NULL

::= fei2 NULL

::= feiS NULL

::= fei4 NULL

::= feiS NULL

::= fei6 NULL

::= fei7 NULL

echoSpecifiedCharacter [9]

minimumEntries [10]

allowedFlrstCharacters [11]

allowedCharacters [12]

disallowedCharacters [13]

entrylnvokeCharacter [14]

[0] IMPLICIT Character,

[1] IMPLICIT SecAttributes

waitingTinne [15]

allowedStringValues [16]

allowedNumericValues [17]

optionalField FEI

mandatoryField FEI

protected Field FEI

fillField FEI

echoReceivedChar FEI

echoOff FEI

ignoreCase FEI

InhibitLogRendAttOp FEI

Character ::= SEQUENCE {

prinnaryValue [0] IMPLICIT PriValue,

36
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

attributes [1] IMPLICIT SecAttributes OPTIONAL

}

-- When used as one element of a comparison, secondary

-- attributes are to be compared only if the attributes

-- element is present.

CharacterValues ::= SEQUENCE OF SEQUENCE {

lowValue [0] IMPLICIT Character,

highValue [1] IMPLICIT PriValue OPTIONAL

}

- The default for highValue is the associated

-- lowValue. Octet values specified for highValue " are constrained by the repertoire corresponding

-- to the lowValue value. The relationship

-- [lowValue < = highValue] must be true.

PriValue ::= OCTET STRING

-- The octet string comprising a value of the PriValue

-- type is constrained to the encoding of a sequence

-- of characters from the repertoires negotiated for

-- the associated Display Object. When used in the

-- ASN.1 module FEI, the octet string is restricted to

-- the encoding of a single character except for its

-- use in allowedStringValues and allowedNumeric-

-- Values.

SecAttributes ::= SEQUENCE {

repertoire [0] IMPLICIT INTEGER OPTIONAL,

foregroundColour [1] IMPLICIT INTEGER OPTIONAL,

backgroundColour [2] IMPLICIT INTEGER OPTIONAL,

emphasis [31 IMPLICIT PrintableString OPTIONAL,

font [4] IMPLICIT INTEGER OPTIONAL }

END *(FEI DEFINITIONS)*

8.3.8 FEICO "mandatory-feico " Initial Content

For each FEIRxx, xx identifies the integer value to be used as "feirList recordlndex" in FDCOUpdate

operations. FEICOUpdate operations must use an "index" greater than 127. Note that the character

oriented FEIRs for the initial FEICO utilize the default secondary attributes, and that the Selectable Field FEI uses implementation-dependent defaults for the 'visit' and 'select' secondary attributes. The FEIR contents

are specified in terms of ASN.1 Value Notation appropriate to the FEICO Update Syntax specified above.

37
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table 10 - FEICO "mandatory-feico" Initial Content

FEIR Value

FEIROO — not used —

FEIROl optionalField

FEIR02 mandatoryField

FEIR03 selectableField { }

FEIR04 protectedField

FEIR05 f illField

FEIR06 echoReceivedCharacter

FEIR07 echoOf

f

FEIR08 ignoreCase

1 Iin LDLX, IjOgKenun L uup

FEIRIO allowedCharacters {{ lowValue {MI'H},

ni gnvalue da n j j — a^s^ . . . f£> —

FEIRll allowedCharacters { { lowValue { • 61h} , nignvaiue /a n j j —— a^ . .

.

/Z

VVTOT 0 axallxoweu^nar r\TAi^f^r*Vk aT-ai^-t-^-re ac ters ( f 1 r\w\7^ lii^ /^•^n'wl \. \, xowvaxue \. ju nj / highValue '39'U )} — 0,1,..., 9 -- FEIR13 disallowedCharacters {{ lowValue {'41'H},

highValue 'SA'H )} — A,B,...,Z —

FEIR14 disallowedCharacters {{ lowValue {'61'H},

highValue 'TA'H }} — a,b,...,z —

FEIR15 disallowedCharacters {{ lowValue {'30'H},

highValue '39'H }} — 0,1,..., 9 —

FEIR16-FEIR127 — These values are reserved —

8.3.9 Field Entry Event Definitions

The Field Entry Events for the mandatory FEPCO are defined in the following subclauses. A parameter of type "Range" is a sequence of integer pairs, each witfi an optional bitmask. Each pair gives the end points

of an interval of integer values. An integer value lies within the range specified if, after applying the bitmask

(if given) to its binary form, it lies in any of these intervals. The end points of an interval are included in the

values of that interval.

It is permissible for the ranges specified by the FEEs referenced in the entry control FEPR-list of a field to overlap. When an event occurs which is referenced in this way by more than one FEPR linked to the current

38
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

field, the FEPR invoked is the first FEPR In the FEPR-list which both references the event and for which the

Field Entry Conditions are satisfied.

8.3.9.1 FEEOO

Not used.

8.3.9.2 FEE01 Logical Keystroke event (Range)

This event takes a range of integers as a parameter, and occurs when a Logical Keystroke occurs within

the specified range. The Logical Keystroke is either initiated by the Logical Keystroke FER or by the human

user, see Definitive Note 8.

8.3.9.3 FEE02 Field entry complete

This event is generated by entry of a character into the last position in a field. It need not imply that all character positions in the field have been entered, since these positions are not necessarily written

sequentially. Local cursor movements, for example, may be used during local editing to move the current

entry position around the screen.

8.3.9.4 FEE03 Field selected

This event is generated by the selection of a field that is linked to the Selectable Field FEI. The means by

which the current candidate for selection is actually selected is implementation dependent.

8.3.9.5 FEE04 Field Waiting Time expired

The field waiting time specified by the Waiting Time FEI linked to the current field has been exceeded.

Fields not linked to such an FEI are not subject to this event.

8.3.9.6 FEE05 Field Entry Instruction violation

Some of the defined FEIs imply Field Entry Validation by the terminal VT-user. Fields linked to such FEIs

are candidates for erroneous field entry. This event is generated when such a violation occurs, thus

enabling linkage to Field Entry Reactions that may signal a visual or audible indication of such a violation, or alternatively may terminate local entry and relinquish WAVAR. A Violation FEC is available to allow

different reactions according to which FEIR is violated. When the reaction is to relinquish WAVAR, the Entrycontrol index and FEPR index elements of the Context Control Object will inform the host which FEPR

caused the return. If this FEPR has made use of the Violation FEC, this FEC will identify to the host that the

39
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

violated FEIR was one of those in the list that forms the paranrieter value for the FEC. Unique identification of the FEIR is obtained if this list contains only one FEIR. The host can then take whatever action is appropriate to the FEIR or FEIRs so identified.

8.3.10 Field Entry Condition Definitions

The elementary Field Entry Conditions for the mandatory FEPCO are defined below. Composite conditions can be built by use of the specified parameters, and an individual FEPR can include multiple conditions in accordance with 20.3.5.2 of ISO 9040.

A parameter of type Action is specified either as an explicit integer value or as the current keystroke, see

Definitive Note 8. Such a parameter evaluates to an integer of the type STCO.Key defined in clause 7.3.7. That clause also defines names of logical keystrokes associated with these integers. The local actions

associated with such values are defined in Definitive Note 9.

8.3.10.1 FECOO

Not used.

8.3.10.2 FEC01 No previous field

The current field has no currently defined previous field, in the sense of 20.3.3.4 of ISO 9040.

8.3.10.3 FEC02 No next field

The current field has no currently defined next field, in the sense of 20.3.3.4 of ISO 9040.

8.3.1 0.4 FEC03 Start of field

The current location for the next character entry is at the first location in the current field.

8.3.10.5 FEC04 End of field

The current location for the next character entry is at the last location in the current field.

40
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.1 0.6 FEC05 At tab stop

The current location for the next character entry is at a tabulation stop defined by the optional Horizontal

Tabulation CO {ewos-vt-co-misc-ht} registered with the EWOS Registration Authority. If this CO is not present in the VTE, this condition is deemed to be always satisfied.

8.3.10.7 FEC06 At characters (Set of character values)

The current location for the next character entry is at an array element whose current value is one of the

specified characters. The set of characters is specified arKl interpreted in accordance with Definitive Note

3.

8.3.10.8 FEC07 Exits field (Action)

The local action designated by the parameter value would move the location for the next character entry out of the current field

8.3.10.9 FEC08 Exits forward path (Action)

The local action designated by the parameter value would move the location for the next character entry out of the forward navigation path starting at the current field.

8.3.10.10 FEC09 Exits backward path (Action)

The local action designated by the parameter value would move the location for the next character entry out of the backward navigation path starting at the current field.

8.3.10.11 FEC10 Exits x-array (Action)

The local action designated by the parameter value would move the location for the next character entry out of the current x-array.

8.3.1 0.1 2 FEC1 1 Exits y-array (Action)

The local action designated by the parameter value would move the location for the next character entry out of the current y-array.

41
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.10.13 FECI 2 Not FEC (FEC)

This condition is satisfied precisely when the FEC given as its parameter is not satisfied.

8.3.10.14 FECI 3 And FECs (Set of FEC)

This condition is satisfied when each of the conditions in the set comprising its parameter is satisfied.

8.3.1 0.1 5 FECI 4 Or FECs (Set of FEC)

This condition is satisfied when at least one of the conditions in the set comprising its parameter is satisfied.

8.3.10.16 FECI 5 Violation (Set of FEIR Identifiers)

This condition is provided for use in conjunction with the Field Entry Instruction Violation FEE. Its parameter

is an FEIR-list specified as a set of FEIR identifiers. Each identifier is a pair <FEICO-name, index> where

index is an integer addressing a record in the FEICO whose name is specified. This FEC is satisfied if the

FEIR whose violation generated this event is one of the FEIRs in this FEIR-list. If it is used in conjunction

with any other FEE then this condition is true.

8.3.10.17 FECI 6 Unconditional

This condition is always true. It is given for completeness only, and has the same effect as an empty set of conditions in an FEPR.

8.3.11 Field Entry Reaction Definitions

The Field Entry Reactions for the mandatory FEPCO are defined below. The significance of a parameter

of type "Action" is as described for Field Entry Conditions. A parameter of type "ResetAttribute" may take

either of the two values "reset" and "noReset." Such a parameter controls the effect of an erase operation on the secondary attributes of the erased elements, corresponding to the values "yes" and "no" for the reset- attribute parameter of a LOGICAL-ERASE operation as defined in 19.2.3.5 of ISO 9040.

8.3.11.1 FEROO

Not used.

42
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.11.2 FER01 Transmit updates

The host copy of the CCA is updated to correspond to the terminal copy by the transmission of all undelivered update operations. The operations required to update field contents are controlled by the Tpolicy component of the Field Definition Record for the fields concerned. However, if this FER generates an FEI violation in accordance with the specifications of the FEICO(s) present in the VTE. and if the current

field is also linked to an FEPR with event FEE05 (FEI violation) and satisfied conditions, then this FER is not performed and that FEPR is activated; the original FEPR is abandoned.

8.3.1 1 .3 FER02 Relinquish WAVAR

The action described under Transmit Updates is performed, followed by return of the WAVAR access right to the host. However, if this FER generates an FEI violation in accordance with the specifications of the

FEICO(s) present in the VTE, and if the current field is also linked to an FEPR with event FEE05 (FEI

violation) and satisfied conditions, then this FER is not performed and that FEPR is activated; the original

FEPR is abandoned.

8.3.11.4 FER03 Erase field right (Reset attribute)

The primary attribute value is cancelled for all elements of the current field from the current character entry

location to the end of the field. The effect on the secondary attribute values is determined by the resetattribute parameter as described above.

8.3.11.5 FER04 Erase path right (Reset attribute)

The primary attribute value is cancelled for all elements of all unprotected fields in the fonA/ard navigation

path containing the current field, from the current character entry location onwards. Note that the forward

navigation path may not terminate, as its definition in 20.3.3.4 of ISO 9040 does not prohibit looping. When

a loop is entered during this operation, the operation terminates when all elements of the entered loop have

been erased. The effect of this operation on the secondary attribute values is determined by the resetattribute parameter as described above.

i 8.3.11.6 FER05 Local action (Action)

That local action is performed which is designated by the given parameter value. The specification of these

local actions is given in Definitive Note 9.

43
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.1 1 .7 FER06 Logical Keystroke (Action)

Initiate tlie FEPR processing wtiich would occur if the given keystroke had occurred. This may itself cause

the Logical Keystroke FER and hence recursive processings of FERs. Processing of current FERs is suspended until this recursive processing is complete. During recursive processing, the current keystroke

is taken as the argument to this FER. When the recursive processing is complete, the previous keystroke

is restored and processing of current FERs is resumed.

8.3.1 1 .8 FER07 Update ST CO (Action)

The integer value corresponding to the given parameter is written to the Sequenced Terminal CO. This FER

will usually be followed by a Transmit Updates or Relinquish WAVAR FER to communicate the update to the

application.

8.3.1 1 .9 FER08 Update UT CO (Action)

The integer value corresponding to the given parameter is written to the Unsequenced Terminal CO. This

update will be communicated to the application immediately.

8.3.11.10 FER09 Execute RIO record (RIO record Id)

An EXECUTE-RECORD operation is performed on the RIO record specified in the parameter, in accordance

with 22.4.1 of ISO 9040.

8.3.1 1 .1 1 FER01 0 Call RIO record (RIO record id)

A CALL-RECORD operation is performed on the RIO record specified in the parameter, in accordance with

22.4.2 of ISO 9040.

8.3.11.12 FER11 Visual indication

Present a visual indication in response to Field Entry Instruction violations.

8.3.1 1.13 FER1 2 Audible indication

Present an audible indication in response to Field Entry Instruction violations.

44
PART 14 - VIRTUAL TERMINAL

8.3.1 1.14 FER1 3 Conditional branch

December 1990 (Stable)

(if: FEC, then: Optional sequence of PER, else : Optional sequence of FER)

If the condition given by the "If' parameter is satisfied then perform the sequence of reactions given by the

'then" parameter, else perform the sequence of reactions given by the "else" parameter.

8.3.1 1.15 FER1 4 Prevent further entry

It is recommended that If a type-ahead buffer is in use by the local user interface, this reaction should

prevent further entry into the buffer. Attempted entry may then sound an alarm or be signalled by some

other local means, but is not an FEI violation. If the WAVAR access right is relinquished without this reaction

being invoked, the buffer may continue to accept entries. Entry Into the buffer is resumed when WAVAR

is next returned to the terminal. It is not a violation of this profile specification if the terminal VT-user does

not behave in the intended manner.

8.3.1 1.16 FER1 5 Write disallowed character

The most recent disallowed character is written as if it were not disallowed. If there has been no disallowed

character, the effect is null. This FER is used when it is desired to trap the entry of a particular character, not to forbid it but instead to generate some other reactions in addition to the character entry.

8.3.1 1.17 FER1 6 Write string (Character string)

The character string given as a parameter is written as LOGICAL TEXT to the current entry location without

regard to FEICO control. If the end of the field is reached before the string has been written in its entirety,

the reaction is terminated prematurely.

8.3.12 Field Entry Pilot Update Syntax

In the following syntax, ASN.1 Value Assignments have been used to attach value references to values of type NULL. This enables the values to be referenced by these names alone, without the need to follow the

identifier explicitly with the value NULL

45
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

FEPR DEFINITIONS ::= BEGIN

FEE ::= CHOICE {

logicalKeystroke

fee02

fee03

fee04

fee05

[1] IMPLICIT Range,

[2] IMPLICIT NULL,

[3] IMPLICIT NULL,

[4] IMPLICIT NULL,

[5] IMPLICIT NULL }

fieldEntryComplete FEE

fieldSelected FEE

fieldWaitTimeExpired FEE

feiViolation FEE

= fee02 NULL

= feeOS NULL

= fee04 NULL

= fee05 NULL

FEC ::= CHOICE {

fec01 [1] IMPLICIT NULL,

fec02 [2] IMPLICIT NULL,

fecOS [3] IMPLICIT NULL,

fec04 [4] IMPLICIT NULL,

fec05 [5] IMPLICIT NULL,

atChar [6] IMPLICIT FEI.CharacterValues,

exitsFleld [7] Action,

exitsForwardPath [8] Action,

exitsBackward Path [9] Action,

exitsXarray [10] Action,

exitsYarray ' [11] Action,

not [12] FEC,

and [13] IMPLICIT SET OF FEC,

or [14] IMPLICIT SET OF FEC,

violation [15] IMPLICIT SET OF SEQUENCE

{ feicoName PrintableStrinc

recordlndex INTEGER },

fec16 [16] IMPLICIT NULL }

noPreviousFleid FEC ::= fecOl NULL

noNextField FEC ::= fec02 NULL

startField FEC ::= fec03 NULL

endFleld FEC ::= fec04 NULL

atTab FEC ::= fec05 NULL

unconditional FEC ::= fec16 NULL

46
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

FER ::= CHOICE {

fer01 [1]

fer02 [2]

eraseFieldRight [3]

erasePath Right [4]

local [5]

logicalKeystroke [6]

updateSTCO [7]

updateUTCO [8]

executeRIO [9]

callRIO [10]

fer11 [11]

fan 2 [12]

branch [13]

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT ResetAttribute,

IMPLICIT ResetAttribute,

Action,

Action,

Action,

Action,

IMPLICIT RIORecordID,

if [1] FEC,

then [2] IMPLICIT SEQUENCE OF FER OPTIONAL,

else [3] IMPLICIT SEQUENCE OF FER OPTIONAL },

fer14 [14] IMPLICIT NULL,

fer15 [15] IMPLICIT NULL,

writeString [16] IMPLICIT SEQUENCE OF

FEI. Character

-- The string written by this FER is the - concatenation of the strings specified by

-- the individual FEI.Character values. - }

transmitUpdates FER : : = ferOI NULL

relinquishWAVAR FER : : = fer02 NULL

visuallndication FER : : = ferl 1 NULL

audiblelndication FER : := ferl 2 NULL

preventFurtherEntry FER : := ferl 4 NULL

writeDisallowedChar FER : := ferl 5 NULL

RIORecordID ::= SEQUENCE {

rioName [1] IMPLICIT PrintableString OPTIONAL,

-- optional if there is only 1 RIO in the VTE

recordID [2] IMPLICIT PrintableString }

Range ::= SEQUENCE OF SEQUENCE {

[1] IMPLICIT STCO.Key,

[2] IMPLICIT STCO.Key OPTIONAL,

mask [3] IMPLICIT BIT STRING OPTIONAL }

47
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

-- The first two values of each trio represent an

-- interval of logical keystroke values. The second

-- value in each pair shall not be smaller than the

first value. If the second value is omitted, the

-- interval contains only the specified first value.

-- If the optional mask is given, then the value being

-- tested is bitwise logically ANDed with the mask

-- before being compared with the end points of the - interval.

ResetAttribute ::= BOOLEAN

reset ResetAttribute ::= TRUE

noReset ResetAttribute ::= FALSE

Action ::= CHOICE {

[1] IMPLICIT STCO.Key,

current [2] IMPLICIT NULL }

currentKeystroke Action ::= current NULL

- The ASN.1 module STCO is defined in the specification of

-- the Sequenced Terminal CO in clause 7.3. STCO.Key is

-- an integer type with a named number list, each named

-- number representing a specific logical keystroke as

-- defined for that CO.

END *(FEPR DEFINITIONS)*

FEPCO "mandatory-fepco" Initial Content

For each FEPRxx, xx Identifies the integer value to be used as "feprList recordlndex" in FDCOUpdate

operations. FEPCOUpdate operations must use an "Index" greater than 127. The FEPR contents are specified in ternns of ASN.1 Value Notation appropriate to the FEPCO Update Syntax specified above. Note

that "shiftTab" is a named integer of type STCO.Key. The local action it designates is defined in Definitive Note 9 to be movement of the current character entry position to the first location of the next field in the

fonward navigation path.

48
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table 1 1 - FEPCP "mandatory-fepco" Initial Content

FEPR No Component ASN.l Descrip'tion

FEPROO —Not used

FEPROl FEE loaicalKevstroke f f 0. 65535 ) }

FEC uncond i t i onal

FEROl updateSTCO currentKeystroke

FER02 r e 1 i nqui shWAVAR

FEPR02 FEE f ieldEntryComplete

FEC noNextField

FER r e1 i nqu i shWAVAR

FEPR03 FEE f ieldEntryComplete

FEC not noNextField

FER local shiftTab

FEPR04 FEE f ieldSelected

FEC uncond i t i ona

FER r e 1 i nqu i s hWAVAR

FEPR05 FEE f ieldWaitTimeExpired

FEC noNextField

FER r e 1 i nqu i shWAVAR

FEPR06 FEE f ieldWai tTimeExpi red

FEC not noNextField

FER local shiftTab

FEPR07 FEE feiViolation

FEC uncond i t i onal

FER visual Indication

FEPR08 FEE feiViolation

FEC uncond i t i ona

FER audiblelndication

FEPR09- — Reserved —

FEPR127

8.3.13 Profile Arguments

r1 - is optional and provides for the negotiation of a value for tlie VTE-parameter x-bound.

integer value greater than zero. Default Is 80.

r2 - is optional and provides for the negotiation of a value for the VTE-parameter y-bound.

Integer value greater than zero. Default Is 24.

r3 - is optional and provides for the negotiation of a value for the VTE-parameter z-wlndow

Integer value greater than zero. Default is 1

49
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

r4 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter repertoire-assignment. The value for the VTE-parameter

repertoire-capability is implied by the number of occurrences of this profile argument. Default is a

single occurrence with the value {value iso2022 {'2842'H}} of ASN.1 type

CDS.RepertoireAssignment as defined in ISO 9041, designating the GL set ISO 2375 Reg. No. 6

(ASCII).

r5 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

va!ue(s) for the VTE-parameter font-assignment. The font-assignment-type component of a font- assignment value is an ASN.1 OBJECT IDENTIFIER that designates a registered syntax and

semantics for the font-assignment-value component. The value forthe VTE-parameter font-capability

is implied by the number of occurrences of this profile argument. If there are no explicit occurrences of this profile argument then the font-capability and font-assignment VTE-parameters

take the default values specified in ISO 9040.

r6 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter DO-emphasis. The syntax and semantics for this VTE-parameter are

specified in Definitive Note 6, and for this profile argument are specified in B.17.4 of ISO 9040. The

default value for the occurrence corresponding to each unspecified subattribute is the ASN.1

PrintableString of length 1 specifying the explicit modal default value for that subattribute.

r7 - is optional and provides for the negotiation of a value for the VTE-parameters

foreground-colour-capability and background-colour-capability. Default is 8. This argument is identified by the identifier for the VTE-parameter foreground-colour-capability for display object A.

r8 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter foreground-colour-assignment. The default values for unspecified occurrences of this profile argument are the corresponding values from the ordered list {"white,"

"black," "red," "cyan," "blue," "yellow," "green," "magenta"}. There are no default values if the value

of the VTE-parameter foreground-colour-capability exceeds 8.

r9 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter background-colour-assignment. The default values for unspecified occurrences of this profile argument are the corresponding values from the ordered list {"black,"

"white," "cyan," "red," "yellow," "blue," "magenta," "green"}. There are no default values if the value

of the VTE-parameter background-colour-capability exceeds 8.

r10 - is optional and provides for the negotiation of a value for the VTE-parameter max-field-elements.

Default is 1

.

r1 1 - is optional and provides for the negotiation of a value for the VTE-parameter access-outside-fields.

Default is "not allowed."

r12 - is mandatory and provides for the negotiation of a value for the VTE-parameter CO-access for the

Field Definition, Field Entry Instruction, Field Entry Pilot, Transmission Policy, Sequenced

Application, Unsequenced Application, Sequenced Terminal, and Unsequenced Terminal control

50
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

objects. If the VT-association initiator is tlie terminal VT-user. it takes the value "WACA," otherwise

it takes the value "WACI." This argument is identified by the kJentifier for CO-access for control

object UA.

r13 - is optional, may occur a number of times and provkJes for the negotiation of a value for the VTEparameter CO-name for optional registered COs. By default no optional COs are invoked.

r14 - is optional, may occur a number of times and provWes for the negotiation of a value for the VTEparameter CO-type-kJentlfier for optional registered COs. The particular generic type concerned is determined from the CO-type-Wentifier by the register entry. The value vt-b-sco-nullrio selects an empty RIO. An occurrence of the previous argument specifies the presence of an optional CO in the VTE-profile. An occurrence of this argument is required for every occurrence of the previous

argument. By default no optional COs are Invoked.

r15 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-repertoire-assignment for the main device. Default is "null" for each unspecified occurrence.

r16 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-font-assignment for the main device. Default is "null" for each

unspecified occurrence.

r17 - is optional, may occur a number of times In an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-emphasis for the main device. The syntax and semantics for

this VTE-parameter are specified in Definitive Note 6, and for this profile argument are specified in B.17.4 of ISO 9040. Default is "null" for each unspecified occurrence.

r18 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-foreground-colour-assignment for the main device. Default

is "null" for each unspecified occurrence.

r19 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-background-colour-assignment for the main device. Default

is "null" for each unspecified occurrence.

r20 - is optional and provides for the negotiation of a value for the VTE-parameter

device-minimum-X-array-length for the main device. It takes an integer value greater than zero. Default is the value of x-bound for the display object.

r21 - is optional and provides for the negotiation of a value for the VTE-parameter

device-minimum-Y-array-length for the main device. It takes an integer value greater than zero. Default is the value of y-bound for the display object.

r22 - is optional, may occur a number of times and provides for the negotiation of additional values for the VTE-parameter device-control-object for the main device. By default there are no additional

values.

51
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

r23 - is a special profile argument identified by the special-profile-arg-ident "Pp-1 ." It is optional and

provides for the negotiation of a printer device. Default is "false."

r24 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-repertoire-assignment for the printer device. Default is "null" for each unspecified occurrence.

j

r25 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a | value(s) for the VTE-parameter device-font-assignment for the printer device. Default is "null" for each '

ii unspecified occurrence.

r26 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a

value(s) for the VTE-parameter device-emphasis for the printer device. The syntax and semantics

for this VTE-parameter are specified in Definitive Note 6, and for this profile argument are specified

in B.17.4 of ISO 9040. Default is "null" for each unspecified occurrence.

r27 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a t value(s) for the VTE-parameter device-foreground-colour-assignment for the printer device. Default

is "black" for each unspecified occurrence.

r28 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a j, value(s) for the VTE-parameter device-background-colour-assignment for the printer device. Default

is "white" for each unspecified occurrence.

r29 - is optional and provides for the negotiation of a value for the VTE-parameter

device-minimum-X-array-length for the printer device. It takes an integer value greater than zero. Default Is the value of x-bound for the display object.

r30 - is optional and provides for the negotiation of a value for the VTE-parameter

device-minimum-Y-array-length for the printer device. It takes an integer value greater than zero. Default is the value of y-bound for the display object. i

r31 - is optional, may occur a number of times and provides for the negotiation of additional values for the VTE-parameter device-control-object for the printer device. By default there are no additional

values.

8.3.14 Profile Dependent Control Objects

This profile uses the OIW registered Control Objects SA, UA, ST and UT. The profile defined values are

specified in the body of this profile. The CO specifications require the usage of each CO to be specified

in the profile. This is as follows.

52
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.14.1 Sequenced Application CO

This Control Object is defined in 7.1. It has CO-category "symbolic." Update of this CO with the value

"audible_alarm" sounds an audible alarm in the terminal. Update with the value 'Visual alarm" generates a

visual indication of a signal from the application. All other values have no effect.

8.3.14.2 Unsequenced Application CO

This Control Object is defined in 7.2. It has CO-category "symbolic." Update of this CO with the value

"audible_alarm" sounds an audible alarm in the terminal. Update with the value "visual_alarm" generates a

visual indication of a signal from the application. All other values have no effect.

8.3.14.3 Sequenced Terminal CO

This Control Object is defined in 7.3. It has CO-category "integer." It is updated by the Update ST CO FER.

and may be used to communicate uninterpreted keystrokes to the application.

8.3.14.4 Unsequenced Terminal CO

This Control Object is defined in 7.4. It has CO-category "integer." It is updated by the Update UT CO FER

and is used to communicate uninterpreted keystrokes to the application urgently.

8.3.15 Profile Notes

8.3.15.1 Definitive Notes

1 . The WT control object provides a mechanism for the application VT-user to specify a time in which

all the fields of a form must be completed. The terminal VT-user starts the timer at the time when

it receives WAVAR. If the timer expires, further entry by the device is stopped, all undelivered

updates are transmitted, and WAVAR is relinquished. The undelivered updates are transmitted

followed by an update to this control object. The WT update is made using the current value of the

WT control object. The device-control-object VTE-parameter is used to link this CO to the input

device that it controls. The data element of this CO specifies the waiting time in seconds. A zero

value signifies that a Form Waiting Time is not to be used. The initial value of this data element is zero.

2. If there are two or more Character-oriented FEIs of the same type associated with the same field, they are equivalent to a single FEI of that type whose parameter is the concatenation of the

individual parameter values.

53
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

\

The following parameteric FEIs and FECs defined in clause 8.3.4 test equality of characters:

Allowed First Characters FEI

Allowed Characters FEI

Disallowed Characters FEI

Allowed String Values FEI I Allowed Numeric Values FEI

At Characters FEC \

The characters for each such FEI or FEC are specified by a parameter that includes an optional set of secondary attributes. If this set is included, the test is on both prirnary and secondary attributes; otherwise it is on primary attributes only. If the test is on primary attributes only, then characters

which pass the test are allowed, disallowed or accepted, as appropriate, irrespective of the values

of their secondary attributes. The set of secondary attributes need not specify an explicit value for every secondary attribute; in particular the empty set is permissible. Default values are used for

| unspecified secondary attributes. These are determined in accordance with Definitive Note 4.

|

4. . The parameter values for a number of FEIs, FECs and FERs require default values to be used for secondary attributes when such values are not specified explicitly by the parameter. The first choice

default for each secondary attribute value is the field modal attribute value at the time that the FEI, FEC or FER is accessed. A first choice default value of "null" is resolved as specified in 19.2.3.1 of ISO 9040 for the LOGICAL-TEXT update operation.

5. When the Character oriented FEIs associated with a particular field have characters in common, the

precedence algorithm given below is used.

The Allowed First Characters FEI takes precedence over the Allowed Characters and Disallowed

Characters FEIs for field character position l<=1.The Disallowed Characters FEI takes precedence

over the Allowed Characters FEI for all field character positions.

The following example illustrates the conflict resolution algorithm. When a particular field is linked to the following three Character oriented FEIs:

the field must be entered with the letter "a" in the first character position of the field. The remaining

character positions in the field are limited to containing the letter "b." Therefore field entry would

be limited to a form such as "abbbb. ..."

6; The following syntax and semantics is mandatory for the emphasis and device-emphasis VTEparameters. The scheme of B.I 7.3 of ISO 9040 is to be adopted except that the maximum length

for an ASN.1 PrintableString used as an emphasis value is increased from 6 characters to 8

characters. Values "B" (Boxed) and "C" (Encircled) are deleted from subattribute "b." Two further

Allowed First Characters

Allowed Characters

Disallowed Characters = a,b

= a

= a

54
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

subattributes are added, denoted by "g" and "h." The table of allowed character values, ISO 6429

SET GRAPHIC RENDITION parameter values and associated semantics given in B.I 7.3 of ISO 9040

is augmented by the addition of:

Subattribute "g" values

II

I

II = "U" * 3

23

Subattribute "h" values

= "F" 51 = "C" 52

= "N" * 54

Italicized characters

Upright, not italicized

characters

No change

Framed

Encircled

Not framed, not encircled

No change

As in B.I 7.3 of ISO 9040, * indicates the value which is the explicit modal default value for the

subattribute. Not all the values of this scheme need to have a 1-1 correspondence with emphasis

levels available on the real device. The device object defines the real mapping.

7. When default values are defined for a multiple-occurrence profile argument and fewer occurrences

are negotiated than are required by the value of a parent VTE-parameter, the remaining occurrences

still take the specified default values.

8. Every action corresponding to the operation of an object updating device shall be assigned a nonnegative integer value. This value shall be interpreted as a logical keystroke in accordance with the

definitions of the Sequenced Terminal CO and Unsequenced Terminal CO in 7.3 and 7.4.

Values in the range 0-255 are used to generate entry of characters into the Display Object from the

available repertoires. Values greater than 255 generate the Logical Keystroke FEE and thus have

effects that are under the control of the FEPCOs present in the VTE.

9. A minimum set of local actions is defined within this profile, but implementors may extend this as

required. A host implementation thus may not know what local action is being over-ridden when

it requests that a particular logical keystroke should be notified to the host. To prevent this from

limiting the capabilities of the terminal, two keystroke combinations that differ only in the inclusion or otherwise of the ALT key are required to have the same potential local action. Host

implementations are advised not to over-ride the action of both such keystrokes.

The defined minimum set of local actions concerns control of the current entry location. At any time

when the terminal possesses the WAVAR access right, there is a well-defined Display Object array element which is the current candidate for update by a character entry operation, as described in Informative Note 4. If this element lies outside of any field, or within a protected field, update is prohibited unless the negotiated value of the VTE-parameter access-outside-fields is "yes," but the

array element is still defined. Neither this location nor that of any cursors which the implementation

55
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

may use to indicate such elements is recorded In the CCA. It is separate from the current position

of either the display pointer or the logical pointer, and movement of this entry location is a purely

local action.

Table 12 - Local Actions that move entry location

Name Unshifted Action Shifted Action

lef tArrow X = x-1 k = k-1

rightArrow X = x+1 k = k+1

upArrow y = y-1 f s f-1, k = 1

downArrow y = y+1 f = f+1, k = 1

home (x,y,z) = "start-y" (k,f,z) = "start-k"

end (x,y,z) = "end-y" (k,f,z) = "end-k"

pageUp z = z-1, x=l, y=l z=z-l, f=l, k=l

PageDown z = z+1, x=l, y=l z = z+1, f = 1, k = 1

tab f = next(f), k = 1

backTab f - previous(f), k = 1

The names given in the first column of Table 12 are the identifiers of named integers of type

STCO.Key. The ASN.1 module STCO is defined as part of the specification of the Sequenced

Terminal Control Object in 7.3. These identifiers or the corresponding integers are used to designate the local actions specified in the second column. If the initial lower case letter of such a name is converted to upper case and prefixed with "shift" then it designates the local action

specified in the third column.

In this table, "=" is used as an assignment operator. The unshifted actions reference array elements

by normal (x, y, z) coordinates while the shifted actions reference them by logical (k, f, z) coordinates. The values next(f) and previous(f) are defined in 19.1.3.2.2 of ISO 9040, "start-k" and

"end-k" are defined in 19.1.3.5, and "start-y" and "end-y" are defined in 19.1.1.4 of ISO 9040.

If the initial or final coordinate values are undefined then the local action is implementationdependent. However, a host implementation can use the mandatory FEPCO to control the behavior

in such circumstances. Field Entry Conditions are provided to test whether a particular local action

would make the entry location leave the current field or navigation path, as defined in 8.3.10.

10. If the VTE-parameter access-outside-fields takes the value "allowed", when data entry terminates,

the display pointer shall be aligned with the current entry location by an explicit or implicit

addressing operation. In this way, the value of the display pointer notifies the application of the current entry location.

56
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

11. Use of the values "F" (Framed) and "C" (Encircled) for emphasis subattrlbute "h" causes groups of characters within a single field which have this subattrlbute value to be outlined by a frame. The

two subattributes differ only in that the external corners of the frame are squared if value "F" is used

and rounded if value "C" is used. An external corner is where two lines meet in a L shape, as

distinct from a T junction and from the intersection of two lines. The nature of the external corner

is controlled by the subattrlbute value of the array element on the inside of the corner.

More precisely, a character box element is defined to be within frame (f,z) if It is in the field with

coordinates (f,2) and has either the framed or encircled attribute. A character box element is defined to be without frame if either it is not in any field or it does not have either the framed or encircled attribute. In the image of a y-array on the real device, a line is drawn between two

adjacent images of character box elements if they are within different frames, or if one is within a frame and one Is without frame. In addition if a character box element is within some frame, a line

is drawn along any edge of that element which is not in common with any other character box

element, i.e., along any edges which are part of the image of the boundary of the Display Object.

8.3.15.2 Informative Notes

1. Updates by the application VT-user (only possible within the z-window) are not necessarily

immediately imaged to the (human user of the) terminal VT-user unless the real window of the

device is currently positioned over such an update. Such updates may move the real window if a VT-DELIVER indication is received.

When WAVAR is relinquished by the application VT-user the window may be moved so that the field addressed by the CCO is within the window.

Application VT-user addressing operations that advance z to a higher address which is outside of the z-window cause the z-window to move and include one or more new y-arrays for which no fields are defined. As the z-window moves, one or more y-arrays at lower addresses will no longer be

included in the z-window. The field definition records for such y-arrays are implicitly deleted.

2. Several of the descriptions of Field Entry Instructions refer to 'empty' array elements of the Display

Object. This is to be interpreted in the sense of 13.2 of ISO 9040. Note that in this sense an array element containing a space character is not empty. The representation of an empty array element on the real device is implementation-dependent, but for this reason it is recommended that the

representation used should be distinct from that of a space character.

3. The descriptions of a number of Field Entry Conditions refer to the current field and to the current

location for the next character entry. Typically this current location will be indicated to the human

user by a visible cursor. When this location lies within a defined field, that field is the current field and the Entry Invoke Character FEI may be used to specify the nature of the visible cursor. However, a terminal implementation may allow the visible cursor to be moved outside of any defined

field. While this is so, the representation of the cursor is implementation dependent, the current field

Is undefined and no FEPRs are active.

57
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8.3.18 Specific Conformance Requirements

For further agreement.

8.4 X3 Profile

0!W VTE-Profile X3-1989 ( r1, r2, r3. r4, r5. r6 )

8.4.1 Introduction

This profile provides support for CCITT X.3 PAD compatible operation.

The purpose of this profile is two-fold:

- to provide a transitional environment for applications that assunne the availability of X.3

parameters with which to control the behavior of the terminal-system.

- to facilitate a gateway function between ISO-VTP and X.3.

8.4.2 Association Requirements

8.4.2.1 Functional Units

The Structured CO Functional Unit is mandatory.

The Urgent Data Functional Unit is optional.

8.4.2.2 Mode

This is an A-mode profile.

8.4.3 Profile Body

Display-objects =

{

{

58
PART 14 - VIRTUAL TERIW8SNAL December 1990 (Stable)

display-object-name = D1,

DO-access = profile-argument-r1

,

dimensions = "one,"

x-dimension =

{

x-bound = "unbounded,"

x-addressing = "not-permitted,"

x-absolute = "no,"

x-window = 0

}.

repertoire-assignment = <ESC> 2/5 2/15 4/2

*( VTS Transparent Set )*

}.

{

display-object-name = D2,

DO-access = opposite of profile-argument-r1

,

dimensions = "one,"

x-dimension =

{

x-bound = "unbounded,"

x-addressing = "not-permitted,"

x-absolute = "no,"

x-window = 0

},

repertoire-assignment = <ESC> 2/5 2/15 4/2

*( VTS Transparent Set )*

},

}.

Control-objects =

{

{ *( PAD - Each element of the PAD CO represents a CCITT PAD parameter. The CO-element-id

of each element has been chosen so that it would be the same value as the CCITT PAD

parameter number that it represents. The PAD CO is used both to set CCITT PAD

parameter-equivalent values and to reply to an update to the READ CO. See Definitive

Note 25 for conventions concerning updates to this CO. )*

co-name = PAD,

co-structure = 22,

co-access = "NSAC,"

CO-priority = "normal,"

CO-trigger = "not-selected,"

{ *( X.3 parameter 1 - PAD recall )*

59
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

CO-element-id = 1,

CO-category = "transparent,"

co-size = 8 },

{ *( X.3 parameter 2 -- PAD echo )*

CO-element-id = 2,

CO-category = "boolean,"

co-size = 1 },

{ *( X.3 parameter 3 - Data Forwarding Character )*

CO-element-id = 3,

CO-category = "boolean,"

CO-size = 7 },

I

!

60
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

{ *( X.3 parameter 4 -- Idle Timer Delay )*

CO-element-id = 4,

CO-category = "integer,"

co-size = 255 },

{ *( X.3 parameter 5 -- Ancillary Device Control )*

CO-element-id = 5,

CO-category = "boolean,"

CO-size = 1 },

{ *( X.3 parameter 6 - Control of PAD Signals )*

CO-element-id = 6,

CO-category = "transparent,"

co-size = 4 },

{ *( X.3 parameter 7 - PAD action on receipt of Break )*

CO-element-id = 7,

CO-category = "boolean,"

CO-size = 5 },

{ *( X.3 parameter 8 ~ Discard Output )*

CO-element-id = 8,

CO-category = "boolean,"

CO-size = 1 },

{ *( X.3 parameter 9 ~ Padding After <CR> )*

CO-element-id = 9,

CO-category = "integer,"

CO-size = 7 },

{ *{ X.3 parameter 10 -- Line Folding )*

CO-element-id = 10,

CO-category = "Integer,"

co-size = 255 },

{ *( X.3 parameter 1 1 - Device Speed )*

CO-element-id =11,

CO-category = "symbolic,"

CO-category = 19 },

{ *(X.3 parameter 12 ~ Flow Control by Device )*

CO-element-id = 12,

CO-category = "boolean,"

CO-size = 1 },

{ *( X.3 parameter 13 - Insert <LF> after <CR> )*

CO-element-id = 13,

CO-category = "boolean,"

CO-size = 3 },

{ *( X.3 parameter 14 ~ Linefeed Padding )*

CO-element-id = 14,

CO-category = "integer,"

61

)
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

co-size = 7 },

*{ X.3 parameter 15 -- Editing )*

CO-element-id = 15,

CO-category = "boolean,"

co-size = 1 },

*{ X.3 parameter 16 - Character Delete )*

CO-element-id = 16,

CO-category = "character,"

CO-repertoire-assignment *( any from CO )* = "void," "void," <ESC> 2/1 4/0,

co-size = 1 },

*( X.3 parameter 17 -- Line Delete )*

CO-element-id = 17,

CO-category = "character,"

CO-repertoire-assignment *( any from CO )* = "void," "void," <ESC> 2/1 4/0,

co-size = 1 },

*( X.3 parameter 18 - Line Display )*

CO-element-id = 18,

CO-category = "character,"

CO-repertoire-assignment *{ any from CO )* = "void," "void," <ESC> 2/1 4/0,

CO-size = 1 },

*{ X.3 parameter 19 - Editing Service Signals )*

CO-element-id = 19,

CO-category = "transparent,"

CO-size = 8 },

*{ X.3 parameter 20 - Echo Mask )*

CO-element-id = 20,

CO-category = "boolean,"

CO-size = 8 },

*{ X.3 parameter 21 -- Parity Treatment )*

CO-element-id = 21,

CO-category = "boolean,"

CO-size = 2 },

*( X.3 parameter 22 -- Page Wait )*

CO-element-id = 22,

CO-category = "integer,"

CO-size = 256 }

{ *( READ -

62
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Each boolean of the READ CO represents an elennent-id of the PAD CO with the same

identifying value. The READ CO is used to request the current values of PAD CO, which

may have been changed by some local agent. See the description of the PAD CO for

how the update to this CO modifies the access to the PAD CO. )*

CO-name = READ,

CO-structure = 1,

CO-access = opposite of profile-argument-rl

,

CO-priority = "normal,"

CO-trigger = "not-selected,"

CO-category = "boolean,"

co-size = 22

}.

{ *( Break Out-of-Band - receipt of this control object represents "X.25 Interrupt"; use is applicable when boolean

1 of element-id 7 in PAD CO has the value "true." )*

CO-name = BO,

CO-structure = 1, CO-access = profile-argument-r1

,

CO-priority = "urgent,"

CO-trigger = "not-selected,"

CO-category = "symbolic,"

co-size = 1

},

{

*( Break In-Band - receipt of this control object represents "indication of break"; use is applicable when

boolean 3 of element-id 7 in PAD CO has the value "true." )*

CO-name = Bl,

CO-structure = 1,

CO-access = profile-argument-r1

,

CO-priority = "normal,"

CO-trigger = "selected,"

CO-category = "symbolic,"

CO-size = 1

63
PART 14 - VSRTUAL TERMINAL December 1990 (Stable)

{ *(CUDThis CO is used to optionally convey Call User Data which is normally carried in the

CCITT PAD call. The CO is not updatable, but may be given initial content value by

special profile arguments r2 and r3. The CO is parametric, with two elements, one

representing the protocol identifier field, and the other representing the call data field containing user data. )*

co-name = CUD,

CO-structure = 2,

CO-access = "no-access,"

{ *( Protocol Identifier )*

CO-element-id = 1,

CO-category = "character,"

CO-repertoire-assignment *( VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-Size = 4 },

{ *( User Data )*

CO-element-id = 2,

CO-category = "character,"

CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 124 }

}.

{

*( DTE - This CO is used to optionally indicate the calling and called DTE addresses which are normally available in a true CCITT PAD environment. They may not be updated, but may

be given initial content values by special profile arguments r4 and r5. )*

CO-name = DTE,

CO-structure = 2,

CO-access = "no-access,"

{ *( Calling DTE address )*

CO-element-id = 1, CO-category = "character,"

CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 15 },

{ *( Called DTE address )*

CO-element-id = 2,

CO-category = "character,"

CO-repertoire-assignment *(\/TS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 15 }

64
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

{ *( FAC - This CO is used to optionally indicate the CCITT facilities which are nornnally negotiable

during the establishment of a PAD virtual circuit. The negotiation takes place via special

profile argument r6, where the initiator may propose the initial content value, and the

acceptor may return other values. )*

co-name = FAC,

CO-structure = 1,

CO-access = "no-access,"

CO-category = "character,"

CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 127

Device-objects *(double occurrence)* =

{

{

device-name = DEVICE-1,

device-default-CO-access = profile-argument-rl

,

device-default-CO-priority = "normal,"

device-default-CO-trigger = "not-selected,"

device-default-CO-initial-va!ue = 1."true,"

device-minimum-X-array-length = 1,*(no constraint)*

device-control-object = {

Bl, BO, PAD },

device-display-object = D1

*(termination parameters are controlled explicitly through the values assigned to elements

3 and 4 of the PAD Control Object)*

}.

{

device-name = DEVICE-2,

device-default-CO-access = opposite of profile-argument-rl

,

device-default-CO-priority = "normal,"

device-default-CO-trigger = "not-selected,"

device-default-CO-initial-value = 1 ."true," device-minimum-X-array-length = 1, *(no constraint)*

device-control-object = { READ, PAD },

device-display-object = D2

}

}.

Type of delivery control = "simple-delivery-control."

65
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

8^4.4 Profile Arguments *

r1 - is mandatory, and is used to establisli the access rules for the display objects and several of the

control objects. If the terminal-system, i.e., that which includes the equivalent of the PAD function,

establishes the VTE-profi!e then the value of r1 should be "WACI". If the system not including the

PAD function establishes the VTE-profile then the value of r1 should be "WACA". This argument

takes one of the values "WACI" or "WACA." It is identified by the identifier for DO-access for display

object D1

.

r2 - is an optional special profile argument, and is used to set the intial content value of element 1 of the CUD CO. The value is encoded from the binary form to the ASN.1 type PrintableString

according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-1."

r3 - is an optional special profile argument, and is used to set the initial content value of element 2 of the CUD CO. The value is encoded from the binary form to the ASN.1 type PrintableString

according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-2."

r4 - is an optional special profile argument, and is used to set the initial content value of element 1 of the DTE CO. The value is encoded from the binary form to the ASN.1 type PrintableString

according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-3."

r5 - is an optional special profile argument, and is used to set the initial content value of element 2 of the DTE CO. The value is encoded from the binary form to the ASN.1 type PrintableString

according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-4."

r6 - is an optional special profile argument, and is used to set the initial content value of the FAC CO.

The value is encoded from the binary form to the ASN.1 type PrintableString according to the

algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-5."

8.4.5 Profile Notes

8.4.5.1 Definitive Notes

1. The value assigned to element 1 of PAD CO selects the character used to return control to the

terminal-system. The valid values and associated meanings are:

66
14 - VIRTUAL TERMINAL December 1990 (Stable)

Table 13 - PAD CO data element 1 value definition

value Meaning

0 not -permit ted

1 1/0 character (DLE)

32-126 graphic character

The value assigned to element 2 of PAD CO determines whether or not characters are echoed at the terminal-system. When the value of this boolean is "true," then the characters are echoed at the

terminal-system.

The values assigned to element 3 of PAD CO control the forwarding of characters from the terminalsystem to the application-system based on the character value. The defined booleans and

associated meanings are:

Table 14 - PAD CO data element 3 value definition

boolean neaning

1 alphanumeric (A-Z, a-z, 0-9)

2 character 0/13 (CR)

3 characters 1/11 (ESC), 0/7 (BEL),

0/5 (ENQ), 0/6 (ACK)

4 Characters 7/15 (DEL), 1/8 (CAN),

1/2 (DC2)

5 characters 0/3 (ETX), 0/4 (EOT),

6 characters 0/9 (HT), 0/10 (LF),

0/11 (VT), 0/12 (FF)

r

all others in coliunn 0 and 1 not

already included above

The value assigned to element 4 of PAD CO controls the fonwarding of characters from the terminalsystem to the application-system based on the duration of idle time elapsed between consecutive

characters received by the terminal-system from the device. The valid values include any nonnegative integer 0-255; a value between 1 and 255 indicates the time-out in twentieths of a second; a value of 0 means that a time-out is not a fonwarding condition.

The value assigned to element 5 of PAD CO determines whether the XON/XOFF flow-control

characters (1 /I and 1 /3) are available for use by the terminal-system. When the value of this element is "true," then the flow-control characters are available, and the terminal-system may use them to indicate to the device its readiness to accept characters from it.

67
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

6. The value assigned to element 6 of PAD CO determines whether the terminal-system issues

messages, called PAD service signals, to the device during the association. The specific service

signals are not a part of this profile definition, only the control of their issue.

7. ' The values assigned to element 7 of PAD CO determine the behavior at the terminal-system when

a Break is received from the device. The defined booleans and associated meanings are:

Table 15 - PAD CO data element 7 value definition

boolean Bteaning

1 update BO CO

2 release the association

3 update BI CO

4 return control to terminal-system

5 discard data from application-system

When all booleans have the value "false," there is no action at the terminal-system when a Break is received.

A useful combination of booleans with value "true" is (1 ,3,5). When a Break is received, the terminalsystem updates both the BO CO and the BI CO and discards all display-object updates from the

application-system until it receives an update to the PAD CO for element 8. The result is that the

data path has been cleared in both directions. Notice that this is non-destructive of control object

updates.

8. The value assigned to element 8 of PAD CO determines whether or not the terminal-system discards

data from the application-system. This element works with element 7 to acknowledge the receipt

of the Break and resume normal processing of display-object updates. The only valid value of this boolean in an update is "false."

9. The value assigned to element 9 of PAD CO indicates the number of padding cfiaracters to be

generated by the terminal-system to the device following a carriage return character. The valid values are integers in the range 0-7.

10. The value assigned to element 10 of PAD CO indicates the number of graphic characters sent to the device after which the terminal-system will insert a carriage return. The valid values are integers

in the range 0-255, where a value of 0 means that this function is not performed.

11. The value assigned to element 11 of PAD CO indicates the bit-transmission speed of the device.

This element may only appear in an update sent to the application-system in response to an update

of the READ CO when boolean 1 1 has the value "true."

63
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

12. The value assigned to element 12 of PAD CO determines whether the XON/XOFF flow-control

characters (1/1 and 1/3) are available for use by the device. When the value of this element is "true," then the flow-control characters are available, and the device may use them to indicate to the

terminal-system its readiness to accept characters from It.

13. The values assigned to element 13 of PAD CO determine under which situations a linefeed is inserted following a carriage return character. The valid values and associated meanings are:

Table 16 - PAD CO data element 13 value definition

boolean eaning

1 insert linefeed after carriage

return sent to device

2 insert linefeed after carriage

return received from device

3 insert linefeed after carriage

return echoed to the device

14. The values assigned to element 14 of PAD CO determine the number of padding characters

generated by the terminal-system to the device following a linefeed character. The valid values are any number in the range 0-7.

15. The value assigned to element 15 of PAD CO determines whether or not the terminal-system

performs data-editing. When this CO has value "true," the values of the elements 3 and 4 of the

PAD CO are ignored.

16. The value assigned to element 16 of PAD CO determines which character is used in editing the line to signify the function "delete character." The valid values are the IA5 characters, decimal value 0- 127. Only applicable if the value of element 15 of PAD CO is "true."

17. The value assigned to element 17 of PAD CO determines which character is used in editing to

signify the function "delete line." The valid values are the IA5 characters, decimal value 0-127. Only

applicable if the value of element 15 of PAD CO is "true."

18. The value assigned to element 18 of PAD CO determines which character is used in editing to

signify the function "display line." The valid values are the IA5 characters, decimal value 0-1 27. Only

applicable if the value of element 15 of PAD CO is "true."

19. The value assigned to element 19 of PAD CO determines whether the terminal-system provides for editing of PAD service signals. The valid values and meanings are as follows:

69
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table 17 - PAD CO data element 19 value definitions

value eaning

0 no editing

1 editing as for a paper device

2 editing as for a glass device

8 editing using one editing character

32-126 editing using one editing character

20. The values assigned to element 20 of PAD CO determines which characters are NOT to be echoed

to the device by the terminal-system. If no bits are set, then all characters are to be echoed,

assuming that element 2 has the value "true." The defined booleans and associated meanings are:

Table 18 - PAD CO data element 20 value definition

boolean mecming

1 Do not echo 0/13 (CR)

2 Do not echo 0/10 (LF)

3 Do not echo 0/11 (VT), 0/9 (HT), 0/12 (FF)

4 Do not echo 0/7 (BEL), 0/8 (BS)

5 Do not echo 1/11 (ESC), 0/5 (ENQ)

6 Do not echo 0/6 (ACK), 1/5 (NAK), 0/2 (STX),

0/1 (SOH), 0/4 (EOT), 1/7 (ETB), 0/3 (ETX)

7 Do not echo the editing characters defined by

data elements 16, 17, and 18 of the PAD CO

8 Do not echo 7/15 (DEL) or any of the other

characters belonging to CO or CI which are

not already mentioned above

21. The value assigned to element 21 of PAD CO determines the treatment of parity on the characters

received from and sent to the device from the terminal-system. The defined booleans and

associated meanings are:

70
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table 19 - PAD CO data element 21 value definition

boolecin Becming

1 parity is checked on characters

received from the device

2 parity is generated on characters

sent to the device

22. The value assigned to element 22 of PAD CO determines the number of linefeeds tliat the terminalsystem may send to the device before it must wait for input from the device to request it to continue

displaying characters. The range of valid values is 0-255, where a value of 0 indicates that the

terminal-system need never wait.

23. The TEXT operation is the only operation allowed on the display objects.

24. Special profile arguments r2-r6 have binary values. However, due to a restriction in the standards

9040 and 9041, those binary values must be conveyed in the ASN.1 type PrintableString. This is accomplished by mapping the value of each semi-octet in the string of binary octets to an octet whose value falls in the value range of a PrintableString. The semi-octet values in the range 0000 - 1001 are mapped into the PrintableString values '0' - '9', whereas the semi-octet values in the range

1010 - 1 1 1 1 are mapped into the PrintableString values 'A' - 'F'. The result is a string of characters

which is exactly twice the length of the original string of binary octets.

25. The value of CO-access for the PAD CO is "NSAC," however a convention is followed that determines when a VT-user may update the PAD CO. Only the VT-user with access to the Display

Object D2 may update the PAD CO except immediately after it has updated the READ CO. When

the READ CO upidate is received by the opposite VT-user, it is treated as a request to update the

PAD CO with the parameter values it is currently using, at which point that VT-user is required to respond.

8.4.5.2 Informative Notes

1. Users of this profile should refer to CCITT Recommendations X.3, X.28 and X.29 for the original

model for this profile.

2. The following values for the elements of the PAD CO are taken from the CCITT Simple standard

profile and may prove useful:

71
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Table 20 - CCITT Simple Standard profile

data element value meaning

1 1 possible to return control to

terminal-system using 0/1 (DLE)

2 l."true" echo performed at the terminal-system

3 1. "false",

2. "true", 3. "true",

4. "true", 5. "true",

6. "true", 7. "true"

forward on receipt of any character in

CO and CI

4 0 no time-out used for forwarding

condition

5 ——^

1. "true" terminal-system may use XON/XOFF to

flow-control the device

6 1. "true" service signals are sent

7 2. "true", all

others "false"

release the association when a Break

is received from the device

8 1. "false" deliver data to device

9 0 do not pad after CR

10 0 do not fold the line

11 read-only

12 1. "true" device may use XON/XOFF to flowcontrol the terminal-system

13 0 do not insert LF after CR

14 0 do not pad after LF

15 1. "false" do not edit data

16 7/15 (DEL) character delete

17 1/8 (CAN) line delete

18 1/2 (DC2) line display

19 1 edit as for paper

20 0 echo all characters

21 0 no parity checking or generation

22 0 no page wait

3. The following values for the elements of the PAD CO are taken from the CCITT Transparent standard

profile and may prove useful.

72
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Table 21 - CCITT Transparent Standard profile

data element value Beaning

1 0 control may not be returned to the

teriuinax—sys r em

2 1X « Lfaax1 eo" a rerminai—sysrem aoes not pertorm

character echo

oJ aix Dooxeans

"false" no forwarding on character value

4 20 forward on time-out of 1 second

5 —

1. "false" terminal-system may not flow-control

the device

6 1

. "false" service signals are never sent

7 2. "true", all

others "false"

release the association when a Break

is received from the device

8 1

. "false" deliver data to device

9 0 do not pad after CR

10 0 do not fold the line

11 read-only

12 1

. "false" device may not flow-control the

terminal-system

13 0 do not insert LF after CR

14 0 do not pad after LF

15 1. "false" do not edit data

16 7/15 (DEL) character delete

17 1/8 (CAN) line delete

18 1/2 (DC2) line display

19 1 edit as for paper

20 0 echo all characters

21 0 no parity checking or generation

22 0 no page wait

73
PART 14 - VIRTUAL TERMINAL

8.4.6 Specific Conformance Requirements

None.

December 1990 (Stable)
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Annex A (normative)

Specific ASE Requirements

For specific ASE Requirements identified by the Upper Layer SIG for Virtual Ternninals, see Stable

Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers.

75
PART 14 - VIRTUAL TERMINAL December 1990 (Stable)

Annex B (normative)

Clarifications

Defaults

When a profile argument is not present in either the offer or vaiue list, the default for the corresponding VTE

parameter is specified by ISO 9040 if it is not given by the argument description in the profile.

76
PART 1 4 - VIRTUAL TERMINAL December 1 990 (Stable)

Annex C (normative)

Object Identifiers

General identifiers:

oiw-vt OBJECT IDENTIFIER :: =

{ iso(1) identified-organization(3) oiw(14) vtsig(12) }

olw-vt-pr OBJECT IDENTIFIER :: =

{ oiw-vt vteProfile(l) }

oiw-vt-co OBJECT IDENTIFIER :: =

{ oiw-vt controlObject(O) }

oiw-vt-co-misc OBJECT IDENTIFIER :: =

{ oiw-vt-co cotypennisc(0) }

oiw-vt-co-tcco OBJECT IDENTIFIER :: =

{ oiw-vt-co cotypetcco(4) }

Profiles defined by OIW VT SIG:

oiw-vt-pr-telnet-1988 OBJECT IDENTIFIER :: =

{ oiw-vt-pr telnet-1 988(0) }

oiw-vt-pr-transparent-1988 OBJECT IDENTIFIER :: =

{ oiw-vt-pr transparent-1 988(1) }

oiw-vt-pr-forms-1989 OBJECT IDENTIFIER :: =

{ oiw-vt-pr forms-1 989(2) }

0iw-vt-pr-x3-1989 OBJECT IDENTIFIER :: =

{ oiw-vt-pr x3-1 989(4) }

Control Objects defined by OIW VT SIG:

oiw-vt-co-misc-sa OBJECT IDENTIFIER :: =

{ oiw-vt-co-misc sa(0) }

oiw-vt-co-misc-ua OBJECT IDENTIFIER :: =

{ oiw-vt-co-misc ua(1) }

77
PART 14 - VIRTUAL TERMINAL December 1 990 (Stable)

oiw-vt-co-misc-st

{ oiw-vt-co-misc

oiw-vt-co-misc-ut

{ oiw-vt-co-misc

OBJECT IDENTIFIER :: =

st(2) }

OBJECT IDENTIFIER :: =

ut(3) }

78
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 15 - Transaction Processing

Output from the December 1990 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Jeff Hildebrand

Jeff Hildebrand
I
PART 15 - TRANSACTION PROCESSING December 1990 (Stable)

Table of Contents

Part 15 -Transaction Processing 1

iii
PART 15 - TRANSACT80N PROCESSING December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Transaction Processing Special

Interest Group (TPSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection (OSI).

Text in this part has been approved by the Plenary of the above-mentioned Workshop. No

significant technical change has occurred in this part since it was previously presented.

iv
Part 15 -Transaction Processing

Editor's Note: This section is a placeholder for future Transaction Processing (TP) Agreennents. Any new text from this group

will be inserted here.

1

i
I

I

l:
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 16 - Office Document

Architecture Level 3 DAP

Output from the December 1990 NIST Workshop for

Implementors of OSI

SIG Chair: Frank Dawson

SIG Editor: Frank Dawson

PART 16 - ODA Level 3 DAP December 1990 (Stable)

Table of Contents

Part 16 - Office Document Architecture Level 3 DAP 1

ill

Part 1 6 - Office Document Architecture Level 3 DAP

NOTE - It is the intent of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection (OSI) to move into this part the Office Document Architecture (ODA) document application profile (DAP) known as FOD36, when rt is approved as an International Standardized Profile (ISP). The draft text for the proposed Draft ISP has been submitted to the ISO/IEC Joint Technical Committee 1, Special Group on Functional Standards (SGFS). Refer to Part 16 of the Working

Agreements of this Workshop for the current version of this text.

This replaces previous contents of this part.

1

Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 17 - Office Document

Architecture Level 3 DAP

Output from the December 1990 NIST Workshop

Implementors of OSI

SIG Chair: Frank Dawson

SIG Editor: Frank Dawson

PART 17 - ODA Level 3 DAP December 1990 (Stable)

Table of Contents

Part 17 - Office Document Architecture Level 2 DAP 1

ill

Part 1 7 - Office Document Architecture Level 2 DAP

NOTE - It is the intent of tlie National Institute of Standards and Teclnnology (NIST) Workshop for Implementors of Open Systems Interconnection (OSI) to move into this part the Office Document Architecture (ODA) document application profile (DAP) known as FOD26, when it is approved as an International Standardized Profile (ISP). The draft text for the proposed Draft ISP has been submitted to the ISO/IEC Joint Technical Committee 1, Special Group on Functional Standards (SGFS). Refer to Part 17 of the Working

Agreements of this Workshop for the current version of this text.

This replaces previous contents of this part.

1

Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 18 - Network Management

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Co-Chair

SIG Co-Chair

SIG Editor

Paul Brusil, The Mitre Corporation

George IVIouradian, AT&T Bell Labs

Robert Aronoff, NIST
PART 18: Network Management September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Network Management Special Interest Group (NMSIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection (OSI). 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.

To highlight textual changes since the last Workshop output, additions to the text in this part are marked with

redlining (redilne); deleted text is left in but marked with strikeouts (s^keou^).

ii
PART 18: Network Management September 1991 (Stable)

Table of Contents

18 Network Management i

0 Introduction 1

1 Scope 1

1.1 Phased Approach 2

1.1.1 Alignment With Evolving Standards 2

1.1.2 Definition of Phase 1 2

1.1.3 Future Phases 3

2 Normative References 4

3 Status 6

4 Errata 6

€ Management Functi ons a nd Servi ces —

8

€t1 General Agreements —

8

S.4t1 Conventi ons Used I n SMF Agreements —

8

St+tS General Agreements Referenced By Many SMF Servi ces —

9

6.1.2.1 Mi ni mal Filter Compl exi ty —

8

6.1.2.2 Mode Parameter Usage —

9

6x2 Object Management Function Agreements —

9

General Agreements —

9

§A2 Object Creati on Reporti ng —^

6t273 Object Del eti on Reporti ng— —

6T2r4 Object Name Change Reporti ng —*5

672.6 Attri bute Val ue Change Reporti ng —

Mi
PART 18: Network Management September 1991 (Stable)

6^ PT Croato —

PT Dol oto —U

PT Sot —46

SA« PT- Acti on —46

6.2.10 PTGot —47

6.2i11 PT- Event —48

673 State Management Punoti on Agroomonts —48

General Agreements —48

er^rfi State Change Reporti ng —49

6r4 Attri butes For Representi ng Relat i onshi ps Agreements —2Q

6r4r4 General Agreements —30

6x4,3 Relat i onshi p Cha nge Reporti ng —34-

676 Al arm Reporti ng Functi on Agreements —22

6^6r4 General Agreements —22

6^6:3 Alarm Reporti ng —28

6r6 Event Report Ma nagement Functi on Agreements —26

6167^ General Agreements —26

6t6.2 I nitiat i on Of Event Report Forward i ng —26

67678 Termi nati on Of Event Report Forward i ng —27

67614 EFD Modi fi cat i on> Suspension, a nd Resumpti on —28

5 Management Functions and Services . , 30

5«1 General Agreements , * , 30

S.1.t Conventions Used In SMF Agreements 30

Si^1.2 General Agreements Referenced By Many SMF Services .... 31

iv
PART 18: Network Management September 1991 (Stable)

9^

iif

s,2,e

s.2.a

5.2.S

$.2.10

$.3

S.X1

$^

S.4

S.4.2

S.5

Maximum Length of >to6tiefitloii identifier . Maximum Number of SET Itema . Maximum Leflglh of AdOWortat Text

Use of Additional Info , ,

Object Managemem Function Agreements

General Agreements ... ...

Object Creation Reporting

Object Deletion Reporting

Attribute Value Change Repod^ng

32

PT-Oreate

iliiiiiiiiiisss

34

PT-Get

PT-fivent , , ---WMM

State Management Function Agreements

General Agreements

3S

35

State Change Reporting , I^^^M

Attributes For Representing Reiationshlps Agreements . .

General Agreement

Refatlonshlp Change Reporting . . . \ .\ . . .\ ^^^^H

Alarm Reporting Function Agreements , , .

Genmial ii^reementa —

. . . 35

... 35

36

37

. . 38

V
PART 18: Network Management September 1991 (Stable)

S»6 Event Report Management Function Agreements 39

Oen^l Agreements w v ^ ^ 39

Initiation 01 £vent Report Forwarding , . < , + 39

S,6,3 Termination Of Event Report Forwarding < . * 41

EFD ModlficatloR, Suspension, and Resumption , , ^ <^ ^ , 41

5<7 Log Control Function Agreements . . .43

$.8 Security Alamt Reporting Function Agreements .43

9.9 Secuilty Audit It^M Function Agreements 43

5.10 Objects and AttriDutes for Access Control Agreements ^3

5.11 Accounting Meter Function Agreements , ^3

$.1^ WcHldosd Monttonng Function Agreements y < 43

5.13 Summarization Function Agreements < , . .43

5.14 Test Management Function Agreements . . i3

hASt Confidence and Diagnos^c Test Ciasses Agreements 43

6 Management Communications 44

6.1 Association Policies 44

6.1.1 Application Context Negotiation 44

6.1.2 Functional Unit Negotiation 44

6.1.3 Security Aspects of Associations 44

6.2 General Agreements on Users of CMIS 44

6.2.1 Object Naming 45

6.2.2 Multiple Object Selection 45

6.2.2.1 Scoping 45

6.2.2.2 Filtering 45

Vi
PART 18: Network Management September 1991 (Stable)

6.2.2.3 Synchronization 45

6.2.2.4 Multiple Replies 46

Curront/Evont Ti me —46

6.2.3 Access Control 46

6.2.4 CMIS Functi onal UnitoSubsets 46

6.3 Specific Agreements on Users of CMIS 47

6.3.1 M-EVENT-REPORT 47

6.3.1.1 Event Argument 47

6.3.1.2 Parameter Agreements 48

6.3.2 M-GET 48

6.3.2.1 Successful Response 48

6.3.2.2 Partially Successful or Unsuccessful Response 48

6.3.2.3 Multiple Replies 49

6.3.2.4 Parameter Agreements 49

6.3.3 M-SET 50

6ididr1 Sucoessful Response —50

6.3.3.1 Partially Successful or Unsuccessful Response 50

6.3.3.2 Multiple Replies 50

6.3.3.3 Add/Remove Response 50

6.3.3.4 Parameter Agreements 50

6.3.4 M-ACTION 51

6.3.4.1 Multiple Objects 51

6.3.4.2 Parameter Agreements 52

6.3.5 M-CREATE 52

vii
PART 18: Network Management September 1991 (Stable)

6.3.5.1 Managed Object Instance 53

6.3.5.2 Attribute Values 53

6.3.5.3 Parameter Agreements 53

6.3.6 M-DELETE 53

6.3.6.1 Deletion of Objects Containing Objects 54

6.3.6.1 Parameter Agreements 54

6.4 Specific Agreements on CMIP 54

6.4.1 Invoke/Linked Identifier Size 55

6.4.2 Version 55

6.4.3 Linked Reply Values 55

6.4.4 Error Codes 55

6.4.5 Parameters 55

6L4yS Access Control Parameter . , , . , , .

6.5 Services Required by CMIP 55

6.6 CMIP PICS 56

7 Management I nformat i on —66

7r1 The I nformati on Model —66

TrM I nheritance— —66

TAri All omorphi sm —66

Filter 66

Trfi Pri nci ples of Na mi ng —67

TAI Name Structure —67

7.2.1.1 Object Class I denti fi cati on —67

7.2.1.2 Object I nstance I dentificati on —57

Viii
PART 18: Network Management September 1991 (Stable)

7.2.1.3 Attribute I dontifioation —&7

7.2.1.^ Ma naged Object Knowledgo —&7

7i3^

7.ar3-

Gui doli noo for the Defi ni t i on of Managomont I nformation —&7

Syntacti cal Defi ni ti ons of Management I nformat i on ^—58

7.3.1.1 Managed Object Claoo Template —58

Tidr+rS Package Template —58

7.3.1.3 Attri bute Template —58

7.3.1. 4 Attri bute Group Templ ate —58

Gui deli nes For Defi ni ng Behavi our —58

Other Gui delines —50

7.3. 4

7

r«i

7.1.1

7.1.2

7.1.2L1

7.1.2.2

7.1.$

7.14

7,1,5

r.2

7.2,1

7.2.1.1

7.2,2

I ni t i al Value Managed Objects (

I VMO) —59

N^knsi^BfvtBf^ Infonriation ...>>^<,...>><<,..+ >>x<,...>>x<,... 59

Tbe Infomiatlon Mod^ 60

tnherltci ., 60

Interoperability 60

tnteroperabilliy Provided By The Agent System 6Q

tnterop^rabtiity Provided By The Manager System / 60

Filler , , ... 60

l^nagement Ope»^tions , *

Deletion of Objects Containing Objects 61

{guidelines tor the Deflnidon of Management Infonnallon ^^^31

SyntacUcat Definitions of Management Informatloi* , *

Attribute Template . . ^ - 61

Guidelines For Defining Behaviour ^^P^^^^^^^^^^

IX
PART 18: Network Management September 1991 (Stable)

1,2.3 . , . , . . /: ; — .eg

8 Conformance 62

8.1 Introduction 62

8.2 General Requirements of Conformance 62

8.3 Specific Conformance Categories 63

8.3.1 Management Communication Categories 63

8.3.2 Management Functions and Services Conformance Categories 63

8.3.2.1 General Management Capabilities Conformance Category 63

8.3.2.2 Alarm Reporting and State Management Capabilities Conformance

Category 64

8.3.2.3 Alarm Reporting Capabilities Conformance Category 64

8.3.2.4 General Event Report Management Conformance Category 64

8.3.2.5 General Log Control Conformance Category 64

8.3.3 Management Information Conformance Category 64

8.3.3.1 MOCS Proforma 64

8.3.4 Management Application Contexts 65

8.4 Demonstration of Conformance 65

8.4.1 Management Communication 65

8.4.2 Management Functions and Services 65

8.4.3 Management Information 65

ANNEX A - Management Information Library (MIL) 65

ANNEX B - NMSIG Object Identifiers 66

X
PART 18: Network Management September 1991 (Stable)

List of Tables

Tabl o 1

Scopo of Agroomonto Rol oting to SMF SorvicoG Dofinod by tho

Object Managomont Standard [QMF] —

Tablo 2: Agroomonto On Paramotor Uoago Portinont to tho Object Crooti on

Reporti ng SMF Servi ce —4^

Tablo 3: Agroomonto On Paramotor Uoago Pertinent to tho Objoot Del eti on

Reporti ng SMF Service —44

Tabl e 4 : Agroomonto On Parameter Uoago Perti nent to tho Attri bute Val ue

Change Reporti ng SMF Servi ce —42

Table 5: Agroomonto On Parameter Uoago Pertinent to the PT Create SMF

Service —43

Table 6: Agroomonto On Parameter Uoago Pertinent to tho PT Del ete SMF

Servi ce —44

Table 7: Agroomonto On Paramotor Uoago Pertinent to tho PT Sot SMF

Son/ico —4§

Tabl o 8: Agroomonto On Parameter Uoago Pertinent to tho PT Acti on SMF

Service —46

Tabl e 0: Agroomento On Paramotor Uoago Pertinent to tho PT Get SMF

Servi ce —47

Table 10: Agrcemcnto On Parameter Uoago Pertinent to tho PT Event SMF

Sorvi ee —4B

Tabl e 11: Scopo of Agroomonto Rel ati ng to SMF Sorvi coo Dofi nod by the State

Management Standard [STMF] —40

Tabl o 13: Agroomonto On Paramotor Uoago Pertinent to tho State Change

Reporting SMF Servi ce —40

Tabl e 13: Scope of Agrocmento Rel ating to SMF Sorvi coo Dofinod by tho

Attri butOG For Repreoenti ng Rolationohi po Standard [ARR] —24- Tablo 1 4 : Agroomonto On Parameter Uoago Pertinent to the Rol ationohip

Change Reporti ng SMF Servi ce —34

Tabl e 15: Scope of Agroomonto Rel ati ng to SMF Sorvi cco Defi ned by the Al arm

Reporti ng Standard [ARF] —33

i| Tabl e 16: Agroomonto On Paramotor Uoago Portinont to tho Alarm Reporting

SMF Servi ce 33

Tablo 17: Scopo of Agroomonto Rel ating to SMF Sorvi cco Defi ned by the Event

Report Managomont Standard [ERMF] —2§

Table 1 8: Agroomonto On Paramotor Uoago Pertinent to the I ni t i ati on of Event

Report Forwardi ng SMF Servi ce —3§

Table 10: Agrcemcnto On Parameter Uoago Pertinent to the Termi nation of

Event Report Forwardi ng SMF Service —37

xi

I
PART 18: Network Management September 1991 (Stable)

Tablo 20: Agroomonto On Paramotor Usogo Porti nont to tho Evont Forwardi ng

Di scrimi nator Modi fi cati on, SuoporiGi on, and Rooumpti on SMF

Sorvi oo —28

is On ^""wmnmrn ilsag© Ptrtlntnt to tm 0ijil''liii8|

ts On Paramamr Usage Pertinent to fm ^,riTioyi.e value

pordrsg SMF Service

m On Psem-sm Usage^..Pertinert to the Sta{i^:'Oliifl||

0mm

On FBra'!iet©r Usage Pertinent to,: porting BMf Sen/ic© . , 37

neter Usage Penirienl to thaiOJiffi'lilclrSnl

: -^a-an>aor Usage Parlinant lu P- " " dti ' £ vu?

ag Sp^p Sen/ice o P. . .",a. S'>-'0/;.:;.- >v::'tP.::,^^ - 1 ^ -f P -lii ha a I P'lg

Modification, Suspposiori, and Resumption' SM|

Table 249:

Table 2210:

Table 2311:

Table 2412:

Table 2&13:

Table 2814:

M-EVENT REPORT Parameters 48

M-GET Parameters 49

M-SET Parameters 51

M-ACTION Parameters 52

M-CREATE Parameters 53

M-DELETE Parameters 54

Xli
September 1991 (Stable)

18 Network Management

0 Introduction

Within the community of OSI researchers, users, and vendors, there is a recognized need to address the

prot>lems of initiating, terminating, monitoring, and controlling communication activities and assisting in their harmonious operation, as well as handling abnormal conditions. The activities that address these prob>lems are collectively called network management.

Network management can be viewed as the set of operational and administrative mechanisms necessary to:

a. bring up, enroll, and/or alter network resources,

b. keep network resources operational,

c. fine tune these resources and/or plan for their expansion,

d. manage the accounting of their usage, and

e. manage their protection from unauthorized use/tampering.

As such, network management is typically concerned with management activities in at least the following five functional areas: configuration management, fault management, performance management, accounting

management, and security management. In order to accomplish these management activities, information

must be exchanged among open systems.

In Part 18, there are Implementation Agreements (lA's) for providing interoperable OSI management

information communication services among OSI systems. Also contained here are agreements on management information. These agreements pertain to the exchange of management information and

management commands between open systems operating in a multivendor environment. For example, one

goal is to ensure that a management system built by one vendor can manage objects built by another vendor.

1 Scope

The purpose of this Part (Part 18), is to provide implementation agreements that will enable independent

vendors to supply customers with a diverse set of networking products that can be managed as part of an

integrated environment. Where possible, these agreements are based upon OSI Systems Management

standards.

1
PART 18: Network Management September 1991 (Stable)

1.1 Phased Approach

Because of the broad scope of the subject, and given that OSI Systems Management standards are still evolving, it is reasonable to assume that a comprehensive set of network management implementation

agreements will take a number of years to develop. To arrive at an initial set of implementation agreements

in a timely fashion, a phased approach has been adopted.

This phased work approach will result in a series of implementation agreements based on the expanding scope

of the OSI Systems Management standards. It is the intention of the NMSIG to define the content of each

phase as a compatible superset of the previous Phases to ensure that Phase N products can interact with

products based on the implementation agreements of earlier phases.

1.1.1 Alignment With Evolving Standards

In some cases, these phased implementation agreements may be based on DIS standards. As the relevant

standards progress from DIS to IS, the agreements will be aligned in future phases.

When a defect is found in any of the management related standards, the reported defect may be technically

resolved by the appropriate international technical committee with likely approval by the voting members

pending for several months. Since relevant defects can't be ignored in an implementation, these agreements

will note defect resolutions which have the tentative approval of the appropriate standards committee. These

interim resolutions will be recorded in clause 4.

Once a defect resolution has been completed by the appropriate standards body, the agreed upon resolution

will be incorporated into the next phase of these implementors agreements. If appropriate, a previous phase

that relied on an interim resolution will be examined to determine whether errata should be issued to bring the

original phase into line with the final resolution.

1.1.2 Definition of Phase 1

As a first step in this phased approach, the NMSIG has targeted an initial set of agreements that provide limited interoperable management in a heterogeneous vendor environment. They are the beginning of a comprehensive set of implementation agreements t)ased on the emerging OSI Systems Management

standards. Furthermore, these initial agreements allow the community to gain experience with OSI

management standards as they emerge.

The focus of the Phase 1 agreements is to enable a managing process provided by one vendor to interoperate

with an agent process provided by a different vendor to perform limited management on a set of managed

objects.

The scope of Phase 1 implementation agreements is the following:

Management Functions:
PART 18: Network Management September 1991 (Stable)

Object Management Function [OMF],

State Management Function [STMF],

Attributes For Representing Relationships [ARR],

Alarm Reporting Function [ARF],

Event Report Management Function [ERMF].

Management Information:

Information Model, Naming, Guidelines and Templates for Defining Managed Objects

Management Communication:

CMIS/P, Association Policies, and Upper Layer Sen/ices Required

Management Objects:

Support Objects required for the above.

Editor's Note: [The relation of the MIL definitions in Annex A of the Working Document to Phase

1 lA's needs to be clarified.]

Conformance Criteria:

Conformance Criteria for the above functionality.

To accomplish these goals in a timely fashion, the following simplifying constraints have been reflected in the

Phase 1 agreements:

1. No agreements are provided regarding management domains.

2. These agreements require only the following application service elements: the Association

Control Service Element (ACSE), the Common Management Information Service Element

(CMISE), Remote Operations Service Element (ROSE), and the System Management Application

Service Element (SMASE).

3. These agreements do not require implementation of services defined by the Directory standards.

4. No agreements regarding the security of management are provided.

1.1.3 Future Phases

It is the intention of the NMSIG to freeze the content of Phase 1 when these agreements are progressed to Stable status. Alignment changes required as the standards progress from DIS to IS will be made in future phases.

3
PART 18: Network Management September 1991 (Stable)

As standards defining new functionality are progressed, the NMSIG will define future phases incorporating the new functionality as a compatible superset of previous phases.

2 Normative References

The following documents are referenced in the statements of the agreements relating to OSI network

management. The notati on i ndi oatoo that tontativo obicot idontifi oro oontai nod i n thooo BI S l ovol dooumontG

arc suporGodod by the NMSIG Phase 1 object idontifi oro contai nod i n Annex B.2 of thooo agroomonto.

[ACSEP]

[ACSESl

[ADDRMVPJ

[ADDRMVS]

iiiiiiTii

ISO 8650, Information Processing Systems - Open Systems Interconnection - Protocol

Specification for the Association Control Service Element (Revised Final Text of DIS 8650),

ISO/IEC JTC1 /SC21 N2327, 21 April 1 988.

ISO 8649, Information Processing Systems - Open Systems Interconnection - Service

Definition for the Association Control Service Element (Revised Final Text of DIS 8649),

ISO/IEC JTC1/SC21 N2326, 21 April 1988.

ISO/IEC9596/DAD 2, Common Management Information Protocol Specification: Addendum

2 (Add/Remove Protocol), ISO/IEC JTC1/SC21, 1 February 1990.

ISO/IEC 9595/DAD 2, Common Management Information Service Definition: Addendum 2

(Add/Remove Service), ISO/IEC JTC1/SC21, 1 February 1990.

DISP 11183

AOMnn OS\

't, Information Teclinology

Management - Management

' International Standardized

CommunicatltMis Protocols -

Profife$

Fart 1: Specification of ACSE, Presentation and Session Protocols for the use by BOSE

f^MT1]

and CMISE, September 1991,

DISP 11183-3, Infornnation Technology - tnternallonal St«f?darc8zed Profifes

AOMnn 0$t Management Management Cbmmunioatlonst Protocols * Part 3:

AOM11 - Basic Management Communications, September 1991,

DISP 11183-2, Information

AOMnn 0${ Management ^ Technology

Management

- lr>ternational Standardized Profiles

Communications Protocols >^ Part 2:

AOMia - Enhanced Management Communications, September 1991

[ARFJi

[ARR]*

ISO/IEC OlS 10164-4, Information Technology - Open Systems Interconnection - Systems Management - Part 4: Alarm Reporting Function, ISO/IEC JTC1/SC21

N48§86369, JuneAugust 19, 1!

ISO/IEC OlS 10164-3, Information Technology - Open Systems Interconnection - Systems Management - Part 3: Attributes for Representing Relationships,

ISO/IEC JTC1/SC21 N48§76ia6, JuneSeptember 1990|.

4
PART 18: Network Management September 1991 (Stable)

[ASN1] ISO/IEC 8824, Information Technology - Open System Interconnection - Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC JTC1/SC21

N4720, 30 April 1990.

[BER] ISO/IEC 8825, Information Technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),

ISO/IEC JTC1/SC21 N4721, 30 April 1990.

[CANGETP] ISO/IEC 9596/DAD 1 , Common Management Information Protocol Specification:

Addendum 1 (CancelGet Protocol), ISO/IEC JTC1/SC21, 1 February 1990.

[CANGETS] ISO/IEC 9595/DAD 1, Common Management Information Service Definition:

Addendum 1 (CancelGet Service), ISO/IEC JTC1/SC21, 1 February 1990.

[CMIP] ISO/IEC 9596-1, Information Technology - Open Systems Interconnection - Common Management Information Protocol Specification - Part 1 : Specification,

24 November 1990.

[CMIS] ISO/IEC 9595, Information Technology - Open Systems Interconnection - Common Management Information Service Definition, Common Management

Information Service, 24 November 1990.

[DMI]* ISO/IEC QIS 10165-2, Information Technology - Open Systems Interconnection - Structure of Management Information - Part 2: Definition of Management

Information, ISO/IEC JTC1/SC21 N4867e363, JemAtiguit 1990|.

[ERMFJi ISO/IEC Q\S 10164-5, Information Technology - Open Systems Interconnection - Systems Management - Part 5: Event Report Management Function, ISO/IEC

JTC1/SC21 N48606360, JweAugust 1990|.

[GDMO]* ISO/IEC QIS 10165-4, Information Technology - Open Systems Interconnection - Structure of Management Information - Part 4: Guidelines for the Definition of

Managed Objects, ISO/IEC JTC1/SC21 N48626309, 4&^Jt»fies|i||i| 1990|.

[ISPFRM] ISO/IEC TR 10000-1, Information Technology - Framework and Taxonomy of

International Standardized Profiles - Part 1: Framework, ISO/IEC JTC1/SGFS

N184, 9 February 1990.

[ISPSRVC] ISO/IEC TR 8509, Information Processing Systems - Open Systems

Interconnection - Service Conventions, TC97/SC16/1646.

[LCF] ISO/IEC ©IS 10164-6, Information Technology - Open Systems Interconnection - Systems Management - Part 6: Log Control Function, ISO/IEC JTC1/SC21

N486S6361, June 19901.

5
PART 18: Network Management September 1991 (Stable)

[MIM] ISO/IEC QIS 10165-1 , Information Technology - Open Systems Interconnection - Management Information Services - Structure of Management Information - Part

1: Management Information Model, ISO/IEC JTC1/SC21 N§2§263$t, June

1990|.

[OMF]* ISO/IEC OlS 10164-1 , Information Technology - Open Systems Interconnection - Systems Management - Part 1: Object Management Function, ISO/IEC

JTC1/SC21 N48§§||||, .kJoeS^mber 19901.

[SMO]* ISO/IEC DIS 10040, Information Technology - Open Systems Interconnection - Systems Management Overview, ISO/IEC JTC1/SC21 N486§R6353, 46

JuReAugust I99^i.

[STMF]* ISO/IEC QIS 10164-2, Information Technology - Open Systems Interconnection - Systems Management - Part 2: State Management Function, ISO/IEC

JTC1/SC21 N4866||8|, JufieSeptember 19901.

3 Status

Asof September I99t. the stefole management communlcattor1 agreements in clause 8 dl part 18 ard dause

7 Of part 13 t>ecame techrijcally equivalent to DI$P ill 83. The Dl$P rlgqrotte $latement of

3. TheNMSlG Is participating Inthedev^opment of the iSP and Inrendsio reference directly ISP

1 1 183, Parts 1 through 3, and, In so doing, all the agreements therein, vrfien l$f* 1118$ Is approved. Hile ISP

is expected to b& approvedinAprii, 1 932. Only editorial modifications are &xpecl«tto occur betwesen

^OISP ^

ISP, In the Interim, please r^erto OISP 11 mIf techhicd) darlfication h requln^d.

(Refer to the Working Implementation Agreements Document for additional status information.)

4 Errata

Editor's Note: [ "Defect Report" material (including applicability) may be included here.]

The following tat>le indicates the clause, type, and reference document of technical errata to this part.

6
PART 18: Network Management September 1991 (Stable)

Erratum

No.

Type &

Date

Entered

Referenced

Document

Clause Comment

1 Technical

6/91

NMSIG91 /Oo

6.4.5 This clause, previously clause 6.2.6,

was modified and moved to clause

6.4.5 to clarify that it is intended as a support agreement for CMIP rather

than a usage agreement for CMIS. 1 Alignment

9/91

NMSIG*

91/1 10

NMSIG91/113

1 This clause has been updated ti; reflect alignment changes to the

relevant base standards which hav0

lust progressed to IS as of August,

1991.

1 fechnical

9/91

NMSIG^

91/161

6.2.2.2 Move text from clause 5. 1.2J tq

more appropriate clause 6.2.2.2 and

clarify required support for minimal

filter complexity to align with the DISP

11183,

1 Technical

9/9t

NMSIG^

iiiiii:

iii ISemove unnecessary restrictions on

sending CMIP tUm parameters.

1 AUgnment

9/91

NMSIGii/i 14

6 1.1 Change reference to required

application context support to align

with IS version of |SMOp

1 Technical

9/91

NMSIG-

|l/161

6.3.ai Jlemove dause requiring mandatory

attribute list in successful set

response because considered

redundant tntormation.

1 Alignmem NMS1GHiiso1

Update clause to reflect ailgnmi^

changes to the relevant base

9/91 Standards which have progressed to

IS as of August, 1991.

1 Editorial

9/91

NMSIGli:/^t:6:1:

6.3.6 1 Move clause 6.3.6.1 to more

appropriate location at clause 7jxS^

7
PART 18: Network Management September 1991 (Stable)

5 Management Functions and Servi ces

SA Gonoral Agroomonto

Conventions Uood I n SMF Agroomonto

Each Systom Managomont Functi on dofi nos a sot of sorvi oos roforrod to i n thi s document as "SMF sorvi cos". Agroomonts portl nont to SMF sorvi cos arc provided i n the foll owi ng subcl ausos. Eaoli subol auso contai ns a

seri es of tabl es, as fol lows.

For each System Management Functi on, a tabl e lists the SMF services encompassed by the functi on, whether each SMF servi ce i s currentl y withi n the scope of these agreements, and rel ated nDanagomont

support objoeto (if any). Al though a managomont support object may bo related to a SMF service, it nrvay or may not bo requi red to provide the SMF sorvi co.

^. For each SMF servi ce, a normative tabl e referonoos text agroomonts whi ch constrai n the usage and/or val ue of the associated servi ce parameters. Text agroomonts defi ned el sewhere i n thi s document arc

referenced by cl ause number. The l ack of a reforonoo signifi es no agreement beyond the base

standard.

These tabl es i ncl ude codes whi ch specify parameter usage for request, i ndi cati on, response, and confirmati on

servi ce pri miti ves. These codes, defi ned i n subol auso 1. 8.3 of these agreements (Cl assification of Confornrxincc)

,

i n I SO/I EC TR 1 0000 1 (Framework and Taxonomy of I SPs) [I SPFRM] , and in I SO/I EC TR 8600 j (Servi ce Conventi ons) [

I SPSRVC], are repeated here for reader conveni ence:

M Mandatory

Q Opti onal G{p)—

I

f Condi tion p oxi sto. then paramotor io mandatory; othorwico, tho

paramotor i o not appli cabl o. X Excl uded

\ Out Of Soopo

I n thooo agroomonto, thio moano that, for tho oorroopondl ng ol omont.

*

i mpl omontati ono may uco I t outoi do tho ooopo of thooo agroomonts,

* oonformanoo tooto ohall not bo provi ded for i t, *

i mpl omontationo may conform to other agroomonto where i t i s required,

* no requi romento are pl aced on ei ther transmi tter or recei ver to support

* recei ver actions are unspeci fi ed when present.

Not Appli cable

The val ue of the parameter i s i denti eal to the corresponding paramotor in the i nteracti on descri bed by tho precedi ng rel ated oorvi co pri mi ti ve. U The use of tho parameter i o a servi ce user opti on.

8
PART 18: Network Management September 1991 (Stable)

I n addition, tho oonvontion "A> B" i s uood i n normatlvo tabl oo to I ndl cato both tho uoago opoolfl od by tho baeo Gtandard (A) and ttio additi onal conctrai nt i mpoood by tiiooo agroomontG (B). Ttil e oonvonti on i o i ntondod to call attenti on to agroomonts whi cii modify tho uoago of a sorvi oo paramotor.

Unl ooo othofwi co notod, condit i onal paramotoro (C) ohall bo prooont accordi ng to tho oonditi onc dofl nod In [CMI S] and the roforoncod Syotcm Managomont Functi on baoo otandard.

SA^i General Agroomonto Rofcronood By Many SMF Sorvi ooo

Tho foll owi ng gonoral agreements pertai n to some or all of the System Managenment Function servi oos dofi nod

throughout cl ause 6. Normative tabl es for each SMF servi ce reference those general agroomonts whoro

appli cable. These agreements do not appl y to SMF soni/i oes and parameters whi ch do not reference thorn.

6.1.2.1 Mi ni mal Filter Compl exity

I f an i mpl ementati on supports Mul ti pl e Object Sol ecti on, then it shall mi ni mall y support AND and OR wi th a sot

of two fil ter conditions (whi ch shall not themsel ves bo AND or OR), and NOT. I n addit i on, tho i mpl omontatl on

shall support tho filter conditi ons Equal ity, GreatorOrEqual

, LessOrEqual, and Present. Thi s moans that a conformi ng i mpl ementation i s not requi red to support compounds (AND or OR) with more than two itoms, and

i s not requi red to support the Substri ng fil ter condition. Additi onal filter items and conditi ons are beyond tho

scope of thoco agroomonts.

6.1.2.2 Mode Paramotor Uoago

Al l SMF Son/i ces mapped to CMI S M EVENT REPORT, M ACTI ON, and M SET shall all ow either confi rmod or unconfi rmed Mode to be specifi ed by the servi ce i nvoker. Tho choi ce of Mode may bo oonstrai nod by tho

managed object cl aos defi nition.

Bz2 Object Managomont Function Agroomonts

^AA General Agroomonts

Those agreements addreoo the foll owi ng SMF oorvi ooo defi ned by tho objoot managomont standard [OMF]:

9
PART 18: Network Management September 1991 (Stable)

Table 1

Scope of Agroomonts Rel ati ng to SMF Sorvl cos Dofinod by the Object

Management Standard [OMF]

Object Management SMF

Sorvico

Within Scope Of

Agroomonts

Rolatod Management

Support Objects

Object Croation Reporting Event Forwarding

Diooriminator

UDjoci ueietion Hoporting Event Forwarding

Diocriminator

Object Name Change Ne

Reporting

Event Forwarding

Diooriminator

Attribute Value Change

Reporting

Event Forwarding

Discriminator

PT Create

PT Delete

PT Action Vac

PT Set Ynf>- PTGet Yrp.

PT Event Ydp. Event Forwarding

Diooriminator

§.2.2 Object Creation Reporti ng

Thi s Gubol auso providoo agroomonto porti nont to tho Objoot Croati on Reporting SMF sorvi oo dofi nod by ooction

0.1.1 of [OMF]. Rol ovont CMI S agroomonto dofi nod i n Dubciauoo 6.3.1 aro ropoatod horo for compl otonoos.

Table 2: Agreements On Parameter Usage Pertinent to tho Object Croation

Reporti ng SMF Servi ce

SMF Object Creation 1 1 VV| SMF Agroomonts CMtS

Reporting Paramotor Agroomonts

Invoke Identifier M MM

Mode M 6.1.2.2

10
PART 18: Network Management September 1991 (Stable)

SMF Object Creation

wcporring r*aromgtcf

Virsrt

1 f W| 1 IO|J SMF Agroomonts CMIS

AgrGGmGnis

Managed Objoot Clacc M y &AS

Managod Qbjoot Inotanoo M y &^

Objoot Croation M &AS

Evont Timo y - &^

Croato Information —Souroo Indioator y 6.3.1.1 —Additional Croato

Information

y 6.3.1.1

Curront TImo y &^

Evont Roply G

Erroro G &AA

Objoot Del eti on Reporti ng

Thi s subol auso provl doc agroomonto porti nont to tho Objoot Dol otl on Roporti ng SMF sorvi oo dofi nod by soction

9.1.2 of [OMF], Rol ovant CMI S agroomonto dofinod in subol auso 6.3.1 arc ropoatod horo for Gompl otonoss.

Tabl e 3: Agroomonts On Parameter Usage Porti nont to tho Object Dolotion

Roporti ng SMF Servi ce

SMF Object Deletion 1 1 W| Pg»r\ SMF Agroomonts GM4S

Roporting Parameter Agroomonts

Invoko Idontifior M MM 6^

Modo M 6.1.2.a

Managod Objoot Claos M y 6^

Managod Objoot Inotanoo M y &^

Objoot Dolotion M 6t4^

Evont Timo y 6tSt3

11
PART 18: Network Management September 1991 (Stable)

WIVII WJ WlWIIUI

1

Reporting Paramotor Agreomonts

Doloto Information —Souroo Indicator y 6.3.1.1 —Additional Doloto

lnfornr)ation

y 6.3.1.1

Current Timo y &A3

Evont Roply G

Errors G &AA

B^2A Objoot Name Change Reporti ng

The Object Namo Change Reporti ng SMF sorvi oe I s usod by tho managod systom to report tho ronami ng of a managed object I nstance to a managi ng system.

Use of the Object Namo Change Reporti ng SMF servi ce I s beyond the scope of these agreements.

Attri bute Val ue Change Reporti ng

Thi s subcl ause provides agroomontc porti nont to tho Attribute Val ue Change Reporti ng SMF servi ce dofi nod

by socti on 0.1 .^1 of [OMF], Rolovant CMI S agreomonts dofi nod i n subcl ause 6.3.1 are repeated hero for completeness.

Tabl e 4: Agreomonts On Paramotor Usage Portinont to tho Attri bute Value

Change Reporti ng SMF Servi ce

SMF Attr Value Change 0A£1 1

1

Pf>r\ SMF Agreements CMIS

Report Parameter Agreements

Invoko Idontifior M MM &A

Mode M 6.1.2.2

Managod Objoot Class M y &AS

Managod Objoot Inotanoo M y 6^

12
PART 18: Network Management September 1991 (Stable)

SMF Attr Value Chango SMF Agroomontc GMIS

Report Parameter AgroomontG

Attribute Valuo Chango M

Evont Timo

Attributo Chango Information —Attributo Chango Dofinition

Attributo ID M - 6.3.1.1

Old Attr Valuo y - 6.3.1.1

Now Attributo Valuo M - 6.3.1.1

Sourco Indicator y 6.3.1.1 —Additional Chango y 6.3.1.1

Information

Currant Timo y &^

Evont Roply G

Erroro G &AA

PT Croato

Thio Gubol auso providoc agroomontc portinont to tho PT Croato SMF sorvi oo dofi nod by ooctl on 0. 1 .6 of [OMF]

Rol ovant GMI S agroomontc dofi nod i n cubcl auoo 6.3.6 arc ropoatod horo for compl otonooG.

Tabl e 6: AgroomontG On Parameter UGago Portinont to tho PT Croato S MF

Servi ce

SIVIF PT- Croato Parameter D.Ck£l

1 IWU SIVIF Agroomonts GM4S

Agroomonts

Invoko Idontifior M 6t4

Managod Objoot Class M G 6^

Managod Objoot Instanoo y G 6.2.1, 6.3.6.1

13
PART 18: Network Management September 1991 (Stable)

SMF PT-Croato Paramotor D1 IWU Pg»

SMF Agroomonts CMIS

Agroomonts

Support Objoot Inotanoo y

AoooGO Control y 6^

Roforonoo Object Inotanoo y

Attribute Liot y G 6.4.6, 6.3.5.2

Current Timo y

Erroro G 6.4.4, 6.3.6.2

[1] Thi s paramotor shall bo i ncl udod i n ALL suocoss Gonfirmati ons.

Ed i tor' s Note:—[I t i s unol oar whothor attri butos suoh as objoctCl asG and I D aro pormittod i n tho Attribute

Li st paramotor of tho PT CREATE roquost. Thi s quootion has boon oubmi ttod to ANSI X3T6. 4 . Dopond i ng upon tho anowor. it may bo noooooary to add an agroomont stating that tho Managod Objoot Cl ass and I nstanco paramotors ovorri do any val uos provi dod i n tho

Attri bute Li st paramotor ]

SAT PT- Delete

Thi s subol auso provides agroomonts porti nont to tho PT Dol oto SMF sorvi oo dofi nod by sooti on 0.1 .6 of [GMF],

[ Rel evant CMI S agroomonts defi ned i n subcl ause 6.3.6 aro repeated here for oompl otonoss. I

I Table 6: Agroomonts On Paramotor Usage Portinont to tho PT Dol oto SMF j Sorvi oo

SMF PT-Doloto Paramotor Pi-fc/l 1 1 W| Pcja SMF Agroomonts GMIS

Agroomonts

Invoke Identlflor M 6t4

Linked Id G 6^

Baoe Object Claos M

Baoo Object Inotanoo M

Scope y 6.2.2.1

Piltnr y 6.1.2.1 6.2.2.2

14
PART 18: Network Management September 1991 (Stable)

SMF PT-Doloto Paramotor Pr\n

1 IWI SMF AgroomontG GMIS

Aocoss Control u R /I 0.c.*+-

Synchronization y 6.2.2.3

Managed Object Claoo G 6t4.6

IVIanagod Object Inotanoe G 6T2r4-

Current Time 6t2^

Erroro G 6.3.6.1, 6.4.4

6A« PT Sot

This subcl ause provi dos agrcoments porti nont to the PT- Sot SMF sorvico dofi nod by soction Q.I .8 of [OMF].

Rol ovant CMI S agroomonts dofi nod i n subcl auso 6.3.3 are ropoatod here for compl otonoss.

Tabl e 7: Agroomonts On Paramotor Usage Porti nont to the PT-Sot SMF Sorvi oo

SMF PT-Sot Paramotor Pr\n SMF Agroomonts CMIS

Agroomonts

Invoke Identifier M MM &A

Linked Id G &A

Mode M 6.1.2.2

Base Object Claso M &AS

Base Object inotanoe M &^

Scope y 6.2.2.1

mef y 6.1.2.1 6.2.2.2

Access Control y 6tS^

Synchronization y 6.2.2.3

Managed Object Class G &AS

Managed Object Instance G 6v2t4-

15
PART 18: Network Management September 1991 (Stable)

SMF PT-Sot Paramotor SMF Agreomonts CMIS

AgreGments

Modification Liot M 6.4.6, 6.3.3.1,

6.3.3.3, 6.3.3.4

Attribute Liot y 6.4.5. 6.3.3.1,

6.3.3.3

Current Time y &^

Erroro G 6.3.3.2, 6.4.4

PT Action

Thi s subol auso provides agroomonts portl nont to tho PT Acti on SMF sorvi oo dofi nod by sooti on 0. 1 .7 of [OMF]

.

Rol ovant CMI S agroomonts dofi nod I n subcl auso 6.3.4 aro ropoated lioro for compl otonoss.

Tabl e 8: Agroomonts On Paramotor Usage Portlnont to tho PT Action SMF

Servi ce

SMF PT-Action Paramotor ff 1 VVf Pg» f\ SMF Agreements

Agroomonts

Invoke Identifier M MM &A

Linked Id G &A

Mode M 5.1.2.2

Base Object Claos M &AS

Base Object Instance M &^

Scope y 6.2.2.1

Piltnr y 5.1.2.1 6.2.2.2

Access Control y 6t2^

Synchronization y 6.2.2.3

Managed Object Class G &AS

Managed Object Instance G 6t2t4

16
PART 18: Network Management September 1991 (Stable)

SMF PT-Action Paramotor p/>«•« SMF Agrcomontc GMIS

Agreomontc

Action Typo M C 4 c

Action Information y

Current Time y

Action Reply G

Erroro G fe4^

6vav40 PT Got

Thi G GubctauGO providoo agroomonte porti nont to tho PT Got SMF sorvioe dofinod by Gootion 0. 1 .0 of [OMF],

Rolovant CMI S agroomonts dofinod i n subclauso 6.3.2 aro ropoatod horo for oompl otonoeg.

Table 9: Agroomonts On Pa ramotor Usage Porti nont to tho PT Got SMF Sorvi oe

SMF PT-Action Paramotor SMF Agroomonts

Agroomonte

Invoke Identifier M MM S^

Linked Id G

Baoe Object Claco M fi 4 g

Base Object Inotanoo M

Scope y s.a.a.i

1 lllwi y 6.1.2.1 e.a.a.a

Aoceoc Control y

Synchronization y 6.3.2.3

y

g 4 c

Managed-Object Claoo G g 4 g 1

Managed Object Inctanco G

Current Time y

17
PART 18: Network Management September 1991 (Stable)

SMF PT-Action Parameter P Deri SMF Agroomonts GMIS

Agroomonts

Attributo Liot G 6.^.6, 6.3.2.1,

6.3.3.3

Erroro G 6.3.2.2, 6.4.4

prevent

Thi s subcta uso providos agroomonte porti nont to the PT- Event S MF servioo dofinod by socti on 9. 1 . 1 0 of [OMF}.

Rdovant CMI S agroomonts dofinod i n subclauso 6.3.1 aro ropoatod horo for compt otonose.

Tabic 10:—Agroomonts On Para meter Usage Port i nont to the PT Event SMF

Servi ce

SMF PT-Action Parameter nw| Ppn SMF Agroomonts GMfS

Invoko Idontifior M

Mode M 6.1.2.2

Managed Object Class M y 6v4t6

Managed Object Instanoo M y 6vSv+

Event Type M 6^

Event Time y &^

Event Information y 6.3.1.1

y &^

Event Reply G

Errors G

&i3 State Management Functi on Agreements

18
PART 18: Network Management September 1991 (Stable)

Gonoral Agroomonte

Thoco agroomontc addroco tho foll owing SMF corvi ooc dolinod by tho ctato managomont ctandard (STMF]:

Ta ble 11: Soopo of Agroomonts Relati ng to SMF Sorvioos Dofi nod by tho State Managomont Standard [ STMF]

State Management SMF

Servi ce Withi n Scope Of

Agroomentc

Relat ed Mana gomont Support Objects

State Change Roporting

Di ocri ml nator

Stato Chango Roporting

Thi o subolauoo provl dos agroomontG perti nent to tho Stato Change Roporting SMF gop/I oo dofinod by cooti on

0.3 of [STMF]. Relevant GMI S agroemontc defi ned in oubol auoo 6.3.1 aro ropoatod hero for oonnpi otoncaG. Table 12: Agroomonts On Parameter Usage Perti nent to tho Stato Cha ngo Reporting SMF Sorvi co

SMF State Chango Report

tCt\ ijkli 1 wlVI

Pp rt SMF Agreemonte

Agreements | invoke Idontifior M

Modo M 6.1.2.2

Managed Object Claoo M y w.^.A F\w 1

II Managed Object Inctanoo M y &^ 1 Stato Chango M y 6^ 1 Event Time y &t2^

j State Change Information —Old Operational Stato y 6.3.1.1 —Now Operational Stato G 6.3.1.1

Old Uoago Stato y 6.3.1.1

19
PART 18: Network Management September 1991 (Stable)

SMF State Change Report

Parameter

1 l\r\J SMF Agreements CMUSi —Now U&age State G 6.3.1.1 —Ola AomtniGtrativQ State 6.3.1.1 —Now AomtniGtrattvo State G 6.3.1.1 _ _ • f\. . —Old Hopair Status y 6.3.1.1

G — —Now Ropair Statue 6.3.1.1 —Old Inctallatien Statue

1y 6.3.1.1 —Now Inotallation Status G - 6.3.1.1

Old Availability Status y - 6.3.1.1 —Now Availability Status G - 6.3.1.1

Old Control Status y - 6.3.1.1 —Now Control Statue G 6.3.1.1

Additional Stato Change y 6.3.1.1 —\pAe

Current Time y 672^3

Evont Reply G

Errors G 6^4^

6t4 Attri butes For Roprosonting Relationships Agroomonts

&AtA Gonoral Agroomonts

Those agroonrtonts addrooo tho foll owing SMF GOfviooo dofinod by the Attri butoG For Roprooonti ng

Rol attonohipo standard [ARR):

20
PART 18: Network Management September 1991 (Stable)

Tabl e 13: Soopo of Agroomonts Rel ating to SMF Sorvi oos Doti nod by the

Attri butes For Roprosonting Rolat l onshipc Sta ndard [ARR]

Attri butoe For RoproGonti ng

Rel ationshi ps SMF Sorvl oo Wi thi n Scopo Of

Agroomontc

Rolat od Management

Support Objoctc

Rol ationohi p Change Roporti ng VfXP_

1 %J19 Event Fofwardi ng

Di GOfi mi natof

6r4.2 Relationshi p Change Reporting

Thi o oubol auGO providoo agroomonto porti nont to the Rol ationohi p Change Roporti ng SMF oorvi oo dofinod by

Gootion Q.3 of [ ARR]. Roi ovant CMI S agroomontc doft nod I n oubol auso 6.3.1 arc ropcatod horo fof oompl otonoGS.

Table 1 4:—Agroomonts On Parameter Usage Portin ont to the Relationship Change Roporti ng SMF Servi ce

SMF Rel Change Report

Parameter

DA£1 n

Agroomonts

GM4S

Agroomontc |

lnvol<o Identifier M M{-}

Mode M 6.1.2.2

Managed Object Claos M U GAR

Managed Objoot Inotanoo M y

Relationohip Change M y fi A p,

Event Time U fi o q

Rolationohip Change Information

Old UoerObjoot U 6.3.1.1 —Now UoerObjoot G 6.3.1.1 —Old ProviderObjoot U 6.3.1.1 —New ProviderObjoot G 6.3.1.1

Old Peer y 6.3.1.1

21
PART 18: Network Management September 1991 (Stable)

8MF Rol Change Roport Pc^rt Anrf*f»nnf»ntft GMiS

1 Wl1 Id 1 lO —Now Poor G 6.3.1.1 —Old Primary 1 1 y 6.3.1.1

G - —Now Primary 6.3.1.1

Old Sooondary y - 6.3.1.1 —Now Sooondary G 6.3.1.1 —Old Backup Objoct InGtanoo y 6.3.1.1 —Now Backup Objoct Inotanoo G 6.3.1.1

Old BackodUp Object

Inotanoo

y 6.3.1.1 —Now BackodUp Objoct —Inotanoo

G - 6.3.1.1 —Old Owner y - 6.3.1.1 —Now Owner G - 6.3.1.1 —Old Member y - 6.3.1.1 —Now Member G 6.3.1.1 —Additional Relationship —Change Info

y 6.3.1.1

Current Time y 6^

Event Reply G

Erroro G 6^

&S Al arm Reporting Function Agroomonts

General Agreoments

ThoGO agroofDonto addrooe tho followi ng SMF oorviooG defi ned by tho al arm reporti ng otandard [ARF):

22
PART 18: Network Management September 1991 (Stable)

Table 1 6: Soopo of Agroomonts Rel ating to SMF Sorvi oos Dofin od by the Al a rm

Reporting Standard [ARF]

Alarm Reporting SMF Service Within Scope Of

Agroomonts

Related Management

Support Objects

Alarm Roporting Vrxr. 1 KJKJ Event Forwarding

DiGcriminator

& Alarm Rocord

&St2 Al arm Re porting

Thi s Gubol auso providoo agroomonts porti nont to tho Atarm Roporting SMF oorvioo dofi nod by socti on 0.3 of [ARF]. Rol ovant CMI S agroomonto dofi nod i n oubol au&o 6.3.1 aro ropoatod horo for oompl otonooo.

Table 1 6:—Agroomonts On Pa r amet er Usage Portinont to th o Alarm Roporting

SMF Alarm Roporting 1 IVU SMF Agreements GM4S

Agreements

Invoke Idontifior M M 6^

Mode M 6.1 .2.2 Managed Object ClaoG M y

C 4 C

Managed Object Inctanoo M y

Alarm Type M R A Ft

Event Time y 6^

Alarm Information —Probable Cauoo M 6.3.1.1

Spooifio Problomo y —Perceived Severity M 6.3.1.1 —Backup Object Inotanco G 6.3.1.1

BaokodUp Statue y &^

23
PART 18: Network Management September 1991 (Stable)

SMF Alarm Reporting

paramGter

D1 1 WV| Rsp SMF Agroomonts GMtS

Agrccmcntc —Trond Indication y 6.3.1.1 —Throohold Information G 6.3.1.1 —Notification Idontifior y {3} 6.3.1.1 —Correlated Notifications y 6.3.1.1 —Generic State Change G 6.3.1.1 —Monitored Attributes y 6.3.1.1

M roi fiD.O. 1 1 1 . 1 —Problem Text y 6.3.1.1 —Problem Data y>4 6.3.1.1

Current Time y

Event Reply G

Errors G &AA

[1] To avoid ambiguity, tho DI sti ngul shod Namo form of this paramotor shall bo I mpiomontod and

may bo used. Uso of Local Di sti ngui shod Namo and Non- Spooi fi o forms arc beyond the scope

of those agroomonts. I f an i mpl omontati on i s unabl e to docodo or understand tho semanti cs of thi s paramotor, an appropri ate CMI S orror (

i .o., I nvalid Attri bute Val uo) shall bo roturnod.

[2] To li mit i mpl omontati on compl exi ty, tho maxi mum numbor of SET itoms oontainod within

the Spoci fi c Probl ems, Corrol atod Noti f i cati ons, and Propoood Repai r Acti on paramotors vyhi ch roci pionts must bo abl e to process shall bo 6^1 .

[3] To li mit i mpl omontati on compl exi ty, tho maxi mum l ongth of tho Noti fi cati on I d parameter shall bo 32 bi ts.

[4] To li mit i mpl omontation compl oxi ty, tho maxi mum l ongth of tho Probl em Text parameter

whi ch roci pi onts must be abl e to process shall bo 266 octets.

[6] Use of the Problem Data parameter i s beyond tho scopo of those agroomonts.

24
PART 18: Network Management September 1991 (Stable)

^

Event Report Management Funotion Agreements

&rSrA Gonoral Agroomonto

Thooo agroomontc addrooo tho foll owing SMF oop/iooc dofinod by tho ovont report managomont ptandard

Table 17:—

S

cope of Agreements Relating to S MF Servioos

Report Management Standard [ERMF]

Evont Report Managomont Rolatod Managomont

Support Objoctc

Within Scope Of

Initiation of ERF Vac Evont Forwarding

DiGoriminator

Tormination of ERF Vr>r I WW Evont Forwarding

Dioorinninator

EFD Modification, Suoponoion, Ynr

Rocumption

Evont FoPAfarding

Diocriminator

I nitiotion Of Event Report Forwardi ng

Thi s 6utx)tauG0 provldoc agroomonts portinont to tho I nit iati on of Evont Report Forwarding SMF sorvi oo dofinod

by sooti on 0.2 of [ERMF], Rolovant CMI S agreements defined i n subciauco 6.3.6 are ropoatod horo for compl otonoee.

Table 1 8:—Agreements On Parameter Usage Perti nent to tho I ni tiation of Event

Report Forwardi ng SMF Servi ce

SMF Initiation of ERF

Parameter

SMF Agreements GM4S

Agreements

lnvol<o Idontifior M fJll-\

Managed Objoot Claoo M G 4 g wT"TTTy Managod Objoct Inotanoo y G 6.2.1, 6.3.6.1

25
PART 18: Network Management September 1991 (Stable)

SMF Initiation of ERF

Parameter

P

1 8MF Agroomonts CMIS

AgroomontG

Support Objoot Inctanoo y -

AoGOGG Control y -

Roforonoo Object Inctanoo y -

Dicoriminator Conotruot y G

6.1.2.1

6.4.6, 6.3.6.2

Declination Addrccc y G 6.4.6, 6.3.5.2

Backup AddroGO y G 6.4.6, 6.3.6.2

Active Addrccc y G

-

6.4.6. 6.3.6.2

Administrative State y G 6.4.6, 6.3.6.2

Operational State G 6.4.6, 6.3.6.2

Uoage State _ G 6.4.6, 6.3.6.2

Availability Statue - G 6.4.6, 6.3.6.2

Allomorphio List y G 6.4.6. 6.3.6.2

Packageo y G 6.4.6, 6.3.6.2

\AJor\W MTPk Li 6 4 6 6 3 6 2

6 4 6

6^3:^

Start Time y G 6.4.6. 6.3.5.2

Of^rx TifTiA y G 6.4.6. 6.3.6.2

Schodular Name y^ G^ {4}

6.3.6.2

C^A irront Tirnn y 6t2^

Erroro G 6.4.4. 6.3.5.2

[1] As spocifi od I n [CMI P], tho valuo 'AblD {)' gIuII bo ucod to roprooont an all pace Dl Gcriminatof Con&truGt. I f thi G paramotor i s omitted from tho roquost. tho all pasc val ue ehaH bo assigned to tho Di oori mi nator Construct attri bute

26
PART 18: Network Management September 1991 (Stable)

[2] Tho Dail y Sohoduli ng Packago. if cupportod by an obj oct. chall cupport at mi ni mum tho defaul t 24 hour I ntofval .

[S] Tho Wookly Sohoduli ng Packago, if cupportod by an objoot. chall cupport tho dofauit valuoc for Start TI mo and Stop Ti mo attributoo. Tho Wook Mack anri buto c hall cupport sohodul ing for oach

day of tho wook, and, at a mi nimum, the dofauit 2A hour porl od for I ntorvato of tho day.

[ 4] Support for the Extornal Sohodul ar Packago i c boyood tho ecopo of thoco agroomontc.

St^^ Termination Of Event Roport Forwarding

Thi s subdauso providos agroomontc pert i nent to the Termi nati on of Event Report Forwardi ng SMF corvico

defi ned by soction Q.3 of (E RMF). Rolovant CMI S agroomontc defi ned i n cubcl auso 6.3.6 aro repeated horo for compl otonoss.

Table 19: Agroomonts On Pa rameter Usage Pertinent to th o Termi nation of Eve nt

Roport Forwa rdi ng S MF Service

SMF Termination of ERF

Parameter

Dan SMF Agreements GMIS

AgroomontG

Invoko Idontifior M 6:4

Linkod Id G &4

Baso Objoct Claos M g 4 c

Baso Objoot Inotanoo M

Soopo y 6.2.2.1

y 6.1.2.1

Aooooo Control y &2t4

Synchronization y 6.2.2.3

G (i A R

Managed Objoct Inotanoo G 6:2r4

Current Timo y fi o o

Erroro G 6.3.6.1, 6.4.4

27
PART 18: Network Management September 1991 (Stable)

EFD Modi fioattont Sueponsi on, a nd Resumption

Thi s suboi ausQ provi doG agroomonto porti nont to tho Evont Forwarding Discri mi nator Modificatton. Sueponsi on. and RoGumpti on SMF sorvtoo defi ned by sooti on 0.4 of [ERMF]. Rol ovant CMI S agroomonts dofinod in subol auGO 6.3.3 arc repeated here for Gompl otonoss.

Table 20:—Agroomonts On Parameter Usage Portinont to tho Evont Forwarding

Di scriminator Modi fi cati on, Suspensi on, and Resumption SMF Sorvico

one CCf% oivi I crtiF Mod/SuGpond/Rocumo

Paremoter

Flop oMr AgroomoniG

M MM 6.4

Linkod Id 6

Modo M 6.1.2.2

Baso Objoot Claoo M - GAR

M 6 2 1 Scope y - 6.2.2.1

Filtfir y 6.1.2.1 6.2.2.2

AoGOGS Control y 6^

Synohronization y 6.2.2.3

Managed Objoot ClaGc G c 4 g

Managod Objoot Inotanoo G 6.2r4-

DlGorinrtinator Conotruot y G

6.1.2.1

6^^

6.3.3.1. 6.3.8.3,

6.3.3.4

Dootlnation Addrooo y G 6^4:€r

6.3.3.1, 6.3.3.3,

6.3.3.4

Backup AddrooG y G

6.3.3.4'

28
PART 18: Network Management September 1991 (Stable)

gMf-EFD

Mod/Sucpond/RoGumo

Paramotor

P/Nfl SMF Agroomonto emus

Agroomonto

Aotivo AddroGS y G

6.3.3.I. 6.3.3.3,

6.3.3.4

Adminictrativo Stato y G 6^4.Sr

6.3.3.1. 6.3.3.3,

6.3.3.4

Allomorphio List y G 6^^v&r

6.3.3.1, 6.3.3.3.

6.3.3.4

Wook Maok y G 6^4^

6.3.3.1, 6.3.3.3,

6.3.3.4

Intorvalc Of Day y G 6.4.6,

6.3.3.1.

6.3.3.3.

6.3.3.4

Start Timo y G 6.4.6.

6.3.3.1. 6.3.3.3,

6.3.3.4

Stop Timo y G 6^4^

6.3.3.1, 6.3.3.3,

6 3 3 4

Schodular Namo y>4 G>4 6^

6.3.3.1,

6.3.3.3,

6.3.3.4

Current Timo y

Erroro G 6.3.3.3, 6.4.4

[1] Ac opooifiod In [CMIP], tho valuo 'AND ()' chall bo ucod to roprooont an all pace Discriminate

Ck)n6truot.

29
PART 18: Network Management September 1991 (Stable)

[2] Tho Daily Sohcxjuling Pao^ogo, if supportod by an obj oot. shal l support at mi ni mum tho default 24 hour i ntofval .

[3] Tho Weekly Scheduli ng Packago. if supportod by an objoot, shal l support tho defaul t val ues for Start Ti rrv) and Stop Time attri butes. Tho Week Mask attri bute shall support scheduli ng for each

day of tho wook, and, at a mi ni mum, the default 24 hour peri od for i ntervals of tho day.

[4] Support for the External Schodul ar Package is beyofxi the scope of those agreements.

5 Management Functions and Services

5,1 General Agreements

5.1.1 Cbnv^ions Used tn SMF Agreements

£ac^ Sy^m Management Function defines a set of services referred to In thfe document m*$MF services*;

Agreements pertinent to SMF services are provided in the fc^ovtt'ing subclauses. Each subdause contains a

series of t^;^ as fdlovi/s,

For each service, a normative table references text agre^ner^ which constrain

^U6a$e and/or value

of the associated service parameters. Text agreements defined elsewtiere In tWs docLH7i«t are referenced by

Ifause nurrriaef. The lack Of a row or reference signifies no agreement beyorxl tt\& base standard.

tSfc^eS p(3iiJe pararneter usage tor recpjest; Indfcatiw^ respor^atxl confirmation

iervice primitives. TlT«se codes, defined in subclause t.8.3 di these agreemerte ^Classification of ponfonnance), tl ISO/IEC TR 10000- 1 (Framework and Taxonomyof I SFs) {ISPFRMJ, and in ISO/IEC TR 8509

(Service Conyentjons) [ISPSRVC], are repeated here for read^ convenience:

30
PART 18: Network Management September 1991 (Stable)

M Mandatory

0 Optionai

C(p) If Condition p exists, then parameter .j$'lT?andatOr^ otherwise, the

p^tfametef Is not applicable.

X Excluded

1 Out Of Scope

In these agreements, this means that, tor thfe correspondkig element,

* Implementations may use It outside Ihe scc^e of these agreements.

* conformance tests shall not be provided for It, * Implementations may conform to other agreenieriilWi fWrk?uired,

f no requirements are placed on either transrrwtter or receiver to support

i

* receiver actions are unspecified when present.

Not Applicable ^ The value of the parameter Is identical to the corresponding parameter lil the Interaction desaibed by the preceding related service primitive.

U The use of the parameter Is a service-user option.

P The parameter is mapped directly onto the corresponding parameters of

the CMIS service primitive; refer to subclause Q for agreements regarding

this pass-through para^

triIddMlon, flie' cohv^ntloh •A> B" Is iised In horrhatlve tat^es tb Indicate both theiisap^p^c^le^ by the fcese standard (A) and the addittonaJ constraint imposed by these agreements (B). This convention Is Intended to

call attention to agreements which modify the usage of a service param^er.

Unless otherwise rKrted, cc^vJitlonat parameters (C) sh^ be present according to the corKOtJons defxied in fCMlS] arKt the referenced System Management Function base standard.

Genera) A9reements Referenced By Many SMf Servieet

The fdlowing general agreements pertain to some or all of the System Managenwnt FurKtloh services defined

thrcxighoiA cteuse 5. Normative tables for each SMF service reference these general ayeements where

applicable. These agre^inents do not apply to SMF services and parameters which do not reference thern.

5.1.2. 1 Maximum Length of Notification Identifier

To firrat lrTQ>lem«itation comf^extty. the maximum length of the Notification IdentTjef parameter shall be 32 bits.

31
PART 18: Network Management September 1991 (Stable)

5.1^2 Maximom Number of SET Items

To Bmft ln^3iemwttatlon conr^irfexfty, the tnaixlmiim itu parameters lhat recif^ents must be aWe to process shall be 64^

5.1^3 Maximum Length of AddHional Text

To IJmlt lmpiemer»!atfon cc«Tfi|rfe>(fty; the ma>^mum teng^ <3i fiie AckStlonjJ Te^d pamm«ief wWch recipients

must be able to process ^t^I be 256 octets.

5.1^4 U«eof Acfditional Info

Editor** Note: [The Additional Information paramet^^ de^

•signScance Indicator/ H requires tl-«t "[e]ven If the AddSion^ Information p^ameter is nd

fijly iflTderstood, an event report indication shaS be Issued to the US^. Indication that the

Adcfitional Information parameter Is n<« fully undwstood te a tpcatf matter."J

Object Management Function Agreements

S^f Generai Agreements

These agreements re<¥uiffi support for the SMF services defined bythe obfec^frsnagerrient ^ndard [OMF].

These a0*eement8 also require conformance to the abstract syntaxes identified In dsme 11 of the objeca

management standard |OMF] arxl specified in (Df^l) , with the exception of event record subdasses. If support

for the log contrd standard [LCF] as described In clause S.7 Is clainwd, then ait {OMF] event record

subclasses shall also be recjulred by these agreements. These agrewieftfs permit optioned n^jo^^on of the

system nrtanagemerU fL9lC specified in dause lO pf |OMf]>,

S^Z Objea Creation Reporting

This subclause provides agreements pertinent to the Object Creation Reporting SfvlFseivlce defined by section

9.2 of [OMF] . Sutxilause 6provldes agreements pertinent to CMIS services and pass-through parameters used

by this SMF sendee,

Table 1: Agreements On Parameter Usage Pertinent to tiie Object Creation

Reporting SMP Service

32
PART 18: Network Management September 1991 (Stable)

^eportl)i9 Parameter

Dam rieci Rsp SMF

Agre^mehtl

EvontType

Event Information

Source Indicator

Attnbute List y

; Notification fdenfifer 1 5:1

Correlated NotHicatJons U 5.1.2.2

Additional Texl U 5.1.2.3

; Additional Info u 5.1.2.2,5:1.2^

5.2.3 Object Deletion Reporting

This sufaclauseproNdctesa£^eements pertlnHsnt to tH6 Direct D^eWll^pltJh^

9.3 of lOMFJ. $ut>clause 6provides agreements pertinent to C^IS services and pa$s-ilvough parameters used

by this SMF sen^^

Table 2: Agreements On Parameter Usage Pertinent to the Object Deletion

Reporting SMF Service

SMF Object DeleUon

Reporting Parameter

Req Rsp SMF

Agreemehtl

Event Type m C{=)

Event fnforn^ticm

Source Indicator u •

Attnbute list •

Notification tdenfifier § 5.1.2.1

Co^ Notifioatidns i

* 5.1.2.2

; Additional Text i 5.1.2.3

Additional Info i 5.1.2.2, 5.1.2.4

33
PART 18: Network Management September 1991 (Stable)

S.2.4 AttrliHtteValuft Change Reporting

This subdausB provides agreements pertinent to the Attritxite Vafu« Change Reporting SMF sefvice d^ed

by section 9.4 of (OMFJ. Subclause 6 provides agreemerta pertin^ to QM^ $ei\4c6S and pass-through

parameters used by this SMF service;

Table 3; Agreements On Parameter Usage Pertinent io the Attribute Value

Change Reporting SMF Service

SMF Attr Value Change

Report Parameter

Req SMF

Event Typo m

Event tnformaticHi

Source Indicator

Attribute Identtfier List i

AttritHite CHange Definition

Attribute Identifier M

Old Attribute Value 0

New Attribute Value M i

NotifioatiCHi tdentifter i 5:1 2.1

Correlated NotMoations i 5.1.2.2

Adcfitional Text 11 5.1.24

Additional Info i $,tJ2.2;5.t.2^

5.2.5 PT-Creale

Ttag 8Ut>clau$e provide? no additional agreements pertinent to Ihe Ft-Oaate SMF advice beyond the base

standard definitlm k\ section 9.5 of [OMF], Subclause 6 provides agreements pertlnemtcCfcftIS: services and

pass-through pamm^^ used by this SMF sen/ice^

34
PART 18: Network Management September 1991 (Stable)

This subcJause profvtdes no addltioral agreements pertinent lo the PT-Detete SMF eorvfce beyond the base

starKJarcl definitfaKi in section 9.6 of [OMFJ, Subclause 6 provides agreemetspertinem to CWIS services and

pa$$-thfouoh parameters i«ed by this SMF services

S^T PT-Sel

This subdatse provides no additional agreements pertinent to the PT-Set SMF service beyond the base

standard d^lnltton in section 9.9 of (OMFJ. Subclause 6 provides agreements perttner^ to CMIS services and

pass-through pararneters used by this SMF service.

This subclause pro^Aies no addittonal aQreernerits pert^^ beyond the t»ase standard definition Resection 9. 7 of [OMF]. Sulxlause 6 provides agreements pfrti^ services and

pass-thnxigh par»t«t^s used by tW$ SMf^ sei^^

TWs siixteuse provides no additional agreements pertinent to the Pt-6^

Standard deflnttkxi In section 9.9 of (OMF] . Subclause 6 provides agreements |>ert^^ and

pass-through paramet©^ used by this SMF service.

5.2.10 PTCveni

TWs sutx^ause piwtdes no additional agreements pertiner* to the PT-Evem SMF s«vtce beyond the base

standard defirttionin sec«ion9. 1 0 of {OMF]< Subclause 6 provides agreements pertinent to CI^S services and

pass-through pa«met^ used by this SMF sen^ce^

5.3 State Management Function Agreements

5.3.1 Genml Agreements

Thes6 agr6em«i8 rec;^^ support for the SMF servfces d^med by tf» state mane^3iem«Tt ^tendeud IST^ijJIf]^

The$0 agre^tl&rts also require conformance to the abstract syntaxes identified m clause tl of the state management st^ard [STMF] and specified in [DM!j. with the exception devera record siAcJass. If support

for the log cor^ standard LI-CFJ as described in clause 5.7 Is claimed, then a8 ISTMFJ event record

35
PART 18: Network Management September 1991 (Stable)

$Mi;>o^$$i$$ $h$ii{at$o b^f0C|uM by ^$$0 a0r$$»i$nt$. Th0$»agr«iem$nt$ permit opttonal ne9oti$tioii of tfi$

State Change Reporting functiwE^ unit specified \n clause 10 of [STMFI>

5,3.a State Change Reporting

Tl^^i^i^oseprovides agreements p^rttnentiothe SEa|0CH$t)00{^$pQt!tng$MF$^iced^ed byse&tton

d<l of [SIMFJ. Subclause 6 iHOvides agre^er^s pervert to OMS seiwes and ji^ss-ltirough paratneters

Tabie4:

Reporting

BiAf State Change Report

Parameter

ill m SMF

Agreements

Event Type i i

£vem Information

Source Indicator i

Attribute Identifier Ust i

Slate Change Definition

Attribute Iden^ler i

Old State Attribute Value i

V State Attribute u

Value

Notifiqation Mentlfier u 5.1.2.1

Correlated Notification^ u 6.1.2.2

Additional Text u

Additional Info u M 5*1.2,2, 5.1.2.4

5.4 Attributes For Representing Relationships Agreements

36
PART 18: Network Management September 1991 (Stable)

Oeneral Agr^^m^rils

Th^0 agr$0m0ni$ require support for tho $MF servloee defined by the mM^imm^^t^r^

Retatibnshlps standsBtl [ARRJ*

These agreenienlsarso require conformance to the abstract syntaxes identrfled in clause 1

'1 of th'e attributes lor repfe$ent^f«| relat^oni^p$ ^tarjdard |ARRj and specified in [DMl), with the exception of event record

subcTass. If support for the log control standard [LCF] as described in clause 5.7 is claimed, then all [ARB]

event recorcJ ^uljotasse^ $halt also be required by these agreements. These agreements pemnit optional

Regotiatjon of Ihe Relaiionshrp Change Reporting functional unit specified in clause 1 0 of ( ARRp

$A2 Belationshtp Change Reporting

This subclause pr£Witre$ agreemerjts pertinent to the Relationship Change Reporting SMFsen/Ice defined by

section 9, 1.1 of [ARB], Subdause 6 provides agreements pertinent to CMIS services and pass-through

pararnetefs::use«li.^iM SMF services

Table 5: Agreements On Parameter Usage Pertinent to the Relationship Change

Reporting SWtF Service

$MF Ret Chajige Report

Parameter

ill SMF

Agreements

Event Type i

Event Informatlan

Source Indtcalof i

Attribute identifier list i

R^aHons^p Change

Infomjation

Attribute Identifier m M

Old Rel Attribute Value i

M New Rel Attribute Value m %

Kotifloatlpn Identifier i 5.1.2, 1

Correlated Notlficatioh$ i 5.1.Z2

Additional Text i 5.1.2.:3

Addi^onal Info i

5.1.2.2, 5.1.2.4

37
PART 18: Network Management September 1991 (Stable)

BM Alarm Reporting Function Agreements

These agr^emehts r^quN support for the SMF setvlc^s ctefjtwd by U^^^larm reportlnfii standard (AftFJ.

These aQreemenls also mqutre conformance tO the ebstraf* Syntaxes Identified in clause 1 1 of the alarm

ffipordrtgi ^nctard [ARF| and specified in [OMl], with i^e exceptkxn of m&ti rBoosd subclass* if support for the log control standard [LCF] as described in claifse 5.7 is claimed, then all [ARFJ event reOor>isubciasses

8h£dl also be requlrs^ by these agreements. These agreements p^mit optional inegotia^n the PMm

Msam Reportli^

This sulx^ause puttvides agreements pertinent to the Aiamn Rspcxting SMF sen^edeSned by section d<d of

|AfiF), Subclause 6 provides agreements pertinent to ClwiS servioes and pass-through parametere used by

thisiiSMiisetvice.

Table 6: Agreements On Parameter Usage Pertinent to the Alarm Reporting

$Mii:Ser»lce

SMF Alarm Reporting

Parameter

Req Rsp SMF

Agreemeht$

Event Type 1 iill

Event Information

Probable Cause m

Specific Problenns i 5.1.2.2

Perceived Severity m

Backup Object Instance i III BackedUp Status i

*

Trend Indication i

Tteshold Informatioi^ i

t^otifloation Identifier i 5J .2*1

38
PART 18: Network Management September 1991 (Stable)

SMFAfarm Reporting Req III SMF

f^aratnetdr ISiriiiiniitiiti n

Sta.te Chahae DefiniSon

til

OldSt^te AttrV^iue i

Nqw St^tQ Attr V^ue i

MonHoredl Attributes i

Proposed Repsir Aqtfon u 5.1.2.2

A(jlctitiOn^ Text u 5.1.2.3

A<tCtitiOnal info u 5.1.2.2, 5.1.2.4

|t] To avoid jtmblgufty, the Dl^nguished Name form of this parameter shalt be Implemented atxJ may be us©! Use of Local Distinguished Name and Non-Specific forms are beyond the scope

<tf the$$i agreements, if an implementation Is unable to decode or understand the semantics Of 8ns parameter, an appropriate CMIS error (j<e<* Invalid Attribute Value) shall be returned.

5,6 Event Report Management Function Agreements

$.d.1 General AQreemenls

These agreements require support for the SMF services defined by the event report management standard

Theseagreemen|$ also require confomiarice to the abstract syntaxes identified in clause 1 1 of the event report

management statvfard [ERMF] and specified In [DMI]. These agreements permit optional negotiation of the

WOnltor Everjf Report Management and Svent Report Management functioral units specified in clause 10 of piMili

5.6.a Initiaiion Of Bvent Report Forwarding

Tf^S subclauseprovides agreements pertinent to the initiation of Event fieport Fon^van^lng SMFsen/toe defined

fay section 9.2 of [ERMF|. Subclause 6 provides agreements pertinent to CMIS services and pass-through

parameters used by this SMF service.

39
PART 18: Network Management September 1991 (Stable)

Table 7: Agreements On Parameter Usage Pertinent to the Initiation of Event

Bepori rorwardfng SIVII= Service

SMF InttiattOfiof ill mm

Parameter Agreements

Discriminator Construct i i

9. i u£* f

ft

M m

s ACuve ussiinauon m

MWt uri loll a.uVQ QtaiQ '(^ M

vJpcfciLIUi lal Oldlp

m

AHrimr>fnh<s

M

r'innfi-rmAH JUtr\H*a

weeKiy ocnociuitny noCKay^

Week Mask i i PI

Daily Schoduling Package

Intervals Of Daj^ i i m

DuraiKon PadkagI

Start Time i i m

StbpTffne i i m

Bctemai Soh0(tular Paoka0$

Sch^dulariName i ill m

40
PART 18: Network Management September 1991 (Stable)

ft| As specltlecf in (CMIPJ, ih^ valu^ "AND {}* shaB be used to mpmmwmw^fwmmfmt

CkMisferuct, ff param^r is omitted from the request, tfie all-pass value shall be assigned to

Dlscrlffilitaior Con$truot ^ttrlbutd.

|2| The Dally $<sh«dUtlng Psickage, If supported by an object. $ha« support at minimum the default

|3| Ifm Weeldy ^cbedullng Pacioge, suppcated by an object, shall support the Week Mask

mtmm for egoh <ray of tKe week, and, at a *nlnlmqm, the default 24 hour period4qrJrttefvai$

|41 The Duration Package. ^ supported hy ar» obfect. shall sipportthe defauft v^uWWWrrife

atidi$topiiiltne;a!!ributes^

"

|5| SiQi^Kat fbf ihe External Scheduler Package is beyond the scope of these agreemetit$.

5.^9 Termination Of Event Report Forwarding

This subclause provides noadditional agreements pertinent to the Termination of Event Report Forwarding

l^F service beyond theiwse standard definition In section 9^3 of [ERMF] . Subclause 6 provides agreements

pertfin®TltoCMIS services and pass-through parameters used by this SMF service.

$.6.4 EFD Modlfteation, Suspension* artd Desumpttoi)

Tfi^sei^lauseprovldesagreementspertinent loihe Event Fonwarding Discriminator Modlficatton, s

mvi Re$urrp:lon Sf4F service defined by section 9.4 of {ERMF|* Subclause 6 provides agreements pertinent

toCMtS services and pass-thtough parameters used by this Wi¥ setvice.

Table S: Agreements On Parameter Usage Pertinent to the Event Forwarding

Discriminator !\flodIficatlon» Suspension, and Resumption SMF Service

srytF £FD

Mod/Suspend/Besume

Parameter

ill wm

Agreements

Disdnmln^or Construct i i

Destinalkm i i

Backup Dest Ust Package

Backup Destinaltori U$t i i

41
PART 18: Network Management September 1991 (Stable)

Mocl/SMSperxi/Resume

ill iii

Acttve u^&tinauon m

Adnilnlstraliv© State M m

m

iMocfe Package

Confirmed Mode it-it y

'ir>k m

Weekly Scheduling Package —-

Week Mask i m M

Daily Scheduling Package

s::::s|f!lt<*fttfll<S •::::::W:l!HW;-¥«Hi«> Of Hav WCljF:

Duration Package

Start Time i 1 11

Stop Time i i 1]:

External Schedular Package

Schedufar Name U>! C>l [51

m As specified in [CMIPJ, the valUB "AND {)" shall be used to represent an i^l-pass Discriminator

|2| The Dally Scheduling Package. If supported by an ob|ect. shail support at minimum the default

Z4 houf ^erval>

|3| The Weefdy Scheduling Package, if supported by an object^ shad support the Week Masic

attrMe lor each day of the week, and, at a minimum, the default 24 hour period for Intervafs c^the day:

f4| The Duifatfon Package, ^ supported by an object, shall support the default values for Start Time

anid:$t£;pi:^imei:a£^

|$| ^i^i^DCit iot Sie Exti^r^l Schedular Package is beyond the scope of thi^ agrei^ents.

42
PART 18: Network Management September 1991 (Stable)

5.7 Log Control Function Agreements

(Refer to the Working Implementation Agreements Document.)

Security Alarm Reporting function Agreements

^efer latheWorking Implementation Agreements Document.)

$S Secartly Audn Trail Function Agreements

(pefer to the W<:ffkinp Imjirfementatlon Agreements Document.)

5.10 Objects and Attributes tor Access Control Agreements

(Refer tothe Wmking Imi^em^atlon Agreements Document)

5,1^ Accounting Meter Function Agreements

(Refer lothe Wwklhg Imi^ementation Agreements Document.)

5.ia Workload Monitoring Function Agreements

^efer to the WofklriQ Imptement^tion Agreements Document.)

5.13 Smnmarl2atlon Function Agreements

$^efef to theWorking Implementation Agreements Documerrt:<)

5.14 Test Management Function Agreements

^efer lotheWctfkIng ImpJementatlon Agreements Document)

5.1 1 :;onfidence and Diagnostic Test Classes Agreements

43
PART 18: Network Management September 1991 (Stable)

(R0Jertothe Work&iQ Impfemetitatioft Agreeflient© Document)

6 Management Communications

This clause identifies, in detail, use of the management communications services and protocols, based on the

standards defined in [CMIS], [CMIP], [ADDRMVS/P] and [CANGETS/P].

This clause covers the agreements pertaining to the use of associations over which to carry management

PDUs, agreements pertaining to the services offered to a CMIS Service User (in terms of the functions defined

in clause 5), agreements pertaining to the protocol used to convey the management PDUs, and agreements

pertaining to the services required of other layers in order to convey the management PDUs defined.

6.1 Association Policies

Associations are established using the procedures described in [ACSEP].

6.1.1 Application Context Negotiation

These lAs specify the negotiation of appli cati on contoxto as dosoribodthe Systems management application context specified in [SMC]. Other application contexts are outside the scope of these agreements.

6.1.2 Functional Unit Negotiation

These lAs specify that System Management Functional Units are negotiated as specified in [SMO].

6.1.3 Security Aspects of Associations

(Rofor to the Worki ng I mpl omontati on Agroomonts Documont.)

the ACSE airthentfeatiort wecharilsnns end associeted dele types ehall be as defined <rt efeuse 1 1 (Upper

Layers Security) di pen 13 of the Ol^WWorking Agreements.

Suiport of ACSi authenticate^

6.2 General Agreements on Users of CMIS

These agreements are based on the standard defined in [CMIS], [CMIP], [ADDRMVP] and [ADDRMVS]

constrain the users of CMIS services and not the implementation of CMIP itself.

44
PART 18: Network Management September 1991 (Stable)

6.2.1 Object Naming

Object Naming will be accomplished using Distinguished Name or Local Distinguished Name. Use of nonspecific form Is outside the scope of these agreements.

6.2.2 Multiple Object Selection

Multiple Object Selection applies to all management operations except M-EVENT-REPORT, M-CREATE and

M-CANCEL-GET.

6.2.2.1 Scoping

These network management lAs specify that scoping shall be used as specified in [CMIS] 6.5.1, 8.3.1.1.5,

8.3.2.1.6, 8.3.3.1.6, 8.3.5.1.5.

6.2.2.2 Filtering

These network management lAs specify that filtering shall be used as specified in [CMIS] 6.5.2, 8.3.1.1.6,

8.3.2.1.7, 8.3.3.1.7, 8.3.5.1.6.

If a system receives a filter parameter that it is unable to process, it shall return the error "complexity limitation",

including the CMISFilter requested.

If, in the process of filtering from a set of selected entitles, there are no managed objects selected, the system

shall return an empty response consisting of an Invoke ID and no response argument.

If an Jm{^ementatloR supports^ Filter fundtonal \mh It shall minimally support AND or OR with a setof

tmfM&t 00nMQm {iot wHch furfih$r tti^intjof MID tifOB CfOn^UCts is not required) , and NOT. In addition,

tfm impA&nerts^km ^t^I support sending and recwv^ng edi tBterttem choices for each filter condttioa This

GJ0Stn$that3i <5onrfornf^R0 teipl^ftiefttalloftis not rec^lred to support compounds (AND or OR) with more than

tv«> Items, arxt Is mt required to support nested constructs, Addftlonal fSter complexly may optiorally fag

supported Mktth6$isa0r$e«i&nt$.

6.2.2.3 Synchronization

In order to support interoperability between managing systems and managed systems, these network

management lAs define that the default synchronization (i.e., BestEffort) shall be supported by all conforming

systems. Atomic synchronization may also be supported as an option.

, If a performer is unable to comply with a synchronization request specified by an invoker, the performer shall

! return the error "synchronization not supported" with the parameter Indicating the synchronization not supported.

45
PART 18: Network Management September 1991 (Stable)

6.2.2.4 Multiple Replies

These network management lAs specify the use of multiple replies as specified in [CMIS] 7.1 , 7.2.3.

Curront/Evont Ti me

The ti me val ue that i s roportod to CMI S, if provided, shoul d bo as oi oeo as poosi bl o to, but not boforo, tho

actual ti me that the operati on to whi ch the reported ti me val ue appli es ooourrod. Thi s constraint is stipul ated

to provi de tho most accurate t i mostamp for temporal orderi ng of operati ons and events on a si ngl e open

system.

For those network management l As, tho encodi ng of tho Current Ti me parameters is ASM. 1 Generali sed Ti me,

UTCType, as spocifi od in [ASN1 ] cl ause 32.3, b) and c), wi th tho preci si on of tho ti me representati on i ndi cati ng

thogranul arity of thoti me measurement. For exampl e, the stri ng 10800613123012.333 0600 roprosonts a l ocal

ti me of 12:30:12 (and 333 msocs) on 13th Juno 1080, i n a ti me zone whi ch is 6 hours behi nd GIVIT.

6.2.3 Access Control

Conformant implementations are not required to use this field. The Access Control field, if provided by the

invoker in CMIS request indicators, may be ignored by responding systems which do not support access

control. These systems shall not reject a request on the basis of the presence of access information. The

invoker may interpret this as acceptance of the access control parameter.

6.2.4 CMIS Funotional UnitsSub^etS

Onl y tho Kernel Functi onal Unit must bo supported. Other functi onal uni ts except Extended Son/ico are opti onal and thei r use shall be negotiated as spocifi od i n [CMI S]. Extended Sorvi oo i s not withi n tho ccopo of these agreements. Negotiati on for its "non uso" shall be supported.

CuiT^ntty Ih0 only way to $ubi$^ OMIP odpat>iliite$ l^througN CM]^ Fiinoftonal Uni!$ j[FM$V

An Implementation shali support CMIP FUs as Indicated by one ol the following defined subsets:

46
PART 18: Network Management September 1991 (Stable)

FUNCTIONAL UNITS

Multiple

"ilil"

Multiple

Object

Selection

Cancel Filt^ Extended

Service

i

i

Basic i I

i i 1

1

i

i

i m i i i !

M « yancl^ttory 0 * Optional VM^^ Scope

«ach d$$ooiattDn, u$e of functional unlt$ $hall be negotiated

^

specified In (CMISJ.

6.3 Specific Agreements on Users of CMIS

These agreements are based on the standard defined in [CMIS] and [ADDRMVS]. The agreements in this clause have been defined in terms of those capabilities necessary to support the functions and services defined

in clause 5 (Management Functions and Sen/ices) of these agreements. These agreements constrain the users

of CMIS services and not the implementation of CMIP itself.

The parameter presence information in the tables in this clause is repeated from [CMIS] and has the same

meaning as in the standard. It is repeated for reader convenience. In addition, these tables provide references

to text clauses where agreements are stated relative to parameters in each table. The lack of a reference

signifies no agreement beyond the base standard.

6.3.1 M-EVENT-REPORT

The following agreements and clarifications, pertinent to section 8.2 of the base standard [CMIS] and section

6.3 of the base standard [CMIP] and regarding the M-EVENT-REPORT sen/ice, are included within these

network management lAs.

Clause 5 (Management Functions and Services) of these agreements defines some of the types of Event

Reports that may be sent.

6.3.1.1 Event Argument

All arguments defined for the particular event type of the managed object class (see clause 7, Management

Information Agreements) for the M-EVENT-REPORT must be supplied in the Event Argument parameter. The

Event Information and Event Reply parameters shall be supplied as specified for the event type.

47
PART 18: Network Management September 1991 (Stable)

6.3.1.2 Parameter Agreements

Conditional parameters (C) siiali be included according to the conditions defined in [CMIS] unless those

conditions are refined by the referenced agreement.

Table 24|: M-EVENT REPORT Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 lnvoi<e Identifier M M(=) 6.4

2 Mode M

3 Managed Object Class M U 6.4.5

4 Managed Object Instance M U 6.2.1

5 Event Type M C= 6.4.5

6 Event Time U

7 Event Information U 6.3.1.1

8 Current Time U

9 Event Reply - C

10 Errors c 6.4.4

6.3.2 M-GET

The following agreements and clarifications, pertinent to section 8.3.1 of the base standard [CMIS] and section

6.4 of the base standard [CMIP] and regarding the M-GET service, are included within these networl<

management lAs.

6.3.2.1 Successful Response

For a successful M-GET operation, the performer shall return (in the Attribute List parameter) either the attribute values for all attributes explicitly requested (in the Attribute Identifier List parameter), or the attribute values for

all attributes defined for the managed object(s) selected (if the Attribute Identifier List is omitted).

6.3.2.2 Partially Successful or Unsuccessful Response

For a partially successful M-GET operation, where only some attribute values were retrieved, the performer

shall return (in the Errors parameter, specifically encoded as GetListError) all attribute ids and their corresponding values that were successfully retrieved from the set of attributes selected as described above,

48
PART 18: Network Management September 1991 (Stable)

together with all attribute ids, and the corresponding error codes, for each of the attributes for which errors were detected. All attributes requested by the invoker must be processed, with either a value or an error code

returned for each.

6.3.2.3 Multiple Replies

For the final reply of a series of multiple relies or the single reply where no objects were selected when filtering

has been specified, the GetResult is omitted. Hence Managed Object Class, Managed Object Instance,

Current Time and Attribute List are all omitted in these cases.

6.3.2.4 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are refined by the referenced agreement.

Table M-GET Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 6.4

2 Linked Identifier C 6.4

3 Base Object Class M 6.4.5

4 Base Object Instance M 6.2.1

5 Scope U 6.2.2.1

6 Filter U 6.2.2.2

7 Access control U 6.2.3

8 Synchronization U 6.2.2.3

9 Attribute Identifier List U 6.4.5

10 Managed Object Class C 6.4.5

11 Managed Object Instance C 6.2.1

12 Current Time U

13 Attribute list C 6.4.5, 6.3.2.1, 6.3.2.3

14 Errors c 6.3.2.2, 6.4.4

't 49
PART 18: Network Management September 1991 (Stable)

6.3.3 M-SET

The following agreements and clarifications, pertinent to section 8.3.2 of the base standard [CMIS] and section

6.5 of the base standard [CMIP] and regarding the M-SET service, are included within these network

management lAs.

For a suGCOSsful M SET confi rmed operati on, tho porformor shall return (i n the Attri bute Li st paramotor) tho

attri bute val ues for all attri butes oxpli oitl y spocifi od (

i n the Attri bute List parameter) i ndi cati ng thoi r now val ues.

For a partially successful M-SET operation, where only some attribute values were modified, the performer shall return (in the Errors parameter, specifically encoded as SetListError) all attribute ids and their corresponding

values that were successfully modified from the set of attributes ids and values supplied, and all attribute ids and the corresponding error codes for each of the attributes for which errors were detected. All attributes requested by the invoker must be processed, with either a value or an error code returned for each.

6.3.3.2 Multiple Replies

For the final reply of a series of multiple relies or the single reply where no objects were selected when filtering

has been specified, the SetResult is omitted. Hence Managed Object Class, Managed Object Instance, Current

Time and Attribute List are all omitted in these cases.

6.3.3.3 Add/Remove Response

Where multi-valued attributes are involved in an M-SET operation [ADDRMVS], the values returned after any

modification operation must be the full set of values of that attribute and not just the values that were modified

(e.g., added or removed).

6.3.3.4 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions specified in [CMIS] unless those

conditions are modified by the referenced agreements.

6.3.3.1 Successful Response

6.3.3.1 Partially Successful or Unsuccessful Response

50
PART 18: Network Management September 1991 (Stable)

Table 2311: M-SET Parameters

item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 6.4

2 Linked Identifier - C 6.4

3 Mode M -

4 Base Object Class M - 6.4.5

5 Base Object Instance M - 6.2.1

6 Scooe u 6.2.2.1

7 Filter u 6.2.2.2

8 Af!CPSi> control u 6.2.3

9 Synchronization u 6.2.2.3

10 Managed Object Class c 6.4.5

11 Managed Object Instance c 6.2.1

12 Modification List M 6.4.5, 6.3.3.1, 6.3.3.3, 6.3.3.4

13 Attribute List u 6.4.5. 6.3.3.1, 6.3.3.3

14 Current Time u

15 Errors c 6.3.3.2, 6.4.4

6.3.4 M-ACTION

The following agreements and clarifications, pertinent to section 8.3.3 of the base standard [CMIS] and section

6.6 of the base standard [CMIP] and regarding the M-ACTION service, are included within these network

management lAs.

6.3.4.1 Multiple Objects

When multiple objects are selected for an M-ACTION operation, there is no ordering implied among selected

objects.

51
PART 18: Network Management September 1991 (Stable)

6.3.4.2 Parameter Agreements

Conditional parameters (C) shall be Included according to the conditions defined in [CMIS] unless those

conditions are modified by the referenced agreements.

Table 2412: M-ACTiON Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 6.4

2 Linked Identifier C 6.4

3 Mode M -

4 Base Object Class M - 6.4.5

5 Base Object Instance M - 6.2.1

6 Scope U - 6.2.2.1

7 Filter U 6.2.2.2

8 Managed Object Class C 6.4.5

9 Managed Object Instance c 6.2.1

10 Access control U 6.2.3

11 Synchronization U 6.2.2.3

12 Action Type M C(=) 6.4.5

13 Action Information U

14 Current Time u

15 Action Reply c

16 Errors c 6.4.4

6.3.5 M-CREATE

The following agreements and clarifications, pertinent to section 8.3.4 of the base standard [CMIS] and section

6.7 of the base standard [CMIP] and regarding the M-CREATE service, are included within these network

management lAs.

52
PART 18: Network Management September 1991 (Stable)

6.3.5.1 Managed Object Instance

The Managed Object Instance request parameter may be present or absent depending on whether the invoker

supplies the instance name or the performer assigns the Instance name automatically. The definition of each

Managed Object Class specifies whether or not this parameter must be present. This definition shall apply to every management-initiated creation of instances of that managed object class.

6.3.5.2 Attribute Values

The values of each of the attributes of the newly created object are derived as defined in [MIM] 5.2.2. 1 . If none

1 of these methods provides a value for any one attribute, then the operation shall be considered to have failed,

I.e., no new instance Is created, and the error code 'Missing Attribute Value' shall be returned.

6.3.5.3 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are modified by the referenced agreement.

Table 2511: M-CREATE Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 6.4

2 Managed Object Class M C 6.4.5

3 Managed Object Instance U C 6.2.1, 6.3.5.1

4 Superior Object Instance U 6.2.1

5 Access Control U 6.2.3

6 Reference Object Instance U 6.2.1

7 Attribute List U C 6.4.5, 6.3.5.2

8 Current Time U

9 Errors c 6.3.5.2, 6.4.4

6.3.6 M-DELETE

I The following agreements and clarifications, pertinent to section 8.3.5 ofthe base standard [CMIS] and section

6.8 of the base standard [CMIP] and regarding the M-DELETE service, are included within these network

management lAs.

53

1
PART 18: Network Management September 1991 (Stable)

6.3. 6.1 Del et i on of Objects Containi ng Obj oots

The error 'ProoosGi ng Fail ure' shall bo roturnod tf a managed objoot has oxl Gt i ng oontai nod objects and tho behavior dofi nod for that object prohi bi ts i ts del eti on unl ess all contai ned objects have boon dol oted.

6.3.6.1 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are modified by the referenced agreements.

Table 2614: M-DELETE Parameters

item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M( = ) 6.4

2 Linked Identifier C 6.4

3 Base Object Class M 6.4.5

4 Base Object Instance M 6.2.1

5 Scope U 6.2.2.1

6 Filter u 6.2.2.2

7 Access control u 6.2.3

8 Synchronization u 6.2.2.3

9 Managed Object Class C 6.4.5

10 Managed Object Instance C 6.2.1

11 Current Time U

12 Errors C 6.3.6.1, 6.4.4

6.4 Specific Agreements on CMIP

These agreements are based on the standard defined in [CMIP] and [ADDRMVPj. The agreements in this clause have been defined in terms of those capabilities necessary to support the functions and services defined

in clause 5 (Management Functions and Services) of these agreements.

These network management lAs make no agreements beyond the specifications in [CMIP] and [ADDRMVP],

except the following:

54
PART 18: Network Management September 1991 (Stable)

6.4.1 Invoke/Linked Identifier Size

Invoke Identifiers and Linked Identifiers must be encoded in an integer of four (4) octets maximum length.

6.4.2 Version

Protocol Version 2 (only) is supported.

6.4.3 Linked Reply Values

Responders must send a linked reply value that corresponds to the original invoke operation value.

6.4.4 Error Codes

Responders must send error types that correspond to the operation definition for the original invoke.

6.4.5 Parameters

The CMIP globalForm shall be supported for the following parameters:

ActionTypeld

Attributed

EventTypeld

ObjectClass

Use of localForm is outside the scope of these agreements.

In^^entatior^ stell receive all forms of all ASN. 1 CHOICE types and values defined in [CMIP]. Receipt sl^

require pas$ingth^ value to the CMIS user,

6.4.6 Acc«»s Control Parameter

ftn implementatior! shall be able to send the accessControl parameter.

6.5 Services Required by CMIP

CMIP requires the sen/ices provided by ACSE and ROSE. The conformance requirements for these sen/ices,

and the underlying communication required to support them, are specified in part 5, subclause 13.7.

55
PART 18: Network Management September 1991 (Stable)

ACSE Functional Units: Kernel

6.6 CMIP PICS

(Refer to the Working Implementation Agreements Document.)

7 Management Information

Thi s ol auso, whi ch i s based on I SO standards' dooumonts [MI M] and [GDMO], oontai nGagroomonts regardi ng

basi c conoopts and modelli ng tochni quos rol atod to managomont i nformati on. I t onumoratos agroomonts on

(

i ) the i nformati on model (subcl ause 7.1), (

ii ) pri nci ples for nami ng managed objects and their attri butes

(subclause 7.2), and (

iii) gui dolinos for defini ng managomont i nformati on (subcl ause 7.3). I t i s not wi thin the

scope of thi s cl ause to make agroomonts about speci fi c el ements of management i nformati on or to defi ne

such specific el ements of managomont information. Such defi ni t i ons and/or agreements can bo obtai ned via

the Managomont I nformation Li brary (

IVI I L) produced by the OSI MI B Worki ng Group ( a subgroup of the NMSIG).

TtI The I nformation Model

Thi s subcl ause contai ns agroomonts rol atod to the i nformati on model as speci fi ed i n cl ause 6 of [MI M].

774t4 inhoritanoo

! The foll owi ng constrai nt rol atod to inheri tance i s enforced i n ordc to remove potenti al ambi guit i es:

Duri ng the lifeti me of a managed object i nstance, each of its attri butes must have a value that is valid for tho attri bute syntax of that attri bute.

774t2 All omorphiom

All omorphi sm, as specifi ed i n cl ause 6. 1.3 of [M I M], i s not supported. Any other speci fi cati on withi n the [MI M]

or [GDMO] that refers to al lomorphi sm is also not supported. "Not supported", i n th i s context, moans that an

i mpl ementati on that compli es wi th tho NMSI G l As is not requi red to i mplement all omorphi sm.

7t4,3 RfterThe concept of fil ter is supported as speci fied in cl ause 6.3 of [MIM]. Restri cti ons on its usage are cpocifiod

i n subcl ause 6.2.2.2 and subcl ause 6.1.3.2 of those agreements. The restri cti ons i n subcl auce 6.2.2.3 are appl icabl e when tho i mpl ementation i s usi ng "pure" CMI S. I f tho i mpl ementati on i s usi ng sorvi ces of the System

Management Functi ons specifi ed i n cl ause 6. the fil t er restri cti ons spocifi od i n subcl ause 5.1.2.1 appl y.

56
PART 18: Network Management September 1991 (Stable)

7^2 Prinoi pl os of Naming

Thi s oubol auGO oontai no agroomonto about pri nciploo of nami ng ac opooifi od I n olauoo 6 of [MI M],

Name Structure

7.2.1.1 Objoct Cl ass I donti fi cati on

A managed object ol aco i o i donti fi od by an ASN.1 objoot i dontifi or. ao Gpooifi od in olauoo 6.3.1 of [MI M].

7.2.1.2 Object I nsta nce I dontificati on

The di oti nguiohod name approach io used for tho idonti fi cati on of managed objoot i notanooG, as Gpooifi od in

ol auoo 6.3.2 of [MI M].

7.2.1. 3 Attribute I dentificati on

Each i ndividual attri bute of a managed objoct i o i donti fi od by an ASN.1 objoot identifier, ao Gpooi fi od i n ol auoo

6.3.1 of [MI M].

7.2.1. 4 Managed Object Knowledge

Dynami c chari ng of managomont knowl odgo i o not oupportod. However, all attri butoG related to oharod

management knowledge are contai nod i n tho managed objoot ol aoo "top", which i o dofi nod i n [DM ! ] . Si nce all managed object cI ogg defi ni t i ons i n tho MI L are deri ved from "top" ao defi ned i n [DMI ], thooo managed objoot ol aoooG will , by defi nit i on, contain tho management knowl edge attri butoG.

Si nce All omorphi Gm i o not Gupportod, the All omorphi c Supcrcl aoGOG attri bute, whi ch i o one of tho attri butoo

defi ned i n "top", will have ao i to val ue, the OBJECT I DENTI FI ER of the managed objoot ol aoo to whi ch it bel ongo.

7^ Gui dol lnos for th o Definition of Managomont Information

Thi o oubcl auoG oontai no agroomonto about gui dol i noo for the defi niti on of management i nformati on, ao

speoi fi ed i n [GDMO]. Thooo guldoll noo appl y to dovoloporo of contri butiono to tho Managomont I nformat i on

Li brary. They form a normative part of tho otandard; honco thoy muot bo otri otl y foll owed whil o defi ni ng

managomont i nformati on.

57
PART 18: Network Management September 1991 (Stable)

JiZri Syntaoti cal Defi ni t i ons of Managemont I nformati on

7.3.1.1 Managed Object Class Template

Tho ALLOMORPHI C SET construct of tho Managed Object Cl ass Templ ate spoci fi od in cl ause 10.3.2 of [GDMO] i s not supported. "Not supportod", i n th i s context, moans that no managed object cl ass defi ni t i on i n the Managemont I nformati on Li brary will contain thi s construct.

7.3.1.2 Pookago Templ ate

The foll owi ng constrai nts appl y to the Package Templ ate specifi ed i n cl ause ^0.A.2 of [GDMO]:

For the ATTRI BUTE GROUPS construct, new attri butes shall not be added to the group attri bute

from withi n the managed object cl ass templ ate because thi s can l ead to ambi guiti es. Hence, tho

[< attri bute l abel >] porti on of th o supporti ng defi ni t i on for the ATTRI BUTE GROUPS construct shall not be uoed.

The REGI STERED AS construct shall bo mandatory.

7.3.1.3 Attri bute Template

The foll owi ng constrai nt appli es to the Attri bute Templ ate speci fi ed i n cl ause 10.7.2 of [GDMO]:

The BEHAVI OUR conctruct may bo omi tted onl y if a behavi our defi ni tion has been i nherited from

the parent attri bute, i .e., the attri bute is deri ved from another attri bute whose defi niti on contains a BEHAVI OUR conctruct.

7.3.1. 4 Attri bute Group Template

For the ATTRI BUTE GROUP to bo useful , it i s rocommondod that tho GROUP ELEMENTS construct be precont.

Ts^^a Guideli nes For Defi ni ng Behaviour

The foll owi ng detail s shall be provi ded i n the sot of spoci fi cati onc defi ni ng a managed object cl ass:

a textual descript i on of tho network resource the managed object cl ass represento. i ncl udi ng

its functi onal rol e.

a descri pti on of tho rel ationshi ps that can occur between different i nstances of the managed

object cl ass being defined, as well as those that can occur between i nstances of the managed

object cl ass bei ng defi ned and i nstances of other managed object cl asses.

58
PART 18: Network Management September 1991 (Stable)

a doscripti on of tho oporationc that aro cupportod by tho managod objoot cl aGc, wi th proci oo

dofi niti on of tho offoctc. ci do offoctc i f any, conctrai ntG, rocponoo notifi cati ono, fa il uro modoo.

spooifi cati on of how i nstanooc of th i s managod objoct cl aoc aro croatod and dol otod, parti oul aily

whothor thoy can bo croatod/dol otod vi a tho managomont CREATE/DELETE oporati ono.

a doscripti on of noti ficationo that can bo gonoratod, tho condi ti one that gonorato thorn (o.g., orosoi ng of a throchol d). their oontonto and ci do offoots, if any. I n part i cular, i denti fy all tho

attrl butoG that aro cubjoct to the Attri buteChango and StatoChango notifi cati ono,

if theoo

notifl oati ons aro supportod.

other oonstrai nte, i ncl udi ng those i nvol vi ng other managod objoct cl aocoG.

7^9^ Other Guidel ines

Tho Systoms Managomont functions have defi ned vari ous attri butes and ovontc, as indi oatod i n clauGO 6 of thoso agroomonto. Objoot dofi nors shall make use of these attri butes and ovonto wherever appli cabl e.

Tidr^ I nitial Val ue Managed Objects (

I VMO)

Tho foll owing text ol arifi os underl yi ng concepts of I nit i al Val uo Managod Objects (IVMOs) specifi od i n cl auoo

8.7of [GDMO]:

I niti al Val ue Managod Objects, described i n cl auso 8.7 of [GDMO], aro most usoful i n cases whore managod object cl asses that do not support tho CREATE operati on have boon defi ned. I nstanoos

of such objoct cl asses would bo created as a resul t of the normal operati on of tho network, but it may bo desi rabl e to bo abl e to control the i nitial val ues of attri butes of now i nstances of such objoct cl asses vi a managomont.—

VMOs provi de a mechani sm to do th i s.—The NMSI G Transport

Connecti on Profi le managod object cl ass defi ned i n the MI L i s an exampl e of an I VMO.—It represents the col lection of charactori st i c attri butes that suppl y defaul t and i nit i all y adverti sed

attri bute val ues to be usod by i nstances of tho NMSI G Transport Connecti on managod object cl ass when the i nstances aro created. Si nce the NMSI G Transport Connecti on managed objoot cl ass does not support the management CREATE operation, thi s I VMO servos as a mechani sm whi ch all ows i nitial values of attri butes of i nstances of tho NMSI G Transport Connecti on managod objoct cl ass to bo controll ed by management.

7 Management Information

This clause, which Is based onlSO standards' documents fMtM]and [GDMO],contalnsagreementsfeprd!ng

basic CohC^ptsunci modetling techniques related to management information. It enumerates agreements on

^) the Information mcxlel (subclause 7,1) and (li) guidelines for defining management information (subdause

7.2)v thes^ agrei^en^a apply to developers of contributions to the Management Information Library (MIL).

They form a normative part of the standard; hence they must be strictly followed wh8e defining management

Normatiort. U is not within the scope of this clause to make agreements aboul^ ^jedfic elements ^

59
PART 18: Network Management September 1991 (Stable)

and/oragreemenks <sm be obtained via the Management information Ubraryx

7,1 Tli^ liiformatfon Moder

WheniTiOdeBinQtmrtageirientmforiTTatloa, these agrees wththefoSOwirig addJtioriat

7*1*1 intterttanee

The foBoWirt9 oort^ralnt related to inheritance is enforced b order to remove potential ^*Tit?l0u^e«

During th^ iUetinTe of a maraged obfect Instance, each of It^ attribtlte^ must haive d value that 1$

\«lid:*QP;;thie:::attrlbute syntax of that attribute.

7.1^ iivteroper^bitity

7.1*2.1 InkffiropwablUty Provided By The A^enl System

AKomorphlsm^assped^d In clauses 2 3 1 of [UM], is out <^ scope. Anyo^r^cl5ca^n«^Nnthe [MUl

Of (ODMOI that refers to allomorphism is also out of scope.

7.1.^2 liit«'opcH^|]^ility Provided By The Manager System

The ssmanttes of clause 5,2.3.2 of [MM] are supported. A manager system can ^

<^ect identic as $ped^6d in daus^ 7-4,5 of [GDMO] to specify that a managed object should perform ah operation as a member of its actuai class. The object identifier Is Intended to be used \n reqiiest^ oitfy, and shall be

Nerpreted by ^e reSpwder as a requirement to return its real object class ValUfeljI^thft:*^ Ag^eitt

s^tenjs shail support thJs object identifier as defined in [MlMj 5.2.3.2 and [GDMO] 7AJSh

7.1^ Filter

The oono^of i&supported as specified in clause 6. Pestrlctiws wfts^ usage are s^ec^Bed m subdause

BJi.Z2 of ^leseagreements;

7.1.4 Manademeni operations

An impiemer^ie^ ©lat compiles with these agreements shall support maragenient {^rations as defined ih diause 5.3.4 df {UM] wISi the fdllowing additional claiiftcation.

60
PART 18: Network Management September 1991 (Stable)

pwij olau$e $.3,4.t (2). [DU\] clause 6.t4, and fGDMO) clause 6.1.4 Imply fih^ the object

attrtbi^eshail not be included in thie create request Attribute Ust parameter. [MJMJ states that any

coBfiltstir^ <iupltoate specifications cause th$ request to fait

7AS Deletion of Objects Containing Objects

TItb error 'Proces^ng Failure' shall be returned tf a managed object has existing contained objects and tfie b^vlor defined fortfiait object prohibits its deletion unless all contakiecl objects have been deleted*.

yjZ Ouldellnes lor the Definition of iManagement rnformatloii

TWs st^JEteusB contetns agreements about guidelines lor the definition of management information, ^

spi6(g8iedin(GDMO|j

7.2.1 S^l^<^cal Definitions of l\Aanagement Informatltm

i 7^^j Attribute Template

^ Tiie fdlowing constraint applies to the Attribute Template specified in clause 9J,2 of (GDMOJl

Hie BEHAViOUi^ construct may be omitted oriy If a betevlour definition has been inherited from

ti!JB:5P2B!erft:ial»:lbute, I.e.. the attribute is derived from another attribute whose definition contains a aEHAVlOUB construct

iJUt Guidelines For Defining Behaviour

The fdlovs^g details should be provided in the set of specifications defining a managed ob|ect classi

* a textual description of the network/system resource(s) ihe managed oiafect class re}>resems»

indydlhg ^eir functional role;*:

- a deeoriptlon of the relationships that can occur between different Ihstswcee of

^

managed

i^mt class being defined, as well as those that can occur between instances of the manage^

C^ect dass being dePned and instances of other managed object classes,

- a dest^lpticwi of the operations tliat are supported by the nonaged object class, with precise

defiritlon of the effects, side effects if any, constraints, response notifications, faiure modes.

« sp©daica«on of hovr Irvstances of this managed object class are created and deleted, partlculartsf

Whether they can be created/deleted via the management CReATE/OElfTE operations.

61
PART 18: Network Management September 1991 (Stable)

a desci-iptlon <)f notiflcatlons that can bd gdneratod, the <;onditrons that generate them {&g..

crossmg of a 1 hreshdd), their contents and stde-effects, If any> In particular^ Identify all the

i3^rll)(tf0$:: ::M are subfect

ndE^ca^ons are supports

to the AttributeChange mi StateChange noti^tions, g these

- c*her constraints, Indliidlng those involving other managed direct classes.

7v2,3 Other OuMeiine^

Th9 $y$tei!n$^ ^»a9^em$nt functions have defined variou$ attribut$$ d»d a$ I»di03t9ci^ tn <ilaM$e ^ of these agreoTwrts, Object definers shoi^ make use <rf these attributes and events whaiever appllcaWe<

S Conformance

8,1 Introduction

C^us© 8 spec^ the conformance requirements for the OIW Networlr Managemem ImirfenE^efitatlon Agreemwits (lAs). tn^CTnentors of products will provide claima erf confornianceto these requlrenients* thesa

claims will be In the form of Protocol Implementation Conformance Statements <PICS) and Managed ObJecS

Confomiance Statwients (MOCS). These requirements wil also be used todev^op lest whlc^iwilt be

used ID vaSdisdte claims of conformance. This clause defines the generat carScgmsim raqiJrements and

criteria which ^8be used as a basis for tests of implementations ctaimtng cofifotmartce tothi^agreement8>

Dependent conformance requirements are defined In the context in which they are used (&g., 8MF gener^

conformance raijulrwients Indude CMIP dependent conformance requirements for C^tS 8^kjes Used),

(F?efer to theWorking Implementation Agreements Document for additional Jntrodudory text)

8.2 Gejuerai Requirements of Conformance

Confonmancefor these agreements Is designed to specify a well-defined set of niarjagememcapabiltles and

features- Porthe|>urposes of organization and darfty of these agreements, n»nagert»ent has baeri divided

Into tfvee cantegortBS. Clauses 5 (Management Functions and Services), 6 <Managemem Communications)

and 7 (Maiiagorrient Information) state the agreements which respectively comprise Ihree Cionformanca

t^egories. Within these categories, particular conformance categories are speeded whidh delineate

conloffinarwereqiBrenTentsfor a well-defined and bounded set of mar^gemer^capabilities arid features <e.g., withtin die Management Functions and Services confomaance categories, a conformancecategoryIs specified

wfiich defines oor^^^mance to Alarm Reporting and State Management Services), OrKje a conformance

category Is d^ln^ed which specifies the set of requirements for that category,, tests can be dev^oped to evaluate conforfnar»oe of products to that conformance category. An6 finally^ fc^" sorne oonformar«j0

categories^ rcfes (Manager, Agent, or both) are specified. One or more roles ntay be sufp»ted f<y those

it^onformariCe^iCategorles to whicfi an implementation is conformant

62
PART 18: Network Management September 1991 (Stable)

Th0 <lfiv^opm$«t i3l oottformanoe <jategorle$ will $naW0i

1) u$m to d^line procurement $p0clfloatlotis.

2) vertdOf$ to define flnati^gem^nt capai>aiti$$ and featur0$;

3) oonlormenoQ lest housee end othei^ to define te9t im&a,

Tol>eoo»iomi^iothe^^ animpieraenteyon $h$ilbe oonrormantto^lee$ton0OfDiefolloW&igMI^^^

0 Management Communication

0 Managenftent Funotlone and Services

0 Mana9ement Iniomnatlon

IfT^emenlatloas which are eonfontiant to these categories shall comply with the requirements stated In the

follawin^ clause^;

8.3 Sp(dcil{<; Conformance Categories

Management Oommunteation Categories

To ise oonfortmni: to the JVIanagement Communication categories, an implementation shall conform to agreemwts inolause6» Cortforrnance to management communication also requires an implementorto state which el ttie management communication profiles specified In clause 6 are supported In the Imfrf^nentation.

Theirt^jiem^or** statement of whicti profSe is supported shalt be indicated in a CMIP PICS as follows. The

implemeiitor 8h£^ con^plete the PiCS proforma as specified by one of tim profiles specified in dau&e

Hole: tConlcH'mance requirements fc* Shese lAs, relating to services required of the upper layers and other

AS^srare discussed in part 5i clause 1 3.7]

Management Functions and Servlcee Conformance Categorlee

{ftefer lotheW<»kbig Implementation Agreements Document.)

8.a.a.1 General Management Capabilities Conformance Category

{Refer tothe Wwking Implementation Agreements Document.)

63
PART 18: Network Management September 1991 (Stable)

Alarm R^rttug amt Mdmigemeftt Capabltilteft Conformttnoa Cal^ory

{f{$/t^t 10 th0 Working Impr^mentatlor) Agr6dm$nt$ Dooum^tit)

AJarm jReportfng Capabilities Conlormanca Category

Pefer to the Working I mplementation Agreements Docufwenl|

8.3.2.4 General Event Report ManaQemet^^

{Hefer toth^ Working Implementation Agreements Document.)

Qanarat Log Contr(^ Conformance GategcMy

(Refer totNe Warkmg Implementation Agreements Dociiment)

0,3^ Management information Conformanoe Category

To be oontormant to Ste Management Information Conformance Category,

^

lmplementaitlc»n shafi incliide at lea^ one managed object defined as specified by clause 7. The requirements for managing ^ismanag«j

object $hail ncA oonflict with the specifications In clauses 5 and 6. Mar^gect <^eot da$d de6i^lQn$ ^tl be

provided eitberinftid or by reference. Registered object identifiers shall be associated wftlianysuclimaiiage<f

object c^a$e {IMtlon and supporting definitions {e.g., attributes, name l^lng$). Ait m^atory abetmct

syntaxes and semantics associated witli those identifiers shall be used* Note ttetaJI managed objects are! supporting di^teifions In Annex A satisfy these conformance requlrementSii;

An Impien^ntate 1$ conformant to a managed object class definition If ft suppori$all the mandatorypacksiQ6$

specified in the nonaged object class as well as all associated information (e<g,>. at^l»ii»s^ Relocations,

actions, parameters) referenced in these packages and at least one name binding that maybeusedtO^Wpport

the naming of instances of this managed object class. Although it is not necessary to be o<ynfonrnam ID all euperior ol^eotolasee^ In the containment tree of an Instance of a conformant managedobj0(^<:^$$, ^name

bindings and r»mlng attributes necessary to access that object instance shall be putjiicly smiisiM*

The Implementor shall provkie a statement specifying which managed objeotolasaes are$U|^Xi^ed. AMQCS

protorma shall be completed by the implementor for each managed ok^ect dass suppoiteEi

Editor's Note: [The CD Version of ISO/lEC 10165-6 (Requirements and Guidelines for Implemwita^on

Conformance Statement Proformas Associated with Marwgemer^ infomiaMon) is now

available. MOOS Proformas for each managed object class supported sbotUd bedeveloped

ilnsistent with 10165-6 IMOCSJ.J

64
PART 18: Network Management September 1991 (Stable)

For each man^Qed object o1a$$ $upported, th$ f<M<Mn^ $|td)l b9 $1^10(1

0......,,^^^^ attribute valu^/mnges, InlSal values)' fOppt^

unless socli constraints are defined in tiie managed ofciject ciass definition;

o a a^^

0 a statement of role(s) (manager, agent, or both) in which the ol)|e(^ class de^

edH0f*t Note iW 10165-6 does not cun^^ty distln^tiift rplll

6.14 Management Application Contexts

Tha Implementation sliall support at least the application context for systems management defined in ISO/tEC*

Hole: t^uch a statement Is required by [SMOJ clause 7.2|

Ifote: [Stidh a slatemem Is required by part 5, clause t^J^ tA^tch di€tcusses conformance reqiAwr»n^

forihesff lAsrw related to $e(A/i0es^^t^^^ the iJpper layers and other ases.|

84 Demonsiration of Conformance

^efer tothe Wcxrking implementation Agreements Document.)

8.4.1 Management Communication

(Refer to the Wofkftig Implementation Agreements Document)

8.4.2 Management Functions and Services

(Refer to the Working Implementation Agreements Document)

8.4.3 ManaQement information

^eHm to Ujo Working implementation Agreements Dooumer*.)

ANNEX A - Management Information Library (MIU

(Refer to the Working Implementation Agreements Document.)

65
PART 18: Network Management September 1991 (Stable)

ANNEX B - NMSIG Object Identifiers

(Refer to the Working Implementation Agreements Document.)

66
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 19 - Remote Database

Access

Output from the December 1990 NIST Workshop for

Implementors of OSI

SIG Chair: Peter Eng

SIG Editor: Peter Eng

Part 1 9 - Remote Database Access

Editor's Note: This section serves as a placeliolder for text provided by the Remote Database Access (RDA) Special Interest Group.

1
I

I

i
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 20 - Manufacturing

Message Specification (MMS)

Output from the December 1990 NIST Workshop

Implementors of OSI

, SIG Chair:

i SIG Editor:

Herbert Falk

Neal Laurance

PART 20 - MMS December 1990 (Stable)

Table of Contents

Part 20 - Manufacturing Message Specification (MMS) 1

0 Introduction 1

1 Scope 1

2 Field of Application 1 2.1 Genera! 1 2.2 Phase 1 agreements 1

3 Normative References 2

4 Definitions 3

5 Corrigenda and addenda 3

6 Status 3

7 General agreements 3

7.1 Max supported PDU size 3

7.2 FileName 4

8 Service-specific agreements 4

8.1 Environment and general management 4

8.1.1 Initiate 4

8.1.1.1 Negotiation of MMS abstract syntaxes 4

8.1.1.2 Max sen/ outstanding 5

8.1.1.3 Local detail calling 5

8.1.1.4 Local detail called 5

8.2 VMD support 6

8.3 Domain management 6

8.3.1 List of capabilities 6

8.3.2 Initiate Download Sequence service 6

8.3.3 Download Segment sen/ice 6

8.3.4 Terminate Download Sequence service 6

8.3.5 Initiate Upload Sequence sen/ice 7

8.3.6 Upload Segment sen/ice 7

8.3.7 Get Domain Attributes sen/ice 7

8.3.8 Get Capability List service 7

8.4 Program Invocation management 7

8.4.1 Start service 7

8.4.2 Stop service 7

8.4.3 Resume service 8

8.4.4 Reset service 8

i

I

\
PART 20 - MMS December 1 990 (Stable)

8.5 Variable access 8

8.5.1 Scattered access 8

8.5.2 Floating point 8

8.6 Semaphore management 8

8.7 Operator communication 8

8.8 Event management 9

8.9 Journal management 9

Annex A (normative)

10

A.I Introduction 10

A.2 Backwards compatibility agreements for calling MMS implementations 11 A.3 Backwards compatibility agreements for called MMS implementations 11 A. 4 General backwards compatibility agreements 12

A.4.1 VMD logical status 12

Annex B (normative)

13

B. I Introduction 13

B.2 References 13

B.3 General 13

B. 3.1 Implementation t>ase 13

B.3.2 Rules of extensibility 13

B.4 Modifications to the protocol definitions 13

B.4.1 Page 39, Section 7.5.2 of DIS 9506-2 13

B.4.2 Page 49, Section 7.6.4, DIS 9506-2 14

B.4.3 Page 95, Section 12.2.1 of DIS 9506-2 14

B.4.4 Page 96, Section 12.3.1 of DIS 9506-2 14

B.4.5 Page 98, Section 12.4.2 of DIS 9506-2 15

B.4.6 Page 138, Section 15.14 of DIS 9506-2 15

B.4.7 Page 166, Section 17.10 of DIS 9506-2 15

B.5 Behavioral requirements 15

B.5.1 Filenames 15

B.5.2 Identify service 16

B.5.3 Initiate service 16

B.5.3.1 Minimum segment size 16

B.5.3.2 Maximum segment size 16

B.5.4 Abstract syntax name 17

B.5.5 Application context name 17

B.5.6 Minor version number 17

B.6 Parameter CBB subset 17

B.7 Service subset 17

iv
PART 20 - MMS December 1990 (Stable)

List of Tables

Table 1 Phase 1 Services 2

Table 2 - MMS Service Subset 18

V
PART 20 - MMS December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Manufacturing Message

Specification (MMS) Special Interest Group (MMSSIG) of the National Institute of Standards and Technology

(NIST) Workshop for Implementors of Open Systems Interconnection (OSI). See Procedures Manual for Workshop charter.

Text in this part has been approved by the Plenary of the above-nnentioned Workshop.

Significant technical change has occurred in this part since it was previously presented.

vi
Part 20 - Manufacturing Message Specification (MMS)

0 Introduction

This section defines Implementors Agreennents based on Manufacturing Message Specification (MMS), as

defined in ISO/IEC 9506. ISO/IEC 9506 lias two parts. Part 1 defines the Virtual Manufacturing Device

(VMD), its subordinate abstract objects, and the services on these objects. Part 2 defines the protocol. Future parts may define companion standards.

MMS, as described in ISO/IEC 9506, is based on the following ISO documents: ACSE Service and Protocol

(ISO 8649, ISO 8650), Presentation Service and Protocol (ISO 8822. ISO 8823), ASN.1 Abstract Syntax

Notation and Basic Encoding Rules (ISO 8824, ISO 8825), and Session Service and Protocol (ISO 8326, ISO

8327). These services and protocols are defined architecturally in the OSI Reference Model (ISO 7498).

These agreements provide detailed guidance for the Implementor, and eliminate ambiguities in interpretations.

An A-Profile based on MMS and these agreements can be used over any T-Profile (see ISO TR 10000)

specifying the OSI connection-mode transport service, or the transport profiles used in support of MAP

(Manuifacturing Automation Protocol), TOP (Technical and Office Protocols), or US GOSIP.

1 Scope

2 Field of Application

2.1 General

Work on implementation agreements will proceed in phases based upon grouping of services and/or

contexts. Implementations are not constrained from implementing services or contexts not addressed by

the current set of stable agreements. Future phases of worl< may affect such implementations.

2.2 Phase 1 agreements

These agreements will be based on a subset of MMS services and protocol listed in table 1 and defined in ISO/IEC 9506-1 and ISO/IEC 9506-2.

1
PART 20 - MMS December 1990 (Stable)

. Tablet Phase 1 Services

Initiate

Conclude

Reject

Abort

Status

GetNameList

Identify

UnsolicitedStatus

GetCapabilityList

Ini t i ateDownloadSequence

DownloadSegment

TerminateDownloadSequence

InitiateUploadSequence

UploadSegment

TerminateUploadSequence

DeleteDomain

GetDomainAt tributes

Read

Write

InformationReport

GetVar i ableAccessAtt r ibutes

Input

Output

CreateProgramlnvocat ion

DeleteProgramlnvocation

Start

Stop

Resume

Reset

Kill

Get ProgramlnvocationAt tributes

3 Normative References

ISO/IEC 9506-1 : 1990 - Industrial automation systems - Manufacturing Message Specification Part 1 : Service

definition

2
PART 20 - MMS December 1990 (Stable)

ISO/IEC 9506-2: 1990 - Industrial automation systems - Manufacturing Message Specification Part 2: Protocol specification

4 Definitions

The definitions given In ISO/IEC 9506-1 are applicable to this document.

In addition the following definitions are used in this document:

- MMS Implementation - a term used to describe a system which conforms to ISO/IEC

9506, acting either as client or server, when it is unnecessary to distinguish between the

MMS-user and the MMS-provider.

- MMSpdu - Any valid value of the MMSpdu abstract data type as defined in Clause 7

of ISO/IEC 9506-2, except fortheinitiate-RequestPDU, initiate-ResponsePDU, and initiate- ErrorPDU choices, encoded in the negotiated transfer syntax.

5 Corrigenda and addenda

(Refer to Working Agreements, Dated December, 1990.)

6 Status

(Refer to Working Agreements, Dated December, 1990.)

7 General agreements

7.1 Max supported PDU size

The max_mms_pdu_size is defined as the maximum number of octets in an MMSpdu encoded using the

negotiated transfer syntax. This size shall apply to all MMSpdu's with the exception of the initiate-Request

PDU, initiate-Response PDU, and initiate-Error PDU. The max_mms_pdu_size shall be negotiated during

connection initiation using the Local Detail Calling and Local Detail Called parameters of the MMS initiate

service.

The negotiated max_mms_pdu_size shall be applied as follows:

3
PART 20 - MMS December 1990 (Stable)

- Any received MMSpdu whose length is less than or equal to the negotiated

max_mms_pdu_size shall be properly parsed and processed.

- An MMS implementation should not send an MMSpdu whose size exceeds the

negotiated max_mms_pdu_size. If an MMS implementation sends an MMSpdu that

exceeds the negotiated max_mms_pdu_size, then it shall be prepared to receive a reject

pdu. Should an MMS implementation receive an MMSpdu that exceeds the negotiated

max_mms_pdu_size, it shall either reject the MMSpdu or accept the MMSpdu as if no

size violation had occurred and perform the expected processing.

- If an MMS implementation is unable to send a service response because the response

would exceed the max_mms_pdu_size, then it shall return a Service response (-) with an

error class of SERVICE and an error code of OTHER.

- When rejecting an MMSpdu because it exceeds the negotiated max_mms_pdu_size,

an MMS implementation shall use a Reject PDU Type of PDU-ERROR and a Reject Code

of INVALID-PDU in the resulting reject pdu.

7.2 FileName

Restrictions for the use of the type FileName in the MMS Abstract Syntax are specified in section 9.1 of part

9 of these agreements.

3 Service-specific agreements

8.1 Environment and general management

8.1.1 Initiate

8.1.1.1 Negotiation of MMS abstract syntaxes

On the A-ASSOCIATE response, the MMS responder shall not accept more than one presentation context derived from an MMS abstract syntax. For this agreement, the term 'MMS abstract syntax' shall represent an abstract syntax from the set containing the abstract syntax defined in clause 19 of ISO/lEC 9506-2 and

abstract syntaxes defined by MMS companion standards.

NOTE - There are technical problems with describing operation in multiple MMS abstract syntaxes over a

single association. These problems have been identified as of 9/90, and form the basis of the prior agreement.

4
PART 20 - MMS December 1990 (Stable)

8.1 .1 .2 Max serv outstanding

An MMS Implementation which intends to conform only with the Client Conformance Requirements for Requester CBBs shall:

a) propose one or greater for the value of the Proposed Max Serv Outstanding Called

parameter in the Initiate service when initiating the application association (calling);

b) offer one or greater for the value of the Negotiated Max Serv Outstanding Calling

parameter in the Initiate service when receiving the application association initiation (called).

An MMS Implementation which intends to conform to one or more Server Conformance Requirements for Responder CBBs shall:

a) propose one or greater for the value of the Proposed Max Serv Outstanding Calling

parameter in the Initiate service when initiating the application association (calling);

b) offer one or greater for the value of the Negotiated Max Serv Outstanding Called

parameter in the Initiate service when receiving the application association initiation (called).

8.1.1.3 Local detail calling

The local detail calling parameter in the initiate request primitive shall specify the max_mms_pdu_size

guaranteed to be supported by the calling MMS implementation. If the local detail calling parameter is absent from the request primitive, then the calling MMS implementation guarantees support for an unlimited

max_mms_pdu_size.

If present in the request or indication primitives, the local detail calling parameter shall not be less than 64; however, it is recommended that at least 512 octets be supported.

8.1.1.4 Local detail called

The local detail called parameter in the initiate response shall specify the negotiated max_mms_pdu_size

for the application association.

If the local detail calling parameter was omitted in the indication primitive, then the local detail called parameter:

a) may be omitted from the response, indicating that the calling MMS implementation

and the called MMS implementation are prepared to support an unbounded

max_mms_pdu_size;

5
PART 20 - MMS December 1990 (Stable)

b) may be specified in the response, indicating a requirement to support the specified

value for max_mms_pdu_size.

If the local detail calling parameter was included in the request, then this parameter shall be present in the

response and its value shall be less than or equal to the value of the local detail calling parameter of the

request.

If present in the response, the local detail called parameter shall not be less than 64; however, It Is recommended that at least 512 octets be supported.

8.2 VMD support

8.3 Domain management

8.3.1 List of capabilities

Only one capability shall be described in each Visible String of the SEQUENCE OF.

8.3.2 Initiate Download Sequence service

The List of Capability parameter shall follow the limitations of 8.3.1.

The syntax and semantics of the capabilities shall be defined by the Server in the PICS. Any deviation from

the defined syntax and semantics shall be grounds for the Server to return a service error with Error Class = RESOURCE and Error Code = CAPABILITY-UNKNOWN.

8.3.3 Download Segment service

A client that receives a Download Segment indication after issuing a Download Segment Result(+) with the

MoreFollows parameter equal to FALSE or after issuing a Download Segment Result(-) shall issue either a

service error, specifying an Error Class = SERVICE and an Error Code = PRIMITIVES-OUT-OF-SEQUENCE,

or an Abort request.

8.3.4 Terminate Download Sequence service

If a client receives a Terminate Download Sequence indication in which the Discard parameter is absent and

the client has not issued a Download Segment response with the More Follows parameter = FALSE for that Domain, it shall behave as If it had received a Terminate Download Sequence indication with the Discard

6
PART 20 - MMS December 1990 (Stable)

parameter present with error class = VMD-STATE and error code = DOMAIN-TRANSFER-PROBLEM. It Is then up to the client application to determine the true state of the Domain and take any recovery action.

8.3.5 Initiate Upload Sequence service

The List of Capability parameter shall follow the limitations of 8.3.1.

8.3.6 Upload Segment service

A server that receives an Upload Segment indication for an Upload State Machine for which it has issued an Upload Segment Resuit(-) or an Upload Segment Result(+) with the MoreFollows parameter equal to FALSE, shall issue either a service error, specifying an Error Class = SERVICE and an Error Code = PRIMITIVES-OUT-OF-SEQUENCE, or an Abort request.

8.3.7 Get Domain Attributes service

The List of Capability parameter shall follow the limitations of 8.3.1.

8.3.8 Get Capability List service

The List of Capability parameter shall follow the limitations of 8.3.1.

8.4 Program Invocation management

8.4.1 start service

A ProgramlnvocationState of non-existent shall be returned in a Result(-) when a request to Start a nonexistent Program Invocation is received.

8.4.2 Stop service

A ProgramlnvocationState of non-existent shall be returned in a Result(-) when a request to Stop a nonexistent Program Invocation is received.

7
PART 20 - MMS December 1990 (Stable)

8.4.3 Resume service

A ProgramlnvocationState of non-existent shall be returned in a Result(-) when a request to Resume a nonexistent Program Invocation is received.

8.4.4 Reset service

A ProgramlnvocationState of non-existent shall be returned in a Result(-) when a request to Reset a nonexistent Program Invocation is received.

It is strongly recommended that for services which use variable access, a Variable List Name or List of Variable be used instead of Scattered Access.

No implementations shall be required to propose or accept the VSCA Parameter CBB.

8.5.2 Fioating point

It is strongly recommended for services which use floating point types or values, that the choice of floatingpoint in the Data and TypeSpecification productions be used instead of the real choice.

No implementations shall be required to propose or accept the REAL parameter CBB.

8.6 Semaphore management

Semaphore services are not considered in Phase 1

.

8.7 Operator communication

No Operator Communication agreements have been identified to date.

8.5 Variable access

8.5.1 Scattered access

8
PART 20 - MMS

8.8 Event management

Event Management services are not considered in Phase 1.

8.9 Journal management

Journal Management services are not considered in Phase 1

December 1990 (Stable)

9
PART 20 - MMS December 1990 (Stable)

Annex A (normative)

Backwards compatibility agreements

A.I Introduction

There Is an installed base of real DIS 9506 based implementations. Providing support for application

connectivity to both DIS and IS is desired as a migration strategy. These implementation agreements will allow IS based implementations to interoperate with DIS based implementations as described in ANNEX B. To achieve this backwards compatibility, the IS implementation shall support all of the agreements in this section.

It was found that the Abstract Syntax name object identifiers of both DIS and IS were identical. Therefore,

the use of zero as the version number allows differentiation between an IS and a DIS based implementation.

Since the abstract syntax name object identifier of any companion standard is different from that used by

the DIS implementations, DIS implementations cannot interoperate with IS based implementations in a companion standard context.

1 The value of zero is a valid value for this parameter in the DIS and not in the IS.

2 There are three types of implementations when considering MMS backwards compatibility.

IMP-1: An implementation based on DIS 9506 as described in Annex B;

IMP-2: An implementation based on IS 9506 with no backwards compatibility agreements

IMP-3: An implementation based on IS 9506 which includes the backwards compatibility

agreements of this annex. Such an implementation can dynamically negotiate to interoperate with an IMP-1, an IMP-2, or an IMP-3 implementation.

Since the value of the minor version number is zero for DIS-based implementations, and is one

or greater for implementations of ISO/I EC 9506, this value can be used to differentiate between

IMP-1 and IMP-2. An IMP-3 system can interoperate with either of these systems. If an IMP-3 is the Calling system, it will offer a value of one (or greater) for the proposed version number. An i IMP-1 system will respond with a value of the negotiated version number of zero, using the

negotiation procedure defined in ISO/IEC 9506. The IMP-3 system will accept this response. If the IMP-3 system is the Called system and has received an Initiate request with a value of zero

for the proposed version number (from an IMP-1 system), it will respond with a value of zero for the negotiated version number. By following this procedure, an IMP-3 can interoperate with an IMP-2 or with another lMP-3 viewed as an IMP-2. After association context establishment, an IMP-3 system shall behave as either an IMP-1 or an IMP-2 system as appropriate on that

NOTES

applied;

10

.1
PART 20 - MMS December 1 990 (Stable)

particular association. The remainder of this section describes additional agreements which

change an IMP-2 implementation into an IMP-3 implementation.

A.2 Backwards compatibility agreements for calling MMS

implementations

A calling MMS implementation shall be capable of receiving and supporting a negotiatedVersionN umber

parameter in the Initiate Sen/ice confirm of zero.

A calling MMS implementation which has received a negotiatedVersionNumber parameter in the Initiate Service confirm of zero shall support the modifications described in A.4.

A calling MMS implementation shall be capable of receiving an Application Context Name parameter value

appropriate to an IMP-1 or IMP-2 in the A-Associate confirm.

A calling MMS implementation which has received a negotiatedVersionNumber of zero shall be capable of receiving and supporting an Initiate Response which has been encoded according to the modifications

described in Appendix B, specifically the capability of receiving and supporting a negotiatedParameterCBB

containing exactly 7 bits.

If a calling MMS implementation receives an Initiate confirm primitive with a negotiatedVersionNumber

parameter equal to zero, the calling MMS implementation shall support the VLIS conformance building block

if the implementation claims support for any service which contains one or more parameters which indicate

the VLIS CBB in its service definition.

A.3 Backwards compatibility agreements for called MMS

implementations

A called MMS implementation shall be capable of receiving and supporting a proposedVersionNumber

parameter in the Initiate Sen/ice indication of zero.

A called MMS implementation which has received a proposedVersionNumber parameter in the Initiate Service indication of zero shall support the modifications in A.4.

A called MMS implementation shall be capable of receiving an Application Context Name parameter

appropriate to an IMP-1 or IMP-2 in the A-Associate indication.

A called MMS implementation shall be capable of receiving and supporting an Initiate Request which has

been encoded according to the modifications described in Appendix B, specifically the capability of receiving

and supporting a proposedParameterCBB containing exactly 7 bits.

If a called MMS Implementation receives an Initiate indication primitive with a proposedVersionNumber

parameter equal to zero, the called MMS implementation shall support the VLIS conformance building block

if the implementation claims support for any sen/ice which contains one or more parameters which indicate

the VLIS CBB in its service definition.

11
PART 20 - MMS December 1990 (Stable)

A.4 General backwards compatibility agreements

A.4.1 VMD logical status

If the current VMD State is SUPPORT-SERVICES-ALLOWED and the association minor version number is zero, then the vmdLogicalStatus parameter shall have a value of STATE-CHANGES-ALLOWED in a Status response or in an unsolicitedStatus request.

12
PART 20 - MMS December 1990 (Stable)

Annex B (normative)

DIS 9506 modifications required for backwards compatibility

B.1 Introduction

This annex is an integral part of this part. It documents the modifications to DIS 9506 required to describe

implementations for which the agreements of this part provide backwards compatibility. This annex as

applied to DiS 9506 is referred to as Version 0.

B.2 References

[1] MMS/1 Manufacturing Message Specification - ISO DIS 9506 - Sen/ice Definition, December 1987

[2] MMS/2 Manufacturing Message Specification - ISO DIS 9506 - Protocol Specification, December 1987

[3] NBS OSI Implementors Workshop Agreements - December 1987

B.3 General

B.3.1 Implementation base

Version 0 is based upon Reference [3] in B.2 as it applies to MMS.

B.3.2 Rules of extensibility

The following sentence is appended to the last paragraph in section 8.2.1.1.5.2 Proposed Parameter CBB

and the last paragraph in section 8.2.1.2.5.2 Negotiated Parameter CBB of DIS 9506-1.

"Any additional bits shall be ignored."

B.4 Modifications to the protocol definitions

B.4.1 Page 39, Section 7.5.2 of DIS 9506-2

CHANGE

13
PART 20 - MMS December 1990 (Stable)

reportEventEnrollmentStatus [60] IMPLICIT ReportEventEnrollmentStatus-Request,

TO

reportEventEnrollmentStatus [60] ReportEventEnrollmentStatus-Request,

B.4.2 Page 49, Section 7.6.4, DIS 9506-2

CHANGE

ApplicationReference ::= SEQUENCE {

ap-title ISO-8650-ACSE-1.AP-title OPTIONAL,

ap-invocation-id ISO-86 50-ACSE-1 .AP-invocation-id OPTIONAL,

ae-qualifier ISO-8650-ACSE-1 .AE-quallfier OPTIONAL,

ae-invocation-id ISO-8650-ACSE-1 .AE-invocation-id OPTIONAL

}

TO

ApplicationReference ::= SEQUENCE {

ap-title [0] OBJECT IDENTIFIER OPTIONAL,

ap-invocation-id [1] INTEGER OPTIONAL,

ae-qualifier [2] INTEGER OPTIONAL,

ae-invocation-id [3] INTEGER OPTIONAL

}

B.4.3 Page 95, Section 12.2.1 of DIS 9506-2

CHANGE

structure [2| IMPLICIT SEQUENCE OF SEQUENCE {

TO

structure [2] IMPLICiT SEQUENCE {

B.4.4 Page 96, Section 12.3.1 of DIS 9506-2

CHANGE

named [4] IMPLICIT SEQUENCE {

TO

14
PART 20 - MMS December 1990 (Stable)

named [5] IMPLICIT SEQUENCE {

B.4.5 Page 98, Section 12.4.2 of DIS 9506-2

CHANGE

generalized-time [10] IMPLICIT General izedTime,

TO

generalized-time [11] IMPLICIT GeneralizedTime,

B.4.6 Page 138, Section 15.14 of DIS 9506-2

CHANGE

additionalDetail [9] IMPLICIT EE-Additional-Detail OPTIONAL

TO

additionalDetail [9] EE-Additional-Detail OPTIONAL

B.4.7 Page 166, Section 17.10 of DIS 9506-2

CHANGE the transfer syntax object identifier value from

{ iso asn1(1) basic-encoding(l) }

TO

{

joint-iso-ccitt asn1(1) basic-encoding(l) }

B.5 Behavioral requirements

B.5.1 Filenames

File Names are specified in accordance with the NBS Implementors' agreements for FTAM Reference [3]

in B.2.

15
PART 20 - MMS December 1990 (Stable)

B.5.2 Identify service

In the Identify service, the vendor, model and revision fields may be of any length, but only the first 64, 16,

and 1 6 octets respectively are treated as significant.

B.5.3 Initiate service

An MMS Client will:

a) propose 1 or greater for the value of the Proposed Max Serv Outstanding Called

parameter in the Initiate service when initiating the application association (calling);

b) offer 1 or greater for the value of the Negotiated Max Serv Outstanding Calling

parameter in the Initiate service when receiving the application association initiation (called).

An MMS Server will:

a) propose 1 or greater for the value of the Proposed Max Serv Outstanding Calling

parameter in the Initiate service when initiating the application association (calling);

b) offer 1 or greater for the value of the Negotiated Max Serv Outstanding Called

parameter in the Initiate service when receiving the application association initiation (called).

B.5.3.1 Minimum segment size

MMS implementations are able to parse and process 512 octets of MMSpdu as they are encoded in ASN.1

basic encoding rules.

B.5.3.2 Maximum segment size

The Max Segment Size is defined as the maximum number of octets in an MMSpdu encoded using the

negotiated transfer syntax. This size will apply to all MMSpdu's with the exception of the initiate-Request

PDU, initiate-Response PDU, and the initiate-Error PDU. The max segment size will be negotiated during

connection initiation using the Proposed Max Segment Size and Negotiated Max Segment Size parameters

of the MMS initiate service.

The Max Segment Size will be applied as follows:

16
PART 20 - MMS December 1990 (Stable)

- Any received MMSpdu which is less than or equal to the Max Segment Size will be

properly parsed and processed;

- An MMS implementation will not send an MMSpdu whose size exceeds the Max

Segment Size.

B.5.4 Abstract syntax name

The ASN.1 object identifier value for the abstract syntax name will be the same as specified on page 166,

section 17.10 of DIS 9506-2.

B.5.5 Application context name

The ASN.1 object identifier value for the application context name will be the same as specified on page 1 66,

section 17.11 of DIS 9506-2.

An MMS implementation ignores the Application Context Name In the A-Associate indication and the A- Associate confirm.

B.5.6 Minor version number

The Minor Version Number is zero.

B.6 Parameter CBB subset

The following subset of MMS Parameter CBBs were considered during preparation of this annex:

- STR1;

- NEST;

- VADR;

- VNAM.

B.7 Service subset

The following subset of MMS services were considered during preparation of this annex.

17
PART 20 - MMS December 1990 (Stable)

Table 2 - MMS Service Subset

Initiate

Conclude

Cancel

Status

GetNameList

Identify

Unsol i ci tedStatus

GetCapabilityList

InitiateDownloadSequence

DownloadSegment

TerminateDownloadSequence

InitiateUploadSequence

UploadSegment

TerminateUploadSequence

Reques t Doma i nDownload

Reques t Doma i nUpload

LoadDomai nCont en

t

StoreDomainContent

DeleteDomain

GetDomainAttributes

Read

Write ' InformationReport

GetVariableAccessAttributes

Input

Output

TakeControl

Rel inqu i shCont rol

ReportSemaphoreStatus

ReportPoolSemaphoreStatus

ReportSemaphoreEntryStatus

CreateProgramlnvocat ion

DeleteProgramlnvocat ion

Start

Stop

Resume

Reset

Kill

GetProgreunlnvocationAt tributes

ObtainFile

GetEventCond i t i onAt t r i but es ReportEventConditionStatus

GetAlarmsummary

ReadJournal

WriteJournal

InitializeJournal

CreateJournal

DeleteJournal

ReportJournalStatus

18
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 21 - Character Set

Output from the December 1990 NIST Workshop for

Implementors of OSI

Editor: Tim Boland

PART 21 - Character Set Usage in OSI Applications December 1990 (Stable)

Table of Contents

Part 21 - Character Set 1

iii
PART 21 - Character Set Usage in OSI Applications December 1990 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Workshop Chair of the National

Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems interconnection

(OSI).

Text in this part has been approved by the Plenary of the above-mentioned Workshop.

iv
Part 21 - Character Set

Editor's Note - Refer to the Working Implementation Agreements for information on this text.

1
I

i!
stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 22 - fWST^Future ODA

Raster Image DAP

Output from the September 1991 NIST Workshop for

Implementors of OSI

SIG Chair:

SIG Editor:

Frank Dawoon Point of Contact: James Wing, IBM

Frank Spielman, NIST
PART 22 - Future ODA Image DAP September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Office Document Architecture

Special Interest Group (ODASIG) of the National Institute of Standards and Technology (NIST) Workshop

for Implementors of Open Systems Interconnection (OSI).

Text in this part has been approved by the Plenary of the above-mentioned Workshop.

Future changes and additions to this version of 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 22: ODA Image DAP September 1991 (Stable)

Table of Contents

Part 22 - Office Document Architecture RASTER |i|i|||DAP 1

Hi

Part 22 - Office Document Architecture RASTER Mi^DAP

Editor's Note - Refer to the Working Implementation Agreements for information on this text.

1
I
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 23 - Future ODA Raster

DAP-(Basic>

Output from the dtme-September1991 NIST Workshop for

Implementors of OSI

SI G Chair:

SIG Editor:

Frank Dawoon Pbint 11^

Frank Spielman, NIST
PART 23 - Future ODA Raster DAP September 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the ODA Special Interest Group (ODA

SIG) of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open

Systems Interconnection (OSI). See Procedures Manual for Workshop charter.

Text in this part has been approved by the Plenary of the above-mentioned Workshop.

Future changes and additions to this version of 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 shaddd.

ii
PART 23 - Future ODA Raster DAP September 1991 (Stable)

Table of Contents

Part 23 - Future ODA Raster DAP-<Baste> 1

0 Introduction 1

iii

Part 23 - Future ODA Raster DAP-(Basie>

0 Introduction

This part is reserved for future stable ODSift Raster DAP-{Basie) agreements. These Agreements may be

found in the aligned part of the Working Implementation Agreements document. When these Agreements

become stable, they will be moved into Part 23.

1

Stable Implementation

Agreements for Open SffWffif

Interconnection Protocols:

Part 24 Future Conforma^^

Testing

Output from the September 1991 NIST Workshop fo^

Implementors of OSl

i Point of Oontact: Eva Kuiper, Hewlett Packard

; Workshop Editor: Brenda Gray, NIST

J,

f
PART 24 - Conformance Testing September 1991 (Stable)

Thi$ part of the |mpii^»in<9ntistton PtgtmmiM i^r^p^^ l?y tho Oonfoirnarto^ T^$£hi$ $pdd$i

Interest Group (GTSiG) i^ the Nallbna{ liistltute Standards and Technology <NI&T) Wori^shcp for tmptementors of Op$n $y$tem9 tiiterooraiection (0$!)^

Text in thl$ part tias appr^^^d by the Plen^ of the above-mentioned V!/ori<$hop.

Future changes and addition$to

^

version of tf)ese ifnptementor Agreements \fM b0 p(^i$hed a$ a new

part. Deleted and ref^aced %m wiit be shown as otitcootit^' New and replacement: lext yM be ^own as

$haded;
PART 24 - Conformance Testing '^^^^^^^IP»"W^

Tabb of Contents

Part 24 - Conformance Testing .

Part 24 - Conformance Testing

Editor'$ NOt0 - Thl$ part 1$ f^s^rved lorMure etabl$ Conformance Testing Agreements. THesC

may be found in the aligrted (Mat of th# Working Implementation Agreements document When these agreements bec<H*» 3t?ible, ttjey will kJe moved into Part ^4*

Stable Implementatiori

Agreements for O^n Syst^j

Interconnection Protocols:

Part 2E j uture Health Care

Output from the September NIST Workshop for

Implementors of OSI

f^oint of Contact:

Workshop Editor:
PART 25 - Heaith Care September 1991 (Stable)

Foreword

Thi$ psift dth^ Stably imfirfementation Agreements was propatK) by the H$^tK Oar^ $p$d$l Ir$t$r0$t Oroup

{CT$t<S:) of the ttetlonal Institute of Standards and Technology (NISI) Workshop iof of Open

Systems Interooniiectiofi (OSI)s

fext in this part has been approved by the Plenary of the above-mentior»ed Workshop;

Future changes and additions to th!s version of these Imfi^ementor Agreements wll be published ^S a new

part. Deleted areJ r^aced text will be shown as otrikoout^ New and replacemerrt text v^l be shown as shaded^
PAm * Health Care September 1 991 (Stable)

Tabb of Contents

Part 25 - H^mOre . . .

. .

. , . . , . ,

, - i^^^^^^^MI

1

l>drt2S« Health Care

I^C^EOf• Note - Thb part is reserved for future afabte Health Care agreomenta.' l\m^'^((mW(W'm^'^

found in tfw ^ndd part of the Working Implementation Agreements document When these agreements

8t«ftjj% will t?0 moved into Part 25.

U. S.G. p. 0. : 1991-31 1-891 : 40056

I

NIST-114A

(REV. 3-89) U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

BIBLIOGRAPHIC DATA SHEET

1. PUBUCATION OR REPORT NUMBER MIST/SP-500/lft3

PERFORMING ORGANIZATION REPORT NUMBER

3. PUBUCATION DATE March 1991

4. TITLE AND SUBTITLE

STABLE ItlPLEMENTATION AGREEMENTS FOR OPEN SYSTEMS INTERCONNECTION PROTOCOLSVERSION 4, EDITION I, DECE^IBER 1990

5. AUTHOR(S)

Tim Boland, Editor

6. PERFORMING ORGANIZATION (IF JOINT OR OTHER THAN NIST, SEE INSTRUCTIONS)

U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

GAITHERSBURG, MD 20899

7. CONTRACT/GRANT NUMBER

8. TYPE OF REPORT AND PERIOD COVERED

Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (STREET, CITY, STATE, ZIP)

Same as item #6

10. SUPPLEMENTARY NOTES

Supersedes NIST/SP-500/177

DOCUMENT DESCRIBES A COMPUTER PROGRAM; SF-185, FIPS SOFTWARE SUMMARY, IS ATTACHED.

11. ABSTRACT (A 200-WORD OR LESS FACTUAL SUMMARY OF MOST SIGNIFICANT INFORMATION. IF DOCUMENT INCLUDES A SIGNIFICANT BIBUOGRAPHY OR

LITERATURE SURVEY, MENTION IT HERE.)

This document records current Stable Agreements for Open Systems Interconnectia

Protocols among the organizations participating in the NIST/OSI Workshop Series

for Implementors of OSI Protocols.

12. KEY WORDS (6 TO 12 ENTRIES; ALPHABETICAL ORDER; CAPITALIZE ONLY PROPER NAMES; AND SEPARATE KEY WORDS BY SEMICOLONS)

13. AVAILABIUTY

UNLIMITED FOR OFFICIAL DISTRIBUTION. DO NOT RELEASE TO NATIONAL TECHNICAL INFORMATION SERVICE (NTIS). X

X

ORDER FROM SUPERINTENDENT OF DOCUMENTS, U.S. GOVERNMENT PRINTING OFFICE, WASHINGTON, DC 20402. ORDER FROM NATIONAL TECHNICAL INFORMATION SERVICE (NTIS), SPRINGFIELD, VA 22161.

14. NUMBER OF PRINTED PAGES 791

15. PRICE

ELECTRONIC FORM

iV U.S. GOVERNMENT PRINTING OFFICE; 1991 — 281-616 /42703

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SYSTEMS TECHNOLOGY

Superintendent of Documents

Government Printing Office

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in the series: National Institute of Standards and Technology Special Publication 500-.

Name

Company

Address

City State Zip Code

(Notification key N-503)
Ii1
1

,i

I

September 1991 (Stable)

CHANGE PAGES TO VERSION 4, EDITION 1 OUTPUT FROM THE SEPTEMBER 1991 WORKSHOP

ISSUED DECEMBER 9, 1991

SUPPLEMENT TO STABLE IMPLEMENTATION AGREEMENTS

FOR OPEN SYSTEMS INTERCONNECTION PROTOCOLS

NIST SPECIAL PUBLICATION 500-183

This document records, In replacement page format, all changes to stable material which was current (according to Version and Edition number) as of the end of June 1991. In this case, that v^ould be NIST

SP 500-183, Version 4, Edition 1. By following the Instructions below, and replacing or inserting the

indicated pages, text will be created which reflects the current status of relevant stable material as of September 13, 1991.

If there are redllnt0 or stri keout in the Table of Contents, then that document should contain the replacement

pages for September 1991. THIS INSERT SET SHOULD BE SAVED.

The following table gives all necessary information. Entries in the first column indicate that those pages are

to be replaced with the pages referenced in the second column.

The instructions below are given by Chapter and Page number, referring to NIST SP 500-183. The changes

made are indicated by redline and strikeout on the pages where the changes occur, and all the replacement

pages are dated in the upper right-hand corner for easy identification.

Changes on replacement pages are Errata (technical, alignment, editorial, or other). The term "other" may

include addition of new stable functionality. All changes apply to the previous version and edition. Replacements reflect the following types of changes:

1. deletion of material (stri ke out) 2. insertion of new material (redHnte-^hadGd wt^ds m senttences), and

3. replacement of old text with new text (combination of (1) and (2) above.

Technical errata are changes from implementor experience which materially affect the meaning or semantics

of a section, and editorial changes do not change semantics. Alignment changes are material changes

made in the interest of international harmonization and evolving base standards.

In general, technical errata are more "severe" than editorial errata, and alignment errata are more "severe" than technical errata. If a particular replacement has a combination of errata, the most "severe" errata will be checked in the replacement page table. Readers should keep in mind that these errata may be further categorized in future editions.
^11^
DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL ALIGNMENT EDITORIAL OTHER

Part 1 Cover

Part 1 Cover

X

Part 1 Foreword

Part 1 Foreword

X

Part 1 Pages 1-2

Part 1 Pages 1-2 X

Part 2

Cover

Part 2

Cover

X

rart 2

Foreword

Part 2

Foreword

X

Part 2

Table of Contents

Part 2

Table of Contents

X

Part 2

Pages 3-4

Part 2

Pages 3-4

X

Part 2 insert Pages 4-1 , 4-2

X

Part 2

Pages 13-14

Part 2

Pages 13-14 X

Part 2

Pages 15-16

Part 2

Pages 15-16

X

Part 5

Cover

Part 5

Cover

X

Part 5

Foreword

Part 5

Foreword

X

Part 5

Table of Contents

Part 5

Table of Contents

X

Part 5

Pages 21-22

Parts

Pages 21-22

X

Part 5

Pages 25-26

Part 5

Pages 25-26

X

ran o Page 26-1 ran 0

Pages 26-1

,

26-2

Y

Part 8

Cover

Part 8

Cover

X
DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL ALIGNMENT EDITORIAL OTHER

rati 8

Foreword

Part 8

Foreword

X

ran o

Table of

Contents

ran o

Table of Contents

X

Part 8

Pages 11-12

Part 8

Pages 11-12

X

Part 8

Pages 15-16

Part 8

Pages 15-16

X

Part 8

Insert Pages 16-1,

16-2

X

Part 8

Pages 59-60

Part 8

Pages 59-60

X

Part 8

Pages 69-70

Page 8

Pages 69-70

X

Part 8

Pages 85-86

Part 8

Pages 85-86

X

Part 9

Cover

Part 9

Cover

X

Part 9

Foreword

Part 9

Foreword

X

Part 9

Table of

Contents

Part 9

Table of Contents

—

X

Part 9

Pages 5-6

Part 9

Pages 5-6 X

Part 9

Pages 13-14

Part 9

Pages 13-14 X

Part 9

Pages 21-22

Part 9

Pages 21-22 X

Part 9

Insert Pages

22-1, 22-2 X

Part 9

Pages 41 -42

Part 9

Pages 41-42 X

Part 9

Pages 43-44

Part 9

Pages 43-44 X
DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL ALIGNMENT EDITORIAL OTHER

Part 9

Pages 45-46

Part 9

Pages 45-46 X

Part 9

Pages 47-48

Part 9

Pages 47-48 X

Part 9

Pages 51-52

Part 9

Pages 51-52 X

Part 9

Pages 53-54

Part 9

Pages 53-54 X

Part 9

Pages 55-56

Part 9

Pages 55-56 X

Part 9

Pages 57-58

Part 9

Pages 57-58 X

Part 9

Pages 59-60

Part 9

Pages 59-60 X

Part 10

Cover

Part 10

Cover X

Dart ran 1 nlu

Foreword

Port ran 1 nlu Foreword X

Part ran in1 u

Table of

Contents

rail Part in1

U

Table of Contents X

Part 10

Pages 1-2

Part 10

Pages 1-2 X

Part 10

Pages 3-4

Part 10

Pages 3-4 X

ran lu Pages 5-6 ran Port inlu

Pages 5-6 X

ran 10

Insert Pages

6-1, 6-2 X

Dor* i n ran lU Pages 13-14Port ran 1 nlU Pages 13-14 X

Part 10

Insert Pages

18-1. 18-2 X

Part 10

Pages 69-70

Part 10

Pages 69-70 X
DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL A 1 & 1 ^LIT ALIGNMENT EDITORIAL OTHER

Part 10

Insert Pages

70-1. 70-2 X

Part 10

Pages 71-72

Part 10

Pages 71-72 X

Part 10

Pages 73-74

Part 10

Pages 73-74 X

Part 10

Pages 75-76

Part 10

Pages 75-76 X

Part 10

Pages 77-78

Part 10

Pages 77-78 X

Part 10

Pages 87-88

Part 10

Pages 87-88 X

Part 10

Pages 89-90

Part 10

Pages 89-90 X

Part 10

Pages 91 -92

Part 10

Pages 91-92 X

Part 10

Pages 93-94

Part 10

Pages 93-94 X

Part 11 CoverPart 11 Cover X

Part 11 Pages iii-ivPart 11 Pages iii-iv X

Part 11 Pages 7-8Part 11 Pages 7-8 X

Part 13

Complete Part

Part 13

Complete Part

X

Part 14

Cover

Part 14

Cover X

Part 14

Pages 1-2

Part 14

Pages 1-2 X ran 14

Insert Pages

2-1, 2-2

X

Part 14

Pages 3-4

Part 14

Pages 3-4 X
DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL AUGNMENT EDITORIAL OTHER

Part 14

Insert Pages

4-1. 4-2

X

Part 18

Complete Part

Part 18

Complete Part X

Part 22

Complete Part

Part 22

Complete Part X

Part 23

Complete Part

Part 23

Complete Part X

Part 24

11 lot^l L Complete Part X

Part 25

Insert Complete Part X

June 1991 (Stable)

CHANGE PAGES TO VERSION 4, EDITION 1 OUTPUT FROM THE JUNE 1991 WORKSHOP

ISSUED SEPTEMBER 9, 1991

SUPPLEMENT TO STABLE IMPLEMENTATION AGREEMENTS

FOR OPEN SYSTEMS INTERCONNECTION PROTOCOLS

NIST SPECIAL PUBLICATION 500-183

This document records, in replacement page format, all changes to stable material wliicii was current (according to Version and Edition number) as of tlie end of March 1991. In this case, that wouid be NIST

SP 500-183, Version 4, Edition 1. By following the instructions below, and replacing or inserting the

indicated pages, text will be created which reflects the current status of relevant stable material as of June

14, 1991.

If there are redllf^e or stri keout in the Table of Contents, then that document should contain the replacement

pages for June 1991. THIS INSERT SET SHOULD BE SAVED.

The following table gives all necessary information. Entries in the first column indicate that those pages are

to be replaced with the pages referenced in the second column.

The instructions below are given by Chapter and Page number, referring to NIST SP 500-183. The changes

made are indicated by redline and strikeout on the pages where the changes occur, and all the replacement

pages are dated in the upper right-hand corner for easy identification.

Changes on replacement pages are Errata (technical, alignment, editorial, or other). The term "other" may

include addition of new stable functionality. All changes apply to the previous version and edition. Replacements reflect the following types of changes:

1 . deletion of material ( stri ke out) 2. insertion of new material (redllnte-^shaded Wi^ds cr sentter^ces), and

3. replacement of old text with new text (combination of (1) and (2) above.

Technical errata are changes from implementor experience which materially affect the meaning or semantics

of a section, and editorial changes do not change semantics. Alignment changes are material changes

made in the interest of international harmonization and evolving base standards.

In general, technical errata are more "severe" than editorial errata, and alignment errata are more "severe" than technical errata. If a particular replacement has a combination of errata, the most "severe" errata will be checked in the replacement page table. Readers should keep in mind that these errata may be further categorized in future editions.

DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL ALIGNMENT EDITORIAL OTHER

Part 1 CoverPart 1 Cover

X

Part 1 ForewordPart 1 Foreword

X

Part 1 Pages 1-2Part 1 Pages 1-2 X

Part 2

Cover

Part 2

Cover

X

Part 2

Foreword

Part 2

Foreword

X

Part 2

Pages 5-6

Part 2

Pages 5-6 X

Part 3

Cover

Part 3

Cover

X

Part 3

Foreword

Part 3

Foreword

X

Part 3

Pages 3-4

Part 3

Pages 3-4

X

Part 3

Pages 9-12

Part 3

Pages 9-12

X

Part 4

Cover

Part 4

Cover

X

Part 4

Foreword

Part 4

Foreword

X

Part 4

Pages 1-2

Part 4

Pages 1-2 X

Part 5

Cover

Part 5

Cover

X

Part 5

Foreword

Part 5

Foreword

X

Part 5

Pages 1-6

Part 5

Pages 1-6

X

Part 5

Pages 11-12

Part 5

Pages 11-12

X

Part 5

Pages 25-26

Part 5

Pages 25-26

X
Part rail

O

Pages 26-1 - 26-2

A

Part 7

Cover

Part 7

Cover

X

Part 7

Foreword

Part 7

Foreword

X

Part 7

Pages 15-16

Part 7

Pages 15-16

X

Part 7

Pages 67-68

Part 7

Pages 67-68

X

Part 8

Cover

Part 8

Cover

X

Part 8

Foreword

Part 8

Foreword

X

Part 8

Pages 61 -62

Part 8

Pages 61-62

X

Part 8

Pages 93-94

Page 8

Pages 93-94

X

Part 10

Cover

Part 10

Cover

X

Part 10

Foreword

Part 10

Foreword

X

Part 10

Pages 5-6

Part 10

Page 5-6

X

Part 10

Pages 11-12

Part 10

Pages 11-12

X

Part 10

Pages 13-14

Part 10

Pages 13-14

X

Part 18

Cover

Part 18

Cover

X

Part 18

Foreword

Part 18

Foreword

X

Part 18

Pages 39-40

Part 18

Pages 39-40

X

Part 18

Pages 41-42

Part 18

Pages 41-42

X

Part 23

Complete Part

X
Stable Implementation

Agreements for Open Systems

Interconnection Protocols:

Part 1 - General Information

Output from the June 1991 NIST Workshop

Implementors of OSI

Chair/Editor, OIW Workshop: Tim Boland

Workshop Editor: Brenda Gray
Part 1 - General Information June 1991 (Stable)

Foreword

This part of the Stable Implementation Agreements was prepared by the Chair of the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection (OSI).

This part replaces the previously existing chapter on this subject. There is no significant technical change

from this text as previously given.

Future changes and additions to this version of these Implementor Agreements will be published as change

pages. Deleted and replaced text will be shown as stri keout. New and replacement text will be shown as shaded.

ii
March 1991 (Stable)

CHANGE PAGES TO VERSION 4, EDITION 1 OUTPUT FROM THE MARCH 1991 WORKSHOP

ISSUED JUNE 1991

SUPPLEMENT TO STABLE IMPLEMENTATION AGREEMENTS

FOR OPEN SYSTEMS INTERCONNECTION PROTOCOLS

NIST SPECIAL PUBLICATION 500-183

This document records, in replacement page format, all changes to stable material which was current (according to Version and Edition number) as of the end of December 1990. In this case, that would be

NIST SP 500-183, Version 4, Edition 1. By following the instructions below, and replacing or inserting the

indicated pages, text will be created which reflects the current status of relevant stable material as of March

15, 1991.

If there are redline or stri keout in the Table of Contents, then that document should contain the replacement

pages for March 1991. THIS INSERT SET SHOULD BE SAVED.

The following table gives all necessary information. Entries in the first column indicate that those pages are

to be replaced with the pages referenced in the second column.

The instructions below are given by Chapter and Page number, referring to NIST SP 500-183. The changes

made are indicated by redline and strikeout on the pages where the changes occur, and all the replacement

pages are dated in the upper right-hand corner for easy identification.

Changes on replacement pages are Errata (technical, alignment, editorial, or other). The term "other" may

include addition of new stable functionality. All changes apply to the previous version and edition. Replacements reflect the following types of changes:

1 . deletion of material (striko out) 2. insertion of new material (redline-shadGd words or sentences), and

3. replacement of old text with new text (combination of (1) and (2) above.

Technical errata are changes from implementor experience which materially affect the meaning or semantics

of a section, and editorial changes do not change semantics. Alignment changes are material changes

made in the interest of international harmonization and evolving base standards.

In general, technical errata are more "severe" than editorial errata, and alignment errata are more "severe" than technical errata. If a particular replacement has a combination of errata, the most "severe" errata will be checked in the replacement page table. Readers should keep in mind that these errata may be further categorized in future editions.
DELETE PAGE

NUMBER

INSERT PAGE

NUMBER

TECHNICAL ALIGNMENT EDITORIAL OTHER

Part 1 CoverPart 1 Cover

X

Part 1 ForewordPart 1 Foreword

X

Part 1 Pages 1-2Part 1 Pages 1-2 X

Part 2

Cover

Part 2

Cover

X

Part 2

Foreword

Part 2

Foreword

X

Part 2

Pages 1-4

Part 2

Pages 1-4 X

Part 2

Pages 9-10

Part 2

Pages 9-10 X

Part 3

Cover

Part 3

Cover

X

Part 3

Foreword

Part 3

Foreword

X

Part 3

Pages 1-6

Part 3

Pages 1-6 X

Part 3

Pages 11-14

Part 3

Pages 11-14 X

Part 4

Cover

Part 4

Cover

X

Part 4

Foreword

Part 4

Foreword

X

Part 4

Pages 3-4

Part 4

Pages 3-4 X

Part 5

Complete Part

Part 5

Complete Part

X

Part 7

Cover

Part 7

Cover

X

Part 7

Foreword

Part 7

Foreword

X

Part 7

Pages 1-6

Part 7

Pages 1-6 X
DELETE PAGE

NUMBER

in*;ert page

NUMBER

AI I^:M^/II:^IT MLIurilVItlN 1 CniTODI cUl A 1 1 UrilAL U 1 ntn

rPart all Qy

Cover

rail Part QS7 Cover

X

Part Q

Foreword

Part r ai I Q57 Foreword

X

Part ran Qy

Pages 5-10

Port ran Qy

Pages 5-10 X

Port ran Qy

Pages 13-16

Port- ran Qy

Pages 13-16 X

Part 9

r ayWo HO Di7

Part 9 X

Part 9

Page 69

Part 9

Dial ii\ \ji 1 UdLriS of Page 69

X

Port rail inlU CoverPart rail 1lUn Cover

A

Port 1 n ran lu

Foreword

Port- -t n ran lu

Foreword

X

Port ran 1lun Pages 5-6Port ran 1

i nu Page 5-6

X

Part 1 ai L in1 u Pages 13-14Part r ai L 101 \j Pages 13-14

V

Port ran 1 rt

i u Pages 17-18 ran Port 1i nu Pages 17-18

AV

ran lU Pages 21-22

Port i n ran lu Pages 21-22

A

ran lu

Pages 31-32

Port t n ran i u Pages 31-32

A

Porf t n ran lu

Pages 47-48

Port ran 1 n\ u Pages 47-48

A

Port ran 1 nlu

Pages 61 -62

Port ran 1 nlu

Pages 61-62

)(

ran 10

Pages 65-92 ran lU Pages 65-92

YA

Part 12

Complete Part

Part 12

Complete Part

X

Part 13

Complete Part

Part 13

Complete Part

X
nCI ETC DA^C

NUMBER

INbtKT PAuc

NUMBER

TcUnNIUAL Al l/^KIHJICKIT' ALIuNMbNl cDITUnlAL Ul ncK

Part 18

Complete Part

Part 18

Complete Part X
NISTTechnical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology—Reports NIST research

and development in those disciplines of the physical and engineering sciences in which the Institute

is active. These include physics, chemistry, engineering, mathematics, and computer sciences. Papers cover a broad range of subjects, with major emphasis on measurement methodology and

the basic technology underlying standardization. Also included from time to time are survey articles on topics closely related to the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs—Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safety codes) de- veloped in cooperation with interested industries, professional organizations, and regulatory bodies.

Special Publications—Include proceedings of conferences sponsored by NIST, NIST annual reports,

and other special publications appropriate to this grouping such as wall charts, pocket cards, and

bibliographies.

Applied Mathematics Series—Mathematical tables, manuals, and studies of special interest to physicists, engineers, chemists, biologists, mathematicians, computer programmers, and others engaged in scientific and technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical

properties of materials, compiled from the world's literature and critically evaluated. Developed un- der a worldwide program coordinated by NIST under the authority of the National Standard Data

Act (Public Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD)

is published quarterly for NIST by the American Chemical Society (ACS) and the American Insti- tute of Physics (AIP). Subscriptions, reprints, and supplements are available from ACS, 1155 Six- teenth St., NW., Washington, DC 20056.

Building Science Series—Disseminates technical information developed at the Institute on building

materials, components, systems, and whole structures. The series presents research results, test methods, and performance criteria related to the structural and environmental functions and the

durability and safety characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treat- ment of a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST

under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures published by the Department of Commerce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally

recognized requirements for products, and provide all concerned interests with a basis for common

understanding of the characteristics of the products. NIST administers this program as a supplement

to the activities of the private sector standardizing organizations.

Consumer Information Series—Practical information, based on NIST research and experience, covering areas of interest to the consumer. Easily understandable language and illustrations provide useful background knowledge for shopping in today's technological marketplace.

Order the above NIST publications from: Superintendent of Documents, Government Printing Office,

Washington, DC 20402.

Order the following NISTpublications—FITS and NISTIRs—from the National Technical Information

Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (FTPS PUB)—Publications in this series col- lectively constitute the Federal Information Processing Standards Register. The Register serves as the official source of information in the Federal Government regarding standards issued by NIST

pursuant to the Federal Property and Administrative Services Act of 1949 as amended, Public Law

89-306 (79 Stat. 1127), and as implemented by Executive Order 1 1717 (38 FR 12315. dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTIR)—A special series of interim or final reports on work performed

by NIST for outside sponsors (both government and non-government). In general, initial distribu- tion is handled by the sponsor; public distribution is by the National Technical Information Service,

Springfield, VA 22161, in paper copy or microfiche form.
U.S. Department of Commerce

National Institute of Standards and Technology

Gaithersburg, MD 20899

Official Business

Penalty for Private Use $300