REFERENCE

NBS

PUBLICATIONS

A11102 5 T 3 b 1

*=1

All 10259361

9

NBS Workshop for Imp/! 1mpleimen^ QC100 .U56 NO.86-3385 REV.2 C.1 NBS-PUBU.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

NBSIR 86-3385-2

Implementation Agreements

for Open Systems

Interconnection Protocols

NBS Workshop

for Implementors of

Open Systems Interconnection

Revised October 2, 1 986

U.S. DEPARTMENT OF COMMERCE, Malcolm Baldrige. Secretary

NATIONAL BUREAU OF STANDARDS. Ernest Ambler. Director

NBSIR 86-3385-2 NBS

RESEARCH

INFORMATION CENTER KBS.'RImplementation Agreements

for Open Systems

Interconnection Protocols

NBS Workshop

for Implementors of

Open Systems Interconnection

Revised October 2, 1 986

Table of Contents

1. GENERAL INFORMATION 1 1.1 PURPOSE OF THIS DOCUMENT 1 1.2 PURPOSE OF THE WORKSHOP 1 1.3 RELATIONSHIPS OF WORKSHOPS TO EVENTS AND ACTIVITIES 1 1.4 RELATIONSHIP OF THE WORKSHOP TO THE NBS LABORATORIES 2

1.5 STRUCTURE AND OPERATION OF THE WORKSHOP 2

1.5.1 Plenary 2 1.5.2 Special Interest Groups 2

1.6 POINTS OF CONTACT 6

2. THE PROTOCOLS 7

3. LOCAL AREA NETWORKS 8

3.1 IEEE 802.2 LOGICAL LINK CONTROL 8

3.2 IEEE 802.3 CSMA/CD ACCESS METHOD 8

3.3 IEEE 802.4 TOKEN BUS ACCESS METHOD 8

4. WIDE AREA NETWORKS 10

4.1 CCITT RECOMMENDATION X. 25 ..... 10

5. PRIVATE SUBNETWORKS 10

5.1 PRIVATE SUBNETWORKS 10

6. NETWORK LAYER 11

6.1 CONNECTIONLESS NETWORK SERVICE (CLNS) 11

6.1.1 Provisions of CLNS using CLNP (IS 8473) 11

6.1.2 Agreements on Protocol Functions 11

6.1.3 Agreements on Optional Protocol Functions 11

6.1.4 Network Dependent Convergence Sublayer Function (CLNS

Over X. 25) 12

6.2 CONNECTION MODE NETWORK SERVICE (CONS) 12

6.2.1

Introduction 12

6.2.2. Provision of CONS Using X.25/PLP 13

6.2.2.

Overview 13

6.2.2. 1.1 Elements of the X.25/PLP for Support of

the CONS 13

6. 2. 2. 1.2 General Operation of X. 25/PLP- 1984 for

Supporting OSI CONS . . . 15

6. 2. 2.Network Connection Establishment Phase 16

6. 2. 2.

Network Connection Release Phase 18

6. 2. 2.Data Transfer Phase -- Data Transfer Service . . 19

6. 2. 2.

Data Transfer Phase -- Receipt Confirmation

Service 19

6. 2. 2.Data Transfer Phase -- Expedited Data Transfer

l
Service 19

6. 2. 2.Data Transfer Phase -- Reset Service 19

6.2.3 Requirements for Underlying Layer 20

6.2.4 Consideration of OSI Transport Layer Protocol Class . . 20

6.2.5 Subnetwork Dependent Convergence Protocol 20

6.2.5.

Network Connection Establishment Phase 21

6. 2. 5.

Network Connection Release Phase ........ 23

6. 2. 5.

Data Transfer Phase - Data Transfer Service ... 23

6. 2. 5.

Data Transfer Phase - Receipt Confirmation

Service 24

6. 2. 5.

Data Transfer Phase - Expedited Data Transfer

Service 24

6. 2.5.

Data Transfer Phase - Reset Service 24

6.2.6 Interworking 25

6.3 ADDRESSING AND ROUTING CRITERIA 26

6.4 GENERAL ADDRESSING AND ROUTING PRINCIPLES 27

7. TRANSPORT ..... 30

7.1 TRANSPORT CLASS 4 . . 30

7.1.1 Transport Class 30

7.1.2 Protocol Interpretation 30

7.1.3 Rules for Negotiation 30

7.1.4 Retransmission Timer 31

7.1.5 Keep-Alive Function 33

7.2 TRANSPORT CLASS 0 34

7.2.1 Transport Class 34

7.2.2 Protocol Interpretation 34

7.2.3 Rules for Negotiation 35

7.3 CONNECTIONLESS TRANPORT 35

8. SESSION 36

8.1 GENERAL 36

8.2 SESSION REQUIREMENTS FOR FTAM 36

8.3 SESSION REQUIREMENTS FOR MESSAGE HANDLING

9. SERVICE ACCESS POINTS AND SELECTORS 38

9.1 UPPER LAYER AGREEMENTS

9.2 TRANSPORT CLASS 4 SERVICE ACCESS POINTS OR SELECTORS

9.3 TRANSPORT CLASS 0 SERVICE ACCESS POINTS 38

10. ISO FILE TRANSFER & ACCESS MANAGEMENT PROTOCOL 39

10.0 INTRODUCTION

10.1 PHASE 1 FTAM IMPLEMENTATION SPECIFICATION 40

10.1.1 Phase 1 FTAM Services 40

10.1.2 Phase 1 Attributes 40

10.1,2.1. File Attributes 40

10.1.2.2

Activity Attributes 41

10.1.3 ISO Deviations and Selections 42

10.1.4 Further Implementation Details 44

10.2 PHASE 2 FTAM IMPLEMENTATION SPECIFICATION 48

10.2.1 Assumptions 48

ii
10.2.2 Presentation Agreements 48

10.2.3 FTAM Service Type Agreements 49

10.2.4 Service Class Agreements 49

10.2.5 Functional Unit Agreements 49

10.2.6 File Attribute Agreements 49 10.2.7

Document Type Agreements 50

10.2.7.1 Character Sets 52

10.2.7.2 Document Type Negotiation Rules 53

10.2.7.3 Relationship Between DUs, DEs and Document Types 54

10.2.8 F-CANCEL ACTION 55

10.2.9 Diagnostic Agreements . 55

10.2.10 Concurrency 57

10.2.11 Requested Access 57

10.2.12 Security 57

10.2.12.1 Optional Password Support 58

10.2.12.2 Access Passwords 58

10.2.12.3 Anonymous User Convention 58

10.2.12.4 Implementation Responsibilities 58

10.2.13 Negotiation 58

10.2.14 Conformance 60

10.2.14.1 Interoperable Configurations 61

10.2.14.2 Relationship to ISO 8571 --The FTAM Standard . . 61

10.2.14.3 Requirements for Document Type Support .... 62

10.2.14.4 Initiators 62

10.2.14.5 Responders 63

10.2.14.6 Senders . 65

10.2.14.6.1 Initiator Senders 65

10.2.14.6.2 Responder Senders . 65

10.2.14.7 Receivers 65

10.2.14.7.1 Initiator Receivers 66

10.2.14.7.2 Responder Receivers . 66

10.2.14.8 Minimum Ranges . 66

10.2.14.9 Meaning for Support of Options Defined in These

Agreements 68

10.2.14.9.1 Service Classes 68

10.2.14.9.2 General Requirements for Implementations

Defined in Section 69

10.2.14.9.3 Recommended Use of Lower Layer Services 69

10.2.14.9.4 Document Type Requirements for

Implementations Defined in Section 69

10.2.14.9.5 Recommended Parameter for

Implementations Defined in Section 70

10.2.14.9.6 Parameter Ranges for Implementations

Defined in Section 71

10.2.14.9.7 File Attribute Support for

Implementations 71

10.2.14.10 Implementation Classes 72

11. ISO PRESENTATION LAYER 75

11.1 GENERAL 75

11.2 PRESENTATION REQUIREMENTS FOR FTAM 75

iii
12. ASSOCIATION CONTROL SERVICE ELEMENT 77

12.1 GENERAL . 77

12.2 APPLICATION ENTITY TITLES ..... 77

12.3 FTAM REQUIREMENTS OF ACSE 77

13. X. 400 BASED MESSAGE HANDLING SYSTEM 78

13.1 INTRODUCTION 78

13.2 SCOPE 79

13.3 PRMD to PRMD 80

13.3.1 Service Elements and Optional User Facilities 81

13.3.1.1 Classification of Support for Services 81

13.3.1.1.1 Support (S) 81

13.3.1.1.2 Non Support (N) 82

13.3.1.1.3 Not Used (N/U) 82

13.3.1.1.4 Not Applicable (N/A) 82

13.3.1.2 Summary of Supported Services 82

13.3.1.3 MT Service Elements and Optional User Facilities 83

13.3.1.4 IPM Service Elements and Optional User

Facilities 85

13.3.2 X.400 Protocol Definitions 87

13.3.2.1 Introduction 87

13.3.2.1.1 Protocol Classification 87

13.3.2.1.2 General Statements on Pragmatic

Constraints 88

13.3.2.1.3 MPDU Size 88

13.3.2.2 PI Protocol Elements . 89

13.3.2.2.1 PI Envelope Protocol Elements 89

13.3.2.2.2 ORName Protocol Elements 93

13.3.2.3 P2 Protocol Profile (Based on [X.420]) 95

13.3.2.3.1 P2 Protocol - Heading 95

13.3.2.3.2 P2 Protocol - BodyParts 97

13.3.2.3.2.1 Privately Defined BodyParts 97

13.3.2.3.2.2 P2 BodyPart Protocol Elements 99

13.3.3 Reliable Transfer Server (RTS) 101

13.3.3.1 Implementation Strategy 101

13.3.3.2 RTS option selection 101

13.3.3.3 RTS Protocol Options and Clarifications .... 102

13.3.3.4 RTS Protocol Limitations 106

13.3.4 Use of Session Services 107

13.3.5 Data Transfer Syntax 107

13.4 PRMD to ADMD and ADMD to ADMD 107

13.4.1 Introduction 107

13.4.2 Additional ADMD Functionality 110

13.4.3 Interworking with Integrated UAs Ill

13.4.4 Differences with other Profiles Ill

13.4.4.1 NTT Profile Ill

13.4.4.2 CEPT Profile 112

13.4.5 Connection of PRMDs to Multiple ADMDs 112

13.4.6 Connection of an ADMD to a Routing PRMD 112

13.4.7 Management Domain Names 112

13.4.8 Envelope Validation Errors 112

iv
13.4.9 Quality of Service 113

13.4.9.1 Domain Availability 113

13.4.9.1.1 ADMD Availability 113

13.4.9.1.2 PRMD Availability 113

13.4.9.2 Delivery Times 114

13.4.10 Billing Information 114

13.4.11 Transparency 114

13.4.12 For Further Study 115

13.5 ERROR REPORTING 115

13.5.1 MPDU Encoding 115

13.5.2 Contents 115

13.5.3 Envelope 115

13.5.3.1 Pragmatic Constraint Violations 115

13.5.3.2 Protocol Violations 115

13.5.3.3 0/R Names 116

13.5.3.4 Tracelnformation 116

13.5.3.5 Unsupported X.400 Protocol Elements 117

13.5.3.5.1 deferredDelivery 117

13.5.3.5.2 PerDomainBilaterallnfo 117

13.5.3.5.3 ExplicitConversion 117

13.5.3.5.4 alternateRecipientAllowed 117

13.5.3.5.5 contentRetumRequest 117

13.5.3.6 Unexpected Values for INTEGER Protocol Elements 118

13.5.3.6.1 Priority 118

13.5.3.6.2 ExplicitConversion . . 118

13.5.3.6.3 ContentType 118

13.5.3.7 Additional Service Elements . . . 118

13.5.4 Reports 118

13.6 MHS USE OF DIRECTORY SERVICES 118

13.7 CONFORMANCE 120

13.7.1 Definition of Conformance 120

13.7.2 Conformance Requirements 121

13.7.2.1 Initial Conformance . 121

13.7.2.1.1 Interworking 122

13.7.2.1.2 Service 122

14. DIRECTORY SERVICES PROTOCOLS 124

15. VIRTUAL TERMINAL PROTOCOL . 125

16. OFFICE DOCUMENT ARCHITECTURE AND INTERCHANGE FORMAT 126

17. PERFORMANCE 127

18. SECURITY 128

APPENDIX A: INTERPRETATION OF SERVICE ELEMENTS 134

APPENDIX B; RECOMMENDED PRACTICES 138

APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS 141

v
APPENDIX D: FTAM DOCUMENT TYPES . 142

APPENDIX E: KNOWN ERRORS IN ISO AND CCITT DOCUMENTS ..... 167

ADDENDUM 1 ............. 169

Index ............. ......... 170

vi
List of Figures

Fig. 3.1 LSAP bit pattern 8

Fig. 6.1 Successful NC establishment 23

Fig. 6.2 NC release 25

Fig. 6.3 Generalized interworking for OSI CONS 26

Fig. 6.4 NSAP address format 29

Fig. 7.1 AK exchange on idle connection 34

Fig. 13.1.1 The layered structure of this implementation agreement ... 79

Fig. 13.2.1 This agreement applies to the interface between: 80

Fig. 13.3.1 Interconnection of private domains 81

Fig. 13.4.1 An ADMD may (b) or may not (a) serve as a relay. ..... 109

vii
List of Tables

Tbl. 6.1 Packets and fields of X.25/PLP used to support OSI CONS .... 14

Tbl. 6.2 CONS: X.25/PLP mapping for the network connection 17

Tbl. 6.3 CONS: X.25/PLP mapping for network connection release 18

Tbl. 6.4 CONS: X.25/PLP mapping for the data transfer service 19

Tbl. 6.5 CONS: X.25/PLP mapping for the reset service 20

Tbl. 10.1 FTAM primitive data types 51

Tbl. 10.2 FTAM negotiation rules 59

Tbl. 10.3 Interoperable configurations 61

Tbl. 10.4 Required minimal parameter support 67

Tbl. 10.5 Implementation class support requirements 73

Tbl. 10.6 Profile name relations - NBS/OSI to SPAG 73

Tbl. 13.3.1 Basic MT service elements 83

Tbl. 13.3.2 MT optional user facilities provided to the 84

Tbl. 13.3.3 MT optional user facilities provided to the UA 84

Tbl. 13.3.4 Basic IPM service elements 85

Tbl. 13.3.5 IPM optional facilities agreed for a contractual 85

Tbl. 13.3.6 IPM optional user facilities selectable on a 86

Tbl. 13.3.7 PI protocol elements 89

Tbl. 13.3.8 ORName protocol elements 93

Tbl. 13.3.9 P2 heading protocol elements 95

Tbl. 13.3.10 P2 BodyParts 99

Tbl. 13.3.11 Checkpoint window size of IP 105

Tbl. 13.3.12 RTS protocol elements 106

viii
1. GENEKAL INFORMATION

1.1 PURPOSE OF THIS DOCUMENT

This document records current agreements on implementation details of OSI

protocols among the organizations participating in the NBS/OSI Workshop Series

for Implementors of OSI Protocols. These decisions are documented to

facilitate organizations in their understanding of the status of agreements.

This is a standing document that is intended to be updated after each workshop

(about every 2-1/2 months).

1.2 PURPOSE OF THE WORKSHOP

In February, 1983 NBS organized the above named workshop 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.

1.3 PET ATIONSHIPS OF WORKSHOPS TO EVENTS AND ACTIVITIES

The workshop is held for those organizations expressing an interest in

implementing OSI protocols. However, there is no corporate commitment to

implementations associated with workshop participation. Other events stem

from the workshop to which commitments are attached. Sixteen organizations

did make formal commitments to implement and demonstrate some of the protocols

at the 1984 National Computer Conference. Commitments were made by General

Motors, Boeing Computer Services, and 21 vendors to demonstrate, at AUTOFACT

1985, a set of OSI protocols known as the Manufacturing Automation Protocol

or MAP specification. This event was an outgrowth of the workshop in that the

implementation decisions reached in the workshops were used for the AUTOFACT

demonstration. However, the AUTOFACT demonstration was planned and carried

out by GM, BCS, and suppliers they selected. This event had no further

affiliation with the workshop.

A different activity, initiated by NBS, is the OSINET, which is to be a long

standing, globally distributed network that is put in place for purposes such

as test methods development and testing of prototype implementations.

Presently, 25 organizations have committed to participate. As with the

AUTOFACT demonstration, protocols used on OSINET are those agreed to in the

workshop. Also, as with the AUTOFACT demonstration, the OSINET has no other

affiliation with the workshop. Unlike the AUTOFACT demonstration, however,

OSINET participation is open to any organization committing to the OSINET

agreements

1
1.4 RELATIONSHIP OF THE WORKSHOP TO THE NBS LABORATORIES

As resources permit, NBS, with voluntary assistance from industry, develops

formal protocol specifications, reference implementations, tests and test

systems for the protocols agreed to in the workshops. This is work made

available to the industry volunteers and to others making valid commitments to

organized events and activities such as NCC, AUTOFACT, and OSINET. As soon

as this work can be adequately documented it is placed in the public domain

through submission to the National Technical Information Service. Any

organization may then obtain the work at nominal charge.

The NBS laboratories bear no other relationship to the workshop.

1.5 STRUCTURE AND OPERATION OF THE WORKSHOP

1.5.1 Plenary

The main body of the workshop is a plenary assembly. Any organization may

participate. Representation is international. NBS prefers for the business

of workshops to be conducted informally, since there are no corresponding

formal commitments within the workshop by participants to implement the

decisions reached. The guidelines we follow are: 1) one vote per company or independent division, 2) only companies that regularly attend should vote, 3)

only companies that plan to sell or buy a protocol should vote on its

implementation decisions, 4) only companies knowledgeable of the issues should

vote, and 5) no proxy votes are admissible.

1.5.2 Special Interest Groups

Within the workshop there are Special Interest Groups (SIGs). The SIGs receive

their instructions for their technical program of work from the plenary. The

SIGs meet independently, usually during the workshop. As technical work is

completed by a SIG, it is presented to the plenary for disposition. Companies

participating in a SIG are expected to participate in the plenary. Voting

rules for SIGS are the same as voting rules for the plenary.

Special Interest Groups sometimes correspond with organizations performing

related work, such as ANSI committees. Such correspondence should be sent

through the plenary to the parent committee, such as ANSC X3T5 or ANSC X3S3

When SIG meetings take place between workshops, the correspondence from these

meetings should be addressed directly to the parent committee and copied to

the workshop plenary.

Following are procedures for cooperative work among Special Interest Groups.

o Any SIG (SIG 1) or individual having issues to discuss with or requirements of another SIG (SIG 2) should bring the matter to

the attention of the chairperson of that SIG (SIG 2).

2
o The SIG 2 chairperson should bring the matter before SIG 2 for

action.

o SIG 2 should respond to the concerns or needs of SIG 1 or the

individual in a timely manner.

o If the matter cannot be satisfactorily resolved or if the

request is outside the charter assigned to SIG 1, then it should

be brought before the plenary.

o SIGs are expected to complete work in a timely manner and bring

the results before the plenary for disposition. However, the

plenary may elect to act on any issue within the scope of the

workshop at any time.

Following are the charters of the the nine Special Interest Groups.

FTAMSIG

Develop phase 2 product-level specifications.

Future new work items will be defined in a Phase 3 specification. It will

contain only extensions of Phase 2 FTAM. It is a goal that Phase 3 will be

backward compatible with Phase 2 FTAM. The set of future work items listed

below may be changed by the plenary if the work is more appropriate for other

SIGs.

High priority work items:

o Clean up section 10 of this document

o Specify Reliable File Service

o Specify Recovery and Restart Data Transfer functional units

in the user correctable file service

o Specify concurrency control parameter.

Low priority work items:

o Add new document types/constraint sets

o Define subset of authorization requirements

o Specify Presentation Context Management functional unit.

X. 400 SIG

Develop product- level specifications for Message Handling Systems using the

CCITT X.400 Recommendations.

Develop abstract tests for X.400, as requested by the ad hoc rapporteur for

3
this study question in CCITT. This work is to be submitted by the plenary

(after its approval) to The U.S. Department of State as a proposed U.S.

contribution to CCITT Study Group VII.

Lower Layer SIG

The Lower Layer SIG will study OSI layers 1-4 and produce recommendations for

implementations to support the projects undertaken by the workshop and the

work of the other SIGs. Both connectionless and connection-oriented modes of

operation will be studied. The SIG will accept direction from the plenary for

work undertaken and the priority which it is assigned.

The objectives of the Lower Layer SIG are:

o Study OSI layers 1-4 as directed by the plenary,

o Produce and maintain recommendations for implementation of these

layers

,

o Where necessary, provide input to the relevant standards bodies

concerning layers 1-4, in the proper manner, and

o Begin work on the implementation specification of the ISO Network

Layer Routing Exchange Protocol prior to the ISO draft achieving DIS

status

Performance SIG

The plenary will provide the following inputs to the OSI Performance SIG:

o the set of applications for which the performance of OSI

protocols is of particular concern,

o the requirements for each application including:

- performance targets

- network topology

- background network loads

- application traffic characteristics, and

o this document, "Implementation Agreements Among

Implementors of OSI Protocols".

The objectives of the OSI Performance SIG are to:

o determine whether the OSI protocols are able to meet

these performance requirements,

o report these determinations to the plenary, and

4
o where appropriate, provide input to the voluntary standards

bodies concerning changes to existing standards and the

requirements for new ones, in the appropriate form.

OSI Security Architecture SIG

GOAL: To develop an overall OSI Security Architecture which is consistent

with the OSI and which economically satisfies the primary security

needs of both the commercial and Government sectors.

APPROACH: To define a security architecture encompassing the security addenda

presently being specified at certain OSI layers, the required

cryptographic algorithms and related key management functions, and

the security management functions which must be performed between

the layers and the peer entitities defined in the OSI architecture.

Directory Services SIG

Produce functional implementation agreements based on ISO/CCITT specifications

for Directory Services in accordance with the objectives and goals of the

plenary.

o Provide a subset for NBS publication which is functional and forward

compatible to further work by this Special Interest Group.

o Define stable core functionality which, can be implemented in the near

term.

Virtual Terminal SIG

This Special Interest Group's charter is based upon the implementation of

Draft International Standards 9040 and 9041 and their respective addenda, in

providing Basic Virtual Terminal Service.

This group will develop agreements for the implementation and testing of the

following terminal types.

o X. 29 PAD

o TELNET

o Basic Scrolling

o Basic Paging

o Basic Forms

5
Upper Layers SIG

Develop product- level specifications for the implementation of Session service

and protocol. Presentation service and protocol, and ACSE service and

protocol. These specifications will be developed to support the application

layer services FTAM, X.400, VT, and Directory Services. In addition, the SIG

is responsible for requirements in common between Multiple Application

services, for example, registration of Application Contexts and Abstract

Syntaxes

Office Document Architecture and Office Document Interchange Format SIG

Develop product-level specifications for the architecture and interchange of

office documents processed by computers. The standard governing the ODA/ODIF

SIG's work is ISO 8613 - Office Document Architecture (ODA) and Interchange

Format (ODIF).

1.6 POINTS OF CONTACT

OSI Workshop - General

OSI Workshop - Registration

FTAM SIG

X.400 SIG

Lower Layers SIG

Performance SIG

Security SIG

DS SIG

VT SIG

Upper Layers SIG

ODA/ODIF SIG

MAP

TOP

Government OSI Spec.

OSINET

Steering Committee

Technical Committee

SME (MAP/TOP Sponsorship)

John Heafner, NBS, 301/975-3618

Mary Lou Fahey, NBS, 301/975-3600

Joan Wyrwa, NBS, 301/975-3643

Rick Peterson, GM, 313/947-0586

John Stidd, Xerox, 408/737-4338

Kevin Miles, DEC, +44-734-868711

Mary Jane Strohl, CDS, 617/460-0808

Denny Branstad, NBS, 301/975-2913

J. J. Cinecoe, WANG, 617/967-5514

TBD

Mike Ellis, HP, 916/786-8000x4292

TBD

Gary Workman, GM, 313/947-0599

Laurie Bride, BCS, 206/763-5719

John Heafner, NBS, 301/975-3618

TBD

Ed Strum, IBM, 415/855-7392

Mark Shaw, 313/271-1500

Paul Borawski, 313/271-1500

6
2. THE PROTOCOLS

The selected protocols for which implementation agreements have been made and

are being developed are:

o IEEE 802.2 Logical Link Control

o IEEE 802.3 CSMA/CD Access Method

o IEEE 802.4 Token Bus Access Method

o CCITT Recommendation X.25

o Private Subnetworks

o Network Dependent Convergence Sublayer Protocol between X.25 and ISO

Connectionless IP

o X.25 Packet Layer Protocol to support the Connection Oriented Network

Service

o ISO Connectionless Internetwork Protocol

o ISO Transport Classes 4 and 0 and Connectionless Protocols

o ISO Session Protocol

o ISO File Transfer, Access and Management Protocol

o ISO Presentation Layer Protocol

o ISO CASE Protocol

o CCITT 400 Series Recommendations for Message Handling Facility

o CCITT and ISO Directory Services Protocol

Reference documents and sources for obtaining them are given under References.

7
3. LOCAL AREA NETWORKS

3 .

IEEE 802.2 LOGICAL LINK CONTROL

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

1.

Link Service Access Point (LSAP)

The IEEE 802 committee has assigned the code below to address systems using

ISO IS 8473 connectionless network protocols. Note that bit zero is

transmitted first.

The most significant bit is bit 7, thus this bit .pattern represents

hexadecimal FE.

0 1 2 3 4 5 6 7

0 1 1 1 1 1 1 1

Fig. 3.1 LSAP bit pattern

2. Type and Class

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

3. Exchange Identification and Test

The Exchange Identification (XID) and Test (TEST) will not be sent. If one is

received it will be discarded.

3.2 IEEE 802.3 CSMA/CD ACCESS METHOD

The 48 bit addressing will be used with the 10 megabit/second baseband coaxial

cable specification.

3 . 3 IEEE 802.4 TOKEN BUS ACCESS METHOD

The following options are agreed to with respect to Draft F of token bus. An

asterisk means that the option has been approved. The absence of an asterisk

means that the option has not been approved.

1. Repeaters

Active Regenerative

2. Medium

Single Cable Coax * Dual Cable Coax

3 o Trunk Cable

RG-6 * RG-11 *

8
Semi-rigid X

Other 75 ohm cables *

4. Trunk Connection Unit

75 ohm tee connector

75 ohm nondirectional passive

impedence-matching tap

75 ohm directional passive impedencematching tap

*

5. Transmit Carrier Frequency

RF

Baseband

*

6. Modulation

Phase Continuous FSK

Phase Coherent FSK

AM/PSK *

7

Encoding

Manchester

Duobinary *

8. Data Rate

1 Mb

5 Mb * 10 Mb *

9. Addressing

2 octet

6 octet *

10. Connector at Station

50 ohm Male BNC Series

75 ohm Female F Series *

11. Priority (4 levels) * 12. Group Addressing *

13. Station Management

14. Broadband Channel Assignments

Forward

P

Q

R

S

T

U

Reverse

3 1 *

4« * 4M' *

5' *

6

' * FM1

9
4. WIDE AREA NETWORKS

4.1 CCITT RECOMMENDATION X.25

When providing CONS, it is agreed to use X.25 as the standard wide area network protocol. Elements of X.25 are explained in section 6.2.2.

5. PRIVATE SUBNETWORKS

5.1 PRIVATE SUBNETWORKS

The architectures agreed upon allow the use of private subnetworks in addition

to private X.25 subnetworks. No particular private subnetwork has been

discussed.

10
6. NETWORK LAYER

6.1 CONNECTIONLESS NETWORK SERVICE (CLNS)

6.1.1 Provisions of CLNS using CLNP (IS 8473)

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

o The "Protocol for providing the connection- less service," ISO IS

8473, will be used to provide the CLNS.

o The non-segmenting and the inactive subsets will not be

supported.

6.1.2 Agreements on Protocol Functions

o For purposes of demonstration the value to be used to bound the

maximum lifetime of the internetwork protocol data unit is three

times the network span. The span of the network is considered

to be the number of intermediate systems between source and

destination plus the destination end system.

o For purposes of testing, intermediate and end systems will log

the following conditions:

o Discarded protocol data units,

o Error protocol data units (recorded by system generating

the error PDU), and

o Detection of protocol data units containing unsupported

type 3 options.

6.1.3

Agreements on Optional Protocol Functions

o The security parameter will not be used.

o Intermediate systems should recognize and support both complete

and partial source routing.

Although end systems may implement source routing (of either

type), any requirement for end system source routing is deferred

for future study, since support for it may be related to layer

management protocols.

o Partial source routing will be supported by intermediate

systems. The destination should log the route, if possible.

o The ISO specification will be followed with respect to quality

of service.

11
o For purposes of testing, checksums will be turned on and used.

In operation this is a local decision.

6.1.4 Network Dependent Convergence Sublayer Function (CLNS Over X.25)

A network dependent convergence sublayer protocol operating between CCITT

Recommendation X.25 and the ISO Connectionless IP has been agreed to. It

shall adhere to the following.

o Follow ISO 8473 DAD1 (N3601) Working Paper for the SNDCF

framework.

o Only initiate one SVC for all outbound PDUs to any other given

intermediate system or PDN end system. Note: this results in at

most two SVCs between any pair of systems.

o Open a connection upon demand.

o Disconnect SVCs by administrative request and a finite timeout

timer.

o Use the default throughput class.

o Do not use D-bit or Q-bit.

o Negotiate window size according to ISO IS 8208. A default of

window size two must be supported.

o Negotiate packet size according to ISO IS 8208. A default of

128 octets /packet must be supported.

o The SNDCF will "advertise" support for SNSDUs up to IK via the

X.25 M-bit facility.

o No statistics gathering is required beyond that which the CLNS

may gather for the X.25 packet layer or for SNDCF entities.

6.2 CONNECTION MODE NETWORK SERVICE (CONS)

There is interest among a limited set of participants in implementing the

connection mode network service. This section records the agreement of the

workshop on the provision of a connection mode network service.

6.2.1 Introduction

The X.25 Packet Level Protocol (PLP) is used to provide the OSI

Connection-mode Network Service (CONS). This proposal is independent of lower

and higher layer protocol considerations, which are also discussed briefly

herein.

When providing the CONS, the following shall apply:

12
o The definition of the CONS is as specified in ISO 8348, "Network

Service Definition";

o The mapping of the elements of the CONS to the elements of the

X.25/PLP is as specified in ISO 8878, "Use of X.25 to Provide

the OSI Connection-mode Network Service"; and

o The general procedures and formats of the X.25/PLP are as specified in ISO 8208, "X.25 Packet Level Protocol for Data

Terminal Equipment". Note that this standard provides for the

use of the X.25/PLP in environments in addition to an X.25

PSPDN, such as point-to-point topologies as well as LANs. (The

details of how to use the X.25/PLP in LANs are given in ISO

8881, "Information Processing Systems - Data Communications - Use Of The X.25 Packet Level Protocol in Local Area Networks.")

6.2.2. Provision of CONS Using X.25/PLP

The provision of the CONS using the X.25/PLP is as described in the second

bullet above. This section provides a brief description taken directly from

ISO 8878; for more detail, see ISO 8878.

Also note that the X. 25/PLP-1984 is capable of supporting the full CONS,

including quality-of-service (QOS) aspects. The X. 25/PLP-1984 shall be used

in LANS and in packet -switched networks allowing the use of the elements of

the X. 25/PLP-1984 needed to support the CONS. In other

packet-switched-network environments, a Subnetwork Dependent Convergence

Protocol (SNDCP) shall be used in conjunction with the X. 25/PLP-1980 (see

section 6.2.5).

6 . 2 . 2 .Overview

6.2.2. 1.1 Elements of the X.25/PLP for Support of the CONS

The table below lists the packets and associated fields used when supporting

the OSI CONS.

13
Tbl. 6.1 Packets and fields of X.25/PLP used to support OSI CONS

PACKET TYPES 1 FIELDS 2

CALL REQUEST

INCOMING CALL

CALL ACCEPTED

CALL CONNECTED

Facility Field, Call and

Called User Data Field

CLEAR REQUEST

CLEAR INDICATION

Clearing Cause Code Field,

Diagnostic Code Field,

Facility Field, Clear User

Data Field

DATA M-Bit, User Data Field

RESET REQUEST

RESET INDICATION

Resetting Cause Code

Field, Diagnostic Code

Field

RESTART INDICATION Restarting Cause Code

Field,

Diagnostic Code Field

Notes

1. The packets shown in the table are used in support of the

primitives of the OSI CONS. Other packets not shown in the

table (i.e., CLEAR CONFIRMATION, RESET CONFIRMATION, and RESTART

CONFIRMATION packets) are essential to the use of the packets

shown. Yet other packets (i.e., RESTART REQUEST, DIAGNOSTIC,

REGISTRATION REQUEST, and REGISTRATION CONFIRMATION packets)

have no relationship to the provision of the OSI CONS.

In line with these agreements, the INTERRRUPT, INTERRUPT

CONFIRMATION, RECEIVE READY, RECEIVE NOT READY, and REJECT

packets are not needed to support the OSI CONS because the

corresponding aspects of the OSI CONS are not to be used (i.e.,

the Expedited Data Transfer Service and the Receipt Confirmation

Service are not used). However, the RECEIVE READY and RECEIVE

NOT READY packets are needed for the proper operation of the

X.25/PLP.

14
2. The information in the fields shown in the table has a direct

relationship to the parameters associated with the primitives of

the OSI CONS. Other fields not shown in the table (e.g., the

Logical Channel Identifier, the Packet Type Identifier, the

Address Length Fields and the Facility Length Field) are essential to the use of the appropriate packets.

In addition, it is also necessary for the following optional user facilities

and CCITT-Specif ied DTE Facilities to be used and/or agreed to:

1. optional user facilities

o Fast Select (facility used)

o Fast Select Acceptance (facility agreed to, if operating in a packet- switched network environment)

o Throughput Class Negotiation (facility agreed to and

used), and

o Transit Delay Selection And Indication (facility used);

Note: When operating in a DTE-to-DTE environment without an intervening

packet-switched network, the use of the Fast Select Facility must also

be agreed to by the two DTEs. In addition, the Fast Select Acceptance

Facility does not apply.

2. CCITT-Specif ied DTE facilities

o Called Address Extension (facility used),

o Calling Address Extension (facility used),

o End-to-End Transit Delay Negotiation (facility used),

o Expedited Data Negotiation (facility used), and

o Minimum Throughput Class Negotiation (facility used).

Elements of the X.25/PLP not needed in support of the CONS are:

o Q-bit

o Permanent Virtual Circuits (PVCs),

o Diagnostic packets, and

o optional user facilities other than those listed above.

Elements of the X.25/PLP not used within the scope of these agreements are:

o D-bit and

o INTERRRUPT packets

6.2.2. 1.2 General Operation of X. 25/PLP-1984 for Supporting OSI CONS

The X.25/PLP can be used to provide the OSI CONS in an end system connected to

a public or private X.25 packet-switched network environment. It can also be

used in environments where the end-system is connected to a local area network

or where end systems are connected by a dedicated path or by a circuit-switched connection.

15
The NS provider (more particularly, the Network Layer (NL) entity in an end-system) must provide a translation between

1. the primitives and parameters of the OSI CONS; and

2. the packets and associated fields of the X.25/PLP.

Request and response primitives are translated into packets to be transmitted

across the DTE/DCE interface by the NL entity. Received packets, where

appropriate, are translated by the NL entity into indication and confirm

primitives. These translations are shown in sections 6. 2. 2.

through 6.2.2. 7.

Note: The Network Service Definition specifies valid sequences of primitives

at a NC endpoint and valid parameter responses at the called NC

endpoint to Receipt Confirmation negotiation. Expedited Data

negotiation, and QOS parameter negotiation. The necessity for the NL

entity to police compliance and the NL entity actions to be taken on non-compliance are a local matter and not subject to standardization.

There is also a relationship between some local mechanism used to identify a particular Network Connection (NC) and a Logical Channel (LC) number used to

identify a particular virtual circuit. This relationship is a local matter.

6. 2. 2.

Network Connection Establishment Phase

Table 6.2 shows the relationships between the primitives/parameters used

during the Network Connection Establishment Phase and the packets/ fields

associated with the Call Setup Procedures.

16
Tbl. 6.2 CONS: X.25/PLP mapping for the network connection

establishment phase

CONS X. 25/PLP-1984

PRIMITIVES

PACKETS:

N- CONNECT request CALL REQUEST

N-CONNECT indication INCOMING CALL

N-CONNECT response CALL ACCEPTED

N-CONNECT confirm CALL CONNECTED

PARAMETERSFIELDS (INCLUDING FACILITIES):

Called Address Called Address Extension Facility

Calling Address Calling Address Extension

Facility

Responding Address Called Address Extension Facility

Receipt Confirmation See Note 1.

Selection

Expedited Data Selection See Note 1

QOS Parameter Set Throughput Class Negotiation

Facility^

Minimum Throughput Class

Negotiation Facility

Transit Delay Selection And

Indication Facility

End-to-End Transit Delay

Negotiation Facility

NS-User-Data Call and Called User Data Field

Fast Select Facility^

Notes to table 6.2:

1. Within the scope of these agreements, the Receipt Confirmation

Service and Expedited Data Service will not be used. Therefore,

the Network Service provider will indicate the unavailability of

these services even if requested by the Network Service user. To

do this does not require an explicit protocol mechanism.

17
2. For proper operation, this optional user facility must also be

agreed to for use on the interface.

3. For proper operation, the Fast Select Acceptance Facility must

also be agreed to on the interface when accessing a packet-switched network.

6. 2. 2.

Network Connection Release Phase

Table 6.3 shows the relationships between the primitives/parameters used

during the Network Connection Release Phase and the packets/f ields associated

with the Call Clearing Procedures.

Tbl. 6.3 CONS: X.25/PLP mapping for network connection release

phase

CONS X. 25/PLP-1984

PRIMITIVES: PACKETS

9 N-DISCONNECT request

N-DISCONNECT indication

CLEAR REQUEST

CLEAR INDICATION,

RESTART INDICATION1

, CLEAR REQUEST2

PARAMETERS

FIELDS (INCLUDING FACILITIES):

Originator and Reason Cause Code and Diagnostic Code

Fields 2

NS -User-Data Clear User Data

Responding Address Called Address Extension Facility

Notes to Table 6.3:

1. Receipt of a RESTART INDICATION packet should be treated as receipt of a CLEAR INDICATION packet for every logical channel

and then mapped to an N-DISCONNECT indication primitive for

every active NC associated with the Packet Level Protocol being

restarted. The Restarting Cause Code and Diagnostic Code Fields are then treated in the same manner as the Clearing Cause Code

and Diagnostic Code Fields.

2. Used only when the NL entity in the end system originates an N-DISCONNECT indication primitive.

18
3. The combination of Cause Code and Diagnostic Fields is mapped

to/ from the combination of Originator and Reason parameters.

Where the IS 8208 diagnostic codes are not provided, all

Cause/Diagnostic code combinations can be mapped to the

Orignator/Reason parameter values of "Undefined".

6

.2.2.4

Data Transfer Phase -- Data Transfer Service

Table 6.4 shows the relationships between the primitives/parameters used for

the Data Transfer Service and the packets/f ields associated with the Data

Transfer Procedures.

Tbl. 6,4 CONS: X.25/PLP mapping for the data transfer service

CONS X. 25/PLP-1984

PRIMITIVES

PACKETS

N-DATA request DATA

N-DATA indication DATA

PARAMETERSFIELDS:

NS-User-Data User Data, M-bit

Confirmation Request See Note 1

Note to table 6.4:

1. Since the Receipt Confirmation Service is not to be provided, a Confirmation Request is not valid.

6. 2. 2.

Data Transfer Phase -- Receipt Confirmation Service

This service is not provided by these agreements.

6. 2. 2.

Data Transfer Phase -- Expedited Data Transfer Service

This service is not provided by these agreements.

6. 2. 2.

Data Transfer Phase -- Reset Service

Table 6.5 shows the relationships between the primitives/parameters used for

the Reset Service and the packets/f ields associated with the Reset Procedures.

19
Tbl. 6.5 CONS: X.25/PLP mapping for the reset service

CONS X. 25/PLP-1984

PRIMITIVESPACKETS

N-RESET request

N-RESET indication

N-RESET response

N-RESET confirm

RESET REQUEST

RESET INDICATION, RESET REQUEST 1 none

none

PARMETERS: FIELDS

Originator and Reason Cause Code and Diagnostic Code

Fields^

Notes to table 6.5:

1. Used only when the NL entity in the end system originates an N-RESET indication primitive.

2. The combination of Cause Code and Diagnostic Code Fields is

mapped to/from the combination of Originator and Reason

parameters. Where the IS 8208 diagnostic codes are not

provided, all Cause/Diagnostic code combinations can be mapped

to the Originator/Reason parameter values of "Undefined".

6.2.3 Requirements for Underlying Layer

As cited in IS 8208, the X.25/PLP requires the following of the

underlying Layer 2:

o low duplication rate,

o low missequencing rate,

o low undetected bit-error rate, and

o low loss rate.

When operating in a packet-switched (X.25) network environment, the underlying

LAPB protocol ensures these requirements. When operating in a LAN

environment, LLC 1 can be used. Considerations for LLC 1 are given in DP 8881.

6.2.4 Consideration of OSI Transport Layer Protocol Class

It may be useful to explore the desirability of an alternative to the

Transport Class 4 protocol for use over the CONS. See section 7, Transport.

6.2.5 Subnetwork Dependent Convergence Protocol

In cases where an end system is required not to use the elements of the

X. 25/PLP-1984 needed to support the OSI CONS (e.g., when operating in .i packet-switched network environment that will treat as an error the use of anv

20
of the CCITT-specif ied DTE facilities), then it shall use a Subnetwork

Dependent Convergence Protocol (SNDCP) to provide the necessary elements of

the OSI CONS to the Network Service user. These elements involve certain

aspects of the Network Connection Establishment Phase and the Network

Connection Release Phase.

The SNDCP to be used is referred to as the Alternative Procedures for Network

Connection Establishment and Release in DP8878. The procedures for the data

transfer phase of the SNDCP, as specified in DP8878, are essentially the same

as those in sections 6. 2. 2.through 6. 2. 2.

of this document.

6.2.5.Network Connection Establishment Phase

The procedures for this phase are as specified in DP8878, Annex A, Section

6.1(b) (the Alternative Network Connection Establishment Procedure). These

procedures use:

o A CALL REQUEST packet containing (in addition to the packet

header, the Address Fields, and other facilities):

the Throughput Class Negotiation Facility if available;

otherwise, the throughput of the virtual circuit must be known a priori (by way of the Default Throughput Classes Assignment

Facility, for example), and

- a Call User Data Field containing three octets: a one-octet

Protocol ID identifying the X.25/PLP-1980 SNDCP encoded X' 84'

(as assigned by ISO) and a two-octet Continuation Parameter

encoded X'2D00' to indicate the first M-bit sequence (MBS) of

DATA packets will contain additional Network Connection (NC)

Establishment parameters;

o A CALL ACCEPTED packet with necessary information for proper

X.25 subnetwork interface operation but without any NC

Establishment parameters;

o An MBS of one or more DATA packets with the Q-bit set to 1,

sent by the originator of the NC Establishment attempt,

containing all necessary NC Establishment parameters encoded

according to DP8878, Annex A, Section 8.7(c) (This MBS is known

as an N-CR message.); and

o An MBS of one or more DATA packets with the Q-bit set to 1,

sent by the recipient of the NC Establishment attempt (assuming

NC acceptance), containing all necessary NC Establishment

parameters encoded according to DP8878, Annex A, Section 8.7(d)

(This MBS is known as an N-CC message.); see section 6. 2. 5.

for

NC refusal.

The transit delay of each subnetwork must be estimated.

Similar to the use of the X. 25/PLP-1984m the following items are to be noted:

21
o The Network Service provider will indicate the unavailability,

during NC Establishment, of the Receipt Confirmation Service and

the Expedited Data Service; therefore, no protocol mechanisms

are necessary for the negotiation of these services; and

o NSAP Addresses are carried entirely in the Address Extension

Fields of the N-CR and N-CC messages.

A Connect Response Timer may be used as specified in DP8878, Annex A, Section

6.8(a).

22
Figure 6.1 shows the NC Establishment Phase.

N- CONNECT

REQUEST

N- CONNECT

CONFIRM

CALL REQUEST/

INCOMING CALL

CALL ACCEPTED/

CALL CONNECTED/

> 1 DATA WITH N-CR

> 1 DATA WITH N-CC

N- CONNECT

INDICATION

N- CONNECT

RESPONSE

Fig. 6.1 Successful NC establishment

6. 2.5.

Network Connection Release Phase

The procedures for this phase are as specified in DP8878, Annex A, Section 6.2

(b) (the Alternative Network Connection Release Procedure). These procedures

are also used to refuse an NC establishment attempt. These procedures use:

o An MBS of one or more DATA packets with the Q-bit set to 1,

sent by the originator of the NC release, containing all

necessary NC Release parameters encoded according to DP8878,

Annex A, Section 8.8(a) (This MBS is known as an N-DR message

and serves as an "invitation to clear," that is, initiate X.25

clearing procedures to the recipient.); and

o The X.25 CLEAR REQUEST/ INDICATION packet as indicated in

DP8878, Annex A, Section 8.8(b).

The above procedures apply to NC release when initiated by the Network Service

user. When initiated by the NS provider, the N-DR message will not be sent

but the Originator and Reason parameter values shall both be "undefined."

A Disconnect Response Timer may be used per DP8878, Annex A, Section 6.8(b).

Figure 6.2 shows the NC Release Phase.

6. 2. 5.

Data Transfer Phase - Data Transfer Service

The Data Transfer Service for the X. 25/PLP-1980 SNDCP is the same as for the

X. 25/PLP-1984 procedures, see section 6. 2. 2.of this document.

23
6. 2. 5. 4 Data Transfer Phase - Receipt Confirmation Service

As for the X. 25/PLP-1984 procedures, this service is not provided by these

agreements

6 .2. 5.Data Transfer Phase - Expedited Data Transfer Service

As for the X. 25/PLP-1984 procedures, this service is not provided by these

agreements

6 .2 <,5.Data Transfer Phase - Reset Service

The Reset Service for the X. 25/PLP-1980 SNDCP is the same as for the

X. 25/PLP-1984 procedures, see section 6. 2. 2.of this document.

24
N-CONNECT

REQUEST

N-DISCONNECT

INDICATION

CALL REQUEST/

INCOMING CALL

> 1 CALL ACCEPTED/

CALL CONNECTED

> DATA WITH N-CR

> 1 DATA WITH N-DR

CLEAR REQUEST/

CLEAR INDICATION

N-CONNECT

INDICATION

N-DISCONNECT

REQUEST

(a) NC ESTABLISHMENT REFUSAL

NORMAL DATA

>1 DATA WITH N-DR N-DISCONNECT

REQUEST

N-DISCONNECT

INDICATION

CLEAR REQUEST/

CLEAR INDICATION

(b) NC RELEASE AFTER DATA TRANSFER

Fig. 6.2 NC release

6.2.6 Interworking

Interworking between subnetworks needs to be specified. The principles of the

Internal Organization of the Network Layer, DP 8648, need to be addressed. A

generalization of these principles for the OSI CONS case is shown in Figure

6.3.

25
' - Routing and Relaying -

X. 25 X. 25

PLP* PLP*

Layer 2 Layer 2

Protocol Protocol

Layer 1 Layer 1 Protocol Protocol

*This can be either X. 25/PLP-1984 or X. 25/PLP-1980 with an SNDCP, see section

6.2.5.

Fig. 6.3 Generalized interworking for OSI CONS

The detailed behavior and properties of the Interworking Unit are to be

specified in future extensions of this document. DP 8881 and DP 8878 discuss

various aspects of interworking.

6.3 ADDRESSING AND ROUTING CRITERIA

The following have been agreed to.

o Do not go beyond ISO routing standardization efforts.

o Keep the end system as simple as possible. Put the needed

complexity into the intermediate systems. Minimize memory

overhead and enhance performance in the end systems

o Addressing and routing decisions should include the NBS OSINET

that permits inclusion of private subnetworks and end systems on PDNs

o Permit multiple subnetwork (alternate paths) in a single

intermediate system.

o Allow expandability for additional functionality beyond that

required for a specific demonstration.

o Support a certain minimal topology. Accommodate multiple LANs,

WANs, and private subnetworks.

26
o Facilitate efficient implementation of intermediate systems.

Minimize memory overhead and enhance performance of intermediate

systems

o The OSINET will accommodate end systems attached directly to

PDNs as one requirement.

6.4 GENERAL ADDRESSING AND ROUTING PRINCIPLES

The following have been agreed to.

1. Support DAD2. This supports criterion no. 1.

2. Routing Management

Static Routing:

All end systems and intermediate systems will provide a local

mechanism to manipulate (and optionally create) the local

routing table. Consistency checking, configuration, and

updating of a local table with all other tables will be

performed by human operators. The lack of flexibility induced

by static procedures can be minimized with the use of the

following aids:

o alternate static routes

o route update utility

o FTAM route table distribution

o table format via X.409 (ASN-1) encoding.

Dynamic Routing:

Endsystern- Intermediate System - A standard that provides the

functionality of dynamic routing must be provided. The protocol

(see references), Item ISO 18, "Network Layer Management

Protocol...", provides for this functionality between end and

intermediate systems. This standard is expected to be endorsed

(and appropriate implementor agreements drafted) to provide this

function at a time when it reaches the draft proposal status.

Intermediate system- Intermediate System

To be determined.

27
3. Routing Principles

The algorithm and data structures used for routing are not

specified by this document. Implementors are free to perform

these functions in the manner which is most appropriate for

their system environment. However, all implementations must

have the following characteristics:

o end- systems

End-systems must recognize a destination address on a directly

connected subnet and send the NPDU to the destination system.

When an NPDU is destined to a system that is not on a directly

connected subnet, the NPDU must be sent to an intermediate

system for further routing. The end system may, but is not

required to, choose the intermediate system used on the basis of

the destination subnet.

o intermediate systems

For static routing, intermediate systems must recognize all

assigned subnetwork addresses and route NPDU's in the following

way: If an NPDU is destined to an end system which is connected

to the same subnet as the intermediate system, the NPDU is sent

directly to the end system. If an NPDU is destined to an end

system which is not connected to the same subnet as the

intermediate system, the NPDU is sent to an appropriate

intermediate system for further routing. If an NPDU is destined

to an end system on an unknown subnet, the NPDU is discarded.

If the error flag is set, an error NPDU is sent to the source address specified in the errant NPDU.

4. There is a single NSAP selector for each NSAP within an end

system. For each end system NSAP, one and only one NSAP address

will be used to identify the NSAP. This conforms to the

requirements of DAD2 and supports criterion no. 1 to comply with

current ISO standards.

5. Hierarchical NSAP addressing should be used to minimize the size

of routing tables. This conforms to criterion no. 9.

6. The NSAP address used at the network service interface is based

on one and only one subnetwork point of attachment (SNPA). This

makes the hierarchial addressing more specific and implies that

subnetwork specific addressing information is embedded in the

NSAP address.

28
7. The encoded network protocol address information (NPAI) conveyed

in the IPDU representing an NSAP address contains an encoded

subnetwork address corresponding to the selected SNPA. This

makes hierarchical addressing more specific as applied to

addressing formats. The embedding of the subnetwork address

facilitates routing and simplifies routing tables.

8. The workshop participants require control over the DSP encoding

of the NSAP address.

9. NBS has obtained an IDI with value 4 from ISO for OSINET so that

the AFI encoding "47" may be used.

10. Optionally, the NSAP addressing format should be able to support

multiple network layer user entities, e.g., transport entities,

within one end system.

11. All of the above principles lead to the address format agreed

upon and shown below.

While one address format is explicitly specified in these

agreements (Fig. 6.4), this address format is not meant to

preclude the support for other ISO standardized NSAP address

formats.

47 ISO NBS PORTION OF DSP DEFINED

IDI ASSIGNED ASSIGNED BY INDIVIDUAL

ORGANIZATIONAL ORGANIZATION ADDRESSING

I.D. AUTHORITIES 12 2 <11

Fig. 6.4 NSAP address format

12. If used in the DSP, an NSAP Selector field is not used for

routing purposes nor for locating the end system. It only

locates the network layer user entity within the end system

attached through the addressed NSAP.

13. In order to fulfill the criteria in section 6.3, item 3, a standard that provides the functionality of dynamic routing must

be provided. The protocol referenced under ISO, item // 18

"Network Layer Management Protocol ..." provides for this

functionality between end and intermediate systems. This

standard is expected to be endorsed to provide this function at

a time when it reaches draft proposal status.

29
7. TRANSPORT

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. Two connection oriented transport classes have been

identified for implementation (class 0 and class 4). In addition, there is

interest among a limited set of participants in implementing a connectionless

transport protocol. Transport class 4 (over CLNP) has been endorsed for

general communication between private systems. Transport class 0 (over X.25)

is used for communication with public (i.e., PT&T and RPOA) MHS systems

operating in accordance with the CCITT X.400 series Recommendations.

Communicating entities between private MHS systems over an X.25 network can,

by negotiation or bilateral agreement, agree to use transport class 0. The

connectionless transport protocol can be used with transaction-type

implementations

7.1

TRANSPORT CLASS 4

7.1.1 Transport Class

The following agreement has been reached with respect to this protocol.

Class 4 will be used with the required implementation of the 31 bit sequence

space and 16 bit window size. The full protocol will be used including

expedited data and negotiation at connection establishment.

7.1.2 Protocol Interpretation

According to the ISO transport specification, a disconnect request is issued

in response to a connect request when the maximum number of transport

connections is reached or exceeded.

7.1.3 Rules for Negotiation

o In general, the ISO rules for negotiation will be used,

specifics follow.

o All implementations will send the 16/31 window size/sequence

space in the CR TPDU. Implementations must all provide the

16/31 ISO option. Implementations must be able to accept the

4/7 in CR TPDU.

30
o The ISO TPDU size is 128 to 8K octets, always negotiated

downward. The ISO rules are to be followed, allowing any valid

size in the CR TPDU. TPDU size negotiation is a local

implementation issue. Each vendor will decide how it is

implemented in their end system.

o The security parameter is optional and user defined in the ISO

specification. Implementations should not send the security

parameter in the CR TPDU; if received it should be ignored.

o Both transports must agree to not use checksum, according to the

ISO specifications. Requesting its use is an implementation

choice. All implementations must be able to operate with

checksum if requested.

o Use of acknowledgement time parameter is optional in ISO 8073.

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 acknowledgement time

parameter. The value transmitted should be expressed in units

of milliseconds and rounded up to the nearest whole millisecond.

o Throughput, priority, and transit delay are optional in the ISO

specification. Do not send in the CR TPDU; ignore in the CC

TPDU.

o User data in the CR TPDU and the CC TPDU are optional. No

implementation should send; all implementations must be prepared

to receive.

7.1.4 Retransmiss ion 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. An example

technique for maintaining the estimate and calculating the retransmission

timer is described below. Further information on similar techniques may be

found in the literature [Edge 84, Jain 85, Mill 83].

31
The value of the retransmission timer may be calculated according to the

following formula:

t < kE + w

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

transport connection, w 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 acknowledgement. Samples are taken by recording

the time of day when a TPDU requiring acknowledgement is transmitted and

calculating the difference between this and the time of day when the

corresponding acknowledgement is received. New samples are incorporated with

the existing average according to the following formula.

E < aE + (1 - o )S

In this formula, S is the new sample and alpha is a parameter which can be set

to some value between 0 and 1. The value chosen for alpha determines the

relative weighting placed upon the current estimate and the new sample. A

large value of alpha 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 a quick response to

variations. (Note that setting alpha to 1 will effectively disable the

algorithm and result in a constant value for E, being that of the initial

seed.

)

If alpha is set to l-2~n for some value of n, the update can be reduced to a subtract and shift as shown below.

E < E +

2“ n (S - E)

When sampling, if an AK TPDU is received which acknowledges multiple DT TPDUs,

only a single sample should be taken being the round-trip delay experienced bv

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.

32
7.1.5 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.

o In accordance with ISO 8073, clause 12. 2. 3. 9. a, all

implementations must respond to the receipt of a duplicate AK

TPDU by transmitting an AK TPDU containing the ' flow control

confirmation' parameter.

Implementations must

expiration of the

12.2.3.8.1). Receipt

__ always transmit

local window timer

of this TPDU

duplicate AK TPDUs on (see ISO 8073, clause

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 7.1.

It is a local matter for an implementation to set the intervals

of its timers to appropriate relative values. Specifically:

o The window timer must be greater than the round-trip

delay. See section 7.1.4.

o 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.

33
A duplicate AK TPDU (See Figure 7.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.

W

reset

reset

expire

expire

expire

Fig. 7.1 AK exchange on idle connection

7.2 TRANSPORT CLASS 0

7.2.1 Transport Class

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, but it is agreed that

transport class 4 and CLNP over all types of lower layer networks allows a larger range of interoperation and is recommended.

7.2.2 Protocol Interpretation

Transport class 0 is a relatively simple protocol providing little opportunity

for conflicting interpretations. A few relevant agreements follow.

o The Disconnect Request (DR) TPDU shall be limited to the first seven octets - "LI" plus "fixed part".

34
o 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.

7.2.3 Rules for Negotiation

The ISO rules for negotiations will be used.

7 . 3 CONNECTIONLESS TRANPORT

Document ISO IS 8072/DAD1 is the Transport Service Definition covering

Connectionless-mode Transmission. Document ISO DIS 8602 is the Protocol for

providing the Connectionless -mode Transport service.

35
8. SESSION

Session services are defined to meet the needs of many applications. The

Session service is defined in ISO 8326 (CCITT X.215) and the session protocol

is defined in ISO 8327 (CCITT X.225). The general agreements about the use of

session are documented below in section 8.1, followed by agreements that are related to specific applications.

8 . 1 GENERAL

The services of the Session kernel functional unit are used as specified in

the standard.

Session Connection

Data Transfer

Orderly Release

Provider Abort

User Abort

Basic concatenation is required by the session protocol standard. Extended

concatenation is not required and can be refused using the normal negotation

mechanisms provided by the session protocol.

Session segmenting is not required and can be refused using the normal

negotiation mechanisms of the session protocol.

Reuse of a transport connection is not required and can be refused using the

normal negotiation mechanisms of the session protocol.

The use of transport expedited is as stated in the session protocol

specification. That is, if transport expedited is available it must be used.

The maximum length of the reflect parameter values parameter in the

3-P-Exception-Report is 1024 octets.

The user data parameter on S-CONNECT SPDU will allow unlimited length user data as specified in the proposed Session draft addendum. This because the

combined P- CONNECT, A-ASSOCIATE, and F-INITIALIZE may exceed the existing 512

byte limit.

A mandatory functional unit is one that must be implemented by the service

provider.

An optional functional unit is one which the service provider may implement,

but irrespective of whether it is implememted or not, must recognize and

respond to correct requests for its use.

8.2 SESSION REQUIREMENTS FOR FTAM

The Phase 2 FTAM requires the following functional units in addition to those

specified in section 8.1.

36
Functional Units Session Services

Duplex -------

Note: Implementation of the Resynchronize functional unit is highly

recommended, since the F-CANCEL service may be ineffective when mapped to

S-DATA.

8.3 SESSION REQUIREMENTS FOR MESSAGE HANDLING

The MHS application requires the following functional units in addition to

those specified in section 8.1.

Functional Units Session Services

Exceptions User Exception Reporting

Provider Exception Reporting

Activity Management

Half -duplex

Activity Start

Activity Resume

Activity End

Activity Interrupt

Activity Discard

Please Tokens

Give Tokens

Give Control

Give Tokens

Please Tokens

Minor Synchronize Minor Synchronization Point

Give Tokens

Please Tokens

Note: Restricted use is made by the RTS of the session services

implied by functional units selected. Specifically,

o No use is made of S-TOKEN-GIVE, and

o S-PLEASE-TOKENS only asks for the data token.

The following additional points should be noted.

o In S-CONNECT, the SynchronizationPointSerial

Number should not be present.

o Format of the SessionConnectionID is

described in Version 3 of the X. 400-Series

Implementor's Guide.

37
9. SERVICE ACCESS POINTS AND SELECTORS

The following guidelines on the size of n-selectors apply to implementations

based on these agreements and therefore to incoming connection requests only.

Outgoing connection requests will support the full range of n-selector sizes.

9 . 1 UPPER LAYER AGREEMENTS

The following upper layer addressing agreements have been reached.

o The combination of NSAP address, TSAP selector, SSAP selector,

PSAP selector and PSAP address must be unique to identify an application entity.

o It is implicitly agreed that the procedure followed for the

assignment of NSAP addresses insures that they are globally

unique.

o The assignment of TSAP, SSAP, and PSAP selectors is a local end

system issue and the values are administered locally.

o SSAP selectors are encoded as a string of octets, the meaning of

which is known only to the local system. The length of the

string cannot exceed 16 octets.

o PSAP selectors are encoded as a string of octets, the meaning of

which is known only to the local system. The length of the

string cannot exceed 16 octets.

9.2 TRANSPORT CLASS 4 SERVICE ACCESS POINTS OR SELECTORS

The TSAP selector 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.

9.3 TRANSPORT CLASS 0 SERVICE ACCESS POINTS

For communieating with public MHS systems. Section 5 of X.A10 specifies the

use and format of TSAP identifiers.

38
10. ISO FILE TRANSFER & ACCESS MANAGEMENT PROTOCOL

10.0 INTRODUCTION

This section defines Implementors' Agreements based on the ISO File Transfer,

Access, and Management (FTAM), as defined in ISO DIS 8571. This Draft

International Standard has four parts. Part 1 of the DIS gives general

concepts. Part 2 defines the Virtual File Store (VFS), Part 3 defines the File

Service, and Part 4 the File Protocol.

FTAM depends on ISO definitions of ASN.l (ISO DIS 8824 and 8825), the

Presentation Service and Protocol (ISO DIS 8822 and 8823), and the Session

Service (ISO 8326/CCITT X.215) and Session Protocol (ISO 8327/CCITT X.225),

and Transport Class 4. FTAM Phase 2 also requires CASE Services (ISO DIS

8649/2 and Protocol (ISO DIS 8650/2). These services and protocols are defined architecturally in the OSI Reference Model (ISO 7498). This section

presumes that the reader is familiar with these standards, and is of a technical level appropriate to implementing or testing them. This section

provides detailed guidance for the implementor, and is not an FTAM tutorial.

The general agreements reached with respect to the ISO File Transfer, Access,

and Management Protocol (FTAM) are:

FTAM will be defined in at least two phases. The Phase 1 FTAM

implementation specification (section 10.1) is based on the

second ISO draft proposal, dated April 30, 1985^, and the ISO

draft proposals 8824 and 8825.

The Phase 2 FTAM specification (section 10.2) is based on the

Draft International Standard (DIS) and later will be based on the International Standard (IS). THERE IS NO BACKWARD

COMPATIBILITY WITH NBS FTAM PHASE 1.

Backward compatibility is impossible, since Phase 1 uses Session services

directly, while Phase 2 uses CASE 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.

Assuming that Phase 2 FTAM implementations will be based on the forthcoming

IS, and that this IS or the CASE IS provides the ability to pass "user

version" information, a mechanism exists for backward compatibility. 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 NBS FTAM Phases,

facilitating backward compatibility for future FTAM products.

1 Part 1 is dated April 20, 1985; Part 2 dated April 29, 1985; and Parts 3

and 4 dated April 30, 1985.

39
10.1

PHASE 1 FTAM IMPLEMENTATION SPECIFICATION

10.1.1

Phase 1 FTAM Services

The subset of file transfer services that has been agreed to is:

F- INITIALIZE

F- SELECT

F-OPEN

F-READ, F-WRITE

F-DATA

F-DATA-END

F- TRANSFER-END

F-CLOSE

F -DESELECT

F-U-ABORT, F-P-ABORT

F~ TERMINATE

Implementation of F-CANCEL is optional.

Both F-READ and F-WRITE will be implemented. At most one F-OPEN and one FREAD or F-WRITE is permitted per file selection, but more than one file may be

selected sequentially over the lifetime of a connection. A Session

connection is established at the beginning of the file activity and is

terminated when the file transfer connection is released by an F-TERMINATE.

The limited management subset of services that has been agreed to is:

F- CREATE

F-DELETE

F-READ-ATTRIBUTE

Note that this subset is complete with respect to the ISO limited file

management functional unit.

The <user correctable file service> and the <storageAttributeGroup> subset of

the virtual filestore attribute group are to be implemented.

10.1.2

Phase 1 Attributes

The following attributes have been agreed upon.

10.1.2.1. File Attributes

Phase 1 FTAM implementations will negotiate the use of Storage file

attributes. A value for the following attributes must be maintained.

1. FILENAME

The minimum range of <filename> values specified in DP8571 Part 2 Section 11 is supported (1-8 characters), with no maximum length or format restriction.

40
Any system that does not support extended <filename> characteristics would

reject the F-SELECT or F-CREATE request of such a <filename>. Values of

<filename> are to consist of upper-case letters (A-Z) and numbers <0-9>, and

must begin with a letter.

2. ACCESS STRUCTURE TYPE

The value of <accessStructureType> type is <unstructured> . The

<accessStructureType> attribute values <flat> and <hierarchical> are not used.

3. PRESENTATION CONTEXT NAME J

Two structures for <presentationContextName> have been approved.

VARCRLF : Text format. Each line is variable length and must be

terminated by a CRLF pair. Maximal line length is 250 characters plus

CRLF. Form feed is excluded. CR and LF cannot occur separately. The

ISO 646 character set is to be used.

UNDEF: Octetstring encoding. No embedded structure is recognized.

4. CURRENT FILESIZE

The current filesize value conforms with the second ISO draft proposal.

5 . REQUESTED ACCESS

The <Requested access> parameter may have <read>, <replace>, <read attributed

and <delete file> attribute values.

In addition to the above attributes, implementations are encouraged to

maintain the following values.

1. FUTURE FILESIZE

The <futureFilesize> parameter is a provider option, conforming to the second

ISO draft proposal.

2. DATE AND TIME OF CREATION

The <dateAndTimeOfCreation> parameter is a provider option. The value

conforms with the second ISO draft proposal; its resolution and accuracy are implementation dependent.

10.1.2.2 Activity Attributes

Phase 1 FTAM implementations negotiates the use of Storage activity

attributes. Other attributes defined are:

1. CURRENT ACCESS STRUCTURE TYPE

The <current access structure type> has the <unstructured> attribute value.

41
2. CURRENT PRESENTATION CONTEXT

The <current presentation context> is the same as PRESENTATION CONTEXT, i.e.,

VARCRLF or UNDEF.

10.1.3 ISO Deviations and Selections

1. F-CANCEL (DP8571/3 8.1 Table 1)

Implementation of the F-CANCEL service for irrecoverable errors in the Read

Functional Unit and Write Functional Unit is optional. An implementation that

receives an F-CANCEL indication may issue an F-P-ABORT or F-U-ABORT.

2. Grouping Functional Unit (DP8571/3 8.2 lb)

There is no implementaiton of the Grouping Functional Unit. The concatenation

constraint on establishing and releasing a <f ileOpenRegime> is not supported.

3. F- INITIALIZE (DP8571/3 14.1.2)

Values have been chosen for these F-INITIALIZE parameters:

Parameter Value

serviceType

(DP8571/3 ,14.1.2.5)

serviceClass

(DP8571/3 14.1.2.6)

functionalUnits

(DP8571/3 14.1.2.7)

attributeGroups

(DP8571/3 14.1.2.8)

rollbackAvailability

(DP8571/3 14.1.2.9)

presentationContextName

(DP8571/3 13.1.2.11)

userCorrectable

file transfer class

{read, write,

1 imi t edF i leManagemen

}

storage

no rollback

defined in section

10.1.2 of this document

The Abstract Syntax for F-INITIALIZE is:

F-INITIALIZErequest ::= SEQUENCE

{

protocolld [0] INTEGER {isoFTAM (0)},

versionNumber [1] IMPLICIT SEQUENCE{

major INTEGER, minor INTEGER},

--initially {major 0, minor 0}--

serviceType [2] INTEGER

{

42
reliable (0), userCorrectable (1)}

serviceClass [3] INTEGER {transfer (0),

access (1), management (2)},

functionalUnits [4] BITSTRING{

read (0), write (1), fileAccess (2),

limitedFileManagement ( 3 )

,

enhancedF i leManagement ( 4 )

,

grouping (5), recovery (6),

restartDataTransfer (7)},

attributeGroups [5] BITSTRING{

storage (0), security (1)},

rollbackAvailability [6] BOOLEAN DEFAULT FALSE,

presentationContextNames [10] IMPLICIT

SEQUENCE OF PresentationContextName OPTIONAL,

identityOfInitiator [7] Graphicstring OPTIONAL,

CurrentAccount OPTIONAL,

f ilestorePassword [8] OCTETSTRING OPTIONAL,

checkpointWindow [9] INTEGER OPTIONAL)

F-INITIALIZEresponse : := SEQUENCE

{

Diagnostic,

protocolID [0] INTEGER {isoFTAM (0)},

versionNumber [1] IMPLICIT SEQUENCE{

major INTEGER, minor INTEGER), —initially {major 0, minor 0)--

serviceType [2] INTEGER{

reliable (0), userCorrectable (1)),

serviceClass [3] INTEGER {transfer (0),

access (1), management (2)),

functionalUnits [4] BITSTRING{

read (0), write (1), fileAccess (2),

limitedFileManagement (3),

enhancedF i leManagement ( 4 )

,

grouping (5), recovery (6),

restartDataTransfer (7)),

attributeGroups [5] BITSTRING{

storage (0), security (1)),

rollbackAvailability [6] BOOLEAN DEFAULT FALSE,

presentationContextNames [8] IMPLICIT

SEQUENCE OF PresentationContextName OPTIONAL,

checkpointWindow [7] INTEGER OPTIONAL)

If the <PresentationContextName> parameter is present, its value will

establish the limits of the life of the FTAM association.

4. F-OPEN

The values of the <ProcessingMode> parameters chosen are <read> or <replace>

(DP8571/3 17.1.2.2).

With FmOPEN, the <presentationContext> parameter must be present to indicate

the context chosen for the transfer, since there is currently no Presentation

43
Layer implementation (DP8571/3 17.1.2.3).

5 . F-DATA

(DP8571/3 24.3.) F-DATA is encoded as:

IDENTIFIER: context specific tag value [55]

Length: (Length of OCTETS)

Contents: (octets)

There is an explicit F-DATA PDU because of the direct FTAM/ Session mapping.

The ASN.l definition of F-DATA is:

F-DATArequest ::= [55] IMPLICIT OCTETSTRING

6. IS0646String ASN.l TYPE

The ASN.l type <IS0646String> is used instead of ASN.l type <GraphicString> in

the abstract syntax. Wherever <GraphicString> is specified in the abstract

syntax, the abstract syntax is modified by <IS0646String>

7. Presentation Context

The <PresentationContext> attribute on the SELECT/CREATE request is restricted

to only one <presentationContextName>

<presentationContextName> parameters are encoded as: PresentationContextName ::= [Application 13]

PrintableString

On F-OPEN Requests and Responses, the <presentationContextName> parameter is

mandatory, not optional.

8. State Machine

Phase 1 FTAM products will use the state machine in the second ISO draft FTAM

proposal, part 4, except where explicitly specified differently in these

agreements

10.1.4 Further Implementation Details

The following recommendations are not specified by the standard but have been

agreed upon in order to ensure that different implementations work together

smoothly.

1. FTAM Phase 1 Use of Session Service

This FTAM implementation is mapped directly to Session services and does not

use CASE. The F-INITIALIZE Request is embedded in the S-CONNECT Request and

the F-INITIALIZE Response is embedded in the S-CONNECT Response, instead of

being sent as S-DATA request after the Session has been established.

44
If the F-INITIALIZE Response is a positive confirmation, that Response is

mapped onto ACCEPT SPDU. Otherwise, it is mapped onto REFUSE SPDU.

F-U-ABORT and F-P-ABORT are mapped to S-DATA Requests. The receiver of an F-U-ABORT or an F-P-ABORT must issue an S-U-ABORT Request. This avoids

S-RELEASE collison should both entries wish to abort simultaneously.

2. Parameter Parsing and Support

Implementations should be able to parse all valid second ISO draft proposal

optional parameters if they are present in the PDU. Only those optional

parameters specified in the agreements are required to be supported for

request and response PDUs.

All second ISO draft proposal optional parameters identified in these

agreements as mandatory must be supported. If this parameter is not present,

its semantics are a local issue. Furthermore, the request should not be

refused.

3. Error Handling and Diagnostics

Error handling and diagnostic action that is permitted by the standard is not

restricted. Implementations may return a response with a negative diagnostic

or issue an F-U-ABORT request.

In the FTAM second ISO draft proposal, the parameter <diagnostic> is defined

as <ImplicitSequenceOfDiagnostics>. The order of the diagnostics in the

sequence is arbitrary and has no significance.

4. Rollback

Specifying <No rollback> implies that, in case of failure, the status of the

involved files is unpredictable. Implementors of receivers may choose to

leave the partially transferred file as is, or they may cancel it.

However, in order to avoid dangling conditions, after a failure (i.e., after

an F-U-ABORT or F-P-ABORT) it is recommended that files always be put in a status that does not prevent further access both from remote and local

systems

5 . Concurrency

No concurrency rules have been adopted, since the file attributes governing

them will not be supported. Therefore, each implementation may choose the

degree of concurrency of the local files as a local matter. However, in order

to minimize possible errors, the following implementation rules are recommended.

a. A file may be involved in several transfers simultaneously only

if accessed in reading mode.

45
b. If a file is involved in a transfer in writing mode, any other

request for access to that file (either for Read or Write)

should be rejected.

c. A file cannot be modified by local users while it is involved in a transfer operation, either in F-READ or F-WRITE. (As a practical matter, this may be very difficult to implement,

regardless of the protection mechanisms provided by the local

operating system.

)

6. ASN.l

ISO ASN.l syntax is used for encoding PDU headers. ASN.l encoding using the

indefinite length style is not supported.

7. Maximum PDU Length

The maximum PDU length is 1024 octets.

8. Response to F-READ-ATTRIBUTE

If an F-READ-ATTRIBUTE request specifies an NBS optional attribute that is not

supported by an implementation's virtual filestore, then that attribute will

not be returned in the <read attribute> response. It is recommended that an implementation return an appropriate diagnostic in this situation (e.g., 4000,

"attribute non-existent").

9. Corrupted S-CONNECT Indication User Data

If a Responder receives an S-CONNECT indication, and the user data carried on that indication are "corrupted" (i.e., decoding the PCI results in an irrecoverable error), then

a. If the user data can be identified as an F-INITIALIZE request,

the Responder should respond with an F-INITIALIZE response (-) or F-P-ABORT with diagnostic conveying an irrecoverable error. This is to be carried on an S-CONNECT response (-), i.e.,

rejecting the connection.

The Responder should further clarify the error in the < further

details> field of the <Diagnostic> PDU.

Parameters on the F-INITIALIZE response should be reflected

where appropriate; where this is not possible, default values

should be chosen by the Responder where mandatory parameters are required and cannot be reflected.

46
b. If the user data cannot be identified as an F-INITIALIZE

request, the Responder should respond with an S-U-ABORT and a reason code appropriate to the error.

47
10,2 PHASE 2 FTAM IMPLEMENTATION SPECIFICATION

10.2.1 Assumptions

1. These agreements are based on the ISO 8571 DIS version of FTAM. When the

IS text is approved following the close of DIS ballots, the agreements will be

modified as necessary to meet the IS specifications.

2. FTAM protocol machines must be able to parse and process up to 7K octets

of File PCI and FTAM user data (including grouped FPDUs) as they would be

encoded with the ASN.l Basic Encoding Rules. It is recommended, however, that

Presentation user data not be restricted in size.

3. 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 a error.

4. Implementations must be able to parse all valid DIS optional parameters if

they are present in the PDU. Only those optional parameters specified as mandatory in these agreements are required to be supported for Request and

Response PDUs. If these parameters are not present, a default value is

assigned locally. A responder should not refuse a request solely because a parameter that is optional in the FTAM standard, but is mandatory in these

agreements, is not present.

5. Consideration of any standarized service interface is not covered by these

agreements

10.2.2 Presentation Agreements

The following Abstract Syntaxes are supported.

ISO 8571 -FTAM (including ISO 8571-FADU)

ISO 8650-ACSE1

NBS-AS1

NBS-AS2

NBS-AS3

If the presentation context management functional unit is available, it is

possible to use P-ALTER-CONTEXT to negotiate the use of an abstract syntax.

See section 11.2 for definition of the <object Identified for <ISO 8571-FTAM>

and <IS0 8650-ACSEl>.

48
10.2.3 FTAM Service Type Agreements

The Reliable File Service level (excluding Recovery and RestartDataTransfer

functional units) is to be implemented. Implementing the error recovery

protocol machine is not required.

10.2.4 Service Class Agreements

Implementation of the following service classes is defined.

o File Transfer

o File Access

o File Management

o File Transfer and Management

o Unconstrained

10.2.5 Functional Unit Agreements

Implementation of the following functional units is defined.

o Kernel

o Read

o Write

o File Access

o Limited File Management

o Enhanced File Management

o Grouping

10.2.6

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:

1. An actual file attribute value.

2. A value indicating that the attribute value is not available at this time.

Optionally, a diagnostic may be provided indicating that the attribute is not

supported.

The <Contents Type> attribute is limited to the <DocumentTypeName> form.

Mandatory Group

A value for file name and contents type will always be available. Only the

Kernel Group of attributes is required.

49
A minimum range is required for <filename> values (1-8 characters). No

maximum length or format restrictions apply. A system that does not support

multi -component <f ilename> values or extended <filename> characteristics may

reject a request involving such a <filename>. All systems must be able to

interpret a <filename> with single component values. Requests using single

component <filename> values are responded to using single component <filename>

values. Responses to requests involving <filename> values having two or more components are not defined here but may be interpreted via bilateral or other

external agreements. Use of <filename> values with multiple components is

discouraged.

Optional Groups

If the optional Storage Group of file attributes is implemented, an actual

value must be available for the <PermittedActions> attribute.

If the optional Security Group of file attributes is implemented, an actual

value must be available for the <AccessControl> attribute.

Implementation of the <Private> Group is not specified.

10.2.7 Document Type Agreements

These document types are defined.

NBS-1 UNDEF

NBS-2 VARCRLF

NBS-3 S859VARCRLF

NBS-4 TEXT

NBS-5 8859TEXT

NBS-6 SEQUENTIAL

NBS-7 RANDOM

NBS-8 INDEXED

NBS-9 FILE DIRECTORY

Part of our ongoing work is to define, discuss, and propose other file types.

Detailed document type definitions are given in Appendix D.

Document type Names:

DTN :

: = DTName | DTName params

DTName : := OBJECT IDENTIFIER

params :

: = param | :param params

param : := PrimType | PrimType, param

PrimType := INT - <n*>

BIT - <n2>

IA5 - <nl>

8859 - <nl>

OCT - <nl>

UTC

GEN

50
NULL

BOOL

FLOAT - <n3, n4>

<nl> - Maximum number of characters/octets in string.

<n2> - Number of bits in string (i.e., nonvarying).

<n3> - The minimum number of bits required to be maintained in the mantissa

for relative precision.

<n4> - Number of bits required to represent the largest unbiased integer in

2

1 s complement

<n*> - Number of octets required to represent, in 2's complement format, the

largest integer to be passed.

The primitive data types and minimal size range that an implementation must

accept are given in the table 10.1.

Tbl. 10.1 FTAM primitive data types

PRIMITIVE DATA TYPE REPRESENTATION MINIMUM RANGE (OCTETS)

IN PARAMETER

ASN.l INTEGER INT <N*> (1 - 2)

ASN.l Bit String BIT <N2> (0 - 1)

ASN.l IA5String IA5 <N1> (0 - 134)

NBS-AS1 8859String 8859 <N1> (0 - 134)

ASN.l OCTETSTRING OCT <N1> (0 - 512)

ASN.l BOOLEAN BOOL

ASN.l NULL NULL

ASN.l Generalized Time GEN

ASN.l Universal Time UTC

NBS-AS1 Floating Point FLOAT <N3 ,N4>

Note: 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.

An <object identified is a string of integers; FTAM <document type>

parameterization is achieved by exploiting that structure.

The final registration authority entity is followed by a <data unit>

description. The <data unit> description is a series of data element

descriptions. Each <data element> description is an integer identical to the

ASN.l type code, followed by any required parameter values, as integers.

51
The following values correspond to the NBS primitives not found in ASN.l and

the integer value for (separator).

FLOAT - 127

8859 - 126

: - 125

Following is an example of how an indexed file with three fields (2-byte

integer, 4-byte integer and 10-character IA5String), with the key being the

second field, would be encoded:

DTN: INT(2) , INT(4), IA5(10): INT(4)

This is derived from the grammar for document type names give above. It would

be represented in the encoding of the Object Identifier as:

(encoding for base document type name) 125 22 2 4 22 10 125 2 4

This is derived by applying the encoding rules given above.

The following notation allows the transfer of floating point numbers, while

retaining their meaning, as defined by existing standards IEC 559 and IEEE

754.

FloatingPointNumber : := [PRIVATE 0] CHOICE!

finite [0]

Sign,

IMPLICIT SEQUENCE!

mantissa BIT STRING,

exponent INTEGER}

,

infinity [1] IMPLICIT Sign,

signallingNaN [2] IMPLICIT NaN,

quiteNaN [3] IMPLICIT NaN, zero [4] IMPLICIT NULL}

Sign ::= INTEGER!

positive (0),

negative (1)}

NaN ::= INTEGER

Notes: 1. The mantissa is a number in the range (1/2 < mantissa <1).

2. The value is equal to mantissa * 2 exPonent . 3. The first bit in the mantissa is most significant.

4. See IEEE 754 for definitions of terminology, such as NaN.

10.2.7.1 Character Sets

IA5 and 8859/1 character sets have been specified, and are to be implemented

as described below.

1. IAS

52
The IA5 character set leaves 2 options and 10 characters unspecified. The

definitions used are:

2/3 #

2/4 $

4/0 @

5/11 [ 5/12 \

5/13 ] 5/14

6/0 ' 7/11 {

7/12 | 7/13 }

7/14

Note: This is exactly the International Reference Version (IRV) specified in

the IA5 standard except that the code 2/4 has the graphic rendition "$"

instead of the IRV-specif ied value of the International Currency Symbol.

Control characters should be handled as follows.

a. Semantics of format effectors will be preserved.

b. Transmission control characters, device control characters,

information separators, and "other" control characters is simply

preserved via their codes.

c. Code extension shall not be used. If it is- received, the code

extension characters should be preserved, as in the case of the

transmission control characters, and any printing characters

that form later parts of escape sequences is interpreted as stand alone characters.

d. Combined horizontal and vertical movement of cursor positioning

is not be preserved.

2. 8859/1

The Latin Alphabet No. 1 is used to specify the printable rendition of CO and

Cl. CO control characters and their associated rules are taken from the IAS

definition. Cl control characters simply have their codes preserved across a transfer.

10.2.7.2 Document Type Negotiation Rules

1 . Connection Establishment

In Connection Establishment, <DocumentTypeName> values are negotiated by

subset of the proposed base set of <DocumentTypeName> values, without regard

to DU syntax parameter(s) that may be supplied on any <DocumentTypeName> that

requires a DU syntax specification.

53
2. File Creation

An F-CREATE Request FPDU must contain a <DocumentTypeName> value from the

negotiated set of base <DocumentTypeName> values. If the <DocumentTypeName>

used requires DU syntax parameters, then these parameters must be supplied.

If the <DocumentTypeName> used requires DU syntax parameters and none are provided on the F-CREATE Request, then the F-CREATE Request FPDU must be

rejected.

3. File Opening

It is recommended that the F-OPEN Request use the <DocumentTypeName> form

(with appropriate DU syntax parameters) when proposing a <Contents Type>, in

preference to the <Constraint Set Name> and <Abstract Syntax Name> form.

Similarly, an F-OPEN response should use the <DocumentTypeName> option (with

appropriate DU syntax parameters) in the <Contents Type> field. This allows

the receiving entity to use the <DocumentTypeName> 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 NBS document

types

Note: An F-OPEN response without a <DocumentTypeName> (but carrying the

Constraint Set Name> and <Abstract Syntax Name> form) may cause the initiator

to issue an F- CLOSE request.

10.2.7.3 Relationship 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.l primitive types. A Data Element (DE) is the smallest piece of data

whose identity is necessarily preserved by the Presentation Service. Data

types may be made up of other 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.

To maintain DU boundaries during transfer, file structuring information must

be passed (ISO 8571-FADU DEFINITIONS, FTAM Part 2 section 5.3.2). A data

element is referred to as a File Contents Data Element in ISO 8571-FADU

DEFINITIONS

Document types refer to aspects of local processing and storage. They

describe:

o structural relationship between DUs,

o structure of DUs, called DU syntax, and

o data element types found in the file.

54
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.

10.2.F- CANCEL ACTION

When an F-CANCEL is sent or received, the following occurs:

o no more data is sent,

o <checkPointNumbers> are removed, and

o state of the file is implementation dependent.

10.2.9 Diagnostic Agreements

1 . A <diagnostic> parameter is mandatory only 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>.)

2. General catch-all diagnostic action is discouraged.

3. A <furtherDetails> subfield is mandatory. Use of octet string

is discouraged.

4. Use of F-P-ABORT for other than protocol errors and catastrophic

situations is discouraged.

55
5

When returning an error status in a file management related

diagnostic (i „ e . , F-READ-ATTRIBUTEresponse or FCHANGE-ATTRXBUTEresponse) » identify the erroneous attribute by

using the first two characters of <further-details> to hold a 2-digit number (encoded in IA5String) from the

F-READ-ATTRIBUTErequest attributes abstract syntax definition

(ISO/DIS 8571/4 section 20-4):

00 Filename

01 Contents -Type

02 Storage Account

03 Date and Time of Creation

04 Date and Time of Last

Modification

05 Date and Time of Last Read

Access

06 Date and Time of Last

Attribute Modification

07 Identity of Creator

08 Identity of Last Modifier

09 Identity of Last Reader

10 Identity of Last Attribute

Modifier

11 File Availability

12 Permitted Actions

13 Filesize

14 Future Filesize

15 Access Control

16 Encryption Name

17 Legal Qualifications

18 Private Use

6. The set of File Management <diagnostics>, found in Table 44 of

ISO 8571/3 Annex A, must be maintained.

7. The <diagnostic> parameter values defined in FTAM (8571/3 Annex

A) are partitioned into sets that apply to:

a. general FTAM <diagnostics> (all but identification * 1 are recommended against),

b. Protocol and supporting services,

c. the <FTAM Regime>,

d. the <File Selection Regime>,

e. the <File Open Regime>,

f. the <Data Transfer Regime>.

Each of those sets is further partitioned into <diagnostics> applicable to

each parameter of the corresponding service elements.

In the case where a specific parameter can in no way be accomodated then the

request fails and a <diagnostic> indicating one such parameter should bm

56
returned by the responder. In the case where a negotiable parameter cannot be

accomodated with exactly the value requested but is negotiated to a different

value (as defined in section 10.2.13) then the request formally succeeds but

informative <diagnostics> indicating those parameters negotiated should be

returned.

10.2.10

Concurrency

The Concurrency control> used by default on the file selection and file open

regime for the first file accessor of a file is:

read shared

insert exclusive

replace exclusive

extend exclusive

erase exclusive

rattr shared

cattr exclusive

del file exclus ive

For subsequent file accessors, the <requestedAccess> and <processingMode>

service parameters are checked against this, and access given only if the

request is for operations that are shared.

10.2.11 Requested Access

The <RequestedAccess> 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 <RequestedAccess> parameter is compared by the responder to the

<AccessControl> and <PermittedActions> file attributes and concurrency

controls (including those requested by the initiator) currently in place on the file. If the value of the <RequestedAccess> parameter is not consistent

with either <AccessControl> , <PermittedActions> , or concurrency controls in

place, then the <F-SELECT> or <F-CREATE> must be rejected.

<RequestedAccess> is consistent with <AccessControl> if, for each action

requested, that action either requires no password, or the required password

has been specified on the <F-SELECT> or <F-CREATE> request.

<RequestedAccess> is consistent with <PermittedActions> i,f for each action

requested, that action is allowed by the <PermittedActions> file attribute.

<RequestedAccess> is consistent with <ConcurrencyControl> requested on the <FSELECT> or <F-CREATE> if, for each action requested, that action has not been

specified as <not required> or <not allowed> in the <ConcurrencyControl>

parameter

<RequestedAccess> 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 <not allowed>.

10.2.12 Security

57
10.2.12.1

Optional Password Support

Users may provide values for <InitiatorIdentity> and <FilestorePassword> . Password support in FTAM is not required. If this information is provided, it

will be sent to the Responder on the F-INITIALIZE.

The syntax of <InitiatorIdentity> and <FilestorePassword> is systemdependent. <XnitiatorIdentity> and <FilestorePassword> will represent

'account' information on the local system, which may be different from the

<account> 10.2.12.2 parameter.

Access Passwords

Users may provide <accessPasswords> . If the information is provided, the

passwords will be sent to the Responder in the <accessPasswords> parameter.

10.2.12.3 Anonymous User Convention

A commonly defined "anonymous user" convention is to be provided for all

systems that choose to support this capability. The access available to that

user is locally determined. The <InitiatorIdentity> value to be used is ANON,

encoded as an <IA5String>. Any password should succeed.

10.2.12.4 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.

10.2.13 Negotiation

The guidelines for negotiation that have been agreed upon are outlined in

table 10.2.

58
Tbl. 10.2 FTAM negotiation rules

Service or Parameter Depends on or may be negotiated

down by:

F- INITIALIZE

Req . Pres . ContextMgmt

Req.Func. Unit

Success or failure.

Negotiated by subset (as per DIS

8571/3 section 10.3).

(Affects session functional units.)

Req.Attr. Groups

Req . Comm . Quality

of services

Req . ContentTypeList

Negotiated by subset.

Reference session.

Negotiated by subset.

F- SELECT

Attributes Only by <filename>.

N.B. The <filename> on response and

confirm must be that of an existing

virtual file.

Requested Access Negotiated by subset (in case of

complete or partial success), must

be consistent with Functional Units

negotiated, access control attribute,

and permitted actions attribute.

F- CREATE Consistent with Functional Units.

Initial attributes 1. The attributes returned are within

the subset negotiated at

initialization.

2. The individual attribute values

returned must be consistent with

negotiation/ranges for that attribute

3. The Responder returns values for

all attributes which differ from the

actual request.

Requested Access As in F-SELECT.

F- DELETE Consistent with Functional Units.

F-READ-ATTR Consistent with Functional Units,

F- CHANGE -ATTR

service class, and requested access.

As for F- READ-ATTRIBUTE.

(Continued on next page.)

59
Tbl. 10.2 FTAM negotiation rules, continued

Attributes If any attribute cannot be

successfully changed, then an error more severe than warning should

be returned and no attribute

should be changed.

F-OPEN

Processing Mode Not Negotiated. Must be consistent

with Functional Unit and Requested

Access negotiated, with the permitted

actions attribute, and with the

contents type name.

Contents Type As defined in the DIS.

Concurrency Control More restrictive than the concurrency

control of F- SELECT; consistent

with the concurrency control of

other users.

F- BEGIN-GROUP Consistent with Functional Units and

F-END-GROUP service class.

F- LOCATE Consistent with Functional Units,

F-ERASE, requested access (and

therefore with permitted actions)

Service Class and

Processing Mode.

F-READ

F-WRITE

Functional Units, Service Class and

number of bulk data transfers,

Requested Access and Processing Mode.

F - DATA/ F- DATA-END

F- CANCEL

F-TRANSFER-END

Functional Units and

Service Class.

10.2.14 Conformance

This section gives the minimal criteria to be satisfied by implementations of

FTAM to be conformant to these agreements.

Conformance to these agreements is stated in terms of the different roles

60
occupied by FTAM implementations. The interoperability of certain

configurations of these roles motivates this approach. Interoperable

configurations of these roles is given in section 10.2.14.1

10.2.14.1 Interoperable Configurations

Any implementation conforming to this specification must be able to act in at

least one of the following role combinations:

1. initiator and receiver,

2. initiator and sender,

3. responder and sender, or

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.

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 sections 10.2.14.3 to 10.2.14.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 sections 10.2.14.3 to 10.2.14.8).

These role combinations and interoperability are shown in the table below.

Tbl. 10.3 Interoperable configurations

Initiator Responder

sender receiver sender receiver

Initiator

sender X

receiver X

Responder

sender X

receiver X

10.2.14.2 Relationship to ISO 8571 --The FTAM Standard

Any implementation in conformance to ISO 8571 (as defined in ISO 8571/4

section 21 (Conformance)), in addition to the implementation of the minimal

protocols and roles enumerated in sections 10.2.14.3 to 10.2.14.8, is

considered to be in conforance with these agreements. Any implementation

61
violating any of the conformance statements in ISO 8571/4 is considered to be

in violation of these agreements.

10.2.14.3 Requirements for Document Type Support

The document type NBS-1 shall be supported for purposes of transfer and

storage. The details regarding support for NBS-1 in the FTAM dialogue are given in sections 10.2.14.6 and 10.2.14.7.

Support of document types other than NBS-1 (including document types defined

elsewhere in these agreements or registered by authorities other than the NBS) are not required by these agreements. However, for the support for any

document type these agreements require that the mechanisms for referencing

those document types in the protocol be consistent with the protocol in both

state and encoding. Support for document types described in these agreements

also entails support for :

o the semantics given in their description,

o the preferred transfer syntax (via the designated transfer syntax name and the name "{ISO standard 8825}," and

o the transfer of that document type under access context US

(unstructured)

Support for other document types is not required by these agreements.

10.2.14.4 Initiators

Every implementation of an FTAM initiator shall support:

o the kernel protocol and its mandatory parameters with minimum

ranges [Minimum required ranges are specified in section

10.2.14.8. ]

,

o the grouping protocol and the threshold parameter with a value

of 2 for use in the file transfer class,

o at least one of the read or write protocols [Specific

conformance for reading and writing is defined in sections

10.2.14.6 and 10.2.14.7.],

and support the applicable procedures defined in ISO 8571/4 sections 8.1 (FTAM

regime establishment), 8.2 (FTAM regime termination), 8.3 (File selection),

8.4 (File deselection), 8.9 (File open), 8.10 (File close), 8.11 (Begin group)

and 8.12 (End group), and 10 (File general actions). To support the above

protocols and procedures the implementation shall be able to:

o request the kernel, grouping and at least one of the read or write functional units.

62
o request the Creliable file service> (but not necessarily any

error control procedures) with the "service level" parameter,

o request the file transfer class with the "service class"

parameter,

o request optional functional units consistently from those

defined for the file transfer service class,

o request the document type NBS-1 using the "document type name"

form of the contents type parameter, and

o request a "communication quality of service" consistent with the

transport definition in these agreements

as part of the filestore initialization procedures in ISO 8571/4 section 8.1,

FTAM regime establishment.

Initiators must be able to operate under all circumstances if the above

minimum values are successfully negotiated and returned on an FINITIALIZEresponse PDU. Initiators must be able to operate with any downward

negotiation of requested parameter values as described in section 10.2.13.

Should the supporting services break down, such that FTAM communication is

impossible, the FTAM protocol machine shall notify the user with an <F-PABORT indication> and <diagnostic> with identifier 1011. Any known "further

details" are recommended.

10.2.14.5 Responders

Every implementation of an FTAM responder shall support;

o the kernel protocol and its mandatory parameters with minimum

ranges [Minimum required ranges are specified in section

10.2.14.8.],

o the grouping protocol and the threshold parameter with a value

of 2 for use in the file transfer class,

o at least one of the read or write protocols [Specific

conformance for reading and writing is defined in sections

10.2.14.6 and 10.2.14.7.],

and support the applicable procedures, defined in ISO 8571/4 sections 9.1

(FTAM regime establishment), 9.2 (FTAM regime termination), 9.3 (File

selection), 9.4 (File deselection), 9.9 (File open), 9.10 (File close), 9.11

(Begin group) and 9.12 (End group), and 10 (File general actions). To support

the above protocols and procedures the implementation shall be able to:

o accept requests for the kernel, grouping and at least one of the

read or write functional units,

63
o accept requests the <Reliable File Service> (but not necessarily

any error control procedures) with the "service level"

parameter,

o accept requests for the file transfer class with the "service

class" parameter,

o accept requests for optional functional units consistently from

those defined for the file transfer service class and consistent

with its supported roles as specified in section 10.2.13.1,

o request the document type NBS-1 using the "document type name"

form of the contents type parameter, and

o accept requests for a "communication quality of service"

consistent with the transport definition in these agreements

as part of the filestore initialization procedures in ISO 8571/A section 9.1,

FTAM regime establishment.

Responders must be able to operate under all circumstances if the above

minimum values are requested on an F-INITIALIZErequest PDU. Responders must

not negotiate upward in the sense described in section 10.2.13.

Each responder shall support, for purposes of both communication and

processing, the kernel and storage groups of attributes. A value shall always

be available for the kernel attributes. (For the storage attributes a value

of "no value available" may be the only applicable value.)

Responders must complete each action requested and supported in a manner consistent with its description in ISO 8571/2 sections 6 (Actions on complete

files) and 7 (Actions for file access), and must interpret each supported

attribute in a manner consistent with its definition in ISO 8571/2 section 8 (File attributes).

Under circumstances where actions cannot be carried out either as requested or consistently with ISO 8571/2 sections 6 (Actions on complete files) and 7 (Actions for file access), the responder must return at least one diagnostic

indicating:

o if the failure was due to either a protocol or filestore

failure, and then;

-- precisely which action failed,

-- at least one of the parameters that could not be accommodated

with the diagnostic type indicating at least the degree of

failure, as given by the action and state result parameters; or

o that the failure was due to unforeseen system shutdown.

Should the supporting services break down, such that FTAM communication is

impossible, the FTAM protocol machine shall notify the user with an <F-P64
ABORT indication> and <diagnostic> with identifier 1011. Any known "further

details" are recommended.

10.2.14.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 sections 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 NBS document type NBS-1 (UNDEF) and shall be able to send them as user

data in PPDUs in blocks of no more than 7168 octets.

10.2.14.6.1 Initiator Senders

Every implementation of an FTAM sender which is also an FTAM initiator shall

support

o the write functional unit and protocol, and

o for the document type NBS-1 the following bulk data transfer

specification parameter:

FADU operation replace

FADU identity first

Access context US

and support the applicable procedures, defined in ISO 8571/4 section 13 (Bulk

data transfer initiating entity actions).

10.2.14.6.2 Responder Senders

Every implementation of an FTAM sender which is also an FTAM responder shall

support:

o the read functional unit and protocol, and

o for the document type NBS-1 the following bulk data transfer

specification parameter:

FADU identity first

Access context US

and support the applicable procedures, defined in ISO 8571/4 section 14 (Bulk

data transfer responding entity actions).

10.2.14.7 Receivers

Every implementaton of an FTAM receiver shall support the read functional unit

as initiator or the write functional unit as responder, and support the

65
applicable procedures, defined in ISO 8571/4 sections 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 NBS document type NBS-1 (UNDEF ) and shall be able to receive them as user data in PPDUs in blocks of at least than 7168 octets.

10.2.14.7.1 Initiator Receivers

Every implementation of an FTAM receiver which is also an FTAM initiator shall

support:

o the read functional unit and protocol, and

o for the document type NBS-1 the following bulk data transfer

specification parameter:

FADU identity first

Access context US

and support the applicable procedures, defined in ISO 8571/4 section 13 (Bulk

data transfer initiating entity actions).

10.2.14.7.2 Responder Receivers

Every implementation of an FTAM receiver which is also an FTAM responder shall

support:

o the write functional unit and protocol, and

o for the document type NBS-1

specification parameter:

the following bulk data transfer

FADU operation replace

FADU identity first

Access context US

and support the applicable procedures, defined in ISO 8571/4 section 14 (Bulk

data transfer responding entity actions).

10.2.14.8 Minimum Ranges

Any implementation of any conformant FTAM configuration shall 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 10.4. (A conforming implementation

may support a broader range of values for any parameter.)

66
Tbl. 10.4 Required minimal parameter support

Parameter Minimum Range

diagnostic Values as specified in ISO 8571/3 Annex A

(Diagnostic parameter values) tables 42,

43 and 45 which correspond directly to

mandatory parameters.

action result All values.

state result All values.

^INITIALIZE

functional units^ "read" (for initiator/receivers and

responder/ senders

)

or"write" (for initiator/ senders and

responder/ receivers )

presentation context management^ "Not required."

all others As specified in sections 10.2.14.4 and

10.2.14.5 above.

F SELECT

attributes Only filename 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 section 11

(Minimum attribute ranges) table 2.

requested access "read" for initiator receivers

"read" for responder senders

"read" for initiator senders

"read" for responder receivers

F_0PEN

processing mode "read" for initiator receivers

"read" for responder senders

"replace" for initiator senders

"replace" for responder receivers

content type "NBS-1"

(Continued on next page.)

67
Tbl . 10.4 Required minimal parameter support, continued

Parameter

F_READ

F WRITE

Minimum Range

FADU operation "read11 for initiator receivers

"read" for responder senders

"read" for initiator senders

"replace" for responder receivers

FADU identity "first" access context "US"

F BEGIN GROUP

threshold3 For file transfer (a minimal required

function)2

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 section 10.2.14.8.

^ 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.

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 2.

10.2.14.9 Meaning for Support of Options Defined in These Agreements

This section describes requirements and options for service classes defined bv

these agreements, as well as specific document types, attributes and

parameters and their ranges. General recommendations in accordance with DIS

8571/4 section 21.1 are given also; those definitions apply to any defined

options

10.2.14.9.1 Service Classes

68
The following service classes are defined individually for implementations.

Note that no defined implementation is precluded from supporting more than one service class.

o File access

o File management

o Unconstrained

Support of a service class requires adherence to: 1. its definition in DIS

8571/3 section 8 and any related procedures in DIS 8571/4 sections 8-17, 2.

requirements given in section 10.2.1-10.2.14 of these agreements, and 3.

requirements for parameter and attribute support as defined in section

10.2.14.8. 10.2.14.9.2

General Requirements for Implementations Defined in Section

10.2.14.10

o Implementations will support the Reliable Service level.

o Implementations will be able to act both as initiators and

responders

o Implementations that support either the limited file management

or both limited file management and enhanced file management

must support both the Storage and Security attribute groups.

o Implementations must support diagnostics as described in section

10.2.9 of these agreements.

0 Implementations that support the file access service class will

support the hierarchical file model and support an arc length

greater than one.

10.2.14.9.3 Recommended Use of Lower Layer Services

o Implementations will, additionally, support the mapping of the

F- CANCEL PDU on P- RESYNCHRONIZE.

o Support for the Presentation Context Management functional unit

is not required.

o Implementations will support the Session, Presentation, and ACSE

requirements as stated in sections 8, 11, and 12.

10.2.14.9.4 Document Type Requirements for Implementations Defined in Section

10.2.14.10

It is recommended that implementations conformant to these agreements also

implement the following document types with the caveats and procedures given.

Those document types are defined in Appendix D of these agreements.

o NBS-2

69
Caveat: NBS-2 is included only to allow compatibility with file

systems storing Phase 1 files,

o NBS-4

o NBSm6

o NBS-7

Note: Support of this document type entails the naming of FADUs by

their position in preorder traversal. NBS-7 applies only to file access. Caveat: Other methods of naming FADUs depend on the system,

application, and specific file, and as such are not described here,

o NBS-5

Note: Support for 8859 strings and their interpretation as defined

in section 10.2.7.1 of these agreements.

Support of the following document types is recommended with qualifications.

o NBS-8

Note: Only when the file access service class is implemented,

o NBS-9

Note: Only when the file management service class is implemented.

Support of NBS-2, 3, 4, 5 require the ability for transfer or access using

transfer syntax TS-1.

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.

Caveat: Specific abstract and transfer syntaxes for the parametrized 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 Appendix D and, where defined, the parameterization scheme given in

section 10.2.7 of these agreements.

10.2.14.9.5 Recommended Parameter for Implementations Defined in Section

10.2.14.10

o Implementations will not use CCR parameters.

o Implementations will use the contents type list parameter on the

F-INITIALIZE service element.

o Implementations will use the Account Parameter on the FINITIALIZE request PDU.

o Implementations will support the Diagnostic Parameter as stated

in section 10.2.9 of these agreements.

o Implementations will use the Charging Parameter on the FTERMINATE Service Element.

70
o Implementations will use the Identity of Initiator Parameter on the F- INITIALIZE Service Element. Use must be consistent with

section 10.2.12 of these agreements.

o Implementations are not precluded from using other parameters

for Security and/or acounting.

10.2.14.9.6 Parameter Ranges for Implementations Defined in Section

10.2.14.10

Parameter ranges for implementations defined in section 10.2.14.10 are as stated for primitive data types in 10.2.7 of these agreements.

10.2.14.9.7 File Attribute Support for Implementations

Implementations defined in section 10.2.14.10 will support file attributes in

the following ways.

o If an attribute is "supported" it implies a value will be

returned other than the value "no value available," and the

value will follow the rules as stated in these agreemnts and in

FTAM 8571 part 2.

o If an attribute is "optionally supported" a value of "no value

available" may be returned.

o If an attribute is "not supported" a value will not be returned

Kernel Group

1 . Filename - supported

2. Contents Type - supported

Storage Group

1 . storage account

2. date and time of creation

3. date and time of last modification

4. date and time of last read access

5. date and time of last attribute modification

6. Identity of Creator

7. Identity of Last Modifier

8. Identity of Last Reader

9. Identity of Last Attribute Modifier

10. File Availability - supported

11. Permitted actions - supported

12. Filesize - supported

13. Future Filesize

Security Group

71
1 . access control - supported

2. encryption name

3. legal qualifications

Private Group

1. Private use - not supported

10.2.14.10 Implementation Classes

The following implementation classes (profiles) are defined:

Tl: Simple File Transfer

T2: Positional File Transfer

T3: Full File Transfer

Al: Positional File Access

A2: Full File Access

Ml: File Store Management

Notes:

1. The File Store Management class is only to be implemented in conjunction

with one of the Transfer or Access classes.

2. Class T2 is a subset of T3» Al and Tl are subsets of A2 and T2,

respectively.

72
Tbl. 10.5 Implementation class support requirements

FU T

Service Class

M A T&M UNCST

A1,A2

Kernel T1,T2,T3 A2 T1,T2,T3

Read T1,T2,T3 A2 A1,A2

T1,T2,T3

Write T1,T2,T3 A2 A1,A2

T1,T2,T3

Limited File Mgmnt. Ml Ml

Enhanced File Mgmnt. Ml Ml

Graphics T1,T2,T3 T1,T2,T3

File Access A2

Document Types

NBS-1 T1,T2,T3 T1,T2,T3

NBS-2 T1,T2,T3 T1,T2,T3

NBS-3 T1,T2,T3 T1,T2,T3

NBS-4 T2,T3 A2 A1,A2

T2,T3

NBS-5 T2,T3 A2 A1,A2

T2,T3

NBS-d T2,T3 A2 A1,A2

T2,T3

NBS-w T2,T3 A2 A1,A2

T2,T3

NBS-8 T3 A2 A2,T3

NBS-9 Ml Ml

The Transfer, Access, and Management classes as defined above correspond to

the SPAG FTAM profiles as described in the "Guide to the Use of Standards," as follows.

Tbl. 10.6 Profile name relations - NBS/OSI to SPAG

Implementation Class SPAG Profile

T1 Alll

T2 A112

T3 A113

A1 A122

A2 A123

Ml A131

73
For further details on which parameters and file attributes are supported for

the SPAG FTAM profiles, see the "Guide to the Use of Standards."

74
11. ISO PRESENTATION LAYER

The Presentation services are defined to meet the needs of many applications.

The Presentation service is defined in ISO DIS 8822 and the Presentation

protocol is defined in ISO DIS 8823. General agreements about the

implementation of the Presentation layer are documented below in section 11.1,

followed by agreements related to specific applications.

Note: When the service definition and protocol specification achieve

International Standard status in ISO, these agreements will be aligned with

the ISO documents.

11.1 GENERAL

o The services of the Presentation kernel functional unit are used

as specified in ISO DIS 8822 and 8823 and must be implemented.

o Presentation connections always use multiple presentation

context mode.

o Multiple encoding of user data on connect requests is not

required.

o The following abstract syntaxes must be supported.

ISO 8650-2-ACSE 1 (ACSE PCI)

o Abstract Syntaxes are identified by registered name.

o The following Transfer Syntaxes must be supported for all

mandatory and defined abstract syntaxes.

NBS-TS1 (application of ASN.l Encoding Rules)

o Transfer Syntaxes are identified by registered name.

o A mandatory functional unit is one which must be implemented by

the service provider.

o An optional functional unit is one which may be implemented by

the service provider, but irrespective of whether it is

implemented or not, it must recognize and respond to correct

requests for its use.

11.2 PRESENTATION REQUIREMENTS FOR FTAM

o The following abstract syntaxes must be supported.

ISO 8571-FTAM (including ISO 8571-FADU)

NBS-AS1 (primitive data types)

75
o In addition, the following optional abstract syntaxes may be

implemented.

NBS-AS2 (floating point numbers)

NBS-AS3 (file directories)

o An implementation must support at least three simultaneous

presentation contexts.

o All session requirements for FTAM are reflected in the

Presentation layer.

76
12. ASSOCIATION CONTROL SERVICE ELEMENT

The ACSE service is defined to meet the needs of many applications. The ACSE

service is defined in ISO DIS 8649/2 and the ACSE protocol is defined in ISO

DIS 8650/2. General agreements about implementation of ACSE are documented

below in section 12.1, followed by agreements related to specific

applications

Note: When the service defintion and protocol specification achieve

International Standard status in ISO, the agreements will be aligned

with the ISO documents.

12.1

GENERAL

o All services specified in ISO DIS 8649/2 must be implemented.

o A mandatory parameter is one that must be implemented in the

protocol by the service provider. The service user must always

make a value for the parameter available.

o An optional parameter is one that must be implemented in the

protocol by the service provider, but the user has the option of

making available or not making available a value for the

parameter.

12.2

APPLICATION ENTITY TITLES

o An Application Entity Title will name a specific Application

Entity Instance on a specific end system.

o The naming of Application Entities is external to the

specification.

o Application Entity Titles may be mapped many-to-one to PSAP

addresses

o An Application Entity Title is a registered name of type Object

Identifier.

12.3

ETAM REQUIREMENTS OF ACSE

o The Application context> value <IS0 FTAM> is used to specify

the use of ACSE and the FTAM ASE.

77
13. X. 400 BASED MESSAGE HANDLING SYSTEM

13.1 INTRODUCTION

This is an implementation agreement developed by the Implementor's Workshop

sponsored by the U.S. National Bureau of Standards 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 OS

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) from the CCITT. Figure 13.1.1

displays the layered structure of this agreement.

This agreement can be used over any transport profile. In particular, this

profile can be used over the transport protocol class 0 used over CCITT X.25,

described in section 7.2 of this document. In addition, this profile 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

The material on PRMD-PRMD message transfer in this implementation

specification is intended to be stable enough to provide a reliable guide to

implementation of X.400. The material on ADMD-PRMD and ADMD-ADMD is

incomplete and serves as an indication of direction.

78
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 CCITT X. 225

Fig. 13.1.1 The layered structure of this implementation agreement

13.2 SCOPE

This agreement applies to Private Management Domains (PRMDs) and

Administration Management Domains (ADMDs). Three boundary interfaces are

specified:

1. PRMD to PRMD;

2. PRMD to ADMD;

3. ADMD to ADMD.

In case 1, the PRMDs do not make use of MHS services provided by an ADMD . In cases 2 and 3, UAs associated with an ADMD can be the source or destination

for messages. Furthermore, in cases 2 and 3, an ADMD can serve as a relay

between MDs. Figure 13.2.1 illustrates the interfaces to which the agreement

applies

X.400 protocols other than the Message Transfer Protocol (PI) and the

Interpersonal Messaging Protocol (P2) are beyond the scope of this agreement.

Issues arising from the use of other protocols or relating to PI components in

support of other protocols are outside the scope of this document. This

agreement describes the minimum level of services provided by Management

Domains (MDs). Provision for the use of the remaining services defined in the

X.400 Series of Recommendations is outside the scope of this document.

This agreement does not cover message exchange between communicating entities

within a domain even if these entities communicate via PI 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 with conforming domains that have made no bilateral

agreements

79
PRMD = Private Management Domain

ADMD = Administration Management Domain

A

i

Fig. 13.2.1 This agreement applies to the interface between:

(A) PRMD and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD

13.3 PRMD to PRMD

This section is limited in scope to issues arising from the direct connection

(interface A in Figure 13.2.1) of two PRMDs. "Direct" means that no ADMD

provides MHS services to facilitate message interchange. "Direct" does not

exclude those instances for which ADMDs provide lower layer services (e.g.,

X.25). Figure 13.3.1 schematically represents the scope of this section.

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 section addresses the PI and P2 protocols

and their related services in a direct connection environment. This section

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 section.

80
Fig. 13.3.1 Interconnection of private domains

13.3.1 Service Elements and Optional User Facilities

This section identifies those service elements and optional user facilities

that must be provided in support of PI and P2.

13.3.1.1 Classification of Support for Services

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.

13.3.1.1.1 Support (S)

This means that:

1 . The service provider makes the service element available to the service

user.

2. 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:

81
1. The service provider makes the service element available to the service

user for invocation.

2. The service user gives adequate support to the end user of the MHS to

invoke the service element.

Support for Reception means that 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:

o the service element is available to the originator,

o the service element is available to the recipient, and

o all intermediate steps carry the information.

13.3.1.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.

13.3.1.1.3 Not Used (N/U)

This means that although the Recommendations allow this service element, this

profile does not use it.

13.3.1.1.4 Not Applicable (N/A)

This means that this service element does not apply in this particular case (for originator or recipient).

13.3.1.2 Summary of Supported Services

o Within a PRMD, a User Agent must support all P2 BASIC I PM

Services (X.400) and all P2 ESSENTIAL IPM Optional user facilities (X.401) subject to the qualifiers listed in Appendix

A.

o 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 Appendix A.

o No support is required of the additional optional user facilities of X.401.

82
13.3.1.3 MT Service Elements and Optional User Facilities

Tables 13.3.1 through 13.3.3 show the message transfer (MT) service elements

and optional user facilities.

Tbl. 13.3.1 Basic MT service elements

Support (S) or Service Elements Non-support (N)

Access Management N/U1 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/U1 Submission Time Stamp Indication S

Not applicable to co-resident UA and MTA.

83
OJ

w

Tbl. 13.3.2 MT optional user facilities provided to the

UA-selectable on a per-message basis

MT Optional User Facilities Categorization

Support (S) or Non-support (N)

Alternate Recipient Allowed E S

Conversion Prohibition E S

Deferred Delivery E N

2

Deferred Delivery Cancellation E N

2

Delivery Notification E S

Disclosure of Other Recipients E N

3

Explicit Conversion A N

Grade of Delivery Selection E S

Multi -destination Delivery E S

Prevention of Non-delivery Notification A N

Probe E N

4

Return of Contents A N

Tbl. 13.3.3 MT optional user facilities provided to the UA

agreed for a contractual period of time

MT Optional User Facilities Categorization

Support (S) or Non-Support (N)

Alternate Recipient Assignment A N

Hold for Delivery A N/U

Implicit Conversion A N

; Essential optional user facility.

; Additional optional user facility.

A local facility subject to qualifiers in Appendix A.

Support not required for an originating MT user; support must be provided

for recipient MT users. Subject to qualifiers in Appendix A.

84
13.3.1. A IPM Service Elements and Optional User Facilities

Tables 13.3.4 through 13.3.6 show the IPM service elements and optional user

facilities

Tbl. 13.3.4 Basic IPM service elements

Service Elements

Origination

by UAs

Reception

by UAs

Access Management N/U5 N/U5

Content Type Indication S S

Converted Indication N/A S

Delivery Time Stamp 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

Does not apply to co-resident UA and MTA.

Tbl. 13.3.5 IPM optional facilities agreed for a contractual

period of time

Service Elements Categorization

Support (S) or Non-Support (N)

Alternate Recipient Assignment A N

Hold for Delivery A N

Implicit Conversion A N

85
Tbl. 13.3.6 IPM optional user facilities selectable on a per-message basis

Origination Reception

IPM Optional User Facilities by UAs 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 (N) E (S)

Deferred Delivery E (N) 6 N/A

Deferred Delivery Cancellation A (N/U) 6 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)

Multi-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)

A local facility subject to qualifiers in Appendix A.

86
13.3.2 X.400 Protocol Definitions

13.3.2.1 Introduction

This section reflects the agreements of the NBS/OSI Workshop regarding PI and

P2 protocol elements.

13.3. 2.1.1 Protocol Classification

The protocol classifications are defined:

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.

87
13.3.2.1.2 General Statements on Pragmatic Constraints

o Where a protocol element is defined as a choice of Numeric

String and Printable String (i.e., Country Name, 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.

o 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.

o 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.

o 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.

13.3.2.1.3 MPDU Size

The following agreements govern the size of MPDUs:

o All MTAEs must support at least one MPDU of at least one megabyte.

o The size of the largest MPDU supported by a UAE is a local matter.

88
13.3.2.2 PI Protocol Elements

13.3.2.2.1 PI Envelope Protocol Elements

Table 13.3.7 contains Protocol Elements and their classes.

Tbl. 13.3.7 PI protocol elements

Element Class Restrictions and Comments

MPDU

UserMPDU G

DeliveryReportMPDU G

ProbeMPDU H

UserMDPU

UMPDUEnvelope M

UMPDUContent M

UMPDUEnvelope

MPDUIdentif ier M

originator ORname M

originalEncodedlnformationTypes G

If this field is absent, then the

Encoded Information Type is

"unspecified"

ContentType M

UAContentID H Maximum length = 16 characters.

Priority G

PerMessageFlag G Maximum length = 2 octets.

deferredDelivery X

PerDomainBilaterallnfo X No limit on number of occurrences.

Recipientlnfo M Maximum number = 32K - 1 occurrences. More severe limitations are by bilateral agreement.

Tracelnformation M

UMPDUContent M

MPDUIdent i f i er GlobalDomainldentif ier M

IA5String M Maximum length = 32 characters,

graphical subset only. Refer to

T.50 for clarification of graphical

PerMessageFlag subset.

discloseRecipients H

conversionProhibited G

alternateRecipientAllowed H

contentRetumRequest X

(Continued on next page.)

89
Tbl. 13.3.7 PI protocol elements, Continued

Element Class Restrictions and Comments

PerDomainBilaterallnfo

CountryName M Maximum length = 3 characters.

AdministrationDomainName M Maximum length = 16 characters.

Bilaterallnfo M Maximum depth = 8; maximum

length = 1024 octets

(including encoding).

Recipientlnfo

recipient M

Maximum value = 32K - Extens ionldentif ier M 1 (32767).

perRec ip ientFlag M Maximum length = 2 octets.

ExplicitConversion X

perRecip ientFlag

ResponsibilityFlag H

ReportRequest M

UserReportRequest M

Tracelnformation Reference should be made to

Version 3 of the X.400 Imple-

• mentor's Guide for information

GlobaIDomainidentif ier M related to Trace sequencing.

DomainSuppliedlnfo M

DomainSupp1 iedlnf

arrival M

deferred X

action M

converted H

previous X

ORName See section 13.3.2.2.2.

EncodedlnformationTypes

bit string M Delivery can only occur if match

is made with Registered Encoded

Information Types. Individual

vendors may impose limits.

Maximum length 3 octets.

G3NonBasicParameters X

TeletexNonBasicParameters X

PresentationCapabilities X

DeliveryReportMPDU

DeliveryReportEnvelope M

DeliveryReportContent M

90
Tbl. 13.3.7 PI protocol elements. Continued

Element Class Restrictions and Comments

DeliveryReportEnvelope

report M

originator ORname M

Tracelnformation M

DeliveryReportContent

original M

intermediate G

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

Extensionsldentif ier M

PerRecipientFlag M

LastTracelnformation M

intendedRecipient H

Supplementarylnformation X Maximum length = 64 characters.

Note: This length is subject to

change. Value is pending

verification by the CCITT SG

VIII or IX.

LastTracelnformation

arrival M

converted H

Report M

Report

Deliveredlnfo G Generated if delivery is reported.

NonDeliveredlnfo G Generated if failure to deliver

is reported.

(Continued on next page.)

91
Tbl. 13.3.7 PI protocol elements, continued

Element Class

Deliveredlnfo

delivery M

typeofUA R

NonDeliveredlnfo

ReasonCode M

DiagnosticCode H

ProbeEnvelope

probe M

originator M

ContentType M

UAContentID H

original G

Tracelnformation M

PerMessageFlag G

contentLength H

PerDomainBilaterallnfo X

Recipientlnfo M

GlobalDomainldentif ier

CountryName M

AdministrationDomainName (4) M

PrivateDomainldentif ier R

Restrictions and Comments

This element must be generated with

a PRIVATE value by PRMDs.

Whenever possible, use a meaningful

diagnostic code.

Maximum length =16 characters.

If this field is absent, then the

Encoded Information Type is

"unspecified"

Maximum number = 32K - 1 occurrences .

Maximum length = 3 characters.

Maximum length = 16 characters or digits.

Maximum length = 16 characters or digits. This element must be

generated by PRMDs.

End of Definitions
13.3 .2.2.2 ORName Protocol Elements

Only form 1 variant 1 0/R names are supported.

Table 13.3.8 contains ORName protocol elements.

Tbl. 13.3.8 ORName protocol elements

Element Class Restrictions and Comments

ORName

StandardAttributeList M

DomainDef inedAttributeList X

StandardAttributeList (1)

CountryName R As defined in X.411, Maximum

length = 3 characters.

AdministrationDomainName (4) R Maximum length = 16 characters

or digits.

X121Address X Maximum length = 15 digits.

TerminallD X Maximum length = 24 characters.

PrivateDomainName (2) G Maximum length = 16 characters.

OrganizationName (2) G Maximum length = 64 characters.

Uni queUAIdenti f i er 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

punctuation and spaces.

generationQualif ier G Maximum length = 3 characters.

(Continued on next page.)

93
Tbl. 13.3.8 ORName Protocol Elements, Continued

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 ascending sequence, from the least

significant COrganizational Unit> (lowest in organization

hierarchy) to the most significant. Only those specified should

be sent. (That is, an unspecified COrganizational 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

name.

5. Many existing mail systems require attributes not present in

these agreements. Domain Defined Attributes are a method of

providing these. Failure to support the specification of DDAs

may prevent successful interworking with such existing mail

systems until such time as all mail systems are capable of

supporting delivery via the standard attribute list only.

Specific recommendations on the use of DDAs are in the

Recommended Practices section.

94
13.3.2.3 P2 Protocol Profile (Based on [X.420])

Tables 13.3.9 and 13.3.10 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.

13.3.2.3.1 P2 Protocol - Heading

Table 13.3.9 below specifies the support for protocol elements in P2 Headings.

Tbl. 13.3.9 P2 heading protocol elements

Element Class Restrictions and Comments

UAPDU

IM- UAPDU G

SR-UAPDU X

IM-UAPDU

Heading M

Body M

Heading

IPMessageld M

originator ORname R

authorizingUsers H

primaryRec ip ients G At least one of primaryRecip ients.

copyRecipients G copyRecipients, or

blindCopyRecipients H

blindCopyRecipients must be

present

inReplyTo G

obsoletes H

crossReferences H

subject G Maximum length = 256 octets; the

expiryDate H

ability to generate the maximum

size subject is not required.

replyBy H

replyToUsers H

importance H Appropriate action is for further

sensitivity H

study.

Appropriate action is for further

autoforwarded H

study.

(Continued on next page.)

95
Tbl. 13.3.9 P2 heading protocol elements, continued

Element Class Restrictions and Comments

IPmessageld

QRName H

PrintableString M Maximum length = 64 characters.

ORDescriptor

ORName H Specify the ORName whenever it is

possible. See Appendix B. freeformName H Maximum length = 64 characters,

graphical subset only (128 octets.)

telephoneNumber X Maximum length = 32 characters.

This allows for punctuation. It

does not take into account possible

future use by ISDN.

Recipient M

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 ForwardedIPMessage

BodyParts nested. Classification is

subject to pending CCITT resolution

SR-UAPBU

nonReceipt H

receipt H

reported M

actualRecipient R

intendedRecipient H

converted X

NonReceiptlnformation

reason M

nonReceiptQualif ier H

comments H Maximum length 256 characters.

returned H May only be issued if specifically

requested by originator.

(Continued on next page.)

96
Tbl. 13.3.9 P2 heading protocol elements, continued

Element Class Restrictions and Comments

Receiptlnformation

receipt M

typeOfReceipt H

SupplementaryInformation X Maximum length = 64 characters.

Note: This value is pending

verification by the CCITT SG

VIII or IX.

End of Definitions

13.3.2.3.2 P2 Protocol - BodyParts

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 section 13.4.3.2.1.

13.3.2.3.2.1 Privately Defined BodyParts

This section describes an interim means for identifying privately defined

BodyParts. This section shall be replaced in a future edition taking into

account CCITT recommendations with equivalent functionality.

BodyPart :

: = CHOICE

[0]

IMPLICIT IA5Text

,

[ 1

]

IMPLICIT TLX,

[234] IMPLICIT UKBodyParts

,

[310] IMPLICIT USABodyParts

,

] Where UKBodyParts and USABodyParts are defined as:

SEQUENCE BodyPartNumber , ANY

BodyPartNumber ::= INTEGER

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

97
EncodedlnformationTypes it registers with the MTA.

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 NBS assigns unique message

BodyPartNumbers for privately defined formats within the United States.

Implementations are required to generate and image IA5Text.

Implementations should specify the other BodyPart types supported.

If an implementation supports a particular BodyPart type for reception, it

should also be able to support that BodyPart type for reception if this is

part of a ForwardedIPMessage.

For the BodyPart types currently considered, support for the protocol elements

is as indicated in table 13.3.10.

98
13.3.2.3.2.2 P2 BodyPart Protocol Elements

Tbl. 13.3.10 P2 BodyParts

Elements Class Restrictions and Comments

BodyPart

IA5Text G

TLX X

Voice X

G3Fax X

TIFO X

TTX X

Videotex X

NationallyDef ined X

Encrypted X

ForwardedIPMessage H

SFD X

TIF1 X

IA5Text

repertoire H

IA5String M For rendition of IA5Text see Appendix C.

TLX For further study by CCITT.

Voice

Set For further study by CCITT.

BitString M

G3Fax

numberOfPages X

G3NonBasicParameters X

SEQUENCE (OF BIT STRING) M

BIT STRING H See Note.

G3NonBas icParameters Support for individual elements is

for further study.

TIFO

T. 73Document M

T. 73ProtocolElement H See Note.

(Continued on next page.)

99
Tbl. 13.3.10 P2 BodyParts, continued

Elements Class Restrictions and Comments

TTX

numberOfPages X

telexCompatible X

TeletexNonBasicParams X

SEQUENCE (of T61String) M

T61String H See Note.

TeletexNonBasicParams

graphicCharacterSets X

controlCharacterSets X

pageFormats X

miscTerminalCapabilities X

privateUse X

Videotex

SET For further study by CCITT.

Videotexstring M

NationallyDef ined

ANY M

Encrypted

SET For further study by CCITT.

BIT STRING M

ForwardedIPMessage

delivery H

DeliveryInformation H

IM-UAPDU M

De 1 iveryInformat ion

ContentType M

originator M

original M

Priority G

DeliveryFlags M

otherRecipients H

thisRecipient M

intendedRec ip ient H

converted X

submission M

(Continued on next page.)

100
Tbl. 13.3.10 P2 BodyParts, continued

Elements Class Restrictions and Comments

SFD

SFD. Document M

TIF1

T.73 Document M

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 NBS/OSI Workshop will

adopt the CCITT decision.

13.3.3 Reliable Transfer Server (RTS)

13.3.3.1 Implementation Strategy

Based on X.410 clause 3 and X.411 clause 3.5.

13.3.3.2 RTS option selection

o 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.

o Associations are established by the MTA which has messages to

transfer.

o Associations are released when they are not needed.

Associations may also be ended prematurely due to internal

problems of the RTS.

o 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:

Dialogue mode: Monologue must be supported for this

profile; two-way alternate is used only

if both partners agree.

Initial turn: Kept by the initiator of the association.

The 'priority-mechanism* and the ' transfer-time limit' are regarded as local

101
matters

13.3.3.3 RTS Protocol Options and Clarifications

Realization of the RTS protocol is subject to the following rules in addition

to those specified in X.410 clause 4:

1. 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.

2. Recovery of a Session connection is only by RTS initiator.

3. Checkpoint size:

o Checkpointing and No Checkpointing should be supported.

Whenever possible, checkpointing should be used.

o The minimum checkpoints ize is 1 (that is, 1024 octets).

4. Window size:

o Minimal value of 1 (if checkpointing is supported).

d 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.

5. APDUs should not be blocked into one activity.

6. Only one SSDU shall be transferred:

o Between two adjacent minor synch points.

o Between minor synch points and adjacent S-ACTIVITY-START

and S -ACTIVITY-END requests.

o Between S-ACTIVITY-START and S-ACTIVITY-END without

checkpoints.

102
7. A monologue association is defined as follows:

o The RTS user responsible for establishing the association

is called the initiator.

o The initiator keeps the initial turn.

o APDUs are transferred in the direction of the initiator

to the recipient only.

o There shall be no token passing.

o Only the initiator can effect an orderly release of the

association.

8. A two-way alternate session is as described in X.410.

9. In the UserData parameter of the S-TJ-ABORT, the

ReflectedParameter will not be used in the Abortlnformation

element.

10. 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.

11. When S -ACTIVITY-RESUME is used to resume an activity started in

another session connection, the following conditions must be

met:

o The current session connection is of type "recover".

o The value of OldSessionConnectionldentif ier in

S -ACTIVITY-RESUME must match the value of the

SessionConnectionldentif ier parameter used in the SCONNECT of the prior session connection. This value is

also identical to the SessionConnectionldentif ier in the

Connect ionData (in PConnect, in SS-UserData) for the

current session connection.

o This must occur as the first activity of the next

session connection for the same RTS-association. It

must be the first, otherwise [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.

103
12. 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 -ACTIVITY-DISCARD.

13. In S- TOKEN-PLEASE, the UserData parameter shall contain an integer conforming to X.409 which conveys the priority.

14. 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.

As stated in Version 3 of the X.400 Series Implementor's Guide , "On receipt of an ' unrecoverable procedure error' the current

activity is not recoverable and the sending RTS issues an SACTIVITY-DISCARD. On receipt of any other reason code (including

a nonspecific error), the sending RTS issues an

S -ACTIVITY-INTERRUPT followed by an S - ACTIVITY-RESUME.

15. In the case of S-P-ABORT, the current activity (if any) is

regarded as interrupted, rather than discarded.

16. The following table illustrates the legal negotiation

possibilities allowed by X.410 clause 4.2.1 regarding checkpoint

size and window size.

104
Tbl. 13.3.11 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 unspecif ied)

WS = i

(or unspecified)

legal legal legal

CS = k

WS = i

(or unspecified)

legal legal not allowed

Legend:

o CS means Checkpoints ize

o WS means WindowSize

o i, j, k, o, and n are integer values with the following relations:

0 < m < k < n (values assigned to CS)

0 < j < i (values assigned to WS)

o For unspecified parameters, the default applies. In this case,

the numeric relations apply, that is, the default values substitute

for the unspecified integer.

105
13.3.3.4 RTS Protocol Limitations

The RTS Protocol Limitations for this profile are listed in table 13.3.12.

Tbl. 13.3.12 RTS protocol elements

Element Class Restriction

PConnect H

DataTransferSyntax M Value = 0.

pUserData M

checkpoints ize H

windowSize H

dialogueMode H

ConnectionData M

applicationProtocol R Value = 1

Connect ionData

open G

recover G

open

RTS user data G

recover

SessionConnectionldentif ier G

RTS user data

mTAWame G Maximum length 32 characters

graphic subset of IA5 only.

password G Maximum length 64 octets

graphic subset of IA5 only.

< null RTS User Data > G Generated if other validation

methods are used.

SessionConnectionldentif ier

CallingSSUserReference M Maximum length 64 octets including

encoding = 62 octets of T.61.

CommonReference M

AdditionalReferencelnformation G Maximum length 4 octets including

encoding = 2 octets of T.61.

PAccept G

DataTransferSyntax M Value = 0.

pUserData M

checkpoints ize H

windowSize H

Connect ionData G

(Continued on next page.)

106
Tbl. 13.3.12 RTS protocol elements, continued

Element Class Restriction

PRefuse G

RefuseReason M

SS User Data G

(in S- TOKEN- PLEASE)

Abortlnformation G

(in S-U-ABORT)

AbortReason H

ref lectedParameter X Restricted to 8 bits.

End of Definitions

13.3.4 Use of Session Services

The session requirements and use of session are covered in section 8 of this

document.

13.3.5 Data Transfer Syntax

This section defines Presentation Transfer Syntax and notation rules

applicable to these agreements. Implementations must conform EXACTLY as specified in X.409 with no further restrictions. Appendix C defines rendition

of IA5 Text and T61 characters.

13.4 PRMD to ADMD and ADMD to ADMD

13.4.1 Introduction

This section 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 section 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 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

107
for interworking with any type of Management Domain (MD). Figure 13.4.1

illustrates the two roles played by an ADMD.

108
This section is presented in the form of deviations from the agreements

applicable to PRMD-to-PRMD (section 13.3.0). Unless explicitly noted in the

remainder of this section, all of the specifications for PRMD to PRMD apply to

PRMD to ADMD and ADMD to ADMD.

PRMD or ADMD

I PM - UA

/«.

MTA

\

-P2-

-PIADMD

/

IPM - UA

MTA

(a)

/N

i

i

i

i

i PI

i

i

i

i

i

i

PRMD or ADMD PRMD or ADMD

I PM - UA /V IPM - UA

MTA MTA

A\

l

l

l

I

I PI

I

l

I

l

l

l

(b)

Fig. 13.4.1 An ADMD may (b) or may not (a) serve as a relay.

109
13.4.2 Additional ADMD Functionality

The following defines the additional ADHD specific functionality required over and above that specified in the PRMD section.

1. ADMDs will relay all content types (not just P2) unchanged in the

absence of a request for conversion.

2. PI Protocol Classification Changes

The following describes the changes to the PRMD PI Protocol

classifications required for a delivering Administration Domain (with

respect to the original message; this means the domain which

originates the delivery reports).

Protocol Elements Class

DeliveryReportContent

intermediate Tracelnformation G See note 1.

Deliveredlnfo

typeOfUA

ReportedRecipientlnfo

SupplementaryInformation

GlobalDomainldentifier

PrivateDomainldentif ier

DomainSuppliedlnfo

Previous GlobalDomainldentif ier H Required for loop detection.

For relaying administration domains, the clasif ications are all "X".

For originating administration domains, these are all "NOT APPLICABLE".

Note 1: If the intermediate trace information is requested by a domain other

than the originating domain, return of the desired information cannot be

assured, as the return path of the delivery report may be different from the

original message and may exclude that domain.

Note 2: 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.

3, 0/R Names

0/R Names shall consist of:

H

H See note 2.

H

110
CountryName

AdministrationDomainName

as well as one of the following:

PrivateDomainName

PersonalName

OrganizationName

OrganizationalUnit

Uni queUAIdent i f i er X121Address

and permits the optional inclusion of a

DomainDefinedAttributeList

Note that 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.

PI Originator Name

Management Domains (MDs) must specify in the ADMD name field of the Q/R

Name StandardAttributeList in PI, the name of the administration domain:

o to which the message is being sent (in recipient names)

o from which the message originated (in the originator name).

13.4.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:

OrganizationName

OrganizationalUnit

PersonalName

and may optionally include a

DomainDef inedAttributeList

13.4.4 Differences with other Prof iles

13.4.4.1 NTT Profile

There are no outstanding issues regarding interworking between NTT-conformant

systems and NBS- conformant systems with the exception of the number of

111
recipients. The Extensionldentif ier field may contain a maximum value of

32K-1; however, according to the current NTT profile, if a message with more

than 256 recipients is received, the NTT-conformant domain will generate a nondelivery notification. This also applies to the ReportedRecipientlnfo in a delivery report.

13.4.4.2 CEPT Profile

For further study.

13.4.5 Connection of PRMDs to Multiple ADMDs

Given that Management Domain names (both PRMD and ADMD) shall be unique within

the U.S., 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:

o Naming

o Routing

o Replying.

13.4.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.

If 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.

13.4.7 Management 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.

13.4.8 Envelope Validation Errors

112
For validation errors, a non-delivery notice shall be generated (if possible)

with reason code of 'unableToTransfer ' and diagnostic code of

' invalidParameters 1 (unless specified otherwise).

ADMDs will validate PI Envelopes in the following areas:

o The X.409 syntax of all elements should be checked.

o The pragmatic constraint limits (lengths of fields and number of

occurrences of fields) should be checked.

o Semantic validation of the following elements should be done:

originator 0/R Name

recipient 0/R Name in the Recipientlnfo

priority

Only recipient Names with the responsibility flag set should be

validated. The validation of 0/R names is defined in 13.5.3.3; the

validation of priority is defined in 13.5.3.6.1.

o MPDU Identifier Validation

Validation of the GlobalDomainldentif ier component of the MPDU Identifier

is performaed upon reception of a message (i.e., as a result of a TRANSFER. Indication)

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.

Additional validation of the GlobalDomainldentif ier is performed against

the corresponding first entry in the Tracelnformation. If

inconsistencies are found during the comparison, a non-delivery notice

with the above defined reason and diagnostic codes is generated.

A request will be generated to the CCITT for a more meaningful diagnostic

code (such as ' InconsistentMPDUIdentif ier 1 )

13.4.9 Quality of Service

13.4.9.1 Domain Availability

13.4.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 to maintenance windows in

its supporting network or in an MTA within the domain.

13.4.9.1.2 PRMD Availability

Although the goal of PRMD availability is also 24 hours per day, business

113
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.

13.4.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.

The following delivery time targets are established:

Delivery Class 95% Delivered Before

Urgent 3/4 hour

Normal 4 hours

Non-Urgent 24 hours

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 as follows. This implies that, after

these times, a Non-Delivery Notice will be generated.

Delivery Class NonDelivery Forced After

Urgent 4 hours

Normal 24 hours

Non-Urgent 36 hours

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 adminstration domain. Transit time within PRMDs in NOT included

in the above times.

13.4.10 Billing Information

All aspects relating to billing, charging, tariffs, and 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.

13.4.11 Transparency

No PI extensions are to be allowed. 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 code of

invalidParameters

The CCITT has been requested to establish a more meaningful diagnostic code

114
(such as protocolError ) for this occurrence.

P2 extensions shall be relayed transparently by ADMDs.

13.4.12 For Further Study

Issues requiring further study are:

o RTS Password Management

o Intra-Domain Routing

o Multi -Vendor Domains

13.5 ERROR REPORTING

This section 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.

13.5.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.

13.5.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 ensures that the P2 content of the

message is okay. As a result, the handling of content errors is a local

matter

13.5.3 Envelope

13.5.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

invalidParameters . Note: it would be desirable for the CCITT to add a DiagnosticCode of pragmaticConstraintViolation to allow a more meaningful

description of this problem. A request for this new DiagnosticCode has been

submitted.

13.5.3.2 Protocol Violations

If not all required protocol elements are present, a nondelivery report with a ReasonCode of unableToTransfer and a DiagnosticCode of invalidParameters

should be generated. Note: it would be desirable for the CCITT to add a DiagnosticCode of protocolViolation to allow a more meaningful description of

this problem. A request for this new DiagonsticCode has been submitted.

115
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 invalidParameters should be generated. Note: it would be

desirable for the CCITT to add a DiagnosticCode of protocolViolation to allow

a more meaningful description of this problem. A request for this new DiagnosticCode has been submitted.

13.5.3.3 Q/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 domain 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: unrecognizedORName, ambiguousORName, and

uaUnavailable.

13.5.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 Tracelnformat ion, that is, arrival time and converted

EncodedlnformationTypes can be provided to the UA without inspection by the

MTAs of the domain as long as the Tracelnformation is properly encoded

according to X.409.

Loop detection in a relaying domain occurs as a message leaves a domain. If

the subsequent domain already appears in the Trace Information and does not

appear in a "previous" field of a trace information element with a "rerouted"

indication, a loop has occurred. A non-delivery notice should be generated

with reason code of 'unableToTransfer' and diagnostic code of ' loopDetected '

CCITT Study Group VII will address this in its October 1986 meeting.

Note that a domain may insert several instances of Trace information into a message. The first must be a "relayed" indication. Additional entries shall

only be of type "rerouted" and must contain the "previous"

GlobalDomainldentif ier . The "previous" field indicates that domain to which

delivery was previously attempted (and not, as might be inferred from the

name, the domain which relayed the message prior to this relaying domain). If

116
this is not the case, a non-delivery notice shall be returned with a reason

code of 'unableToTransfer 1 and a diagnostic code of ' invalidParameters 1 .

A request shall be made to CCITT for a more meaningful diagnostic code (such

as ' invalidTracelnformation 1 )

13.5.3.5 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.

13.5.3.5.1 deferredDelivery

The domain shall do one of the following:

o deliver at once,

o hold for deferred delivery,

o return a nondelivery notification with a ReasonCode of

unableToTransfer

Note: It would be desirable for the CCITT to add a diagnostic code of

noBilateralAgreement to allow a more meaningful description of this

problem. A request for this new diagnostic code has been submitted.

13. 5. 3. 5 .2 PerDomainBilaterallnfo

If a domain receives this service element, the service element can be ignored,

and the message should be delivered if possible.

13.5.3.5.3 ExplicitConversion

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 domain could not perform the requested conversion. If

delivery is not possible, then a nondelivery report should be generated with a ReasonCode of conversionNotPerformed with no DiagnosticCode.

13.5.3.5.4 alternateRecipientAllowed

If a domain receives this service element the service element can be ignored,

and this message should be delivered if possible.

13.5.3.5.5 contentReturnRequest

If a domain receives this service element, the service element can be ignored,

and the message should be delivered if possible.

117
13.5.3.6 Unexpected Values for INTEGER Protocol Elements

There are three INTEGERS in the PI Envelope. Appropriate actions are described below for domains receiving unexpected values for Priority,

ExplicitConversion, and ContentType.

13.5.3.6.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 domain 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 domain

can either generate a nondelivery report as previously specified or default

the Priority to normal and deliver the message.

13.5.3.6.2 ExplicitConversion

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 domain could not perform the requested

conversion. If delivery is not possible, then a nondelivery report should be

generated with a ReasonCode of conversionNotPerformed with no DiagnosticCode.

13.5.3.6.3 ContentType

If the ContentType is not supported, then a nondelivery report should be

generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of

invalidParameters. Note: it would be desirable for the CGITT to add a DiagnosticCode of contentTypeNotSupported to allow a more meaningful

description of this problem. A request for this new DiagnosticCode has been

submitted.

13.5.3.7 Additional Service Elements

In the absence of bilateral 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.

13.5.4 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

13.6 MHS USE OF DIRECTORY SERVICES

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

118
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.

o Verify the existence of an 0/R name.

o Return the 0/R address that corresponds to the 0/R name presented,

o Determine whether the 0/R name presented denotes a user or a distribution list.

o Return a list of the members of a distribution list.

o When given a partial name, return a list of 0/R name possibilities.

o Allow users to scan directory entries.

o Allow users to scan directory entries selectively.

o Return the capabilities of the entity referred to by the 0/R name.

o 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,

expandability, 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 OSI based applications.

Given the incomplete nature of the ongoing activities within the CCITT and the

ISO, no implementation 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.

It is recognized that these agreements enable a wide variety of naming and

addressing attributes (see section 13.3.5.3.3 ORName Protocol Elements)

wherein each PRMD may adopt particular routing schemes within its domain.

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:

o manual directories

o on-line directories

o ORName address specifications

o 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

section 13.3.4.2.2 herein. 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 form, via the

X.400 ORName attributes of these agreements, is outside the scope of these

agreements

119
13.7 CONFORMANCE

In order to ensure that products conform to these implementation agreements,

it is necessary to define the types and degrees of conformance testing

products that must pass before they may be classified as conformant . This

section defines the conformance requirements and provides guidelines for the

interpretation of the results from this type of testing.

In order to achieve a minimum level of confidence in the conformance of a product, the most basic requirements a product must meet to be classified as conformant to these agreements are provided. This minimal set was defined to

ensure that the resulting MHS network will provide a reasonable interpersonal messaging facility to its users while still giving a reasonable

assurance that conforming products can soon be made available. In addition,

the full conformance requirements for products implementing all aspects of

X.400 Messaging governed by these agreements are provided.

This section 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.

13 .7.1 Definition of Conformance

For this section, the term conformance is defined by the following:

o The tests indicated for this section are intended to establish a high degree of confidence in a statement that the implementation

under test (IUT) conforms (or does not conform ) to the

agreements of this section.

o 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):

o causes appropriate information to be displayed, or

o causes appropriate information to be obtained.

o Conformance to PI, P2, and RTS as part of an X.400 OSI

application requires that only the external behavior of that OSI

system adheres to the relevant protocol standards.

In order to achieve conformance to this section, it is not

required that the inter-layer interfaces be available for

testing purposes.

120
o Conformance to the protocols requires:

o that MPDUs correspond to instances of syntactically correct

data units,

o 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,

correct sequences of protocol data units in responses

(resulting from protocol procedures).

o Statements regarding the conformance of any one implementation

to this profile are not complete unless a Protocol

Implementation Conformance Statement (PICS) is supplied.

o The term "Implementation Under Test" (IUT) is interchangeable

with the term "system" in the definition of conformance , and

may refer to:

o a domain, which may be one or more MTA's with co-located or remote UA's,

o a single instance of an MTA and co-located UA with X.400

(PI, P2, RTS and session) software,

o a relaying product with PI, RTS and session software,

o a gateway product.

o Tests for conformance apply independently to:

o origination,

o reception,

o relaying.

13.7.2 Conformance Requirements

Conformance to this specification requires that all the services listed as supported in sections 13.3 and 13.4 of these agreements are supported in the

manner defined, in either the CCITT X.400 Recommendations or 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 1988.

13.7.2.1 Initial Conformance

121
This section 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 interworking capabilities. It is equally feasible

that for purposes of testing interoperability, only a subset of this

specification will initially be tested. Therefore it is recommended that the

following subset of total information be made accessible to allow for

meaningful testing.

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 sections.

13.7.2.1.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 their classifications (i.e., X, H, G, R, and M). For an origination

system, this implies that the protocol elements generated must be correct.

For a relay system, the correct protocol elements should be relayed as appropriate. And for a recipient system, a message with correct protocol

elements must not be rejected where appropriate.

13.7.2.1.2 Service

For information available to the recipients via the IPMessage Heading and

Body, the following should be made accessible:

o IPMessage ID - only the PrintableString portion of the IPMessageld

needs to be accessible.

o subject

o primaryRecipients

o copyRecipients

o blindCopyRecipients

o authorizingUsers

o originator

o inReplyTo

122
o replyToUsers

o importance

o sensitivity

o IA5Text BodyPart
14. DIRECTORY SERVICES PROTOCOLS

To be competed.

124
15. VIRTUAL TERMINAL PROTOCOL

To be completed.

125
16. OFFICE DOCUMENT ARCHITECTURE AND INTERCHANGE FORMAT

To be completed.

126
17. PERFORMANCE

To be completed.

127
18. SECURITY

To be completed.

128
REFERENCES

NBS

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

Collision Detection Access Method and Physical Layer Specifications and Link

Layer Protocol, NTIS, U.S. Department of Commerce, 5285 Port Royal Road,

Springfield, VA 22161.

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.

ICST/SNA-85-10, Implementation Agreements Among Participants of OSINET, edited

by Jerry Mulvenna, National Bureau of Standards.

IEEE

IEEE Project 802, Local Area Network Standards, P802.2 Logical Link Control,

November, 1982.

IEEE Project 802, Local Area Network Standards, IEEE Standard 802.4, Token - Passing Bus Access Method and Physical Layer Specification.

IEEE Project 802, Local Area Network Standards, IEEE Standard 802.3, CSMA/CD

Access Method and Physical Layer Specification.

Binary Floating Point Arithmetic (ANSI Approved), IEEE 754, March 21, 1985,

Institute of Electrical and Electronics Engineers.

The above documents may be obtained from: IEEE Standards Office, 345 East 47th

Street, New York, N.Y. 10017.

IEC

Binary Floating Point Arithmetic for Microprocessor Systems, IEC 559, First

Edition, International Electrotechnical Commission, June 20,1982.

ISO

Addendum to DIS 8473 Covering Provision of the Connectionless-Mode Subnetwork

Service, ISO/TC97/SC 6/N3453.

Network Service Definition, DIS 8348, ISO/TC97/SC6 N2990.

Addendum to the Network Service Definition Covering Connectionless Data

Transmission, DIS 8348 DAD1, N3152.

Addendum to the Network Service Definition Covering Network Layer Addressing,

DP 8348 DAD2, N3134.

129
Internal Organization of the NetworkLayer , WD, N3141.

Protocol for Providing the Connectionless Network Service, DIS 8473, N3154.

Information Processing Systems - Open Systems Interconnection - Transport

Service Definition, ISO IS8072, 1984.

Information Processing Systems - Open Systems Interconnection - Transport

Protocol Specification, ISO IS8073, 1984.

Information Processing Systems - Open Systems Interconnection - Session

Service Definition, ISO DIS8326, 1984.

Information Processing Systems - Open Systems Interconnection - Session

Protocol Specification, ISO DIS8327, 1984.

Information Processing Systems - Open Systems Interconnection - File

Transfer Access and Management Part 1: General Description, ISO DP8571/1,

TC97/SC16 N 1669, February 1984.

Information Processing Systems - Open Systems Interconnection - File

Transfer Access and Management Part II: The Virtual Filestore, ISO DP 8571/2,

TC97/SC16 N1670, February 1984.

Information Processing Systems - Open Systems Interconnection - File

Transfer Access and Management Part III: Service Definition, ISO DP8571/3,

TC97/SC16 N1671, February 1984.

Information Processing Systems - Open Systems Interconnection - File

Transfer Access and Management Part IV: Protocol Specification, ISO DP85/1/4,

TC97/SC16 N1672, February 1984.

Data Communication - X.25 Packet Layer Specification for Data Terminal

Equipment, ISO/TC 97/SC 6 N 2641, ISO/DP 8208, 1983.

7-bit Coded Character Set for Information Processing Interchange, ISO-646,

1973.

Information Interchange- -Representation of Local Time Differentials, ISO-3307,

1975.

Draft Network Layer Management Protocol for the exchange of routing

information between end systems and intermediate systems ISO/TC97/SC6/ 3862

January 1986.

Information Processing Systems - Open Systems Interconnection

Transfer, Access and Management Part I: General Description, ISO DIS8571/1,

TC97/SC21 N2371 , August 1986.

Information Processing Systems - Open

Transfer, Access and Management Part II:

130

Systems Interconnection - File

The Virtual ISO DIS8571/2, TC97/SC21
N2372, August 1986.

Information Processing Systems - Open Systems Interconnection - File

Transfer, Access and Management Part III: File Service Definition, ISO

DIS8571/3 , TC97/SC21 N2373, August 1986.

Information Processing Systems - Open Systems Interconnection - File Transfer,

Access and management Part IV: File Protocol Specification, ISO DIS8571/4,

TC97/SC21 N2374, August 1986.

Information Processing Systems - Open Systems Interconnection

Connection-Oriented Presentation Service Definition, ISO DIS8822, TC97/SC21

N1594, May 1986.

Information Processing Systems - Open Systems Interconnection

Connection-Oriented Presention Protocol Specification, ISO DIS8823, TC97/SC21

N1594, May 1986.

Information Processing Systems - Open Systems Interconnection - Service

Definition for Common Application Service Elements - Part 2: Association

Control, ISO DIS8649/2, TC97/SC21 N1493, May 1986.

Information Processing Systems - Open Systems Interconnection - Protocol

Specification for Common Service Elements Part 2: Association Control,

ISO DIS8650/2, TC97/SC21 N1494, May 1986.

Information Processing Systems - Open Systems Interconnection - Specification

of Abstract Syntax Notation One (ASN.l), DIS 8824, Oct., 1985.

Information Processing Systems - Open Systems Interconnection - Specification

of Basic Encoding Rules for Abstract Syntax Notation One (ASN.l), DIS 8825,

Oct., 1985.

The above documents may be obtained from:

Frances E. Schrotter

ANSI

ISO TC97/SC6 Secretariat

1430 Broadway

New York, N.Y. 10018

CCITT

X.25 Interface Between Data Terminal Equipment (DTE) and Data

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

on Public Data Networks.

X.400 (Red Book, 1984), Message Handling Systems: System Model-Service

Elements

131
X.401 (Red Book, 1984), Message Handling Systems: Basic Service Elements and

Optional User Facilities.

X.408 (Red Book, 1984), Message Handling Systems: Encoded Information Type

Conversion Rules.

X.409 (Red Book, 1984), Message Handling Systems: Presentation Transfer Syntax

and Notation.

X.410 (Red Book, 1984), Message Handling Systems: Remote Operations and

Reliable Transfer Server.

X.411 (Red Book, 1984), Message Handling Systems: Message Transfer Layer.

X.42Q (Red Book, 1984), Message Handling Systems: Interpersonal Messaging User

Agent Layer.

X.430 (Red Book, 1984), Message Handling Systems: Access Protocol for Teletex

Terminals

X.214 (Red Book, 1984), Transport Service Definition for Open Systems

Interconnection for CCCITT Applications.

X.224 (Red Book, 1984), Transport Protocol Specification for Open Systems

Interconnection for CCITT Applications.

X.215 (Red Book, 1984), Session Service Definition for Open Systems

Interconnection for CCITT Applications.

X.225 (Red Book, 1984), Session Protocol Specification for Open Systems

Interconnection for CCITT Applications.

X.400 - Series Implementor's Guide (Version 3, 1986).

The above documents may be obtained from: International Telecommunications

Union, Place des Nations, CH 1211, Geneve 20 SWITZERLAND.

Miscellaneous

[Edge 84] S. W. Edge, An Adaptive Timeout Algorithum for Retransmission

Across a Packet Switching Network, ACM Computer Communications Review, Vol.

14, No. 2, June 1984.

[Jain 85] R. Jain, Divergence of Timeout Algorithms for Packet

Retransmission, Proceedings IEEE Computer Communications Conference, Phoenix

March 28-29, 1986.

132
[Mill 83] D. L. Mills, Internet Delay Experiments, DARPA Network Working

Group REC #889, December 1983.

133
APPENDIX A: INTERPRETATION OF SERVICE ELEMENTS

The work on service element definitions is limited to those that are defined

as 'supported' in section 13.3 of this specification. Furthermore it is not

the intent of this section 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 service should be defined in the

sections 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.

SERVICE ELEMENTS

The following Service 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 section are as defined in X.400.

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.

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.411.

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.

134
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 autoforwarded 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.

Registered Encoded Information Types

A UMPDU with an 'unspecif ied' value for Original Encoded Information Type

shall be delivered to the UA.

Delivery Notification

The UAContentID may be used by the recipient of the delivery notification for

correlation purposes.

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 PI 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.

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.

Blind Copy Recipient Indication

135
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.

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.

Primary and Copy Recipients Indication

It is required that at least one primary recipient be specified; however, for

a forwarded 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.

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 personal message may be printed on a shared printer.

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.

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.

Forwarded IP message Indication

The following use of the original encoded information type in the context

of forwarded messages is clarified:

136
o If forwarding a private message body part the originator of the

forwarded message shall set the original encoded information

types in the PI envelope to undefined for that body part.

o The encoded information types of the message being forwarded

should be reflected in the new original encoded information

types being generated.

o See Appendix B on recommended practices for the use of the

delivery information as part of Forwarded IP-message.

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 IAS body parts, each one representing a paragraph of text.

137
APPENDIX B: RECOMMENDED PRACTICES

B.l RECOMMENDED PRACTICES IN P2

1 . ORDescriptor

Vendors following the NBS/OSI Workshop guidelines shall,

whenever possible, generate the ORName portion of an ORDescriptor in ALL IPM heading fields.

2 . ForwardedIPMessage BodyParts

ForwardedIPMessage BodyParts should be nested no deeper than

eight. There is no restriction on the number of

ForwardedIPMessage BodyParts at any given depth.

3. DeliveryInformation

It is strongly recommended that DeliveryInformation be supplied

in both forwarded and autoforwarded message body parts.

Deliverylnformation is useful when a message has multiple

forwarded message body parts because without it, the

EncodedlnformationType(s) of the component forwarded messages

cannot be deduced easily. Deliverylnformation 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

1. 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 five minutes).

In instances where this delay is not required or necessary,

report a localSystemProblem.

138
2.

S-U- EXCEPTION-REPORT reason codes can be interpreted as follows:

o receiving ability jeopardized (value 1)

Possible meaning: The receiving RTS knows of an impending system shutdown.

o local ss-User error (value 5)

Possible meaning: <for further study>.

o irrecoverable procedure error (value 6)

Possible meaning: the current activity is NOT

recoverable.

o non specific error (value 0)

Possible meaning: <for further study>.

o sequence error (value 3): The S -ACTIVITY-RESUME

request specified a minor synchronization point serial

number which does not match the checkpoint data.

B. 3 RECOMMENDED PRACTICES WITH X.409

The following practices are recommended for use with X.409.

1. The maximum length of a primitive data element is 256.

2. Bit Strings should be built using primitive form. The

constructor form should not be used except in the case of very

long Bit Strings (e.g., 63Fax or Voice).

3. All defined bits of a Bit String should be present.

o Note that, in accordance with X.409, defined bits need

not be present; missing bits are assumed to be zero.

o To ensure upward compatibility. Bit Strings of excess

length must also be allowed; the excess bits are ignored.

4.

The maximum definite length should be (2**32)-l. <For further

study>

139
5. It is intended that implementations support upwardly compatible

changes to X.409, as defined in Version 3 of the X. 400-Series

Implementor's Guide, but no guarantees will be made about

initial implementations.

6. The concrete encoding of ANY must be a valid X.409 type, and can only be omitted if it is an OPTIONAL element in a SET or SEQUENCE.

B.4 RECOMMENDED PRACTICES FOR ORName

Table 13.3.8 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 DomainDef inedAttribute to be used in

addresing UAs in existing mail systems, in order to curtail the proliferation

of different types of DomainDef inedAttributes used for the same purpose. The

syntax of this DomainDef inedAttribute 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 DomainDef inedAttribute has the type name "ID" (in uppercase). It

contains the unique identifier of the UA used in addressing within the domain.

This DomainDef inedAttribute 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.

140
APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS

C.l GENERATING AND IMAGING IA5Text

The characters that may be used in an IA5String are the graphic characters

(including Space), control 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.

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

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 have no guaranteed effect.

The character Delete may occur but has no guaranteed effect. The IA5String in

a P2 IA5Text 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 T61String

For further study.

141
APPENDIX D: FTAM DOCUMENT TYPES

Part 1 Part 2

Part 3

Part 4

Document Types

Constraint Sets

Abstract Syntaxes

Transfer Syntaxes

142
Part 1 : Document Types

Entry number : NBS-1

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) UNDEF(O)}

Document Descriptor Value: unstructured binary file

Document Semantics:

The document consists of a single data unit. The data unit consists of an unbounded sequence of data elements. Each data element is is an octet string.

Note: The boundaries between transferred data elements are not maintained by

the filestore.

Scope and Field of Application:

This document type defines the contents of a file for storage and for

transfer using FTAM.

Constraint Set Name:

{ISO standard 8571 constraint set name(5) unstructured( 1 )

}

Abstract Syntax:

The abstract syntax of each Data Element is an instance of the ASN.l data type

Octetstring.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO x825) to the data element and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting

Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

143
Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Concatenation

Concatenation of this type with itself is possible, and produces a document

of the same type consisting of one data unit which is the concatenation of

the octet string(s) from one file with the octet string(s) of the other file.

Note: The boundary of the original octet string(s) is no longer visible.

Simplifications:

A document of this type cannot be accessed as any other document type.

144
Entry Number : NBS-2

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) VARCRLF(l)}

Document Descriptor Value: unstructured text file

Document Semantics:

The document consists of a single data unit. The data unit consists of an unbounded sequence of data elements. Each data element is an IASString. The

last two characters of each data element are carriage return followed by line

feed. Neither the character carriage return nor the character line feed may

appear elsewhere in the data element.

Note: The boundaries between transferred data elements are not maintained by

the filestore.

Scope and Field of Application:

The document type defines the contents of a file for transfer using FTAM.

Note that this document type should only be used for transferring entire text

files in. the case where NBS-4 is not supported. It has an implicit structure

which allows, for example, text files stored in UNIX format (lines terminated

by LF) to be converted to a format in which lines are terminated -by CR

followed by LF and vice versa.

Constraint Set Name:

{ISO standard 8571 constraint set name(5) unstructured( 1 )

}

Abstract Syntax:

The abstract syntax of each Data Element is an instance of the ASN.l data type

IA5String.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data element and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting.

145
Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name;

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Concatenation:

Concatenation of this type with itself is possible, and produces a document of

the same type consisting of one data unit which is the concatenation of the

octet string(s) from one file with the octet string(s) of the other file.

Note: The boundary of the original octet string(s) is no longer visible.

Simplification:

A document of this type can be accessed as a document of type NBS-1 by

specifying a document type of NBS-1 in the Contents Type parameter of the FOPEN request, and limiting access context to US on F-READ.

146
Entry Number : NBS-3

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) 8859VARCRLF( 2)

}

Document Descriptor Value: unstructured text file

Document Semantics:

The document consists of a single data unit. The data unit consists of an unbounded sequence of data elements. Each data element is an 8859String. The

last two characters of each data element are carriage return followed by line

feed. Neither the character carriage return nor the character line feed may

appear elsewhere in the data element.

Note: The boundaries between transferred data elements are not maintained by

the filestore.

Scope and Field of Application:

The document type defines the contents of a file for transfer using FTAM.

Note that this document type should only be used for transferring entire text

files in the case where NBS-5 is not supported. It has an implicit structure

which allows, for example, text files stored in UNIX format (lines terminated

by LF) to be converted to a format in which lines are terminated by CR

followed by LF and vice versa.

Constraint Set Name:

{ISO standard 8571 constraint set name(5) unstructured( 1 )

}

Abstract Syntax:

The abstract syntax of each data element is an instance of the data type

8859String.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data elements and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting

147
Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TS1 (0)}

Concatenation

Concatenation of a document of this type with another document of this type is

possible and produces a document of the same type consisting of one data unit

which is the concatenation of the octetstring(s) of one file with the

octetstring(s) of the other file.

Note: The boundary of the original Octetstring is no longer visible.

Simplification:

A document of type NBS -3 can be accessed as a document of type NBS-1 by

specifying a document type of NBS-1 in the Contents Type parameter of the FOPENrequest, and limiting access context to US on F-READ.

148
Entry number : NBS-4

Document type name:

{ISO registration-authority NBS FTAM( ) document(6) Text(3) parameter}

Note: "parameter" is a parameter which will be appended to the registered

identifier in an OBJECT IDENTIFIER.

Document Descriptor Value: Sequential Text File

Document Semantics:

The document consists of an unbounded series of data units. Each data unit

contains one data element which is a character string. Each character is

taken from the IA5 character set.

Scope and Field of Application:

The document type defines the contents of a file for storage and for

transfer using FTAM.

Note: Storage refers to apparent storage within the virtual filestore.

Constraint Set Name:

{ISO standard 8571 constraint set name(5) sequential flat(2)}

Additional Constraints:

FADU Identity will be limited to begin, end, first and next.

Abstract Syntax:

The abstract syntax of each data element is an instance of the data type

IA5String.

The abstract syntax of each data unit is specified by the parameter.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data elements and concatenating the resulting octects.

Note: This transfer syntax is not self -delimiting

149
Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Concatenation

Concatenation of a document of this type with another document of this type is

possible and produces a document of the same type consisting of a series of

IA5Strings which is the result of placing the series of IA5Strings from one file of this type after the last IA5String in the original file.

Note: The boundary of the original sequence is no longer visible.

Simplification:

A document of type NBS-4 can be accessed as a document of type NBS-1 by

specifying a document type of NBS-1 in the Contents Type parameter on the FOPENrequest, and limiting access context to UA on F-READ.

150
Entry number: NBS-5

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) 8859Text(4) parameter}

Note: "parameter" is a parameter which will be appended to the

registered identifier in an Object Identifier.

Document Descriptor Value: Sequential Text File

Document Semantics:

The document consists of an unbounded series of data units. Each data unit

contains one data element which is a character string. Each character is

taken from the ISO 8859/1 character set.

Scope and Field of Application:

The document type defines the contents of a file for storage and transfer

using FTAM.

Note: Storage refers to apparent storage within the virtual filestore.

Constraint Set Name:

{ISO standard 8571 constraint set name(5) sequential flat (2)}

Additional Constraints:

FADU Identity will be limited to begin, end, first and next.

Abstract Syntax:

The abstract syntax of each data element is an instance of the data type

8859String.

The abstract syntax of each data unit is specified by the parameter.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data elements and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting

151
Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TS1 (0)}

Concatenation

Concatenation of a document of this type with another document of this type is

possible and produces a document of the same type consisting of a series of

8859Strings which is the result of placing the series of 8859Strings from one file immediately following the last 8859String in the original file.

Note: The boundary of the original series is no longer visible.

Simplification:

A document of type NBS-5 can be accessed as a document of type NBS- 1 by

specifying a document type of NBS-1 in the Contents Type parameter on FOPENrequest, and limiting access context to UA on F-READ.

152
Entry Number ; NBS-6

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) SEQUENTIAL(5) parameter}

Note: "parameter" is a parameter which will be appended to the registered

identifier in an Object Identifier.

Document Descriptor Value: Sequential File

Document Semantics:

The document consists of an unbounded series of data units. Each data unit

contains an unbounded series of data elements. Each data element is a data

type from the set of primitive data types defined in the main body of this

document. Each data unit contains the same data element types in the same order as all other data units.

Scope and Field of Application:

The document type defines the contents of a file for storage and transfer

using FTAM.

Note: Storage refers to apparent storage within the virtual filestore.

Constraint Set Name:

{ISO standard 8571 constraint set name(5) sequential flat(2)}

Additional Constraints:

FADU Identity will be limited to begin, end, first, and next.

Abstract Syntax:

The abstract syntax of each data element is an instance of one of the

primitive data types defined in the main body of this document.

The Abstract syntax of each data unit is specified by the parameter.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

optionally, {ISO registration-authority NBS FTAM( ) abstract syntax(2)

NBS-AS2( 1 )

}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

153
syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data elements and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting.

Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

(ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Concatenation

Concatenation of a document of this type with another document of this type is

possible and produces a document of the same type consisting of a series of

data units which is the result of placing the series of data units from one file immediately following the last data unit of the original file.

Note: The boundary of the original file is no longer visible.

Simplification:

A document of type NBS-6 can be accessed as a document of type NBS-1 by

specifying a document type of NBS-1 in the Contents Type parameter in the FOPENrequest, and limiting access context to UA on F-READ.

154
Entrv number: NBS-7

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) RAND0M(6) parameter}

Note: "parameter" is a parameter which will be appended to the registered

identifier in an Object Identifier.

Document Descriptor Value: Random Access File

Document Semantics

The document consists of an unbounded series of data units. Each data unit

contains an unbounded series of data elements. Each data element is a data

type from the set of primitive data types defined in the main body of this

document. Each data unit contains the same data types in the same order as all

other data units in the file.

Scope and Field of Application:

The document type defines the contents of a file for storage and transfer

using FTAM.

Note: Storage refers to apparent storage within the virtual filestore.

Constraint Set Name:

{ISO registration-authority NBS FTAM( ) constraint set name(5)

NBS Ordered Flat(2)}

Abstract Syntax:

The abstract syntax of each data element is an instance of one of the

primitive data types defined in the main body of this document.

The abstract syntax of each data unit is specified by the parameter.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

optionally, {ISO registration-authority NBS FTAM( ) abstract svntax(2) NBSAS2( 1 )

}

Transfer Syntax:

An implementation supporting this abstract syntax shall support a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data element and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting

155
Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Concatenation

Concatenation of a document of this type with another document of this type is

possible and produces a document of the same type consisting of a series of

data units which is the result of placing the series of data units from one file immediately following the last data unit of the original file.

Note: The boundary of the original file is no longer visible.

Simplification:

A document of type NBS-7 can be accessed as a document of type NBS-1 by

specifying a document type of NBS-1 in the Contents Type parameter of the FOPENrequest, and limiting access context to UA on F-READ.

A document of type NBS-7 can be accessed as a document of type NBS-6 by

specifying a document type of NBS-6 in the Contents Type parameter of the FOPENrequest.

156
Entry Number : NBS-8

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) INDEXED(7) pi p2}

Note: "pi" and "p2" are parameters which will be appended to the registered

identifer in an Object Identifier.

Document Descriptor Value: Indexed Sequential File

Document Semantics:

The document consists of an unbounded series of data units. Each data unit is an unbounded series of data elements. Each data element is a data type from

the set of primitive data types defined in the main body of this document.

Each data unit contains the same data types in the same order as all other

data units in the file.

Each data unit in the file has a key associated with it. 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

the main body of this document.

The primitive data types and minimum size range of each unit which an implementation must accept as a key value are given in the following table.

Key Type Minimum Range (octets)

ASN.l General izedTime

ASN.l UniversalTime

NBS-AS2 Floatingpoint

Scope and Field of Application:

The document type defines the contents of a file for storage and for transfer

using FTAM.

Constraint Set Name:

{ISO registration-authority NBS FTAM( ) constraint set name(2)

Abstract Syntax:

The abstract syntax of each data element is an instance of one of the

primitive data types defined in the main body of this document.

ASN.l Integer

ANS.l IA5String

NBS -AS 1 8859String

ASN.l OctetString

(1-2)

(0-16)

(0-16)

(0-16)

Indexed Flat(l)}

157
The Abstract syntax of each data unit is specified by the parameter pi.

The Abstract syntax of the data unit key (FADU Identifier) is specified by the

parameter p2.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2) NBS-ASl(O)}

optionally, {ISO registration-authority NBS FTAM( ) abstract syntax(2)

NBS-AS2(1)>

Transfer Syntax:

An implementation supporting this abstract syntax shall suport a transfer

syntax for each data element obtained by applying the ASN.l Basic Encoding

Rules (ISO 8825) to the data elements and concatenating the resulting octets.

Note: This transfer syntax is not self -delimiting .

Implementations may optionally support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax( 3 ) NBS-TSl(O)}

Concatenation

A document of this type may not be concatenated with a document of this type

or any other type.

Simplification:

A document of type NBS-8 can be accessed as a document of type NBS-1 by

specifying document type NBS-1 in the Contents Type parameter on the FOPENrequest, and limiting access context to UA on F-READ.

A document of type NBS-8 can be accessed as a document of type NBS -6 by

specifying document type NBS-6 in the Contents Type parameter on the FOPENrequest.

A document of type NBS-8 can be accessed as a document of type NBS- 7 bv

specifying document type NBS-7 in the Contents Type parameter on the F- OPENrequest

158
Entry Number: NBS-9

Document Type Name:

{ISO registration-authority NBS FTAM( ) document(6) FILE_DIRECT0RY(8)}

Document Descriptor Value: FileDirectory File

Document Semantics:

The document consists of an unbounded sequence of data units. Each data unit

consists of one and only one data element of type FileDirectoryEntry (a

complex data type defined in the main body of this document).

Scope and Field of Application:

This document defines the contents of a file for transfer (not for storage)

using FTAM.

Constraint Set Name:

{ISO registration-authority NBS FTAM( ) constraint set name(5) Sequential

Flat(l)}

Additional Constraints:

FileDirectory Files may be Selected, Opened, Read, Closed, Created, and

Deleted. They may not be Written or Modified (except as a side-effect of

actions performed on individual files contained within a FileDirectory).

DataUnits within a FileDirectory may only be accessed sequentially.

Abstract Syntax:

An indefinite series of data units. Each data unit contains one data element

of type FileDirectoryEntry. Each data element consists of a required FileName

and a number of optional Attributes.

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(3) f iledirectory

entry(O)

}

Transfer Syntax:

An implementation supporting this data type shall support a transfer syntax

for each data value obtained by applying ASN.l Basic Encoding Rules to the

data type FileDirectoryEntry in the data value and concatenating the resulting

octets

Note: This transfer syntax is not self -delimiting

159
Implementations may also support other named transfer syntaxes for this

abstract syntax.

Transfer Syntax Name:

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Concatenation:

A document of this type cannot be concatenated with a document of this type or any other type.

Simplification:

A document of this type cannot be simplified.

160
Part 2: Constraint Sets

Constaint Set Title : NBS-Ordered Flat

Constraint Set Name :

{ISO registration-authority NBS FTAM( ) constraint set name(5)

NBS Ordered Flat(2)}

Field of Application: Files which are structured into a sequence of

individual FADUs and to which access may be made

on a FADU basis by position in the sequence.

Node Names: none

Actions: Locate, Read, Replace, Insert, Erase

Special Action Parameters: none

Special Action Semantics: Erase: Used on the root node to empty the file.

When used on a leaf node, it leaves a FADU with no associated data unit.

Insert: Allowed only at end of file. The new

node is inserted following all existing

nodes in the file or on a leaf node with

no existing data unit. The inserted

data unit is asociated with the

currently existing leaf node.

Available Access Contexts: HA, FA, UA, US

Erase and Locate Context: HA

Constraints on Structure: 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.

Creation State: Root node without an associated data unit.

FADU Identity: begin, end, first, last,

current, next, previous,

traversal number (greater than or equal to one)

Location After Open: root node

Beginning of File: root node

161
End of File: No node is selected. Previous gives the last

node in the traversal sequence, current and next

result in an error.

Constraint Set Title : Indexed Flat

Constraint Set Name :

{ISO registration-authority NBS FTAM( ) constraint set name(5)

NBS Indexed Flat(l)}

Field of Application: This constraint set is for representing single

key ISAM files where the keys are the FADU

identifiers for the leaf nodes. The keys are restricted to being single primitive data types,

and restricted to all keys being of the same primitive data type.

Node Names: Any single primitive data type.

ActionsLocate, Read, Replace, Insert, Erase

Special Action Parameters: none

Special Action Semantics: Locate: The specified FADU is made the current

FADU. If the FADU Id form is used, the

least recently inserted FADU with the

specified FADU at level 1 is located.

Read: Allowed at root and leaves. If there

is another FADU after (in pre-order

traversal order) the one read with the same FADU Id, a diagnostic on TRANSFER_END will indicate this fact.

Insert: Insert the specified FADU (level 1 only)

in the lexical order of the key

primitive data type. Ifthere is already

another FADU with the specified FADU Id,

insert the new one after (in pre-order

traversal) the existing FADUs and

indicate that this was done via a diagnostic on TRANSFER_END.

Replace: Allowed only at leaves and only in access context US (DU only w/o

delimiters). Only allowed with write

operation of "current" (i.e., preceded

by locate) or "Previous" (i.e.,

preceded by read).

162
Erase: If the addressed FADU is the root, the

file is reduced to the initial state.

Available Access Contexts :

Erase and Locate Context :

Constraints on Structure :

Creation State :

FADU Identity :

Location After Open :

Beginning of File :

End of File:

HA, FA, UA, US

HA

The root node shall not have an associated data

unit or/ and FADU Id. All children of the root

node shall be leaf nodes and shall have an associated data unit and FADU Id. All arcs from

the root node shall be of length one. Some

primitive types may not be supported as keys.

Root node without an associated data unit or FADU Id.

begin, end,

current, next, previous,

FADU Id

root node

root node

No node is selected. Previous gives the last

node in the traversal sequence, current and next

result in an error.

163
Part 3: Abstract Syntaxes

Abstract Syntax : NBS -AS

Abstract Syntax Name ;

{ISO registration-authority NBS FTAM( ) Abstract Syntax(2) Basic(O)}

Abstract Syntax Definition :

DE :: Choice{INTEGER,

BOOLEAN,

IA5String,

8859String,

OCTETSTRING,

UniversalTime

,

GeneralizedTime

,

Null}

8859String :

: = [ PRIVATE 1] Implicit 8859CharacterString

Transfer syntax name: -- 8859CharacterString is a string of characters from

the ISO 8859 character set

{ISO registration-authority NBS FTAM( ) Transfer Syntax(A) NBS-TS1 (0)}

Abstract Syntax : NBS-AS2

Abstract Syntax Name :

{ISO registration-authority NBS FTAM( ) abstract syntax(2) FloatingPoint( 1 )

}

Abstract Syntax Definition :

Float ingPointNumber ::= [PRIVATE 0] CHOICE

{

finite [0] IMPLICIT SEQUENCE

{

Sign,

mantissa BITSTRING,

exponent INTEGER

},

infinity [1] IMPLICIT Sign,

signalling NaN [2] Implicit NaN,

quietNaN [3] IMPLICIT NaN, zero [4] IMPLICIT NULL

}

Sign ::= INTEGER ( {positive(O) , negative(l)}

NaN ::= INTEGER

Transfer Syntax Name :

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

164
Abstract Syntax : NBS -AS

Abstract Syntax Name:

{ISO registration-authority NBS FTAM( ) abstract syntax(2)

FileDirectoryElement(2)}

Abstract Syntax Definition:

FileDirectoryEntry ::=[ PRIVATE 2] IMPLICIT SEQUENCE

{

fileName Graphicstring,

ContentsType}

ContentsType : : =CHOICE

document-type-Name[0] IMPLICIT OBJECT IDENTIFIER,

constraint-set-and-abstract-syntax [1] IMPLICIT SEQUENCE{

constraint-set-Name [ 0 ] IMPLICIT OBJECT IDENTIFIER,

Abstract - syntax-Name [ 1 ] IMPLICIT OBJECT IDENTIFIER}

Transfer Syntax Name:

(ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

165
Part 4: Transfer Syntaxes

Transfer Syntax : NBS-TS1

Transfer Syntax Name ;

{ISO registration-authority NBS FTAM( ) transfer syntax(3) NBS-TSl(O)}

Encoding Rules :

ASN.l Basic Encoding Rules shall apply.

The first bit of a "mantissa" must be "1".

Transfer Syntax Definition :

The transfer syntax shall be that which results from applying the encoding

rules described above to the individual data elements.

166
APPENDIX E: KNOWN ERRORS IN ISO AND CCITT DOCUMENTS

This appendix lists errors that are known in ISO and CCITT documents. Known

errors are removed from this appendix when corrected text is available from

ISO and CCITT. This appendix is for information only.

FTAM DIS Errors

Following is a list of known errors in the FTAM DIS which are expected to be

corrected in the forthcoming IS. These errors are listed here for information

only and will be removed when the IS text is available.

1. The Access Context parameter on the F-READrequest and F-WRITErequest is

specified as OPTIONAL instead of mandatory in the FTAM protocol abstract

syntax.

The expected correction is to make this parameter mandatory.

2. The Contents Type List is defined as a SEQUENCE of Document Type Name and

Constraint-Set, Abstract-Syntax in the FTAM protocol abstract syntax.

The expected solution is to use the following definition:

Contents-Type-List IMPLICIT SEUENCE OF CHOICER

document -types [0] IMPLICIT Document-Type-Name,

constraint-set-and-abstract-syntax[ 1 ] IMPLICIT SEQUENCE

constraint-sets [0] IMPLICIT Constraint-Set-Name

abstract-syntax [1] IMPLICIT Abstract-Syntax-Name}

3. The processing-mode parameter on the F-OPEN request is not defined

correctly in the FTAM protocol abstract syntax.

The expected correction is:

processing-mode [0] IMPLICIT BITSTRING {

read (0),

insert (1),

replace (2),

erase (3),

extend (4) }

4. In part 2 clause 5.3.2 the application tags conflict with tags in part 4

in the protocol abstract syntax.

The expected correction is to use the following definitions in part 2 clause

5.3.2:

Node-Descriptor-Data-Element ::= [Application 21] IMPLICIT...

Enter-Subtree-Data-Element ::= [Application 22] Implicit Null...

Exit-Subtree-Data- Element ::= [Application 23] IMPLICIT Null...

167
5. An object identifier for the CASE protocol abstract syntax is not defined.

The expected correction is:

{iso standard 8650 abstract syntax (1) acse (1)}

168
ADDENDUM 1

Note on ETAM and X.400 Character Sets

On July 21, 1986, a group of twelve individuals from the FTAM and X.400 SIGs

met to resolve differences in recommended use of character sets. The

following was agreed (in favor, 9; opposed, 2; abstaining, 1) by these

individuals

"Both SIGs should implement IA5 for the current phase of development, and

independently support expanded character sets. It is recommended that the

FTAM and X.400 SIGs support both 8859/1 and 6937/2 in the next phase of their

agreements .

Neither SIG brought forward to the plenary on Thursday, July 24, 1986, a recommendation on this issue. However, it was raised for plenary discussion.

The plenary felt (in favor, 22; opposed, 3; abstaining, 1) that this

information should be carried in some form in this document in addition to

inclusion in the minutes. Hence, it is included as an addendum so as to keep

the information associated with this document while showing that it has not

been accepted for inclusion in the main body of this document.

169
Index

ADDRESSING 26

ADMD . . 78, 79, 80, 94, 107, 108, 110, 111, 112, 113, 114, 116

Administration Management Domains 79

Basic Activity Subset (BAS) 78

BASIC IPM Services 82

BASIC MT Services 82

BodyParts 96, 97, 99, 100, 138

CCITT X.25 78

CEPT Profile 112

Checkpoint size 104

CONFORMANCE 120, 121

CONNECTION MODE NETWORK SERVICE (CONS) 12

CONNECTIONLESS NETWORK SERVICE (CLNS) 11

CONNECTIONLESS TRANPORT . 35

Connectionless transport protocol 30

CONS Using X.25/PLP 13

Directory 78, 118, 119

Dynamic Routing ..... 27

EncodedlnformationTypes 90, 97, 116, 117, 118

ESSENTIAL IPM Optional user facilities 82

ESSENTIAL MT optional user facilities . 82

Extensionldentif ier 90, 112

GENERAL INFORMATION 1 GENERATABLE 87

Interpersonal Messaging Protocol 79

Intra-Domain Routing 115

Lower Layer SIG 4

Management Domains 79, 111

MANDATORY ....... 87

Manufacturing Automation Protocols 78

MAP . 78

Maximum number of recipients 88

MDs Ill

MESSAGE HANDLING SYSTEM 78, 132

Message Handling Systems 131

Message Transfer Protocol 79

MPDU Size 88

MT-Service 81

MTL 80, 81

Multi-Vendor Domains 115

Naming authority 117

Negotiation 10^

Network Dependent Convergence Sublayer Function 17

NON- SUPPORT 81

NSAP address format 79

NTT Profile HI

0/R Name 94, 110, 111, 112, 113, 115, 116

OSI Reference Model '8

170
PI . 79, 80, 81, 87, 89, 90, 91, 92, 97, 109, 110, 111, 113, 114, 118, 120,

121, 135, 137

P2 79, 80, 81, 82, 87, 95, 96, 97, 99, 100, 109, 110, 115, 120, 121, 134,

135, 138, 141

Password Management 115

Plenary 2

POINTS OF CONTACT 6

Pragmatic constraint limits 113

Presentation Transfer Syntax 107, 132

Printable String 88, 140

Private Management Domains 79

PRMD . . 78, 79, 80, 82, 92, 94, 107, 109, 110, 111, 112, 113, 114, 119, 134

Reliable Transfer Server 101, 132

REQUIRED 87

ROUTING 26, 78, 112

RTS 101, 102, 104, 106, 107, 115, 120, 121, 138

Semantic validation 113

Session 79, 102, 106, 107, 130, 132

Special Interest Groups 2

Static Routing 27

Subnetwork Dependent Convergence Protocol 20

SUPPORT 81

SUPPORTED 87

Technical and Office Protocols 78

TOP 78

TRANSPORT 30

Transport class 0 1 30

Transport class 4 30

TSAP selector 38

UAL 80, 81

UNSUPPORTED 87

User Agent 79, 80, 82, 132

Window size 102, 104

X. 25/PLP-1984 15

X.409 104, 107, 113, 116, 132, 139, 140

171
.

.
You will receive the documents from the next workshop by either attending the

workshop or completing and returning the form below.

READER RESPONSE FORM

Please retain my name for the next mailing of the NBS/OSI Implementors

Workshop

NAME

ADDRESS

PHONE NO.

Mail this page to: Mary Lou Fahey

National Bureau of Standards

Bldg. 225/B217

Gaithersburg, MD 20899

172

NBS-114A (rev. 2 »ec) U.S. DEPT. OF COMM.

4. TITLE AND SUBTITLE

Implementation Agreements for Open Systems interconnection Pjrotocols

5. AUTHOR(S)

John Heafner, Editor

BIBLIOGRAPHIC DATA

1. PUBLICATION OR

REPORT NO.

NBSIR 86-3385-2

2. Performing Organ. Report No, 3. Publication Date October 1986

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

7. Contract/Grant No.

8. Type of Report & Period Covered

Gaithersburg , MD 20899 |_

9.

SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City, State, ZIP)

10.

SUPPLEMENTARY NOTES

~1 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

bibliography or literature survey, mention it here)

This document records current agreements on implementation details of Open

Systems Interconnection protocols among the organizations participating in

the NBS/OSI Workshop Series for Implementors of OSI Protocols. These

decisions are documented to facilitate organizations in their understanding of the

status of agreements. This is a standing document that is updated after each

workshop (about every two and one-half months). A reference list of standards

and a list of contributing organizations are included in the Appendix.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s

)

local area networks; NBS/OSI Workshop; network protocols; Open systems

interconnection; OSINET; testing protocols

13. AVAILABILITY

| | Uni imited

[~Xl For Official Distribution. Do Not Release to NTIS

Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

15. Price

USCOMM-DC 604S-PS0
*

-

'